SCCM 2007 Fallback Status Point (FSP)

Function

The Fallback Status Point is a new Site System role in Configmgr 2007 that serves 2 purposes.
The initial goal of the Fallback Status Point is to serve as a contact point for Configmgr 2007 clients in native security mode that cannot contact their Management Point because of certificate problems. As we will see in Chapter X “Security and Network Access Protection” native mode requires https and client certificates for communication with the Management Point, Distribution Point, Software Update Point and the State Migration Point. This certificate requirement opens up a potential issue where a client’s certificate gets damaged, deleted or corrupted in one way or another essentially orphaning the client from the Configmgr 2007 infrastructure. The Fallback Status Point can be the lifeline for those clients as it will accept S.O.S. state messages from clients that need administrative assistance to get back in working order.
The second purpose of the Fallback Status Point is to allow for monitoring the state of a client rollout from a central location, based on a bunch of Configmgr 2007 reports. Historically the previous versions of SMS used to have a blind spot during the client rollout. System administrators could analyze some individual logs at the client side but didn’t have a full view of the entire installation process from a central location. This made follow-up during the client rollout stage of an SMS project fairly labor intensive for these sysadmins. This lack of central view made it difficult to detect clients that for instance started, and potentially completed the installation but that did not get assigned to an SMS Site. The Fallback Status Point helps system administrators in a Configmgr 2007 environment to avoid these problems. Configmgr 2007 clients send state messages to their Fallback Status Point after successful deployment another one after successful Site assignment, giving you a detailed overview of your client rollout. This functionality obviously assumes that the client knows where to find his Fallback Status Point.
A Configmgr 2007 client can find the Fallback Status Point by querying Active Directory or because a specific Fallback Status Point was defined during the installation.
As you might have concluded by reading the function description of the Fallback Status Point this is not a mandatory Site System role. Although this role is not really required, it is strongly advised to install one, and depending on your setup the necessity for one might be greater than for other setups. If you plan to use Internet Based Client Management or plan to use Native Security Mode than having a Fallback Status Point is not a luxury.

Type of network traffic

Because Fallback Status Points serve, amongst other things, as the lifeline for clients with certificate problems, and are most notorious for their function in an internet based scenario, it should come as no surprise that the communication protocol of choice is http.

Scalability & Availability

Another interesting question is the placement of your Fallback Status Point(s). There are two approaches to this. The first one is to just put a Fallback Status Point in your Central Site at the top of your hierarchy. Given the fact that the amount of network traffic to the Fallback Status Point is fairly limited, and mainly happens during the initial client rollout, this approach is one approach that should work pretty well in most environments. Another approach that is worthwhile to investigate is to put Fallback Status Points in accordance with your administrative model. In other words, put a Fallback Status Point in every location where you have administrative personnel that will follow-up on client rollout and client health. This makes it easy for Site Administrators to keep an eye on their own environment’s client health and rollout.
Note: The Fallback Status Point cannot be installed on a system that already has a Site System role installed that requires https for its communication protocol.

The above note might influence your Fallback Status Point decision quite a bit. This obviously only impacts sites that operate in Native Security Mode, but you might still want to consider it in your designs to minimize the impact of security mode upgrades in the future. The reason that they cannot be co-located is that Configmgr 2007 installs all Site System roles in the same website. Configmgr 2007 has the option of installing in a different website than the default website, but this is a site wide setting, meaning that all Site Systems would then install their websites in this new “SMSWEB” website, which doesn’t solve our http/https problem. Although you could have separate virtual directories with different http/https settings this is generally not accepted as a good security practice. Conclusion, the Fallback Status Point is generally best installed on a machine separate from the Management Point, Software Update Point or Distribution Point which might increase the cost of having the Fallback Status Point locations based on your administrative model.

Security

Because the Fallback Status Point is most important in internet based client management, and is most likely to be installed in a demilitarized zone, it deserves some extra security attention. The Fallback Status Point is the only Site System in Native Security mode that allows anonymous http connections to be mode. Although all other Site Systems are fairly well-protected using https and by requiring mutual authentication based on client certificates, the Fallback Status Point, because of its function cannot have these stringent security requirements in place. This leaves the Fallback Status Point open for attack.

To mitigate the impact of any potential attack Configmgr 2007 has implemented two ways of mitigation. The first one was covered in the configuration section, this is the throttling of the amount of messages you are willing to accept for this Fallback Status Point. The default settings are rather loose, but you could easily trim these numbers down to something that is more in accordance with your environment. The second way of mitigating the impact of an attack on your Fallback Status Point is to make sure that the firewall blocks all traffic from the Fallback Status Point to the intranet. By configuring the option Allow only site server initiated data transfers from this site system as explained in the adding a Site System section, you can make sure that the Fallback Status Point operates in a pull-only mode. So even if the Fallback Status Point would rollover during an attack it cannot be used as a jumphost to attack the rest of the Configmgr 2007 infrastructure. With these two security precautions configured the Fallback Status Point becomes an uninteresting target for most hackers.