Previous Section
 < Day Day Up > 
Next Section


Developing Site Hierarchies

In Chapter 2 you learned about the importance of developing a viable deployment strategy for SMS 2003. A significant part of that design process should include determining the kind of site hierarchy—if any—that 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.32 shows 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.

Click To expand
Figure 4.32: SMS hierarchy viewed through the SMS Administrator Console.

SMS sites, as we have seen, are identified by the site boundaries that you assign. Clients are assigned to an SMS site based on either IP subnet or Active Directory directory service site boundaries. 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.33 illustrates an example hierarchy. Contoso, Ltd. 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 Contoso locations because it includes all the IP subnets in its site subnet boundaries.

Click To expand
Figure 4.33: The Contoso site hierarchy, with one SMS site.

In contrast, Figure 4.34 shows the same organization, but this time with individual SMS sites in each region, each reporting back to a central site located at Contoso headquarters in Chicago.

Click To expand
Figure 4.34: The Contoso site hierarchy, with multiple SMS sites.

Many factors and circumstances can affect your site structure strategy. Each must be considered carefully before implementing the hierarchy. These factors are likely to include, but are certainly not limited to, the following:

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’s 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 average size of a full default inventory file—this traffic would total 500 MB once a week and would largely be randomized.

Network traffic concerns are particularly significant when SMS traffic must cross WAN connections. You might ask yourself whether the existing WAN connections are well connected 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 Contoso 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.35. 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 individually within the same site—and generally uncompressed.

Click To expand
Figure 4.35: 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, it generally sends the package to the target site in a compressed format. As illustrated in Figure 4.36, 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 site deployment strategy should already have assessed and predicted how you’ll use SMS and the amount of data that you’ll 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.

Click To expand
Figure 4.36: A package distributed from one site to distribution points in another site.
More Info 

The scenarios suggested here aren’t exhaustive. SMS 2003 introduces new server roles and additional server properties, such as proxy management points and protected distribution points, both of which affect network traffic and server performance in their own ways. For a more detailed discussion of factors that can affect network traffic and server performance, see Chapter 9, “Capacity Planning for SMS Component Servers,” in the Microsoft Systems Management Server 2003 Concepts, Planning, and Installation Guide available from the SMS 2003 Online Library, and on the product CD.

Tip 

Microsoft recommends implementing a single SMS site across WAN links 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 2003 site apply to all the clients assigned to that site—they are sitewide settings. As such, there are no means of installing certain components on one set of clients and other components on another set. For that matter, there are 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 enabled with Remote Tools. If the Do Not Ask For Permission configuration 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 don’t require Remote Tools, or if 100 don’t require permission to establish a Remote Tools session, you can’t accommodate those clients. They must all either have Remote Tools installed or not. They must all either require permission or not. Chapter 10, “Remote Control of Client Systems,” discusses the Remote Tools Client Agent and all its configuration options in more 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 don’t require Remote Tools (or that don’t require permission to establish a Remote Tools session) and to enable Remote Tools appropriately. The same reasoning applies to all the client component options.

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. Each SMS site can potentially handle 10,000 or more clients. But if you think this gives you license to create one large site and be done with it, go back and read the section entitled “Network Performance” earlier in this chapter.

The true number of clients that any one SMS site server can 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 550 MHz Pentium processor, 256 MB of RAM, and a recommended 2 GB of disk space. Let’s say that you have two site servers with this configuration. Suppose you install 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 might suggest the creation of multiple SMS sites depending on the SMS features you’re 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 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 supports a wide variety of language versions in its operating system, so too does SMS 2003 support a wide variety of language versions for both the site server and SMS clients. SMS 2003 site servers support the following languages:

  • Chinese (simplified and traditional)

  • English

  • French

  • German

  • Japanese

Each of these site server languages supports clients in its language, as well as English-language clients, with the exception of French, which doesn’t support 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. The client-side user interfaces have been localized to the local language.

