On Demand Content Distribution / Fallback Distribution Points – A 2012 Configuration Manager Micro-Deep Dive
Welcome to 2013 – It’s a new year and an exciting time here at neilp central. I have several larger Configuration Manager and Orchestrator projects that I will be tackling this year; all of which will be detailed in this blog. In addition to these ‘Mega Solution Posts’, I hope to be knocking out more frequent product micro-deep dive’ quick reads. In these posts I will take a close / deep look at specific aspects of the Configuration Manager product. We will see how it goes, hopefully very well.
To get these Micro-Deep Dive’s kicked off, I present, On Demand Content Distribution – A 2012 Configuration Manager Micro-Depp Dive. In this post I will be examining what on demand content distributing is, examining the behavior of on demand content distribution from both the distribution point perspective as well as the clients, and finally looking at the relationship between on demand content distribution and fallback distribution points (there is some overlap / play between the two). I will be exploring On Demand Content Distribution through the examination of the following content location examples –
- Scenario 1: Fallback and Content on Demand are both Disabled
- Scenario 2: Fallback Enabled, Content on Demand Disabled
- Scenario 3: Fallback and On Demand Distribution Enabled
- Scenario 4: Fallback Disabled, On Demand Enabled
It is worth pointing out that the following tech net article provides a very good overview of each of these scenarios. My intent here is to expand on the TechNet article with a more hands on look into the console configuration, log tracing, and behavior observation.
Planning for Content Management in Configuration Manager - https://technet.microsoft.com/en-us/library/gg712321
On Demand Content Distribution – what is it?
For most, if not all pieces of content that require distribution to one or many distribution points, we have the ability to flag ‘Distribute the content for this package to preferred distribution points’. In essence if a client requests content that has not already been distributed to the clients preferred distribution point(s), when this flag is selected, this content will then be auto-distributed to those preferred distribution point(s). This could be helpful if you have a large amount of packages that are only sporadically requested. Instead of populate every distribution point with every package, let On Demand Distribution figure out an appropriate distribution pattern. This process is very straight forward however there are a few gotchas to be aware of specifically around the inclusion of a Fallback Source DP and/or depending on the purpose of a specific deployment (available / required).
On the back end there is not much to configure. For each Application / Package on which you would like to enable On Demand Content Distribution, select the check box next to ‘Distribute the content for this package to preferred distribution points’. Once a client has requested access to a package (and it is not already on the clients preferred distribution point), the management point ‘intercepts’ the requests and creates a .DMD file in the Distribution Manager incoming inbox.
We can see the contents of the DMD file contain the package ID and the preferred distribution point to be populated.
Once processed we can observe in DISTMGR.LOG the On Demand Content Distribution process.
The result of this process is a preferred distribution point which will be populated with the requested content that will the be available for all clients preferring the distribution point.
Fallback Source DP – what is it?
If a client requests content, and this content has not already been distributed to the clients preferred DP, we also have the ability to enable the clients to use a fallback source location. A fallback source location is simply a distribution point that has been configured with ‘Allow fallback source location for content’. This will allow clients not located within the distribution points assigned boundary group to download content from the distribution point. In order for a client to located a package on a fallback distribution point, each package needs to be enabled with the 'Allow client to use a fallback source location for content'.
Fallback Source DP’s can be helpful when DP infrastructure has gone down, when urgent software needs to be distributed ASAP however has not had an opportunity to fully distribute to all DP’s, or in any case when you want to give clients the opportunity to located content on a non-preferred distribution point. The caution here is that in many circumstances the Fallback Source DP will be located across a wide area network from the client. It would be best to selectively enable the use of Fallback DP’s.
Scenarios:
As discussed, I will highlight four scenarios here. In each of these scenarios the client is requesting content that has not been distributed to the client preferred distribution point.
Scenario 1 – Fallback and Content on Demand are both Disabled
This scenario is only being examined in order to set the stage as to what happens if content has not been distributed, and neither Content on Demand, nor Fallback DP’s being utilized. It goes without saying that the deployment will fail, but for completeness sake, and also to set the stage for the remaining scenarios, I am including the screenshots and logging in this post.
Application Distribution Settings:
Deployment Types Content Settings:
After the attempted execution of the application, we can see in CAS.LOG that no distribution points containing the content have been found. Even though the content has been distributed to one of the two distribution points in this configuration manager site (not preferred for this client), because the use of Fallback DP’s has not been enabled, this client will not be able to access this content and the installation will fail.
Scenario 2 – Fallback Enabled, Content on Demand Disabled.
This scenario is also self-explanatory, but for completeness sake, here it is.
Application Distribution Settings:
Deployment Types Content Settings – notice here that unlike scenario one, I have enabled the use of Fallback DP’s.
After a successful execution, we can trace CAS.LOG and see that the content was found on one distribution point and if we look closely will also note that the distribution point is “REMOTE”. Because the content has not been distributed to the clients preferred distribution point, and the fact that the deployment allows for fallback, the software installation has succeeded using the Fallback (Remote) DP.
Scenario 3: Fallback and On Demand Distribution Enabled – Here is where things get interesting.
In this scenario I will be enabling On Demand Distribution and Fallback content access. The results of my testing here were not necessarily what I would have expected.
Application Distribution Settings - This is the first scenario in which I am demonstrating this setting.
Deployment Types Content Settings – once again, fallback is enabled.
When the first client using the non-populated distributing point requests access to the deployment content, this content is not found on the preferred DP, since fallback is enabled the client receives the content from the ‘remote’ or fallback DP.
At almost the exact same time (compare time stamps in the two screen shots) the on Demand content distribution process begins; the .DMD file is dropped, and the package content is distributed to the initial requesting clients preferred DP.
Finally when any additional clients requests the content after the preferred DP has been populated, the content will come from the preferred DP and not the Fallback DP.
The takeaway here is that in a configuration in which both on demand content distribution and Fallback DPs are enabled, it is possible that one or more clients will still access the content from the Fallback DP and potentially across the slow Wide Area Network. If this is a concern, ensure that Fallback DP is not enabled for the particular deployment.
Scenario 4: Fallback Disabled, On Demand Enabled – Still some interesting things going on here.
In this scenario only Content Distribution on demand has been enabled for the package / application. Fallback source location has not been enabled for the deployment. As we will see, in this configuration, the behavior at deployment time differs based on the deployment purpose (Required of Available).
Application Distribution Settings:
Deployment Types Content Settings:
When a deployment has been marked as a purpose of Required, I have observed the following behavior (as described in the TechNet article noted in this post).
In CAS.LOG we will see a download request, however the deployment does not execute.
Over on the application side (site server) we can see that the .DMD file has been dropped and that the On Demand distribution of content has begun.
Once an hour the client will make an additional content request. Once the content has completed distributing to the preferred distribution point, and the clients makes the subsequent content request, the content will be found and the application installation etc. will complete.
AppEnforce.LOG showing the application execution:
Now, when the deployment has been made available the story is a bit different.
In this configuration the first client requesting the content will fail to find content, however instead of going into an hourly retry cycle, the deployment will fail completely. The on demand content distribution process will kick off, and once completed, a manual re-execution of the available deployment will complete successfully.
At the same time as the application deployment failure on the client, server side the On Demand Content Distribution process will begin.
Conclusion:
While this is in essence a very simple process, through some digging and scenario tracing, some behavior is surfaced worth noting. Most notably –
- When both Fallback DP and On Demand Distribution are enabled for a deployment, the clients will use Fallback until the On Demand distribution process has completed for the clients preferred DP.
- When using On Demand Distribution and no Fallback, an available deployment will fail and require manual re-execution once the On Demand distribution process has completed for the clients preferred DP.
Hope you have enjoyed the post, as always please leave feedback and sign up for my twitter feed using the button located on this page.
Comments
Anonymous
January 01, 2003
This blog is as good as it gets. ThanksAnonymous
January 15, 2013
Nice blog!!! <a href="www.revenue-performance.com/Distribution.html ">distribution management </a>Anonymous
January 24, 2013
Good Blog !!Anonymous
October 04, 2013
Thanks. Very good and Micro deep-diveAnonymous
January 16, 2014
super cool !!!!Anonymous
February 05, 2014
Good gear!!Anonymous
April 10, 2014
Great blogAnonymous
May 15, 2014
Great PostAnonymous
May 28, 2014
The comment has been removedAnonymous
September 30, 2014
Hey this is some great information....one issue I see with using Fallback Content for application source is that from my understanding that it then enables the content on slow or unreliable networks (eg. RAS/Home users) where ideally you may not want any content being deployed as it may affect users experience while working remotely...it seems to be an all or nothing option here.Anonymous
February 07, 2015
good and fed to my thirstyAnonymous
January 20, 2016
Vey helpful and clear explanantion