Holding Sites

Let me introduce the concept of a holding site. This concept is discussed in great detail in the SMS 2003 documents I have referenced at the beginning of this chapter, but I’ll summarize its purpose for you here.

Three groups of computer systems can be SMS clients. Group 1 represents those systems that are fully supported by SMS 2003 and run the Advanced Client, although they also can run the Legacy Client. Group 2 represents those systems that are fully supported by SMS 2003, but whose operating systems don’t support the Advanced Client. These systems generally run the Legacy Client, but they can also run the SMS 2.0 client. Group 3 represents those systems that can only be supported by SMS 2.0 sites and run the SMS 2.0 client.

After evaluating your options, you might choose to drop your SMS support for Group 3 systems. In this case you can simply start with a fresh installation of SMS 2003, set your site boundaries and client installation methods, and let your supported systems be assimilated into the new SMS 2003 site.

A holding site is the SMS 2.0 site that you identify and maintain in the SMS 2003 site hierarchy that helps you to deal with the Group 3 systems and to maintain manageability of existing Group 1 and Group 2 clients until they finish migrating to an SMS 2003 site. It’s a child site of an SMS 2003 site, usually the SMS 2003 central site, and its boundaries overlap with those of the SMS 2003 site to which the SMS 2.0 site’s clients are migrating.

You see, Group 1 and Group 2 clients will natively migrate to the SMS 2003 site when you enable a client installation method, because SMS 2003 fully supports them. Group 3 clients, however, will basically “ignore” the client installation method and remain SMS 2.0 clients. Later, you can choose to continue to manage these clients through the SMS 2.0 site, upgrade them so that SMS 2003 sites can support them, or not support them at all.

I’ve greatly oversimplified the process of migrating clients because the SMS 2003 documentation covers this and other scenarios quite well. (I should know, because I wrote much of it.) But I’ve given you the gist of the process.

Site Data Propagation

If your migration strategy involves upgrading an existing SMS 2.0 site hierarchy to SMS 2003 and you have taken all the necessary steps to ensure a clean transition as outlined earlier in this chapter, your databases should be up-to- date and all information should have been passed up through the hierarchy. Data will continue to propagate between SMS 2.0 sites and their SMS 2003 parents. Data that normally flows down the hierarchy, such as collection, package properties, and advertisements, continues to flow down from SMS 2003 parent sites to SMS 2.0 child sites. Data that normally flows up the hierarchy, such as inventory and discovery information, continues to flow up from SMS 2.0 child sites to SMS 2003 parent sites. However, data unique to the SMS 2.0 child site, particularly software metering data and inventory Managed Information Format (MIF) files from 16-bit SMS 2.0 clients, will be discarded by the SMS 2003 site.

Note

SMS 2.0 SP5 and higher site servers have the capability of signing data that’s propagated to a parent site to make it more secure. SMS 2.0 SP4 site servers don’t have this capability, so their data transfer is less secure. As a result, you might choose to not allow unsigned data from SMS 2.0 SP4 site servers to be propagated to an SMS 2003 parent site. You can do this by navigating to the site properties dialog box of the SMS 2003 parent site and, in the Advanced tab, selecting the Do Not Accept Unsigned Data From Sites Running SMS 2.0 SP4 And Earlier option.