In addition to English, SMS 2003 clients are available in 21 additional language versions:

  • Chinese (simplified and traditional)

  • Czech

  • Danish

  • Dutch

  • Finnish

  • French

  • German

  • Greek

  • Hungarian

  • Italian

  • Japanese

  • Korean

  • Norwegian

  • Polish

  • Portuguese-Brazilian

  • Portuguese-Portugal

  • Russian

  • Spanish

  • Swedish

  • Turkish

For the most part, you can create a site hierarchy with any combination of language versions. Keep in mind, however, that some data that’s recorded in one language version will be transferred between sites in that language version. For example, site code, collection, package, and advertisement names and Management Information Files (MIFs) 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’re using the same code pages, data will be passed on and displayed correctly. If not, the names might 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 appear correctly. If the child site is using a different code page, the default collection names might 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 either in the Name or Comment field of collections, advertisements, packages, and programs properties to provide easier identification. You could also use a separate Windows computer running the SMS Administrator Console with the appropriate code page enabled. Also, be aware that extended and double-byte character names aren’t 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 

The SMS 2003 Online Library, which includes the Microsoft Systems Management Server 2003 Release Notes, discusses language considerations; consult these references for more specific information. If language versions are a concern within your organization, you should also periodically review the Microsoft Knowledge Base articles published for SMS 2003 for references to specific issues you might be encountering (See http://support.microsoft.com and http://www.microsoft.com/smserver for more information.)

Planning 

If you have installed an International Client Pack (ICP) for your SMS 2003 site and are planning to upgrade to an SMS service pack, be sure to upgrade your ICP with the service pack version as well. If you don’t, the ICP files will be overwritten and only English language clients will be supported. Also, in order to correctly process and display characters in the appropriate language in the SMS Administrator Console on a Windows 2000 or higher computer, the Locale Regional Options setting on that computer, located on the Control Panel, must be set to match the language of the data you want to view or input.

Administrative Model

The structure of your organization’s Information Services (IS) support (as well as company policies) will no doubt influence your SMS site structure. Whether or not a proposed SMS site has a designated SMS administrator locally might determine, for example, whether you install a primary or a secondary site at that location. The size and location of the administrative staff might 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 persons 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 2003 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 more 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.

Active Directory Domain Model

Certainly the Active Directory site structure that you’re using within your organization will have a significant impact on the look of your SMS hierarchical structure since you can use Active Directory site names to define SMS site boundaries. Similarly, the domain model that supports your organization will also influence your SMS 2003 hierarchical structure. You might, from an administrative point of view, decide to simply let your SMS structure reflect your Active Directory site structure or domain model. If your organization spent a great deal of thought and planning when implementing its Active Directory site structure and domain model, and it’s well organized and optimized, then following that model for your SMS site hierarchy will make the most sense. However, if your current Active Directory site structure and domain model is less than optimal, you might want to consider cleaning it up before you implement your SMS site hierarchy or choose not to base your SMS hierarchy or your site boundaries on your Active Directory structures.

If you’re implementing SMS in a multiple-domain environment, especially in a mixed mode environment (Active Directory and Windows NT domains), and you’re running SMS in standard security mode, remember that SMS will still require the use of the SMS Service account and several internal accounts to connect between sites and site systems within a site. When multiple domains are involved, and you wish to reference in one domain an SMS account such as the SMS Service account from another domain, you’ll need to understand how trust relationships have been implemented between those domains (especially where Windows NT domains are involved) or create duplicate accounts that Windows can use through pass-through authentication, or both. Refer to your Windows documentation for more detail on the authentication process and how it can affect your SMS sites. Also, refer to Chapter 8 of the Microsoft Systems Management Server 2003 Concepts, Planning, and Installation Guide included with the SMS Online Library for a more detailed discussion of domain-specific issues.



Previous Section
 < Day Day Up > 
Next Section