Partager via

What is Fallback and What Does it Mean?

  • Article

This question seems to come up frequently when I am working with a customer.  It's no wonder to me that people can get confused about "fallback".  We have a Fallback Status Point, fallback for content location, and Fallback Site for Client Assignment.  Each one of these "fallback"'s are very different from each other and can be easily mixed up.  Let's start by examining each type of "fallback" and what it does.

 

Fallback Status Point

The Fallback Status Point (FSP) is a role is used to receive State Messages from clients, similar to a management point (MP).  The difference is that only certain types of state messages are sent to a FSP, in particular messages related to client installation, client site assignment, and clients unable to communicate with their HTTPS MP.  There are built-in reports that can be leverage to view the data the is received by the FSP.  However, adding the FSP role itself is not enough, clients must be configured to use the FSP.

The following log snippets are from a ccmsetup.log where the client has not been passed the FSP= property during client installation.

Notice that the FSP: line is blank.

Here you can see that because a FSP was not defined, the state messages (100, 400) from the ccmsetup.log were not forwarded anywhere. 

The next set of snippets are from the ccmsetup.log where the client is passed the FSP= property during client installation.

Notice that the FSP line is no longer blank and contains the FQDN of the server holding the FSP Role

Now we can see that the State Messages were indeed forwarded to the FSP for processing

 

There are various reports available for viewing the results of the data processed by the Fallback Status Point.  They are located in the "SMS - Client Information" category in Reporting Services.  The ones related to Client Installation and Site assignment are:

  • Client assignment detailed status report
  • Client assignment failure details
  • Client assignment status details
  • Client assignment success details
  • Client deployment failure report
  • Client deployment status details
  • Client deployment success report

 

Fallback Site

The next "Fallback" to discuss is using a "Fallback Site".  I recommend using caution when enabling this feature.  It can lead to unexpected results if its not used properly.  In Configuration Manager 2012, simply creating boundaries is not enough.  It order to define a boundary to be used for Site Assignment it must be added to a Boundary Group that is enabled for Site Assignment.  The Fallback Site allows clients that are installed using the SMSSITECODE=AUTO installation property to be assigned to the Fallback Site if they are not located in a boundary that is associated with a Boundary Group that is enabled for Site Assignment. 

You can enable a site to be used as a fallback site under Administration -> Hierarchy Settings as seen below:

 

 

Fallback for Content Location

Finally, let's dive into the "fallback" for content location feature.  Essentially, this feature is designed to allow client to gain access to content that is not available on a Distribution Point (DP) that is located in their Boundary Group.  If this feature is not implemented correctly, it can lead to unexpected results and high network utilization over remote WAN links. For some types of deployments, this option is enabled by default.

Let's take a step back and talk about Configuration Manager design.  One best practice of design is to minimize network bandwidth utilization.  One of the ways to do this is to place DP's near the clients that will be pulling content from those DP's.  Normally the design should be such as to reduce or limit the amount of traffic that is traversing the organizations WAN links.  In some cases, this is not always possible (i.e. clients connected over VPN).  

When you install the DP role, the wizard prompts for Boundary Group membership.  One the lower half of the screen, you will notice a selection check box (on by default) the is used to determine whether or not this DP should be set to "Allow fallback source location for content" . 

When this box checked, it allows clients that are not in the Boundary Group(s)  that the DP is associated with to still obtain content from this DP. In some cases, particularly if this DP is in a remote office, this may not be the desired results. Let's look at the following example.

 

In the diagram below, we have a simple design with a DP located in the Headquarters site (HQ) and a DP located in each remote office (Remote A and B). Each location is its own Boundary Group with its own DP assigned. When the DP for Remote B was installed, the "Allow fallback source location for content" box was left "checked" thus enabling this DP to allow clients not in its boundary group to obtain content.

A deployment was created and targeted to clients in Remote A.  However, the content was never added to the DP in Remote A, since Remote B's DP is enabled for fallback, all the clients in Remote A are returned Remote B as a source location for content and begin to download content from the Remote B DP.  Depending on the size of the content, this can quickly saturate not only Remote A's link back to HQ but also impact Remote B's link.  We have now created a situation with undesired results and could possibly impact business operations. 

If you plan to use the option to "Allow fallback source location for content", make sure you carefully plan which DP's have this option set.  It will normally be DP's that are located in your headquarters locations or data centers. 

In addition to setting the DP to allow fallback,  there are additional settings on Application, Packages, Software Updates, and Task Sequences that determine whether or not that particular Deployment or Deployment Type should be enabled to use the fallback source for content location. (An example of a Deployment Type show below)

This allows us now to design a strategy for leveraging the capability of using "Allow fallback source locations for content" on a per-deployment basis.  There are some designs that may call for us to have DP's designated for allowing fallback and where critical deployments are configured to allow for fallback.  Such use cases would include certain business critical applications or Software Update that needs to be installed on clients even if the content is not available on the DP in their boundary group.  Be aware of the size of the deployments that are set to allow fallback.  Content that is less than 100MB in size is going to have a much different impact than content that is greater than 500MB in size.

Comments

  • Anonymous
    August 24, 2016
    excellent thank you so much
  • Anonymous
    October 27, 2016
    Great article. This definitely clears the confusion..
  • Anonymous
    May 07, 2017
    Very helpful, thanks!
  • Anonymous
    March 30, 2018
    Nicely describe clear all the doubts. Thanks...