What s Changed Since Systems Management Server 1.2?
SMS 2.0 differs from SMS 1.2 in several key areas. First and foremost, SMS 2.0 represents a fundamental regeneration of the program code. Most services and processes have been completely reworked to provide a higher level of performance and a more efficient load balancing of resources. For example, whereas the SMS 1.2 Executive service managed about 10 SMS process components, the SMS 2.0 Executive service manages 42 process components. At first glance, you might infer that this proliferation of process components would in fact reduce performance rather than improve it. In actuality, overall performance does improve because the various SMS tasks are being carried out by their own individual process components. In SMS 1.2, each process component might be responsible for handling many SMS tasks.
Another major performance change from SMS 1.2 comes through the use of SQL stored procedures and triggers. Process components and services in SMS 1.2 would wake up and carry out a task based on a sometimes configurable polling cycle. This cycle would necessarily cause delays in the completion of a task such as processing a change to a site's properties or updating the database with inventory changes.
SMS 2.0 installs SMS SQL Monitor on the SQL Server computer. With nearly 200 different SQL triggers and stored procedures, SMS 2.0 uses SQL Monitor to wake up process components, allowing a task to be carried out immediately rather than waiting for the next polling cycle to occur. To visualize how SMS 1.2 carried out a task, imagine the workings of an old mechanical clock tower. Before the minute hand can move, several gears and cogs must engage and click and move. In contrast, SMS 2.0's clock tower model has a refined quartz movement.
Some other differences between SMS 1.2 and 2.0 come from feature changes, as you have probably already noticed. The more notable of these differences are listed in Table 1-2.
Table 1-2. Feature changes between SMS 1.2 and SMS 2.0
| Feature Change | SMS 1.2 | SMS 2.0 |
|---|---|---|
| Software inventory implementation | Simulates a software inventory through the use of software inventory packages and audit rule files. This manual process requires that you know some unique characteristics of the software in question, such as file size or cyclic redundancy check (CRC) value. | Adds true software inventory capabilities through a simple configuration process and reports the application name and version where possible as well as the executable file name. |
| Client support | Supports OS/2, Macintosh, and MS-DOS platform computers as manageable clients. | No longer supports OS/2, Macintosh, and MS-DOS platform client computers. |
| Shared network application | Provides support for shared network applications, which allows the administrator to use SMS to install a network version of an application and then provide access to the application by creating a program group and shortcut on the client s desktop. | No longer provides this support directly through the SMS site server as a configurable option, although it can be duplicated through other SMS 2.0 components. |
| Administrative tools | Uses the SMS 1.2 Administrator window. | Uses the SMS Administrator Console, which is a snap-in for MMC. This console is far more customizable than the SMS 1.2 Administrator window. |
| Security level | When accessing the SMS database through the SMS 1.2 Administrator window, the administrator has to provide the account and password that would be used to open the database. Some additional security roles can be assigned to various users, but this is basically as secure as you can get with SMS 1.2. | Adds object-level security through the SMS Administrator Console to provide a true method for locking down a console, delegating administra-tive tasks, and creating stream-lined custom consoles for specific tasks as opposed to the single logon access to the SMS 1.2 Administrator window. For example, if a selected group of help desk users need to perform Remote Tools tasks for a specific group of clients, a custom console can be created that displays only the collection for that group of clients. A thorough implementation of object security enables that group of users to see only the collection they need to use in the SMS Administrator Console. |
| Package delivery | Uses jobs to deliver packages to other sites, distribution servers, and clients. | Merges elements of the job process into its packages and advertisements. Part of the package definition, for example, now includes the DPs for the package files and the priority level for sending the package. The advertisement includes the target resources (grouped by collection), the program to be executed, and any mandatory time assignments. |
| Package recipients | Packages can be sent only to target SMS client computers. | A package is advertised to a collection, and an SMS collection can include SMS client computers as well as discovered users and user groups. This capability allows you to send a package directly to a user regardless of what computer that user is sitting at. |
| Status messaging system | Uses the SMS 1.2 Event Viewer. | Uses a more robust and detailed status messaging system named Status Message Viewer. |
| Package target management | Uses machine groups, which are created and maintained manually. If a new client computer is added to the site or to a machine group, the ad- feature ministrator will have to create a separate job to distribute any packages that the client requires. | Uses collections based on SMS queries. Thus, when the query result changes, the collection is updated automatically. This greatly simplifies package management in SMS 2.0. Because packages are advertised to collections, when the collection membership is updated, any new members automatically receive the advertisement, and any members removed no longer see the advertisement. |
| Hardware inventory implementation | Before an administrator can perform any client or package management, SMS has to be installed on the client, and the client s hardware inventory has to be in the SMS database. | Implements hardware inventory as an option rather than a requirement for installing the SMS client, advertising programs, and initiating a Remote Tools session. |
| Site boundary | Determines site boundaries based on domain structure and management requirements. | Bases a site s boundaries on network topology using IP subnet addresses or Internet Protocol Exchange (IPX) network numbers to assign clients and resources to the site and therefore is not constrained by the Windows NT domain structure. |
| Sender support | LAN Sender, RAS Asynchronous Sender, RAS ISDN Sender, RAS X.25 Sender, SNA Batch Sender, and SNA Interactive Sender. | Standard Sender (LAN Sender in SMS 1.2), RAS Asynchronous Sender, RAS ISDN Sender,RAS X.25 Sender, SNA RAS Sender (replacing the SMS 1.2 SNA Senders), and Courier Sender. |
| Remote control | Remote Control settings cannot be preset by the SMS administrator before installing the Remote Control Agent on the client. The settings are configured at each client through the help desk program. Users can potentially modify these settings. | Remote Tools settings such as which remote options are enabled and requiring permission can be predefined by the SMS administrator before the Remote Control Agent is installed on the SMS client. Additionally, the Remote Control Agent can now be configured so that the user cannot make any changes to the settings. |
| Database maintenance | Database maintenance tasks are manual. | Provides scheduled database maintenance routines. Tasks such as backing up the database and site server can now be automated through the SMS Administrator Console. |
| Network monitoring | Network Monitor Agent needs to be installed as a service on remote clients. | Network Monitor has been enhanced to include experts and monitors to assist the administrator in identifying problem areas in the network infrastructure. No longer needs Network Monitor Agent. |
In addition to these feature changes, SMS 2.0 now supports eight site system roles—three more than SMS 1.2. These are described in Table 1-3.
Table 1-3. Server role changes between SMS 1.2 and SMS 2.0
| SMS 1.2 Server Role | SMS 2.0 Server Role |
|---|---|
| Site server Domain controller. | Site server Domain controller or member server. |
| Site database server Any Windows NT 4.0 server running SQL Server 6.0 or later. Does not support SQL Server 7.0. | Site database server Any Windows NT 4.0 server running SQL Server 6.5 with Service Pack 4 or later. Supports SQL Server 7.0. |
| Logon server Domain controller. | Logon point Domain controller. |
| Distribution server Any Windows NT 4.0 server. | Distribution point Any Windows NT 4.0 server. |
| Helper server Any Windows NT 4.0 server; used primarily to designate servers for sender support, such as installing one of the RAS senders on a separate Windows NT RAS server. | Site system Any Windows NT 4.0 server running the SMS Executive; used primarily to designate servers for sender support, such as installing one of the RAS senders on a separate Windows NT RAS server. |
| N/A | CAP Any Windows NT 4.0 server; used as the main point of interchange between the client and the site server. These functions were provided by the logon server in SMS 1.2. |
| N/A | Software metering server Any Windows NT 4.0 server |
| N/A | Software metering database server Any Windows NT 4.0 server running SQL Server 6.5 with Service Pack 4 or later. Support SQL Server 7.0. |
NOTE
The server roles referred to in Table 1-3 are roles maintained on Windows NT servers. NetWare servers are also supported for some of these roles. The level of support provided by NetWare servers will be referenced as we discuss each role in more detail in later chapters.
Changes have also occurred on the client side with SMS 2.0. Perhaps the most noticeable change has to do with disk space requirements. The SMS 2.0 client installation will require from 12 MB to 15 MB of disk space, depending on the components that are installed. This requirement is largely due to changes made in the way client components function. Unlike the components in SMS 1.2, SMS 2.0 client components run almost entirely as services or service processes on 32-bit clients (Windows 95/98, Windows NT, and Windows 2000). While this change does require additional resources on the client computers, it also results in increased functionality and less user interaction.
Much of the component processing has been implemented as scheduled events on the client computer. For example, hardware inventory frequency in SMS 1.2 was configured at the site server and collected largely as a function of the user logging in and initiating a hardware inventory collection process from the logon server. In SMS 2.0, the Hardware Inventory Client Agent and Software Inventory Client Agent are enabled and configured at the site server and installed on the SMS client. The agents then run on the client computer and collect inventory according to the configured frequency. After the first complete inventory is processed and copied to the CAP, the agent maintains inventory history on the client and sends only changes in subsequent collection cycles. This process results in a significant reduction in network bandwidth utilization and a marked decrease in the amount of time it takes the user to log in.
NOTE
In switching from SMS 1.2 to SMS 2.0, 16-bit client computers (Windows 3.1 and Windows for Workgroups 3.11) will see little change in function. Inventory, for example, will still be initiated during logon and will still collect and send a complete inventory file at each collection cycle.
The SMS client program group is no longer created in SMS 2.0. Instead, any SMS client agents that require any kind of user interaction will be accessible through program icons added to the Control Panel. The SMS.ini file has also been eliminated on 32-bit clients (yeah!). Instead, all SMS client configuration settings are maintained in the registry under the HKEY_LOCAL_MACHINE\SOFTWARE\MICROSOFT\SMS and NAL keys. In SMS 1.2, the MS\SMS subdirectory structure created when the SMS client is installed was placed in the root directory. In SMS 2.0, this directory structure is created in the operating system directory. This makes the structure less obvious to the user and less tempting for them to erase (double-yeah!).
EAN: 2147483647
Pages: 167