Lesson 2: The Design Phase
Close attention must be paid to site design to ensure an effective systems management strategy. An SMS implementation lacking a well-thought-out design will prove disruptive to users and fail to meet the objectives identified in the needs analysis. As the size of the network increases, so does the importance of a properly designed SMS implementation.
After this lesson, you will be able to
- Create an SMS design that will effectively integrate into the current network environment to provide enhanced systems management capabilities.
- Determine appropriate site boundaries for SMS.
- Analyze an organization's domain and network structure to verify its efficacy as an SMS site.
- Decide how client computers will be organized within SMS sites.
As Figure 9-2 shows, site design defines where site boundaries should be placed. It also defines the site hierarchy, site types (primary or secondary sites) in the hierarchy, and a deployment strategy.
Figure 9-2. The components of a site design.
Defining Site Boundaries
Determining where SMS sites will be defined in an organization requires a thorough understanding of the network's layout and physical constraints. For example, it is important to know how a remote site is connected to a local network, as well as the bandwidth and current utilization of that connection. In most cases, smaller organizations entirely connected by a LAN become a single SMS site. Larger, more distributed companies are likely to contain multiple SMS sites connected into a site hierarchy. Regardless of the organization's size, the site hierarchy should be kept as flat as possible without over-utilizing WAN connections or compromising future network growth. For example, if Windows 2000 Server Active Directory Services is planned or in use, consider a deeper site hierarchy (less flat) to accommodate the structure of the Active Directory.
The SMS implementation team should consider the issues outlined below to determine effective site boundaries.
Physical Location of Computers
Geographically dispersed locations linked by a WAN are excellent candidates for individual sites. This is because site boundaries provide the most efficient use of the network, while network activity is much heavier within a site than between sites. If distributed locations are connected by a fast, under-utilized link such as a T3 or ATM connection, then an acceptable level of performance can be achieved with a single site. The remote side of an under-utilized T1 link can be included in a single site. However, this type of connection can become over-utilized by SMS, depending on the SMS functions that will be supported. A site design in a WAN using one site server will significantly increase network utilization across the WAN connection during inventory collection, online software metering, and software distribution.
Remote networks with unreliable WAN connections to a LAN supporting SMS can be made part of the site hierarchy using the WAN connection. Package data transfer between the site can be accomplished using the Courier Sender, which prevents overwhelming the WAN connection. The Courier Sender allows for SMS package data interchange using removable media rather than the network. In the design phase, any remote networks that will be part of the site hierarchy using the Courier Sender must contain a local primary or secondary site server. The Courier Sender is discussed in Chapter 11.
In most cases, network performance over WANs is slower, and possibly less reliable, than LAN connections. In most environments, it is inefficient to operate a single SMS site that spans geographic locations. However, in the following cases, it is appropriate to support geographically dispersed client computers in a single SMS site:
- Remote users
- Small locations
- Small locations with a fast, reliable WAN connection
Users who work from home or travel with laptops dial in to the site and their computers can be included in the site. The mobile computer and the dial-in server used to establish the connection should be part of the same site.
If a small location, such as a field sales office, has only a few computer resources and no budget for a secondary site server, it may be added to a site at a larger facility. It is important to balance the opportunity costs of poor network performance across the network with the budget needed for a secondary site server at the remote location.
If a small location has a fast network connection, it is reasonable to make it part of a site at a larger facility.
Once site boundaries have been delineated between dispersed locations, each site should be analyzed for the speed of network connections, number of client computers, and other characteristics of the geographic location.
NOTE
There are situations where it is beneficial that a single physical location is divided into multiple SMS sites. This is particularly true of large organizations. This will be discussed later in this lesson.
Network Connections
Typically, LAN-connected computer resources are included in the same site. A site is defined by one or more resource boundaries. A resource boundary is an IP subnet number or IPX network number. Low-performance links within a LAN, however, may necessitate a site boundary within a LAN. In this case, two or more sites are configured with different resource boundaries.
NOTE
A resource boundary can be included in more than one site, but it is not recommended if Windows 2000 Server's Active Directory Service is, or will be, used in the network. Windows 2000 Server does not allow a subnet to be assigned to more than one site in the active directory.
As a general rule, link speeds under 2 megabits per second (Mbps) are considered slow links, while link speeds over 2 Mbps are considered fast. However, link utilization, interference, and the SMS functions supported across a link may require higher bandwidth connections.
All line speeds should be tested in the lab to ensure the various SMS functions will perform adequately over them. For example, will an administrator send a 30-MB package to ten distribution points across a 56-Kbps line? If the answer is yes, the package will be sent ten times, once for each distribution point. In this scenario, it makes more sense to place a site server on the far side of the 56-Kbps link. As a result, the package is sent only once to the remote site server. The remote site server then sends the package to each distribution point across the local LAN connection. Conversely, if inventory is collected once a month, or if very few packages are distributed, then link speed becomes less of an issue.
In summary, for slow links, consider the cost of upgrading the link versus the cost of adding a site server and administrative resources to a remote location. Also, be aware of which SMS and other functions will be used across slow links.
Domain Structure
Existing domain models play a less significant role in determining site boundaries in SMS 2.0 than they do in SMS 1.2. SMS 1.2 sites are based on domain structure without regard to network structure. SMS 2.0 sites are based on the network structure and are influenced by the domain structure. Logon discovery uses domains to find computer resources, and network discovery uses network components such as routers and DHCP servers to find computer resources.
Domain models typically reflect the logical structure of an organization, which may not align with the physical distribution of the network. For example, a company's SALES domain may extend to many geographically dispersed field offices. Figure 9-3 shows the SALES domain split across a WAN connection. The remote site contains a local resource domain as well.
Figure 9-3. A domain split across a WAN connection.
In this example, each field office could contain a BDC in the SALES domain and a local resource domain. Using site servers on each side of the WAN connection and logon discovery for the SALES domain, the SMS core client component evaluates both domain membership and the subnet ID or network number of the client computer. If resource boundaries are distinct for each site, the client computer will then be assigned to the site containing its subnet ID or network number.
While it is not necessary to change an existing domain structure to run an SMS site, it is better to consider the efficacy of the current domain structure before SMS is deployed. It is more difficult to redesign the domain structure after deployment. However, if the domain structure is modified, SMS 2.0 site assignment rules can change to reflect the domain changes.
Novell NetWare does not conform to the Windows NT/2000 Server domain model. Rather, at least one Windows NT/2000 domain is part of the site and NetWare servers are configured as CAPs, logon points and distribution points within the site. So Windows NT/2000 Server supports NetWare bindery servers and NDS volumes as site systems within the site. The NetWare site systems support computer resources running Novell NetWare client redirectors.
Number of Servers and Clients
All hardware limitations aside, one site can contain more than 1,000 logon points, and each logon point can support more than 45,000 client computers. Thus, in a single site, SMS can support over 60 million client computers. SMS does not really impose any limitations on the number of client computers in a single site. The number of client computers and the SMS client computer functions supported by the staff influence site boundaries. In addition, choosing a primary site or a secondary site is affected by the number of client computers requiring administrative support at each location.
NOTE
The information that follows does not include discussions of client computers added to the site from subsites, nor does it deal with network performance issues in detail. Network performance was examined earlier in this lesson.
Small numbers of client computers (fewer than 100) are typically made a part of a secondary site or added to a larger site. Factors include:
- Site server equipment availability
- Site licensing
- SMS feature requirements
If equipment is not available or cannot be justified, then remote client computers should be added to the larger site.
Each location running a site server requires an SMS site license. See the section titled, "Licensing Systems Management Server" in Chapter 1, Lesson 2, "Environment and Terminology."
If SMS usage is limited to hardware and software inventory collection on an occasional basis, or if few packages will be sent, these client computers can be added to a larger site with only minimal impact on network utilization.
A moderate number of client computers (100 to 2,000) in one location is the most difficult to classify for the purposes of defining site server boundaries and selecting an appropriate site server type (primary or secondary). A small number (fewer than 100) of client computers, secondary site servers, or remote WAN-connected primary site servers is typically used. And because local administration is common, 100 to 2,000 client computers usually contain a primary site server. Consider the factors described for a small number of client computers before choosing the appropriate SMS configuration for a moderate number of client computers at a single location.
If there is a large number of client computers at a single location (more than 2000), primary site servers are the best choice. The administrative staff should consider dividing the client computers into multiple sites unless the network is centrally managed. Factors for choosing multiple sites include the following:
- Sufficient staff and equipment for separate sites.
- Adequate processing power and disk space to handle SMS activities in a single site.
- Multiple sites are more fault-tolerant than one large site. If one site in a site hierarchy fails, the failed site can be repaired or even replaced and simply reattached to the site hierarchy. Thus, an entire hierarchy does not have to be rebuilt in the event of a failure within a single site.
TIP
Often in larger organizations, the hardware policy helps to determine how sites will be configured. Some policies call for a large number of smaller servers, while other policies choose very large server platforms to minimize support costs. It is helpful to determine this policy in advance.
Types of Users
Within a site, SMS manages all client computers in a similar fashion. For example, software inventory file collection and client agent installation are configured on a site-wide basis. If there are sets of users in one location with different SMS client agent requirements, it is helpful to make them into separate sites. In this way, only the client computer agents required by a set of users will be installed on their computer resources.
A client computer can be made a member of more than one site. Client agents enabled at two sites will be installed on the client computer. However, the most restrictive settings apply to the settings of the client agents. For example, if the Remote Tools Client Agent is enabled on both sites but one site does not allow the user to modify Remote Tools Client Agent settings, the user will not be able to change Remote Tools settings. Therefore, it is best to assign client computers to only one site in the site hierarchy. Further, it is a good idea to enable Traveling Mode for mobile users so that they are not automatically reassigned to another site in the hierarchy when they log on to a remote site's network.
International Considerations
SMS is available in several languages. Languages running on the site server support the same language on the client computer and, in some cases, other languages. The following list shows the supported site server languages.
- English
- German
- French
- Japanese
- Korean
- Simplified Chinese
- Traditional Chinese
English running on the site server supports all languages on client computers that are supported by Windows NT version 4.0 or later. Korean and French only support their languages running on the client computers in the site. All other site server languages support their language and English on client computers.
NOTE
For more information on how languages affect site design, refer to the section later in this lesson titled "Site Restrictions Based on Site Server Language Code Page Differences" and to the section titled "Multi-languages Site Hierarchies" in Chapter 3 of the SMS Administrator's Guide.
When you have knowledge of these constraints, you can determine the need for site boundaries. For example, if a French version of a site server is required in a site supporting two client computer languages, French and English, then a second site server supporting English will be required for the English client computers.
Number of Sites
In general, it is best to minimize the total number of sites in the hierarchy to reduce complexity. A small company can often use a single site, while a large enterprise will contain many sites. All configurations, however, should be kept as flat as possible, since the deeper the hierarchy, the longer it takes for system-wide changes to be propagated. This will be discussed in more detail later in this lesson under "Designing the SMS Hierarchy."
Corporate Structure
There may be organizational and political factors within the corporation that dictate site boundaries. For example, large corporations may have departmental information systems staff who insist on managing their own site servers even when the physical environment dictates a single site configuration. When it comes to defining site boundaries, this political issue will likely take precedence over any physical network characteristics. Resolving political issues regarding SMS is crucial for the acceptance of SMS and its ultimate success in the organization.
Designing the SMS Hierarchy
Hierarchical design can be approached from the top down (central site to child sites) or from the bottom up (child sites to the central site). While both methods are acceptable, the top-down method is more common and is discussed in this section.
The central site usually includes the information systems (IS) staff responsible for most, if not all, of the organization's computer hardware and software support. In larger organizations, smaller IS units are supported by the main information systems staff.
Once a central site is designated, other sites should be added based on many of the same factors used for determining site boundaries. Additional factors include the availability of administrative resources, the benefits of a shallow hierarchy, the advantages of load balancing across site systems, network application support requirements, and site restrictions based on site server language. Each of these factors will be explored in this section.
NOTE
Read Chapter 11 before finalizing the site hierarchy's design.
Availability of Administrative Resources
The administrative model in an organization will influence the design of the site hierarchy. For example, if the administrators are all located at the company's headquarters, the site hierarchy is usually flat, with a single primary (central) site and a secondary site at each remote location.
Using the needs analysis that was completed prior to the start of the design phase, assess the SMS administrative requirements at each location. For example, determine whether administrators at a remote location will be distributing applications to the client computers through SMS or whether hardware and software inventory collection is the only objective. If the former (software distribution is initiated by local administrators), then a primary site server should be installed. If the latter (only inventory collection is managed and viewed from the central site), then a secondary site server is adequate.
Verify that the administrative personnel responsible for a site, including any subsites, are prepared to support the SMS hierarchy. Before a site hierarchy is implemented, administrative personnel must be trained in using SMS and understand the additional tasks associated with managing an SMS implementation. Even with a distributed administrative model, one or two members of the IS staff should be responsible for the overall site hierarchy.
Benefits of a Shallow Hierarchy
The flatter the hierarchy the less complex systems management will be, and thus the easier it is to maintain the site databases.
From a performance perspective, a shallow hierarchy reports inventory, software metering, and status information faster than a deep hierarchy. Inventory reporting from child site to a parent site can take 24 to 36 hours per site. Inventory at the bottom of a deep hierarchy may take days to be relayed to the central site server. While there are no limitations imposed in the SMS software, if 50 or more sites are reporting to a single site, consider setting up another level in the hierarchy. Otherwise, keep the hierarchical model shallow—one level deep—where all subsites report to a single parent site.
Performance must be balanced with bandwidth utilization and management requirements. If a parent site is used to send a large package to hundreds of child sites, a WAN connection quickly becomes inundated by network traffic. By supporting a deeper hierarchy, a package can be sent to a few subsites directly below the parent site. Then these sites send packages to subsites below them in the hierarchy. A deeper hierarchy supports a distributed management model where remote site administrators manage their own package distribution schedules. An SMS hierarchy running Windows 2000 Server should be deeper rather than flat to take advantage of the Active Directory.
Advantages of Load Balancing
As levels are created in the hierarchy, balance the load between different primary sites. That is, if two primary sites report to the central site, it is best if each site has a similar number of subsites, client computers, and SMS functional requirements. This ensures that both branches in the hierarchy are equally responsive.
NOTE
This is true only if the available network bandwidth is equal across all servers. This illustrates the importance of understanding the underlying network so that performance is consistent with users' expectations.
User and User Group Support Requirements
To support Windows NT/2000 domain users and domain user groups within collection rules, users and groups are enumerated at each site, added to that site's database, and then passed up to the parent site. The complete collection of users and user groups at the central site is not passed back down the hierarchy. Therefore, collection rules are only assigned to user groups that are in a child site's database.
Site Restrictions Based on Site Server Language Code Page Differences
It is critical that you understand the implications of attempting to mix certain site server languages. The issues that arise from mixing languages are a result of code page language differences. A code page is a table of characters, also called a character set, with a numeric index assigned to each character. Different characters within the code page are used by the various language editions of the operating system, SQL Server, and SMS. A code page allows the software to provide support for the character sets and keyboard layouts used in different countries. SMS, Windows NT/2000 Server, and SQL Server must use the same code page for a site to be created.
In a multi-language hierarchy, any collection, package, or advertisement assumes the code page-specific name of the parent site where it is created and appears with that same name throughout the hierarchy. The default collections are a special case, however. Default collections are defined at each local site, but when a child attaches to a parent, the parent site's collection names overwrite the child site's for the default collections. Therefore, to use the local site's language, you must create collections, packages, and advertisements locally.
If data is created at a parent site and sent to a child site using the same character set, the SMS Administrator console at the parent and child site sees the data in the parent site's language, but the data is not corrupted. If data is created at a parent site and sent to a child site using a different character set, then the data is corrupted when viewed in the SMS Administrator console using the child site's character set. In this case, you must configure the parent site's locale on a computer at the child site and use the SMS Administrator console on this computer. Locale is configured from a Windows NT/2000 computer Control Panel's Regional Settings application.
Since default collections remain unreadable, consider renaming them in ASCII only, or in a combination of ASCII and the parent site's language so that they are identifiable in the subsite's code page. Use ASCII only for all details of collections, advertisements, packages, and programs if they must be viewed at the subsites. All languages support similar characters for the first 127 ASCII-compatible characters in the code page.
Choosing Primary or Secondary Site Servers
The factors affecting the design of the site hierarchy influence the selection of primary or secondary site servers as well. Network utilization, however, is not a factor in site server type selection, since primary and secondary site servers both utilize the network to report information to a parent site. Beyond the design issues previously discussed, selecting a site server type should be based on the characteristics of each site server type.
Primary Site Server Characteristics
From the perspective of SMS, the central site is the only site that must contain a primary site server (the central site server). Primary sites may also be administered locally and may contain child sites, whereas secondary site servers do not have these capabilities.
A primary site server is more processor-, RAM-, and I/O-intensive than a secondary site server because it maintains the site database on a SQL Server site system, usually manages more client computers, and may manage additional loads from subsites.
If a primary site server is required at a remote site that cannot support a SQL Server site system, a SQL Server computer at another site can be used to maintain the remote site's database. To implement this solution, the SQL Server computer must have the appropriate hardware to manage the additional site databases, including a fast, reliable network connection to each site system it supports.
Secondary Site Server Characteristics
The main benefit of a secondary site is that it does not require a local site database. Secondary sites are typically implemented in locations with few client computers and limited or nonexistent administrative personnel. They are also appropriate for a remote site connected by low-performance, expensive, or unreliable WANs. A secondary site server must be installed on a Windows NT/2000 Server computer, but the computer does not have to be a domain controller. This site server type may be used as an SMS logon point; CAP; distribution point to collect SMS inventory, install client computers, and distribute software; and a software metering server. If the secondary site server will be used as a software metering server, it should have fast reliable network access to a software metering database site system.
If there are no administrators at a remote location, the location should be configured as a secondary site. While this is not necessary, it is more efficient from a resource perspective. A secondary site does not have administrative capabilities, so it cannot be administered locally.
If resources are not an issue, a primary site should be installed at locations without an administrative staff. The primary site can then be administered either from its parent site or locally. In addition, a primary site can have child sites, while a secondary site must be located at the bottom of the hierarchy. If child sites below the remote location will be necessary in the future, configure the server as a primary site, since secondary sites cannot be upgraded to primary sites.
If parent sites are upgraded, secondary sites can also be upgraded from the parent site. If a parent site has many secondary sites, the upgrade process significantly increases network utilization. However, it is possible to set maximum data transfer rates on addressees and to limit the number of concurrent sends on senders to alleviate this problem. You can also upgrade a secondary site server using files located at the secondary site. See Chapter 11 for details. If SMS 1.2 secondary sites will be maintained in the site hierarchy, an SMS 1.2 primary site server must remain in the hierarchy to manage the SMS 1.2 secondary site servers.
EAN: 2147483647
Pages: 107