New site systems for the SMS site are defined as site settings for the site. As such, you could consider these site systems to be properties of the site as well. In this section, we will review the site systems that you can define and examine how each becomes a site system for your SMS site. The various site roles that can be assigned to an SMS 2.0 site system are listed here (with abbreviations corresponding to those in Table 3-1):
Each of these roles is supported to a greater or lesser extent depending on the operating system platform the site system is using (Windows 2000 and SMS 2.0 compatability issues are discussed in Chapter 20). Table 3-1 outlines the site system roles supported by each platform.
Table 3-1. Site system roles and their supported platforms
Platform | Role Supported | |||||||
---|---|---|---|---|---|---|---|---|
Site Server | Site DB Server | Logon Point | CAP | Distrib. Point | SWM | SWM DB Server | Comp. Server | |
Windows 2000 (version limited) | X | X | X | X | X | X | X | X |
Windows NT 4.0, Enterprise Edition | X | X | X | X | X | X | ||
Windows NT 4.0, Terminal Server Edition | X | |||||||
Windows NT 4.0, Service Pack 4 or later | X | X | X | X | X | X | X | X |
Windows NT 4.0, Service Pack 3 (x86) | X | X | X | |||||
Windows NT 4.0 | X | |||||||
Windows NT 3.51 Service Pack 5 or later (x86) | X | X | ||||||
NetWare Bindery 3.12 or later | X | X | X | |||||
NetWare NDS 4.1x | X | X | X |
NOTE
CAPs and distribution points created on NetWare NDS servers must be defined in the same container as the logon point volume; otherwise, Windows clients will be unable to access them.
We've already looked closely at installing and configuring the site server and the site database server (the SQL server). Let's now focus on the other site system roles. Some site system roles are assigned by the SMS administrator. The SMS administrator can assign CAPs, distribution points, and software metering servers.
Other site system roles are assigned automatically when another component is enabled. When you first install the site server, it is automatically assigned as a CAP and distribution point. If you install SMS 2.0 using the Express Setup option and the site server is also a domain controller, it is also assigned as a logon point. When a sender is installed on a server, or when the CAP role is assigned to a site system, that site system is automatically assigned the role of component server. A component server is any site system running the SMS Executive service. When a client discovery or installation method is enabled, SMS automatically assigns the logon point site system role to the Windows NT domain controllers for the domain specified by the SMS administrator or to the NetWare Bindery or NDS servers defined by the SMS administrator.
In either case, you must be sure that the proposed site system meets the platform requirements outlined in Table 3-1. In addition, check for space and partition requirements as outlined in the relevant sections later in this chapter for each site system role. For example, both logon points and CAPs require an NTFS partition because of security that SMS 2.0 applies to the directories it creates on those site systems. Clients must be able to access site systems such as logon points, CAPs, and distribution points in order to execute the SMS login script, access advertisements and client component files and configuration updates, write discovery and inventory data, and read and execute package scripts. In large part, SMS 2.0 assigns the appropriate level of permissions, but this does not totally absolve you from checking and testing permissions and access.
PLANNING
If you plan on including NetWare Bindery servers or NetWare NDS servers as site systems, you must first install a connection service for the NetWare servers. NetWare NDS servers require that Novell IntranetWare Client be installed on the site server before you assign any site system roles to them. NetWare Bindery servers require that either Novell IntranetWare Client or Windows NT Gateway Services for NetWare (GSNW) be installed on the site server, with the recommended preference being Novell IntranetWare Client. Of course, you will also need to install the NWLINK IPX/SPX Compatible Transport protocol on the site server. Refer to the Microsoft Systems Management Server Version 2.0 Service Pack 1 Release Notes topic "Supported NetWare Redirectors" for a list of supported redirectors.
SMS 2.0 uses site system connection accounts, also called server connection accounts, to establish communications between the site server and site system services. When you installed SMS 2.0 on the site server, the Setup program created the SMS Service account. Among other tasks, this account is used by the site server to connect to site systems. You can, however, create additional accounts, called SMS Site System Connection accounts, depending on the security requirements of your site. You do so through User Manager For Domains. An SMS Site System Connection account must be a member of the site system's local Administrators group and must be granted the Log On As A Service user right. It should also have the Password Never Expires option selected since service accounts cannot change their own passwords. The site server uses SMS Site System Connection accounts to connect to the site systems to transfer data. In particular, the site server requires SMS Site System Connection accounts for accessing NetWare Bindery or NDS servers.
When you identify and assign site system roles, the site server automatically creates an SMS Server Connection account named SMSServer_sitecode. Site systems such as CAPs and logon points use this account to connect to the site server and transfer data such as inventory and discovery data. SMS creates and maintains this account on its own, so do not modify it in any way. With Windows NT site systems, SMS will attempt a connection first through any existing service connection. It then tries the SMS Site System Connection account if one exists. If the attempt fails, SMS tries the SMS Service account. Typically, SMS will use the SMS Service account because current connections with that account are likely to exist.
The connection process with NetWare servers is similar, but with two exceptions. A NetWare NDS or NetWare Bindery Site System Connection account must be created by the SMS administrator. You must create the account or accounts on the NetWare NDS or NetWare Bindery server first, and then assign the accounts the appropriate level of permissions. For the NDS servers, the accounts must have Admin permissions for the appropriate container object and volume. For the Bindery servers, the accounts must have Supervisor permissions or the equivalent. Then you must identify the account or accounts to the SMS site server as NetWare NDS or Bindery Server connection accounts. If the connection accounts for the NetWare Bindery servers do not exist, however, SMS will then try the SMS Service account before giving up on the connection attempt. If the connection accounts do not exist for NetWare NDS servers, SMS site system management components won't attempt to use the SMS Service account.
After you have created the connection account either through User Manager For Domains or on the NetWare servers, identify the account to the SMS site server using the following method:
Figure 3-19. The SMS Administrator Console, showing the Site System folder selected.
Figure 3-20. The SMS Administrator Console, showing the connection account types for the Site System object.
For a Windows NT connection account, enter the account name in the form domainname\username, and enter and confirm a password, as shown in Figure 3-21. Choose OK.
Figure 3-21. The Windows NT Account dialog box.
For a NetWare NDS connection account, enter the account name and tree reference using the syntax indicated in Figure 3-22, and then enter and confirm a password. Click OK.
Figure 3-22. The NetWare NDS Account dialog box.
For a NetWare Bindery connection account, enter the account name using the syntax indicated in Figure 3-23, and then enter and confirm a password. Click OK.
Figure 3-23. The NetWare Bindery Account dialog box.
Now that you have identified the servers that will become site servers and created any necessary connection accounts, you must tell SMS that the server should be considered a site system. To do so, follow these steps:
TIP
If you need a discovery record for the site system created as a Windows NT share, perhaps because you want to use the Network Trace utility to monitor its health, create the site system as both a Windows NT share and a Windows NT server. Simply assign the CAP and distribution point roles to the Windows NT share site system entry; do not assign any site system roles to the Windows NT server site system entry. Refer to Chapter 7 for details on discovery records.
Figure 3-24. The New Site System options list.
Figure 3-25. The Site System Properties window for Windows NT Server.
Figure 3-26. The Site System Properties window for Windows NT Share
Figure 3-27. The Site System Properties window for NetWare Bindery Volume.
NOTE
NetWare Bindery volumes support the CAP and distribution point roles, but not the software metering server role. They can also be assigned the logon point role by enabling the NetWare Bindery Logon Discovery or NetWare Bindery Logon Client Installation methods.
Figure 3-28. The Site System Properties window for NetWare NDS Volume.
NOTE
NetWare NDS volumes also support the CAP and distribution point roles, but not the software metering server role. They can also be assigned the logon point role by enabling the NetWare NDS Logon Discovery or NetWare NDS Logon Client Installation methods.
The new site system still has to be assigned the role or roles that you want it to play in your SMS site. We'll discuss these roles in the following sections.
Recall that a CAP is an SMS site system and functions as the exchange point between SMS clients and the SMS site server. Components of SMS clients are installed from a CAP. Inventory, status, and discovery information is collected to a CAP. Advertisement information and other client instructions are obtained from a CAP. When a client receives an advertisement for a program, it will also include a list of distribution points at which the client can find the package files.
When the site server is installed, it becomes a CAP by default. Typically, however, you will want to assign other site systems as CAPs and remove this role from the site server to reduce its resource requirements and improve its performance. CAPs are installed through the SMS Administrator Console as a site system setting. To assign the CAP role, follow these steps:
Figure 3-29. The General tab of the Site System Properties window.
Figure 3-30. The Client Access Point tab of the Site System Properties window.
If you want to remove the CAP role from the site server, right-click on the site server, and follow the same procedure you used to assign a CAP role to the site system. In this case, however, you should uncheck the Use This System As A Client Access Point check box on the Client Access tab.
When you enable a new CAP, you have identified a change to the site control information for the site. A new site control file will be created according to the process described in the section "The Site Configuration Process Flow" earlier in this chapter. Recall that during that process, after the new site control file is generated, other components wake up and read the file to determine whether they need to perform any tasks. One of these components is Site Component Manager.
In this scenario, Site Component Manager wakes up and installs the SMS Executive service and the Inbox Manager Assistant thread on the new CAP if it is a Windows NT server. SMS Executive runs Inbox Manager Assistant, which is used to copy inventory files, discovery records, and so on from the CAP to the site server. In addition, the Inbox Manager thread on the site server wakes up and creates the directory structure and share needed on the CAP for both Windows NT and NetWare servers, as shown in Figure 3-31. The directory name and share is CAP_sitecode. This directory includes all the inboxes needed for client agents to write information generated on the client to the CAP, and to write instructions needed by the client from the site server to the CAP. As you can see, the folder names in the CAP directory structure are fairly descriptive of the data that is written.
Figure 3-31. The CAP directory structure, which contains the inboxes needed to write data from both the client and the site server.
Inbox Manager and Inbox Manager AssistantThose of you that come from an SMS 1.2 or earlier environment may recognize Inbox Manager and Inbox Manager Assistant. These two SMS 2.0 threads carry out similar functions to that of the Maintenance Manager thread in SMS 1.2. Like Maintenance Manager, both Inbox Manager and Inbox Manager Assistant are responsible for writing information from the site server to the CAP (Inbox Manager) and from the CAP to the site server (Inbox Manager Assistant), maintaining the integrity of the data and ensuring that it is written to the appropriate inbox on the appropriate server.
Inbox Manager copies client component and configuration information, the site assignment list, advertisements, package instructions, and the SMS_def.mof file (hardware inventory definition) to the CAP. It also copies client data files from NetWare servers defined as CAPs since Inbox Manager Assistant would not be running on these site systems. It wakes up when the site control file changes and when any inbox is written to or modified, and it reports status messages and logs activity in the Inboxmgr.log file if logging was enabled for this thread.
Inbox Manager Assistant copies client data records from the client inboxes on the CAP (Ccr.box, Ddr.box, Inventry.box, Sinv.box, and Statmsgs.box) to their counterpart inboxes on the site server. It wakes up when an inbox on the CAP has been written to or modified, reports its status messages, and logs activity to the Inboxast.log file on the CAP if logging was enabled for this thread.
For example, Ddr.box, Inventry.box, and Sinv.box are used by the client to write discovery data records, hardware inventory files, and software inventory data. Clicomp.box, Offerinf.box, and Pkginfo.box are used by the site server to write client configuration parameters, instruction and offer files for advertisements and packages, and package contents and location information.
CAPs require 27 MB of disk space on an NTFS partition and will generate about 35 MB of network traffic to complete installation. The time the installation takes will, of course, depend on the performance level of your network and on whether the installation will need to take place across a WAN connection. As with all site systems, Microsoft strongly suggests that CAPs be located on the local LAN, or be accessible through a fast and reliable remote connection.
The actual number of CAPs that you create will depend on several factors. Perhaps the most significant factor will be the number of clients that the site manages. Recall that CAPs provide the main point of contact between the SMS client and the SMS site. The CAP provides client component configuration, advertisement, and package information to the client, and it records and relays inventory, discovery, and status information from the client. The more clients managed, the greater the resource requirement on the CAP. From another perspective, the larger the number of packages and advertisements the site generates, the greater the resource requirement will be at the CAP. In other words, there is no cookie-cutter approach in determining the optimum number of CAPs that should be created. You need to monitor resource usage on the CAP itself (using the Windows NT Performance Monitor utility), monitor the network traffic that is generated (using Network Monitor), and consider the needs of the site and your organization.
The distribution point is an SMS site system that stores the package files, programs, and scripts necessary for a package to execute successfully at an SMS client computer. When the site server is installed, it becomes a distribution point by default. As with CAPs, however, you will want to assign other site systems as distribution points and remove this role from the site server to reduce its resource requirements and improve its performance. Distribution points are installed through the SMS Administrator Console as a site system setting.
To assign the distribution point role, follow these steps:
Figure 3-32. The Distribution Point tab of the Site System Properties window.
If you want to remove the distribution point role from the site server, right-click on the site server, and follow the same procedure you used to assign a distribution point role to the site system. In this case, however, you should clear the Use This System As A Distribution Point check box on the Distribution Point tab.
When you enable the new distribution point, you have identified a change to the site control information for the site. A new site control file will be created according to the process described in the section "The Site Configuration Process Flow" earlier in this chapter. However, no SMS components are installed on the distribution point.
The distribution point is not written to until a package is actually distributed. At that time, the Distribution Manager thread on the site server checks the distribution point for the partition with the most free space. On that partition, it creates a shared folder named SMSPkgx$, where x is the drive letter of the partition. The share is a hidden share—a change from earlier versions of SMS. Then Distribution Manager copies the package and program files to a subfolder beneath SMSPkgx$. If in the course of copying packages to the distribution point you begin to run low on disk space, Distribution Manager will find the next partition with the most free space and create another shared SMSPkgx$ folder there. We will encounter Distribution Manager again in Chapter 12.
TIP
If you want or need to specify where the package files will be copied on the distribution point, create the SMSPkgx$ folder and share yourself. Be sure to give your users at least Read access to the folder, and give the SMS Service account Full Control access.
You can also use the Distribution Point tab in the Site Properties window to create what are known as distribution point groups. Basically, distribution point groups let you group your distribution points into more manageable units. Packages can then be targeted to a distribution point group rather than to individual distribution points.
To create a distribution point group, follow these steps:
Figure 3-33. The Distribution Point Group Properties window.
Now when you create a new distribution point or display the properties of an existing distribution point site server, any distribution point groups you created will be displayed in the Group Membership list on the Distribution tab of the Site Systems Properties window, as shown in Figure 3-34, and you will have the opportunity to include the distribution point in one or more of the distribution point groups.
Figure 3-34. The Group Membership list on the Distribution Point tab.
Unlike CAPs, distribution points can be shared among SMS 2.0 sites. This sharing enables you to leverage equipment and place distribution points closer to the users and clients that will need to access them. The most significant resource consideration for a distribution point is disk space. Since you are copying source files and scripts for package installation there, you will need enough disk space to accommodate all the packages. The next most significant resource consideration will be network access and traffic. You can use Network Monitor to track and gauge this factor. This tool can also help you determine when an additional distribution point may be necessary. The amount of network traffic that is generated will depend on the size of your packages, the number of clients accessing the distribution point to execute a program, and whether you scheduled the package to run at an assigned time.
The SMS software metering server is an SMS site system that enables you to track application usage on SMS clients, restrict application usage, and grant or deny licenses for applications running on an SMS client. This feature of SMS requires its own SQL database for storing usage and license data. This site server role is assigned in the same way you assigned the CAP and distribution point roles.
To assign the software metering server role, follow these steps:
Figure 3-35. The Software Metering Server tab.
The complete installation process, including the SMS components that are used and installed and the network traffic that is generated, is covered in detail in Chapter 14. In brief, the License Server Manager thread does most of the work, including creating the Swmtr directory structure and files, sharing the Swmtr folder as Licmtr, loading and starting the SMS_License Server service on the software metering server, and initiating the Install_ODBC process. Install_ODBC installs the Open Database Connectivity (ODBC) support needed to access the software metering SQL database and a local data cache used to collect metered data from the clients. Inbox Manager also gets involved here, creating inboxes in the Swmtr directory. All in all, about 10 MB of disk space is required to complete the installation as well as enough space to store metered data from the clients. The amount of space needed will, of course, vary greatly depending on how many applications you intend to meter and how many clients are involved.
Any site system that runs SMS Executive is considered a component server. As we've seen, the CAP is also considered a component server for this reason. The other type of component server that you may define in your site would support the site server by running senders. Senders are communication routines used by one site server to contact another site server in a site hierarchy in order to transfer information. For example, a child site will send inventory data, discovery data, status messages, and site control information to its parent via a sender. A parent site will send package information, advertisements, collections, and configuration data to its child sites via a sender.
When a sender is installed on another Windows NT 4.0 server (with Service Pack 4 or later applied), the SMS Executive service and all required support files for that sender are copied to the server and the server becomes a component server—a site system for that SMS site. The best example of using a component server effectively in a production environment is when a Remote Access Service (RAS) connection is required or is available as an alternative connection mechanism between two sites. It would probably not be practical or advisable to install the SMS site server on the Windows NT RAS server. The combined resource requirement would no doubt result in reduced performance. So with RAS on one server and SMS on another, the RAS server could be installed with an SMS RAS sender, making it a component server for the SMS site. Outside of this scenario, the network traffic that might be generated between the site server and the component server (depending on the size and number of packages, advertisements, and so on) might counterbalance any positive benefit derived from having the additional sender capability. We'll look at senders more closely in Chapter 4.
The logon point is an SMS site system that becomes the first point of contact between a client computer and the SMS site. Using a logon script (SMSls.bat), the logon point collects discovery information about the client, determines the client's site assignments, and provides the client with a list of CAPs. Actual installation of the client takes place from the CAP.
A logon point is implemented when either Windows Networking Logon Discovery or Windows Networking Client Logon Installation is enabled by the SMS administrator. All domain controllers in the Windows NT domains identified by the SMS administrator will be installed as logon points. It is not possible to install only specific domain controllers, even if the SMS site server is itself only a member server. If you installed SMS using the Express Setup option, both Windows Networking Logon Discovery and Windows Networking Logon Client Installation are enabled by default. If SMS was installed on a domain controller, all domain controllers for that Windows NT domain will be set up as logon points for that site by default. If you installed SMS using the Custom Setup option, by default neither Windows Networking Logon method is enabled.
If you enable the NetWare NDS or NetWare Bindery Logon Discovery method, or the NetWare NDS or NetWare Bindery Logon Client Installation method, you can identify which NetWare servers to install as logon points. All these discovery methods and installation methods will be addressed in more detail in Chapters 7 and 8. For now, let's review the basic steps for enabling these methods and explore the process behind setting up the logon point site system.
To enable Windows Networking Logon Discovery, follow these steps:
NOTE
If you installed the site server using the Express Setup option, this discovery method will be enabled already by default.
Figure 3-36. The Windows Networking Logon Discovery Properties window.
Figure 3-37. The New Windows Networking Logon Point dialog box.
To enable NetWare Bindery Logon Discovery, follow these steps:
Figure 3-38. The NetWare Bindery Logon Discovery Properties window.
Figure 3-39. The New NetWare Bindery Logon Point dialog box.
To enable NetWare NDS Logon Discovery, follow these steps:
Figure 3-40. The NetWare NDS Logon Discovery Properties window.
Figure 3-41. The New NetWare NDS Logon Point dialog box.
To enable Windows Networking Logon Client Installation, follow these steps:
NOTE
If you installed the site server using the Express Setup option, this installation method will be enabled already by default.
Figure 3-42. The Windows Networking Logon Client Installation Properties window.
Figure 3-43. The New Windows Networking Logon Point dialog box.
To enable NetWare Bindery Logon Client Installation, follow these steps:
Figure 3-44. The NetWare Bindery Logon Client Installation Properties window.
Figure 3-45. The New Server dialog box.
To enable NetWare NDS Logon Client Installation, follow these steps:
Figure 3-46. The NetWare NDS Logon Client Installation Properties window.
Figure 3-47. The New NetWare NDS Logon Point dialog box.
As with other site server installations, the enabling of a logon discovery or logon installation method triggers a change in the site control file for that site. Whenever a site control file changes, as we have seen, other SMS components read it to determine whether they need to carry out any changes of their own. In this scenario, SMS Logon discovery managers and SMS Logon installation managers read the modified site control file to determine whether there are any changes that affect them. If you enabled a logon discovery method, an appropriate SMS Logon discovery manager will initiate the process of installing the logon points. Similarly, if you enabled a logon client installation method, an appropriate SMS Logon installation manager will initiate the process of installing the logon point(s). SMS Logon Server Manager actually carries out the installation of the logon point.
SMS Logon Server Manager creates and shares the folder SMSLogon on the logon point, applies the necessary permissions, and copies the appropriate files to that directory structure. These files include the site list, the CAP list, the logon script, and support programs to initiate client discovery and installation routines and detect slow network speeds. About 15 MB of disk space is required, with a corresponding amount of network traffic generated. On Windows NT logon points, an NTFS partition is also required. The time it takes to complete the installation will, of course, depend on when the process takes place, and what other kinds of network traffic are being generated. Also, the number of logon points that need to be installed will affect the time and the network traffic generated. Recall that all Windows NT domain controllers in a Windows NT domain will be installed as logon points.
Each logon discovery and installation method has an SMS Logon discovery manager, SMS Logon installation manager, and SMS Logon server manager. As shown in Figure 3-48, when a change is detected in the site control file, the SMS Logon discovery managers and SMS Logon installation managers wake up and read the file to determine whether the change applies to them. If it does, the appropriate discovery or installation manager creates a *.pcf file in the appropriate SMS Logon server manager's inbox. This file contains the files required for performing logon discovery and a list of discovery properties, or the list of files required for logon installation. When this file is written to Logon Server Manager's inbox, Logon Server Manager wakes up, reads the files, and proceeds to install the Logon Point.
On Windows NT logon points, SMS Windows NT Logon Server Manager installs and starts the SMS_NT_Logon_Discovery_Agent, an SMS component that discovers computers running Windows as they log on to Windows NT domains in an SMS site. No SMS services or threads are installed on a NetWare server.
Figure 3-48. The Logon Point Site Server Installation process.