This lesson lays the foundation for understanding and effectively utilizing SMS, its documentation, white papers, and technical publications. If you are experienced with earlier versions of SMS, this lesson maps key SMS 1.x terminology to that used in SMS 2.0.
SMS provides an information transfer infrastructure for all its operations. To facilitate this transfer of information, an SMS-managed network passes all information through a hierarchical structure from the bottom-most site systems to the top of the management tree (Figure 1-9). Management data, such as packages and collection, pass down through the hierarchy, while inventory and status information flow up the hierarchy. An SMS environment consists of one or more SMS sites. The structure that ties multiple sites together is called the hierarchy. When viewing the hierarchy it is important to understand what is meant by the terms child site, parent site, central site, primary site, and secondary site.
A parent site is any SMS site having one or more sites below it. A child site is any SMS site that has a parent site above it. A hierarchy is created by linking sites to form parent-child relationships. Do not confuse the parent-child terminology with the primary and secondary site terminology described next.
Two different types of sites (primary and secondary) help structure the administration of the SMS environment. These sites can work together to form a hierarchy. A site consists of an SMS site server and one or more networks that form a site boundary. A network can run NetBEUI, TCP/IP, or IPX/SPX to be part of an SMS site. However, site boundaries are defined only by TCP/IP subnet or IPX/SPX network number. Site boundaries cannot be defined using the NetBEUI protocol.
Whenever possible, limit networks to a single protocol. This approach more efficiently utilizes network bandwidth.
An SMS 2.0 primary site contains a Microsoft SQL Server 6.5 or 7.0 database, a primary site server, and at least one network. Primary sites run the database for all client computers and other resources in that site's boundary. Further, SMS data from a child site always passes to its parent site.
A primary site server contains SMS site services and the SMS Administrator console, so it can be managed directly. The primary site server located at the top of the hierarchy is called the central site server. A virtually unlimited number of subsites may exist below any primary site server regardless of whether or not it is the central site server.
A secondary site does not run a SQL Server database, but does contain an SMS site server, appropriately named a secondary site server. A secondary site reports information to the primary site directly above it in the hierarchy. Secondary sites do not contain the administrative utilities required for SMS administration. A secondary site is either created from a primary site or installed from the SMS installation CD-ROM. A secondary site must be administered through one of the primary sites above it in the hierarchy. A secondary site cannot have subsites below it.
Figure 1-9 shows an example of an SMS site hierarchy. Site A is the central site, site B and C are primary sites, and site D is a secondary site. Site A is a parent site to site B. Site C is both a child site of site A and a parent site to site D. Site B is a child site of site A. Sites B, C, and D are subsites of Site A. A subsite is defined as any site that is below a parent site. The difference between a child site and a subsite is subtle. A site is called a child if it is being viewed from the site directly above it in the hierarchy, the parent site. A subsite, on the other hand, is defined as any site located below another site.
Figure 1-9. An example of an SMS hierarchy.
Site-to-site communication occurs through the hierarchy in three ways. All three methods communicate using senders. A sender transmits instructions and data from one site to another. For example, a sender might report inventory information or distribute software between sites.
The three classes of senders in SMS are the Standard Sender, RAS senders, and the Courier Sender.
Multiple senders can be configured between sites for fault tolerance and other connection considerations (such as performance and cost). SMS uses one or more senders to communicate with other sites. Other senders can be written and provided by third parties.
A small implementation of SMS may contain a single central site server, while a large SMS implementation may contain hundreds of site servers (primary and secondary) in a multi-level hierarchy. Multiple site servers in a large implementation of SMS help to balance processing across many computers. Additional load balancing is achieved by distributing the various SMS services to other computers on the network. For example, the SQL Server database can be located on a computer other than the site server.
The site server does not have to be installed on a domain controller. At minimum, a site server must be a member server in a Windows NT/2000 domain. Configuring the site server as a member server decreases processing requirements associated with domain control.
All computers that participate in providing systems management functions to SMS are called site systems. Each site system serves a role in site management. The computer running the site database is assigned the site database role, and any computer acting as a site server is assigned the site server role. Computers running Novell NetWare or Microsoft Windows NT/2000 can play site system roles. However, roles might be limited by the operating system. For instance, a Windows NT/2000 Server member server or domain controller play all roles, but a Novell NetWare server cannot perform the site server or site database role.
Site system roles can be delineated by examining more closely how systems management is accomplished within a site. When resources are discovered in a site, data flows through the network and is eventually written to the site database. Data from computer resources can be collected via logon discovery. For logon discovery to occur, the logon point role must be assigned to at least one site system. Computers then log on to the network and a logon point installs SMS programs used for computer resource discovery. A data discovery record (DDR) is generated at each computer resource, sent to the logon point, and eventually written to the site database. The logon point role can be assigned to a server that acts as a Windows NT/2000 Server domain controller, NetWare bindery server, or a NetWare NDS server.
If client agent installation is enabled, computer resources that can become client computers install client agents. The installation files are located on any site system serving the role of client access point (CAP). Besides logon, all communications between client computers and the site server occur through the CAP. For example, a client computer contacts a CAP to determine if there are any packages advertised through the SMS software distribution facility. A CAP can be a server running Windows NT/2000 Server, NetWare bindery server, or a NetWare NDS server.
After the CAP informs the client computer that there is an advertised package, the package and program run from a site system serving the distribution point role. The distribution point receives packages and programs from the site server and the CAP receives advertisements. Ultimately, the Advertised Programs Monitor Client Agent reads the advertisement from the CAP and either automatically runs a program from the distribution point or presents the user with the option of running a program. Like the CAP, a site system serving the role of distribution server can be a Windows NT/2000 Server, NetWare bindery server, or a NetWare NDS server.
The CAP maintains all client agent installation routines. If software metering is enabled, the CAP installs the Software Metering Client Agent on the client computer. Once the Software Metering Client Agent is running, it communicates with a site system serving the role of software metering license server. The software metering license server communicates with both the client agent and the site system serving the role of software metering database server. The software metering database server maintains a distinct database separate from the site database, but both databases can be maintained by the same SQL Server. Both the site server and the software metering database server run only on Windows NT/2000 Server.
The site system serving the role of site server runs many SMS components (processes and threads). The primary SMS process on a site server is the SMS Executive. This process spawns many threads to perform various systems management functions. Threads are objects within processes that run program instructions. Some of these threads, like the SNA RAS Sender, can be located on other site systems. Site systems that run threads of the SMS Executive are called component servers. A site system performing the component server role can only run on Windows NT/2000 Server.
The SMS Provider is the only role that must coexist on the same computer serving the site server or site database role. The SMS Provider allows you to access and manipulate data in the SMS database using any Windows-Based Enterprise Management (WBEM)-compliant application, such as the SMS Administrator console. WBEM will be explained in Lesson 3. Software metering information is the only data that is not viewed or modified via the SMS Provider. Since the SMS Provider role must be located on a site server or site database, it can only run on Windows NT/2000 Server.
For more details on supported platforms (version and service pack level for site system roles), see Appendix A of the SMS Administrator's Guide.
While there are many ways to distribute roles to many computers in an SMS site and throughout the hierarchy, it is best to start simply. Begin by installing SMS to run all roles from the central site server. As you become more familiar with SMS, you can distribute site system roles as required to support your network. Figure 1-10 shows the flow of data from computer resources, client computers, and site systems in a distributed site.
Figure 1-10. Inside an SMS site.
One site server license is required for each site regardless of the number of site systems configured within a site. However, SMS client computers can only use PerSeat licensing mode, not PerServer licensing mode to access the SMS site. PerSeat licensing costs more than PerServer licensing for a single server network. However, the typical SMS site will contain more than one computer running Windows NT/2000 Server, so PerSeat licensing is more economical for accessing SMS.
If SMS and SQL Server are purchased as part of Microsoft BackOffice, the SMS site server and SQL Server must be installed on the same computer. If SQL Server and SMS will be installed on different computers, an additional SQL Server license is required. SQL Server database client licenses are not necessary if the SQL Server database supports SMS exclusively.
For more information, view "PerSeat vs. PerServer Licensing" (license.htm) on the disc included with this training kit. For specifics on licensing Systems Management Server, go to http://www.microsoft.com/smsmgmt and find the Licensing link under the Product Guide. If you cannot locate this link, search the Microsoft web site for documents on SMS 2.0 licensing.
Terminology has changed significantly from SMS 1.x to 2.0. If you are experienced with SMS 1.x, this table will aid you in understanding SMS 2.0 terminology. There is no direct mapping of all terminology, since SMS 2.0 is more robust than SMS 1.x.
|SMS 1.x Terminology||SMS 2.0 Terminology|
|Distribution Server||Distribution Point|
|Helper Server||Component Server|
|Logon Server||Logon Point|
|Machine Group and Site Group||Static|
|Named Queries||Dynamic Collection|
|Package Command Manager||Packages node|
|Software Auditing||Software Inventory|
|Help Desk Utilities||Remote Tools|
|LAN Sender||Standard Sender|
|SNA Sender||SNA RAS Sender|
|Database Manager||Database Maintenance node|
|SMS Security Manager||WBEM namespace and the SMS Provider interface|
|SMS Sender Manager||Senders node|
|SMS Service Manager||SMS Service Manager|
|SMS Event Viewer||System Status node|
|SMS Administrator||SMS Administrator console|
See Appendix B of the SMS Administrator's Guide for more details about changes from SMS 1.2 to SMS 2.0.