|
|
< Day Day Up > |
|
SMS 2003 offers remote desktop administration in six primary areas:
Inventory and resource management The ability to gather and maintain a workstation's hardware and software configuration in a central database that's easily accessible and interpreted.
Diagnosis and troubleshooting The tools to effectively analyze hardware and software concerns on remote workstations.
Package distribution The ability to install applications and updates and execute programs remotely on a user's workstation.
Application management The ability to track and restrict software usage on users' workstations, as well as to detect and monitor unregistered or unsupported applications.
Security With Standard Security, the reliance on internal and optional user accounts to run services, connect between systems, and perform client-based functions as happened with SMS 2.0; with Advanced Security, the ability to leverage the local system account and computer accounts and to perform the same functions.
Reports The ability to create and manage meaningful reports directly through the SMS Administrator Console through two new components: the Report Viewer and dashboards.
We'll explore these SMS features more closely throughout this book. First, let's look at the various SMS components; we'll refer to these components as we look at features.
The term process refers to a program that performs a specific SMS task. The term component refers to a computer running SMS software, in particular, server computers. In this section we'll review some basic SMS 2003 component and process definitions. If these descriptions seem brief, don't despair! Each is discussed in detail later in this book.
An SMS client is any computer that SMS 2003 will manage. An SMS client can be a user's desktop or portable computer, workstation, or a network server, including an SMS site server or site system. SMS clients fall into two categories: Legacy and Advanced. The distinctions between these two client types will be discussed in greater detail later in this book. For now, let's define Legacy Clients as those that SMS 2003 will manage in the traditional manner, using client access points (CAPs), distribution points, and internal user accounts to perform various client functions, and so on. Legacy Clients are most often stationary desktop systems. Legacy Clients also communicate with Server Locator Points and Reporting Points.
By contrast, SMS 2003 manages Advanced Clients by leveraging Active Directory. Advanced Clients communicate with the site through Management Points, Server Locator Points, Reporting Points, and Active Directory. Advanced Clients are most often portable computers, but they can also be stationary desktop computers. Table 1.1 represents the operating system platforms supported by SMS 2003 for Legacy and Advanced Clients.
|
Legacy Client |
Advanced Client |
|---|---|
|
Windows 98 |
n/a |
|
Windows NT 4.0 Workstation or Server SP6a or later |
n/a |
|
Windows NT Terminal Server SP6a |
n/a |
|
Windows 2000 Professional |
Windows 2000 Professional |
|
Windows 2000 Server, Advanced Server, Datacenter Server |
Windows 2000 Server, Advanced Server, Datacenter Server |
|
Windows XP Professional |
Windows XP Professional |
|
Windows Server 2003, Standard, Enterprise, Datacenter, and Web Editions |
Windows Server 2003, Standard, Enterprise, Datacenter, and Web Editions |
| Note |
SMS 2003 doesn't support any Windows family operating system not specifically listed in Table 1.1, including Windows Millennium Edition (Windows Me) and Windows XP Home Edition, nor does it support any version of Macintosh, Novell NetWare, or Microsoft Small Business Server. In addition, SMS 2003 doesn't support Alpha-based computer systems, IP version 4 or earlier, or the Netscape Browser for Web-based reporting. |
An SMS site defines the computers, users, groups, and other resources that SMS will manage so that the SMS site can remotely control a client, advertise a package, view all IP devices, inventory system resources, track software usage, and report on this data. SMS 2003 sites are defined either by Active Directory sites or IP subnet address, or both. This means that you have a lot of flexibility as far as defining which resources you wish to manage and allows SMS 2003 to scale more efficiently to your enterprise network. An SMS site consists of an SMS site server, SMS site systems, and SMS clients and resources.
The SMS site server is the Windows server on which SMS 2003 has been installed and that manages the SMS site and all its component attributes and services. The SMS site server is the primary point of access between you and the SMS database. It must be a Windows server (SP2 or later) or a Windows Server 2003 server that's a member of either a Windows NT 4.0 domain or an existing Windows 2000 or higher Active Directory domain. If the SMS site server will be a primary site, it will need access to a SQL server running Microsoft SQL Server 7.0 with SQL Service Pack 3 or later (required to support a primary site server in standard security mode) or SQL Server 2000 with SQL Service Pack 3 or later (required to support a site server in advanced security mode). You can install an SMS site server on either a domain controller or a member server, but not on a stand-alone server.
| Note |
Servers running Windows Server 2003 don't support Microsoft SQL Server 7.0. |
Included with SMS 2003 is the Deployment Readiness Wizard. This tool is designed to be run on servers in an SMS 2.0 site server prior to upgrading to SMS 2003 to identify potential incompatibilities, such as unsupported operating systems. The results are stored in Extensible Markup Language (XML) format and so can be viewed using a Web browser. Specific installation requirements for site servers are discussed in Chapter 2, 'Primary Site Installation.'
An SMS site system is a Windows 2000 server (SP2 or later) or Windows Server 2003 server that performs one or more SMS roles for an SMS site. These SMS roles include CAPs, distribution points, management points, server locator points, and reporting points. The CAP and distribution point roles are installed on an SMS site server by default. (Chapter 3, 'Configuring Site Server Properties and Site Systems,' covers all these roles in detail, as well as discusses additional server requirements necessary to support some new features of SMS 2003.) You can then identify additional SMS site systems within the SMS site and assign various SMS roles or combinations of roles.
| Note |
SMS 2003 no longer supports the logon point role or software metering server roles, as these components of SMS no longer exist. The software metering function has been reengineered as a configurable client agent that you can install on your SMS clients. |
An SMS client access point (CAP) is an SMS site system and functions as the exchange point between SMS Legacy Clients and the SMS site server. You install components of SMS Legacy Clients from a CAP. Inventory, status, and discovery information is collected on the Legacy Client and forwarded to a CAP. The Legacy Client obtains advertisement information and other instructions from the CAP. When a Legacy Client receives an advertisement for a program, it will also include a list of distribution points at which that client can find the package files.
An SMS 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. By default, SMS places these files on the drive with the most free space and shares them using a hidden share. A new feature of distribution points is the ability to enable Background Intelligent Transfer Service (BITS). Advanced Clients use BITS to control the download of package files from a distribution point, using idle bandwidth. If the download is interrupted for any reason, BITS keeps track of where the download stopped and restarts it at the next opportunity, beginning with the file that was interrupted. For example, if a user connects a portable computer for a short time while in the office and then disconnects and leaves the office while a package download was initiated, that download is interrupted. The next time the user connects the portable computer, the download will continue, beginning with the file that was interrupted.
An SMS management point is an SMS site system used by Advanced Clients to communicate with their assigned SMS site. It provides the same kinds of functionality as a CAP does for a Legacy Client. A management point is only supported in an SMS primary site because it requires access to the SMS site database. However, a proxy management point can be deployed in a secondary site when roaming boundaries are enabled to support Advanced Clients that roam to that site. The concept of roaming and roaming boundaries will be explored in more detail in Chapter 2.
An SMS server locator point is an SMS site system that's used primarily in client installation. It provides site assignment information to clients and locates a CAP for Legacy Clients, or a management point for Advanced Clients, and directs the client there to complete installation. The server locator point requires that Microsoft Internet Information Server (IIS) be installed. This site system replaces the SMS 2.0 system role of logon point and so eliminates most of the network traffic and server performance issues that affected domain controllers.
An SMS reporting point is an SMS site system that hosts the Report Viewer component for Web-based reporting functionality. As it communicates with the local site database, it can only be implemented on primary sites. Like the server locator point, a reporting point requires installation of IIS. Specific implementation requirements for this and all site system roles are discussed in Chapter 3.
An SMS administrator is the individual trusted with the implementation, maintenance, and support of an SMS site or specific objects in the SMS database. An SMS Administrator Console, as shown in Figure 1.1, is the primary tool that an SMS administrator uses to maintain an SMS site.
The SMS Administrator Console can be installed on the following platforms:
Windows 2000 Professional, SP2 or later
Windows 2000 Server, SP2 or later
Windows 2000 Advanced Server, SP2 or later
Windows 2000 Datacenter Server, SP2 or later
Windows XP Professional
Windows Server 2003, Standard Edition
Windows Server 2003, Enterprise Edition
Windows Server 2003, Datacenter Edition
The SMS Administrator Console is actually Microsoft Management Console 2.0 (MMC) with the SMS Administrator snap-in added. The 12 top-level SMS objects in the SMS site database that can be administered are described in Table 1.2; each top-level object contains additional objects. Since the SMS Administrator Console is an MMC, you can create a custom console that includes it and additional snap-ins from third-party SMS developers such as Altiris, the Microsoft SQL Enterprise Manager snap-in, or Windows 2000 or Server 2003 management tools. Also, all the functionality of an MMC is available to you, including creating taskpads, exporting lists to a file, and printing standard lists in the details view pane of the console. Specific details concerning the use and navigation of the SMS Administrator Console are discussed in Chapter 2 and Chapter 6, 'System Performance and Network Analysis.'
|
Object |
Description |
|---|---|
|
Site Hierarchy |
Display the site hierarchy and contain site properties and component configurations, such as client agents, installation methods, discovery methods, site systems, status filters, and summarizers. |
|
Collections |
Create, delete, view, and modify predefined or SMS administrator-defined groupings of SMS resources, as well as view resource information, create advertisements, and initiate remote tools functions. Collections can consist of any SMS- discovered resources. |
|
Packages |
Display package and program settings. A package is a set of files, programs, or commands that you want executed on an SMS client. Package programs are advertised to collections. Package files are stored in distribution points. |
|
Advertisements |
The means by which you let an SMS client know that a package is available for it. An advertisement can be offered not only to SMS client computers, but also to any users or user groups that SMS has discovered. Advertisements are maintained on CAPs. |
|
Product Compliance |
Determine the compliance level of Microsoft applications installed and inventoried on SMS clients. |
|
Software Metering Rules |
Monitor the usage of programs on SMS clients. |
|
Reporting |
Create, modify, and run reports and dashboards. |
|
Queries |
Provide a means of displaying database information based on a set of predefined criteria. Several queries are defined by default, and the SMS administrator can also create new queries. |
|
System Status |
SMS equivalent to the Windows Event Viewer. Virtually every SMS service or process generates a robust set of status messages that outline the progress of that service or process. The information provided by the System Status object is the best place for an SMS administrator to begin troubleshooting. |
|
Security Rights |
Provide the capability to define and refine the level of access that users have when working with SMS objects. This gives you the ability to delegate specific tasks to specific groups of users. |
|
Tools |
Run the SMS Service Manager, for monitoring component and service status, stopping and starting SMS services and threads, and logging component and service activity. |
|
Online Library |
View and search comprehensive documentation provided for SMS 2003, including Release Notes, Concepts, Planning and Deployment Guide, and Administrator Help, as well as access online documentation and order printed versions of online documentation. |
An SMS site hierarchy resembles an organizational flowchart and exists whenever two or more SMS sites have been defined in a parent-child relationship. SMS site hierarchies provide a means of extending and scaling SMS support across a wide variety of organizational structures.
Parent and child sites are defined by their relationship within an SMS site hierarchy. A parent site is any site with at least one child site defined, and it has the ability to administer any child site below it in the SMS site hierarchy. A child site is any SMS site that has a parent defined. Child sites send discovery, inventory, and status information up to the parent site. Any SMS primary or secondary site can also be a child site. An SMS primary site can have a child site reporting to it, but an SMS secondary site can't.
An SMS primary site is an SMS site that has access to a SQL Server database. An SMS primary site can be directly administered through the SMS Administrator Console as well as by any SMS site above it in the SMS site hierarchy. An SMS primary site can also administer any child site below it in the site hierarchy. SMS primary sites can be children of other primary sites. They can also have child sites of their own. Only SMS primary sites can support site systems assigned the management point, server locator point, and reporting point roles.
An SMS secondary site is an SMS site that doesn't have access to a SQL Server database. An SMS secondary site is always a child of a primary site and is administered solely through its parent or through another primary site above it in the SMS site hierarchy. A secondary site can't have child sites of its own nor can it support site systems assigned the management point, server locator point, and reporting point roles, although it can be assigned a proxy management point.
An SMS central site is an SMS primary site that resides at the top of the SMS site hierarchy. Inventory data, status messages, site control data, and discovery data roll from child to parent and are collected ultimately at the central site's SMS database. An SMS central site can administer any site below it in the SMS site hierarchy.
Figure 1.2 illustrates a simple SMS hierarchical model showing both primary and secondary sites as child sites of a central site. An SMS site system's roles don't all have to be enabled on the site server. Rather, these roles can be enabled on other servers in the domain.
That's it for general terminology. All these components and terms will be explored in more detail later in this book.
SMS 2003 can collect and display resources deployed within your network. These resources include, of course, the workstations and servers that have been installed. You have the ability to discover and view your Windows domain users and groups, as well as any IP-addressable component connected to your LAN or WAN. SMS 2003 offers several configurable discovery methods. SMS 2003 also provides three kinds of Active Directory discovery: Active Directory System Discovery, Active Directory User Discovery, and Active Directory System Group Discovery. Although not all discovered resources might be manageable, the administrator can display and view some basic properties. For example, a computer's discovery data includes its IP address, network card address (the MAC address), its computer name, and the domain of which it's a member. The process of discovering resources will be discussed at length in Chapter 7, 'Resource Discovery.'
| Note |
The process of discovering a resource such as a computer doesn't automatically mean that SMS is installed on that computer. Nor does it mean that inventory is collected. Rather, it means that the 'fact' of the resource being there is recorded along with some basic properties of that resource. |
In addition to discovery data, SMS 2003 can collect hardware and software data from an SMS 2003 client. Two of the five client agents that can be installed on an SMS client computer are the Hardware Inventory Client Agent and the Software Inventory Client Agent. The SMS administrator enables and configures both and then installs them on an SMS client. Collected inventory is stored, viewed, and maintained in the SMS site database. This database is created and maintained on a SQL Server. The SMS Administrator Console acts as a front end to this database and provides the SMS administrator with the tools to manage that data. For example, you view an SMS client's inventory through the SMS Administrator Console by selecting that client in an appropriate collection and executing a tool called the Resource Explorer.
When troubleshooting needs to be performed, it's not always possible, or even appropriate, that users have full knowledge of their hardware or software configuration. Having an SMS client's inventory readily available and up-to-date, however, provides an administrator with the computer configuration data needed to assist a user with a problem.
The Hardware Inventory Client Agent executes according to an administrator- defined frequency and collects system configuration such as hard disk space, processor type, RAM size, CD type, monitor type, and so on. In addition, you can configure the Hardware Inventory Agent to collect more granular information from SMS clients using a template file called SMS_DEF.MOF, such as the installation date of the system's BIOS, asset and serial number information, program group names, and printers installed. It does so by using the WMI service. WMI is Microsoft's implementation of Web-Based Enterprise Management (WBEM). (You'll learn more about these services in the section entitled 'Understanding WBEM and WMI' later in this chapter.) Briefly, WMI allows for more detailed system configuration data to be reported and stored on the workstation for use by management applications such as SMS. Once the Hardware Inventory Client Agent on a 32-bit client has collected the full inventory, only changes to the inventory on the client will be reported in subsequent inventories. The hardware inventory process and configuration are discussed thoroughly in Chapter 9, 'Inventory Collection.'
The Software Inventory Client Agent also executes according to an administrator- defined interval and essentially audits the SMS client for applications installed on its local hard disks. The SMS administrator can configure the Software Inventory Client Agent to audit other file types and report on specific files, as well as to collect copies of specific files. As with the Hardware Inventory Client Agent, the first time the Software Inventory Client Agent runs, a complete software audit or file collection takes place and the full inventory is gathered and reported. At each successive inventory interval, only changes to the audited files will be reported. The software inventory collection and configuration process is discussed more completely in Chapter 9.
Provided with SMS 2003 are several tools that can help the SMS administrator diagnose problems in the SMS site, problems with communications within and among sites, and problems with SMS client computers-and troubleshoot those problems with little direct physical intervention.
Network Monitor provides the means to track, capture, and analyze network traffic that occurs between individual client computers or within the network itself. This version has been enhanced both in functionality and security. For example, a set of functions called experts has been included to assist you in tracking down and parsing events such as top users, protocol distribution, and so on. Network Monitor is discussed in detail in Chapter 6.
Network Trace offers a snapshot flowchart of the SMS site system structure that maps the communication path of each site system, checks for communication status between site systems, and displays the status of SMS components running on each site system. Think of Network Trace as a miniature SNMP manager. See Chapter 6 for more information about working with Network Trace.
When SMS has been installed on a site server, it also adds several new objects that contain counters to the Windows 2000 and Server 2003 Performance Monitor utility. These objects are listed here:
SMS Discovery Data Manager
SMS Executive Thread States
SMS In-Memory Queues
SMS Inventory Data Loader
SMS Software Inventory Processor
SMS Software Metering Processor
SMS Standard Sender
SMS Status Messages
These objects and their corresponding counters, along with the traditional Windows 2000 and Server 2003 objects and counters (Processor, Process, Memory, Logical Disk, Physical Disk, and so on) can assist the SMS administrator in performance testing site systems and determining optimization alternatives. See Chapter 6 for more information about working with Performance Monitor.
Remote Tools has been perhaps the most appreciated feature of any SMS version. This utility enables the SMS administrator to gain keyboard and mouse control of an SMS client from the administrator's workstation. Through a video transfer screen, the administrator can 'see' the user's desktop and diagnose and troubleshoot problems without having physical access to the remote client. The administrator can also 'talk' to the user through a remote chat screen, execute programs on the remote client, transfer files to and from the remote client, and restart the remote client. As with the Hardware Inventory Client Agent and Software Inventory Client Agent, the amount of remote access that can be initiated is configured by the SMS administrator and rendered on the client by a Remote Tools Client Agent.
Remote Tools also includes remote diagnostic utilities specific to Windows NT 4.0 and later computers and other Windows operating systems that provide real-time access to system attributes such as interrupt usage, memory usage, services running, and device settings. You can also configure Remote Tools to manage the remote connection features of Windows XP Professional. This feature is discussed more thoroughly in Chapter 10, 'Remote Control of Client Systems.'
SMS Trace allows the SMS administrator to view one or more SMS log files in real time in order to follow, diagnose, and troubleshoot service activity. You can use this tool to search for text strings and to highlight found values. See Chapter 5, 'Analysis and Troubleshooting Tools,' for more information about SMS Trace. This tool, along with several others, is available for download from the Microsoft SMS 2003 Web site http://www.microsoft.com/smserver.
All SMS services and processes create and update a wide variety of log files and generate detailed event status messages. These files and messages provide the SMS administrator with an extensive source of diagnostic data that's critical to the successful maintenance of the SMS site and also provide an ideal means to learn about the inner workings of SMS. Server-based log files aren't enabled by default to conserve server resources, but the SMS administrator can enable and configure them. Client-based log files are enabled by default and can be disabled through the client registry. You can view log files with any text editor.
One important way of reducing the total cost of owning and maintaining client computers is to minimize the amount of time an administrator needs to physically spend at a computer. When part of the administrator's job involves installing and upgrading software at a computer, the amount of time spent at each computer can be significant. We've already looked at some of the remote tools available to reduce the time spent at a user's computer. Another way to reduce this time is to acquire the ability to remotely install, maintain, and upgrade software. SMS 2003 enables you to do just that. Through its package distribution feature, you can run programs on client computers to install and upgrade software, update files, execute tasks such as disk optimization routines, and modify configuration settings such as registry entries or INI files.
The SMS administrator defines a package's properties, including the location of source files; sending priority; where the package should be stored and shared on the distribution point; and version and language values. The SMS administrator identifies which distribution points should receive the package and also creates one or more programs for the package that define how the package should be executed at a client computer. For example, a software application installation might have several types of installations that can be run, such as Typical, Custom, and Laptop. Each of these installations would represent a program that the SMS administrator would create for the package. The same package definition could then be used to install the application in different ways on different clients.
Clients are made aware of the existence of an application through advertisements. The SMS administrator creates an advertisement, and it identifies both the program that should be executed by the target resources and the SMS collection that defines the target resources. Programs can be advertised only to collections, and a valid collection can consist of SMS clients and Windows 2000 or Server 2003 users and groups or Active Directory discovered resources. The advantage of this arrangement is that when a new computer, user, or user group is added to a collection, it will automatically receive any advertisements for that collection. Packages and advertisements are discussed in detail in Chapter 12, 'Package Distribution and Management.'
SMS 2003 offers several tools for managing applications installed on SMS clients. In SMS 2.0, Microsoft introduced the software metering server component. The software metering server provided two main functions: application usage tracking and application licensing. When an application was executed at the client, a client agent reported that fact to the software metering server, which was, in turn, passed to the SMS site server and stored in its own SQL database. The data could then be summarized and displayed for the SMS administrator through the SMS Administrator Console. The SMS administrator could also register an application. The SMS administrator could then set restrictions on it or enforce tracking of licenses.
This function was never fully integrated into the SMS site server 'suite' of components. Note, for example, the use of a separate SQL database for storing usage and license information rather than incorporating that information into the main SMS database. The interaction between the client and a software metering server, as well as between the site server and its software metering servers, could generate a fair amount of network traffic. For example, licenses would be propagated and periodically balanced among existing software metering servers in the site, and the software metering client agent would need to contact a software metering server whenever a registered application was executed on the client. When I taught the Microsoft Certified classes for SMS 2.0, I would frequently refer to the software metering component as a glob of Silly Putty stuck onto the otherwise smooth globe of SMS.
In SMS 2003, the software metering component has been redeveloped and is now fully integrated with the rest of SMS. It uses WMI to monitor running applications. You can now create software metering rules that are downloaded to specified clients. You can configure a software metering rule to monitor all or specific applications that are executed on an SMS client, detect and report on unregistered or unsupported applications, and collect application usage information. The software metering data that's collected is now stored in the SMS site database, and you can generate more useful reports regarding the usage of applications on SMS clients. You can use software usage data to determine:
How many copies of a program have been deployed in your organization
How many licenses you need to purchase to remain compliant
How many users actually use the program
What times of day the program is most frequently used
Software metering will be explored in detail in Chapter 15, 'Software Metering.'
An additional application management tool, Product Compliance, is installed with SMS. The product compliance database allows you to import or configure your own product information for applications running within your organization and use it to identify those clients that are running noncompliant applications.
This process actually involves several SMS components. You can use the Software Inventory Client Agent to collect a list of programs installed on each client. This list is compared to the product compliance database using SMS queries. Once you have identified programs that are unsupported or nonstandard, you can use software metering rules to restrict the execution and use of those programs. If you identify programs that need to be upgraded, you can use the package distribution process to send and apply the appropriate upgrades.
|
|
< Day Day Up > |
|