Developing Site Hierarchies
In Chapter 2, you learned about the importance of developing a viable deployment strategy for SMS 2.0. A significant part of that design process should include determining the kind of site hierarchy—if any—you need to implement for your organization. An SMS site hierarchy exists whenever two or more SMS sites have been defined in a parent-child relationship; its structure resembles an organizational flowchart. Site hierarchies provide a means of extending and scaling SMS support across a wide variety of organizational structures. Figure 4-30 illustrates what our completed SMS hierarchy looks like when viewed through the SMS Administrator Console from the central site server. As you can see, the central site has the ability to view and manage any site below it in the hierarchy.
Figure 4-30. The SMS hierarchy viewed through the SMS Administrator Console.
SMS sites, as we have seen, are identified by the site boundaries you assign. Clients are assigned to an SMS site based on either IP or IPX subnet addresses. As such, a multinational organization with locations in different countries could be managed by one large SMS site or by individual SMS sites in each location connected to a central site. Figure 4-31 illustrates an example hierarchy. Awesome Computers has a corporate office in Chicago and regional offices in New York, London, and Tokyo. Each office has its own IP subnet. The single SMS site, located in Chicago, could manage all Awesome Computers locations because it includes all the IP subnets in its site subnet boundaries.
Figure 4-31. The Awesome Computers site hierarchy, with one SMS site.
In contrast, Figure 4-32 shows the same organization, but this time with individual SMS sites in each region, each reporting back to a central site located at Awesome Computers headquarters in Chicago.
Figure 4-32. The Awesome Computers site hierarchy, with multiple SMS sites.
Many factors and circumstances can affect your site structure strategy. Each must be considered carefully before you implement the hierarchy. These factors are likely to include, but are certainly not limited to, the following:
- Network performance
- SMS client components
- Location and number of clients
- International site considerations
- Administrative model
- Windows NT domain model
Let's look at each of these factors in detail.
Network Performance
Network performance issues will no doubt be the single most significant factor in determining what your site structure should look like. Varying amounts of network traffic are generated among SMS site servers, SMS site systems, and SMS clients. Site servers communicate package, advertisement, and site configuration data to their site systems. The amount of traffic that is generated depends on the nature of the data being sent. For example, a site that distributes three packages a day with an average size of 50 MB to 10 distribution points is generating 500 MB of network traffic three times a day. This traffic could be significant on an already crowded network infrastructure. Or suppose that hardware inventory files representing only changes that have occurred are collected from a group of 32-bit SMS clients. If inventory is collected once a week from 5000 clients, the amount of traffic generated is probably not going to be significant. Even at 100 KB per client, the size of a full default inventory file, this traffic would total 500 MB once a week.
Network traffic concerns are particularly significant when SMS traffic must cross WAN connections. You might ask yourself whether the existing WAN connections are fast, reliable, and efficient enough to handle the traffic generated between the proposed SMS site systems or whether it would make more sense to create an additional SMS site at the other end of a WAN connection. Let's return to our Awesome Computers example. Suppose that you need to send a 50-MB package from the site server in Chicago to 10 distribution points in New York, as illustrated in Figure 4-33. This transaction will generate about 500 MB of package distribution traffic across the WAN connection between Chicago and New York because SMS must deliver the entire package to each distribution point within the same site—generally in an uncompressed state.
Figure 4-33. A package distributed from a site server to multiple distribution points.
On the other hand, SMS sends packages from one site to distribution points in another site by sending the package to the target site once and letting the target site distribute the package to its local distribution points. Furthermore, SMS generally sends the package to the target site in a compressed format. As illustrated in Figure 4-34 , the amount of WAN traffic generated for the same package scenario is considerably less—only about 25 MB as opposed to around 500 MB. Your deployment strategy should already have assessed and predicted how you will use SMS and the amount of data that you will be generating within the site. Armed with this information, consider its effect on the current network traffic patterns and volumes, especially across WAN links, when deciding whether to implement one large SMS site or several SMS sites participating in a site hierarchy.
Figure 4-34. Package distribution between different sites.
TIP
Microsoft recommends implementing a single SMS site only if the WAN links are fast and reliable and can handle network traffic within acceptable thresholds (as identified by you, of course).
Client Components
Client component settings within a given SMS 2.0 site apply to all the clients assigned to that site—they are sitewide settings. As such, there is no means of installing certain components on one set of clients and other components on another set. For that matter, there is no means of enabling one set of attributes for a component for some clients and a different set of attributes for the same component for other clients.
The most frequent example of this situation concerns the Remote Tools component. If Remote Tools is enabled as a client agent for the SMS site, all SMS clients will be installed with Remote Tools. If the Do Not Ask For Permission option is disabled for the Remote Tools Client Agent, permission will be required on all clients before a Remote Tools session can be established. In other words, if your site has 1000 clients and 100 do not require Remote Tools, or if 100 do not require permission to establish a Remote Tools session, you cannot accommodate those clients. They must all either have Remote Tools installed or not. They must all either require permission or not. Chapter 10 discusses the Remote Tools Client Agent and its configuration options in detail.
One solution would be to create one SMS site for those clients that require Remote Tools (or that require permission to establish a Remote Tools session) and another SMS site for those clients that do not require Remote Tools (or that do not require permission to establish a Remote Tools session) and to enable Remote Tools appropriately. The same reasoning applies to all the client component options.
REAL WORLD Enabling Client Features as Sitewide SettingsAt first glance, it might seem that enabling client features as sitewide settings is not that big a concern. Consider this case, however: suppose you choose to enable Remote Tools for your SMS site and require that permission at the client be granted before a Remote Tools session can be established. Of course, all clients will be installed with the Remote Tools Agent and all will be required to grant permission before the Remote Tools session can be established. So far, so good.
You also have a need, however, to establish Remote Tools sessions with your Windows NT servers, which are also clients in your SMS site. As SMS clients, they too will have been installed with Remote Tools and will require that permission be granted before a Remote Tools session can be established. The latter setting will cause problems at the servers because typically no user is logged on at a Windows NT server to grant the permission request.
One solution, of course, would be to create a separate SMS site to manage the Windows NT servers. This would involve being able to identify the servers on a subnet or subnets separate from those that the other SMS clients are segmented on. This segregation may also involve a separate investment in hardware and software to install the SMS site server for that site, which may not be practical. Another solution would be to not require permissions at any of the clients in your site—which could raise other security or privacy concerns—or to forgo the use of Remote Tools for your servers altogether.
A third solution might be to require permission but also allow the user to change Remote Tools options at the client. This would let you as the administrator turn off the permission requirement at each Windows NT server. Unfortunately, this solution also lets users modify Remote Tools attributes without regulation, which could pose other Remote Tools problems on a client-by-client basis.
Location and Number of Clients
Another factor that might affect the structure of your SMS site hierarchy is the number and location of SMS clients and resources. Microsoft recommends between 10,000 and 30,000 clients per SMS site. But if you think this gives you license to create one large site and be done with it, go back and read the section "Network Performance" earlier in this chapter.
The true number of clients that any one SMS site server will be able to manage will be dictated more realistically by the server hardware—how powerful it is—as well as by the number of SMS features and options you have decided to enable on that server. The minimum hardware requirements for an SMS site server are a 133-MHz Pentium processor, 96 MB of RAM, and a recommended 1 GB of disk space. Let's say that you have two site servers with this configuration. Suppose you install only the basic site server and enable Remote Tools on one server, and install all options and enable all client components on the other. The resource requirements for the latter site server will obviously surpass those of the former server. It follows logically, then, that the second site server could manage fewer SMS clients than the first site server (perhaps 10 as opposed to 20—which also gives you some idea of how minimal the minimum hardware requirements are).
Location of clients can also be a factor, as it was with network performance. Your site server can easily manage 10,000 SMS clients or more. However, their location in the network may suggest the creation of multiple SMS sites depending on the SMS features you are implementing, the amount of network traffic generated, the efficiency of your WAN link, and the number of clients that need to be managed. For example, suppose you have three regional locations. If these are relatively small offices—say, 10 to 20 clients—with a modest WAN link between them and the corporate SMS site server, you might create a single SMS site, perhaps placing a distribution point, a logon point, and a CAP in each local subnet. On the other hand, if these regional locations had 100 or more clients, you might begin to weigh the possibility of creating separate SMS sites in each location and linking them together into a site hierarchy—depending, of course, on what features (such as package distribution) you have enabled, the size of packages, the frequency of advertisements, and so on.
International Site Considerations
Just as Windows NT supports a wide variety of language versions in its operating system, so too does SMS 2.0 support a wide variety of language versions for both the site server and SMS clients. SMS 2.0 site servers support the following languages:
Each of these site server languages, with the exception of French, supports clients in its language, as well as English-language clients. Note also that English is the default language for the server-side user interfaces for Chinese and Korean site servers, but you can choose to display the local language characters instead. The client-side user interfaces have been localized to the local language. In addition to English, SMS 2.0 clients are available in 23 language versions:
For the most part, you can create a site hierarchy with any combination of language versions. Keep in mind, however, that some data that is recorded in one language version will be transferred between sites in that language version. For example, site code, collection, package, and advertisement names and MIF files will always be transferred in the language version in which they were created. This untranslated information can cause a problem if the parent and child site servers are using different language code pages. If they are using the same code pages, data will be passed on and displayed correctly. If not, the names may appear corrupted.
Default collection names are defined at each site; however, in a parent-child relationship, the default collection names from the parent site overwrite those of the child sites. Again, if both sites are using the same code page to view the default collection names, the names will be displayed correctly. If the child site is using a different code page, the default collection names may be corrupted.
If the site servers are using different code pages, you do have a couple of options. You could use all ASCII characters or a combination of ASCII and the language characters in the Name or Comments field of collections, advertisements, packages, and programs to provide easier identification. You could also use a separate Windows NT workstation running the SMS Administrator Console with the appropriate code page enabled. Keep in mind that extended and double-byte character names are not supported in domain and site server names. When your sites represent a mix of languages, use ASCII characters when naming domains and site servers.
MORE INFO
Both the Systems Management Server 2.0 Administrator's Guide and the Microsoft Systems Management Server Version 2.0 Service Pack 1 Release Notes discuss language considerations; consult these references for more specific information. If language versions are a concern within your organization, you should also periodically review the Knowledge Base articles published for SMS 2.0 for references to specific issues you may be encountering. (See www.microsoft.com/smsmgmt. )
PLANNING
If you have installed an International Client Pack (ICP) for your SMS 2.0 site and are planning to upgrade to SMS 2.0 Service Pack 1, be sure to upgrade your ICP with the service pack version as well. If you do not, the ICP files will be overwritten and only English-language clients will be supported.
Administrative Model
The structure of your corporate Information Services (IS) support (as well as company politics) will no doubt influence your SMS site structure. Whether or not a proposed SMS site has a designated SMS administrator locally may determine, for example, whether you install a primary or a secondary site at that location. The size and location of the administrative staff may also determine the number of child sites in the hierarchy, as well as its depth.
This is a good opportunity to make a recommendation regarding SMS administrative staff. The reality of many corporate environments is that a small number of people manage large numbers of computers and networks and typically fulfill many roles: database administrator, network administrator, mail server administrator, and so on. The role of the SMS administrator is just as significant and time-consuming. As you've already seen, implementing SMS 2.0 is far from trivial. A successful installation requires a significant amount of planning and testing.
The ongoing management of SMS clients and resources, troubleshooting, and maintenance are no less trivial. Therefore, you could recommend that many SMS tasks be delegated to other support personnel. For example, help desk staff might be given the ability to initiate Remote Tools sessions to facilitate their task of troubleshooting client problems. Resource administrators in specific departments might be given the ability to create and distribute packages to users and clients within their departments. Nevertheless, these are administrative tasks, and they make up only a small percentage of the overall management of an SMS site or an SMS site hierarchy.
Windows NT Domain Model
As with earlier versions of SMS, the Windows NT domain model that supports your organization will no doubt influence your SMS 2.0 hierarchical structure. You may, from an administrative point of view, decide to simply let your SMS structure reflect your domain model. This kind of model may or may not be efficient for managing SMS resources. In fact, if your current Windows NT domain model is "messy," you might want to consider cleaning it up before you implement your SMS site hierarchy.
Consider too the issue of Windows Networking Logon Client Installation and Windows Networking Logon Discovery. If either of these two methods is enabled, every domain controller for the domain specified will be assigned the logon point site system role. If your domain model is a single domain with several WAN links, a fair amount of network traffic will be generated across those WAN links to configure and install the domain controllers located across those links if you choose to create a single SMS site. Conversely, the same domain model could result in having domain controllers become logon points for multiple SMS sites if you choose to create an SMS site at each WAN link location.
EAN: 2147483647
Pages: 167