http://www.microsoft.com/TechNet/boes/bo/sms/technote/whouse.htm (PC Press Internet CD, 03/1996)
| Updated: March 15,1996 |  Go To TechNet Home Page |
Introduction
Project Vision and Scope
SMS Test Plan
Architecture/Design Recommendation
Pilot Plan
For More Information
Conclusion
Appendix A: Overview of Microsoft SMS
Historically, managing distributed desktop microcomputers in an enterprise has been labor-intensive, time consuming, and expensive in large organizations. Administrators based procurement and upgrade decisions on unreliable inventory information (often gathered manually), helpdesk personnel visited users to resolve problems, and new/upgraded software was distributed in labor-intensive ways that often disrupted end user activities.
By centralizing and automating hardware/software inventory, software distribution, helpdesk support, and access to networked applications, a solution combining Microsoft Windows NT Server (NTS) and Microsoft Systems Management Server (SMS), enables more efficient performance of these operations and enhances the business processes that rely on them.
An SMS solution increases efficiency because:
Automating reduces expenses for large IT organizations in several areas:
Note
Although this document focuses on developing an SMS, NTS, and Windows NT network solution, it contains important SMS implementation information applicable for any network configuration. For general information on SMS, see Appendix A. For information on deploying SMS on other vendor's networks, please refer to the Systems Management Server Administrator's Guide available as part of your SMS documentation.
SMS helps automate and centralize many support/maintenance functions. Standardization on software across the enterprise should be an integral part of any SMS deployment, because it reduces helpdesk support costs and employee training costs, therefore providing key benefits to the organization and allowing for easier maintenance of the new SMS system. For instance, standardization on Microsoft Windows NT Server helps centralize network administration. Standardization on Microsoft Office Professional reduces helpdesk support requirements while increasing productivity. The enterprise should be standardized on one network operating system, one messaging product, one desktop product suite, one database package, and one client operating system. If enterprise-wide standardization is not an option in your case, see the general guidelines for software distribution in a non standardized later in this document.
|
Client |
Operating System: Windows NT Workstation Product suite: Microsoft Office Messaging: Lotus cc:Mail Number of clients: 24,000 |
|
Server |
Operating System: Windows NT Server Network: Windows NT Network Systems Management Server Corporate database standard: Oracle |
Design and implement an enterprise Systems Management Server solution that:
To accomplish these goals, the solution should:
Project success is measured by how much the solution:
Key milestones of an SMS project are:
Project team size can be expected to vary with the size of the project. In general, the team should consist of:
Size and scope of the implementation determine staffing. In small projects, one person may fill more than one of these roles; in large projects, several people may share a role. You can also hire outside consultants to perform many of the roles mentioned above, but it is essential that those consultants be well educated on the internal network architecture.
Throughout this paper, at key points in the process, assumptions are listed and the implications of those assumptions (sometimes representing constraints) are listed below them.
Throughout a project such as this, the team must understand and accept basic assumptions:
Constraints arise from real-world factors such as resources, budget, schedule, and internal organization. It is extremely important to define constraints and any open issues that may arise early in the process because of them. For instance, if one of your IT network architecture experts is expected to become unavailable soon due to other projects, make sure you work this time constraint into the project plan.
This section defines testing stages and identifies key features, functions, and configurations of SMS that require testing in the corporate environment. Test results help planners make design decisions later in the project. A sample testing/validation outline at the end of this section shows the sequences in each test stage.
Note
Read the SMS Administrator's Guide and its appendices before you test.
Thorough, iterative testing helps ensure successful implementation. Test results may suggest necessary or desirable changes in architecture or server configurations. Optimal function and performance can be achieved only after testing, analysis, and reconfiguration are completed within each unique computing enterprise. Because of the many variables involved, testing timeframes are difficult to estimate, a factor which must be taken into account when planning.
The section below lists five test plan stages; it is followed by a section that outlines the testing plan. For technical details, see SMS documentation, the SMS software development kit, Microsoft TechNet, SMS training materials, Windows NT documentation, the Windows NT Resource Kit, and SQL Server documentation.
Accurate test results are critical in configuring SMS in a given environment: conduct tests in a controlled, well documented manner and re-run any that yield questionable results. Run tests only on machines that:
Testing must collect accurate results (for a specific corporate computing environment) which are used to develop an architecture and implementation that meet requirements and satisfy initial assumptions.
There are five stages to SMS Testing:
This stage tests basic SMS system functionality in a single-server, dual-client laboratory environment. It includes:
Stage 2 tests basic functionality in a multi-tier configuration consisting of a central site server, a second-level primary site server, and a third-level secondary site server with two Windows NT clients. It includes:
This conducts tests at all corporate network link speeds, as determined by corporate network topography research.
This tests migration to the new SMS system, performing all testing defined in Stage 2 in a mixed environment as necessary (Novell, LAN Server, Pathworks, etc.).
This final stage tests the pilot system with a live user base.
Note
Use the following outline as a reference when designing your own testing plan, but keep in mind that needs specific to your environment, even if not discussed here, will need to be included. Also remember that the time required to perform these tests is extremely difficult to estimate.
(2) Domain settings
(3) Logon server designation
(4) Help desk options
(5) Package Command Manager options
Check initial inventory reporting
This section provides a sample architecture and design recommendation for Microsoft Systems Management Server. More specific recommendations can be based on understanding of business requirements and derived through extensive testing.
Your environment may be vastly different from the enterprise used as an example here, but reading the following sections can help you better understand the importance of a well defined hierarchy to any SMS deployment, and may provide you with valuable "tips" on defining your own hierarchy.
Recommendations are included for:
Each recommendation has a list of assumptions, usually stating reliances between SMS design and the network or an administrative process. Implications of the assumptions are also listed.
To define the corporate IT environment:
Sites can range from headquarters facilities to manufacturing sites to engineering facilities to small sales offices, etc. Each site tends to differ from other sites in some ways, and resemble other sites in some ways, so the best way to begin is to classify sites based on variables important to SMS, including:
Network link speed. The speed of external network links (56KB, 128KB, 256KB, T1, T3, etc.) to the central site server.
When designing an SMS system, learn about the network structure and work closely with the internal network team to ensure that SMS system design overlays the local resource domain structure. Include corporate network overviews in the project plans.
The SMS site hierarchy is arranged geographically, closely following the configuration of your NT Domain whenever possible. All networked PCs in the enterprise are managed by SMS based on their physical location. Each of these machines is assigned to a particular business unit, as defined by the user, for management flexibility. The enterprise can then group and manage distributed hardware/software assets according to location or specific business unit requirements.
A hierarchy of SMS servers is deployed throughout the network. The central site server resides on a dedicated machine in the central data center. The central SMS database, resident on a separate dedicated machine, also resides in the central data center.
Second-level primary site servers exist in major metropolitan areas. Primary sites are named after their metropolitan area (Seattle, Portland, etc.) for easier management.
Inventory reporting and software distribution are managed based on a machine's association with its NT resource domain. In this case, resource domains exist for each site. Each resource domain's primary domain controller is configured as an SMS secondary site server, reporting to its metropolitan-area parent site. All site locations report to and are managed from their nearest metropolitan site.
NOTE
Secondary site servers (at the building-level) usually do not require dedicated SMS servers. Rather, SMS uses file/print resource servers that are already present for other purposes. The only dedicated SMS machines are at the primary site level (metropolitan areas), and the central site and central database machines.
Example: For a 440-site, 24,000-desktop organization, an initial deployment would include nine dedicated servers for SMS. Each resource server would require 2 GB of disk space and 24 MB of RAM above the requirements recommended for each server's primary purpose.
This hierarchy minimizes network traffic across WAN links, keeping most SMS activities within a site's routed subnets, and minimizes cost by using existing resource servers.
SMS metropolitan-area site names are city names; SMS site codes are capitalized 3-letter strings for them. For example:
|
Site name |
Site code |
|---|---|
|
Pittsburgh |
PGH |
|
Orlando |
ORL |
|
Baltimore |
BLT |
|
Houston |
HOU |
|
Atlanta |
ATL |
|
Charlotte |
CHA |
|
Belgium |
BEL |
|
Australia |
AUS |
|
Middle East |
MDE |
Each SMS site contains at least one resource domain. In large building sites, collections of resource domains, grouped as SMS domains, can be managed by a single SMS site server, which is the PDC for one of the resource domains it manages. The SMS site server automatically detects all servers configured as BDCs for a resource domain and configures them as SMS collection/distribution points. Metro-area primary site servers are domain controllers in account domains, which allows auto-detection and management of all account domain controllers.
Example: A metropolitan area contains resource domains in locations called xxx, yyy, zzz and so on. The metropolitan primary site server is a domain controller in the xxx resource domain. Secondary site servers exist in each resource domain in the metropolitan area. All PCs in the metropolitan area are reported by their location (resource domain) to the metropolitan site server "Metro_site_name". Logically the hierarchy appears as:
Figure 1: Hierarchy of metropolitan system
Use all resource domain PDC/BDCs as collection points for inventory and distribution points for software packages. This approach load-balances SMS activities across resource servers, localizes SMS-generated network traffic, and minimizes potential points of failure. From the resource domain PDC (secondary site server) SMS automatically detects the resource domain BDCs, and configures them with the appropriate NT services and SMS directories and files. Account domain controllers house the LOGON.BAT script file that initiates SMS, and the SMSLS.INI that maps each machine to its respective SMS site.
When needed for performance reasons, confine SMS duties to specified resource servers. Any resource server designated as non-SMS should not be configured as a PDC or BDC for any resource domain. For example, high-demand resource servers running imaging applications should contain no SMS server activity, and are managed by the SMS system as clients. NT applications that require a domain controller are either placed in an SMS domain (manually configured by the SMS administrator) or create their own resource domain and are managed as clients.
Dedicated application servers, such as database servers hosting OLTP applications, should not configured as SMS servers.
Also as needed for performance reasons in the future, SMS site server duties can be further distributed among multiple servers by configuring SMS helper servers to run specific SMS services for a site server.
Assumptions in the site hierarchy and their implications:
Assumption: Existing resource servers are used as SMS collection/distribution points.
Implication: Existing resource servers incur additional burden and require additional system resources (24 MB RAM, 2 GB disk). They must be sized to handle the additional load of SMS.
While user accounts are managed by business unit-specific NT account domains, physical client machines belong to (and can be managed by) location-oriented NT resource domains. Resource domains exist for each location, and SMS uses this resource domain distribution to build its site hierarchy, then uses all resource domain PDC/BDCs as collection points for inventory and distribution points for software packages. Account domain controllers detect new networked client machines automatically upon authentication of each user, an approach that evenly balances SMS load activities across resource servers, and greatly reduces "single point of failure" potential.
This approach allows the team to control the SMS rollout process easily, and significantly eases the desktop/network rollout process. By making it possible for SMS to be "turned on" for new client machines only through the logon/authentication process of new NT users, this enables SMS and the new desktop/network to be rolled out simultaneously. New users turn on their new NT workstations for the first time, logon to the new NT network for the first time, and immediately have SMS loaded and their inventory reported for the first time. As more desktops are rolled out, and the SMS system grows, SMS functions as real-time management mechanism for the new environment during migration. Each group of new desktop/network users is manageable almost immediately through SMS.
SMS is activated on workstations by executing SMSLS.BAT from a logon server. Clients execute SMSLS.BAT automatically from a site server upon being validated by the preconfigured account domain controllers. SMSLS.BAT determines if SMS client code is already resident on the client machine, and, if it is, moves on to the inventory collection phase. If SMS is not resident on the machine, SMSLS.BAT initiates the client installation process and collects initial inventory.
To ensure that each client machine runs SMSLS.BAT, a standard network logon script named LOGON.BAT connects clients to SMS servers and executes the SMSLS.BAT file during every user's network logon. Local sites can implement their own logon scripts by creating a LOCAL.BAT file, which is called by the standard network logon script after SMSLS.BAT.
The master LOGON.BAT file resides on (and is managed from) the IT PDC. The NT Replicator Service on this machine is configured to distribute (or export) this standard logon script to all account domain controllers.
When any domain controller performs logon authentication for any client in the enterprise, it always calls LOGON.BAT, an approach that assures that new machines are discovered by the SMS system (as they are added), are mapped to the appropriate site servers, and are never inadvertently excluded from the inventory process.
SMSLS.BAT executes setup routines to install client components and report inventory. One of these routines, SETLS.EXE, checks a configuration file called SMSLS.INI for custom SMS settings. This text file is configured to map each machine's inventory to the resource domain it belongs to, rather than to the account domain where the user logged on (which is the SMS default) because many users will be authenticating across the WAN. Each secondary site server has a secondary site server defined to map directly to its resource domain.
The master SMSLS.INI file resides on (and is managed from) the IT PDC. The NT Replicator Service on this machine should be configured to distribute this file to all account domain controllers.
Note
Users should not connect manually to an SMS server to run SMSLS.BAT: this causes their machine's inventory to be reported through their logon account domain rather than their location-specific resource domain.
Metropolitan-area site servers are the domain controllers in each account domain. Secondary site servers are the domain controllers in the resource domain that makes up their site. For example, the Seattle secondary site server is the PDC/BDC for the Seattle resource domain.
Below is an example network diagram of a metropolitan site called Pittsburgh:
Figure 2: Network diagram of Pittsburgh site
Assumptions in network configuration and their implications:
SMS servers store inventory information in a relational database management system (RDBMS) Microsoft SQL Server for Windows NT. Each SMS primary site server maps to a SQL database that may reside either on the same Windows NT Server machine, or on a different machine running SQL Server. Inventory from each child-site is reported upward to its parent-site, which continues reporting upward to higher level parent-sites until it reaches the central site database containing the inventory for all of the enterprise.
The SMS database schema is very normalized, comprising approximately 93 tables tied together through a master table of relations. Each computer in the enterprise is stored as its own record in the database and requires approximately 10 KB of storage. Each machine is assigned a unique SMSID which is used as the database's primary key. For example, a database of 24,000 client machines and 500 servers should require approximately 240 MB of storage.
After initial inventory is reported during SMS client installation, only inventory changes are reported to the SQL Server by SMS site servers. The change files are extremely small, so there is negligible network traffic generated for inventory reporting after the initial reporting. By using primary site servers only at the metropolitan-level, the required number of SMS databases is minimized. All inventory data should be housed on a single SQL Server located in the central data center. This machine should have enough disk space for the database and OS, and a redundant disk array should be added to ensure data integrity. The RAM should be able to accommodate multithreading the database transactions from all the site servers. A centralized SQL Server is easily maintained, backed up, etc. Schedule reporting from all site servers to the central site (across the WAN) to occur during off-peak hours.
Alternative: If the central SQL Server performance is degraded by high network traffic or CPU utilization, SQL Servers can be added to the metropolitan-area primary site servers to collect inventory information from their sub-sites and forward it to the central SQL Server. Corresponding SMS servers can redirect their inventory reporting to these databases, which is then forwarded to the central site during off-peak hours.
Assumptions of database configuration and their implications:
Workstations post inventory files to any SMS-configured resource server (PDC or BDC) in their resource domain. SMS NT services on the secondary site server collect inventory files from the resource servers and pass them to their parent primary site server, which posts inventory changes to SQL Server, which passes them to its parent primary site.
The inventory reporting flow logically appears as:
Figure 3: Inventory reporting flow logic
Here is a closer look at a single metropolitan area:
Figure 4: Metropolitan site configuration
A single SMS Administrator account, called SMSAdmin, is defined in the account domain, which is trusted by every other domain in the enterprise. The SMSAdmin account belongs to the SMSADMINS group, which is added to the Administrators local group on each SMS site server, and to the Domain Administrators global group in each resource domain. Each site server has SMSADMINS added to the "Logon As a Service" user rights list. This approach allows management of any part of the SMS system in the enterprise based on a single user account. This account can be maintained and modified as needed, or additional accounts can be added to SMSADMINS.
In addition to the SMS Administrator account, an account/password is required to logon to a site's database and perform SMS management of that site and its sub-sites. The SQL Server databases for each primary site need an account/password unique to that site, and the SMS administrator must use it to logon to the site's database. This allows authorized IT and business unit personnel to manage the SMS system, but allows only authorized SMS administrators to log into and manage a site.
Once available, workstations should be configured with all remote access options disabled by default so that users must explicitly allow for remote desktop takeover by granting permission to the central administrators.
Assumptions made during security planning and their implications:
Design tables similar to the following that detail specific settings required on all machines in the SMS system.
|
Windows NT server settings |
Systems Management server settings |
|---|---|
|
Will be a DC in the valid account domain. |
SMS volume must be NTFS. |
|
Create SMSAdmin account in the account domain (full admin rights), add SMSAdmin to SMSADMINS group. |
Site code is CSS. Site name is [Corporation Name]. |
|
Add SMSADMINS group to "Logon As A Service" user rights. |
SQL database server is \\server. |
|
Add Repluser account for NT Replicator Service and add to REPLICATOR group. |
Database Name is SMS (caps). SQL Server logon is xxx/xxx. |
|
Contains master LOGON.BAT file in: \winnt35\system32\repl\export\scripts. |
Contains master SMSLS.INI file in: \winnt35\system32\repl\export\scripts. |
|
Configure Replicator Service to export \winnt35\system32\repl\export\scripts to all account domain BDCs and PDCs. |
|
| Synchronize time with Time Service. |
|
| Ensure IT domain is trusted from all other domains. |
|
|
Windows NT Server settings |
Systems Management Server settings |
|---|---|
|
Should be a domain controller for an account domain. |
SMS volume must be NTFS. |
|
Add SMSADMINS group to local Administrators group. |
Site code is 3 letters code as described above. |
|
Add SMSADMINS group to "Logon As A Service" user rights. |
Site name is city specific. |
|
Synchronize time with CSS (Net Set Time). |
SQL database server is \\server. |
|
| SQL database name is SMS. SQL device names are SMSData and SMSLog. |
|
Windows NT Server settings |
Systems Management Server settings |
|---|---|
|
Should be a PDC or BDC for one of the resource domains it will manage. |
SMS volume must be NTFS. |
|
Add SMSADMINS group to local Administrators group. |
Site code is 3 bytes: first byte is the first letter of the parent site; other 2 bytes are a sequential number (for example. P01, P02, P03 in Pittsburgh). |
|
Add SMSADMINS group to "Logon As A Service" user rights. |
Site name is building specific. |
|
Synchronize time with CSS (Net Set Time). |
No direct SQL database (it is reported through parent-site). |
|
Windows NT Server settings |
SQL Server settings |
|---|---|
|
Cannot be a domain controller. |
A SQL device called SMSData will house the central database (SMS). A second device will house the SMS log file (SMSLog). |
|
Servername is \\server. |
Create SQL devices for each primary site's data and log files. |
|
SQL Admin accounts configured for SMSAdmin. |
Set maximum user connections = xxx. |
|
Synchronize time with CSS (Net Set Time). |
Configure TEMPDB size = xxx. |
|
| Set number of SQL connections = xxx. |
|
| Configure memory option = xxx. |
|
| Configure open objects option = xxx. |
|
Windows NT Workstation settings |
Systems Management Server client settings |
|---|---|
|
Must be a member of a valid resource domain through Control Panel/Networks setting. |
User completes User Information MIF upon initial installation. |
|
Must Logon to Windows NTS "from" a valid account domain to run LOGON.BAT. |
Set PCM interval to 240 minutes. |
|
Synchronize time with CSS (Net Set Time). |
User may set default remote control options. |
|
Windows 3.x settings |
Systems Management Server client settings |
|---|---|
|
Must be a member of a valid resource domain through Control Panel/Networks setting. |
User completes User Information MIF upon initial installation. |
|
Must Logon to Windows NTS "from" a valid account domain to run LOGON.BAT. |
Set PCM interval to 240 minutes. |
|
Synchronize time with CSS (Net Set Time). |
User may set default remote control options. |
|
Non-Windows NT clients should check: SYSTEM.INI Device=\windows\vuser.386 TimerCriticalSection= NetHeapSize= WIN.INI Load=SMSRUNx.EXE AUTOEXEC.BAT CLIENT.BAT SMS.INI SMS ID Domain settings Logon server designation Help desk options Package Command Manager options CLIENT.BAT SMSRUNx.INI
|
Initial SMS client configuration occurs during a user's first logon/authentication on the new NT network. Account domain controllers that validate user accounts are pre-configured to execute SMSLS.BAT, which installs SMS on the client machine.
SMS creates a directory called \MS\SMS, and copies the necessary files and subdirectories to it, then adds to the Windows Program Manager or Start Menu a program group called Systems Management Server, which contains icons for various SMS components.
During initial installation, the user is prompted to complete a User Information Form (user MIF). This information is stored with the machines' inventory. The default user MIF can be modified to include corporation-specific fields such as Business Unit, Department, and Bay location--fields which allow administrators to manage hardware and software by enterprise organization as well as by geographical location.
The user can change the MIF at any time (for instance, if a machine is moved). Other fields may be added, or custom MIF forms developed, to collect any other information from a user, such as employee ID#, serial numbers of telephones and chairs, etc.
All remote control settings should be disabled by default.
Assumptions made during client configuration and their implications:
Assumption: Once available, workstations are configured with all remote access options disabled by default. User must explicitly allow for remote desktop takeover by granting permission to the central administrators.
SMS is primarily a store-and-forward management system (with the exception of real-time troubleshooting utilities). Once SMS is installed, SMS activities for clients and servers are based almost exclusively on timed intervals: SMS components "wake up" at specified times to perform duties. This provides a very flexible means of managing network bandwidth use by scheduling network-intensive SMS operations to occur during off-peak network traffic hours (distributing software to site servers across the WAN). The site hierarchy cascades large scale networks geographically, further minimizing network bandwidth utilization by localizing most SMS network activity.
Tuning an SMS system entails configuration of many interdependent timing intervals and polling rates, and as in most things it is important to have appropriate expectations for what SMS can or cannot do. For example, distributing a large software package can easily take several hours. And some changes may take up to 24 hours to be reflected at the central site database.
System tuning always involves tradeoffs and in this case they are between bandwidth and "real-time" management. If all levels of inventory must be reported upwards frequently (and reflected in the central database quickly), then the frequency of timed SMS events must go up and so must bandwidth use. Conversely, if bandwidth use must be minimized, then decrease the frequency of events in order to decrease network traffic.
Start out by protecting network bandwidth by keeping event timing and polling intervals at the system defaults (see table below). If system management requires more immediate response from the SMS system, the SMS administrator can force synchronization by manually "waking up" SMS components immediately. If delayed synchronization hinders everyday management, modify event timing.
In this case, the recommended timed interval for Package Command Manager is 240 minutes rather than the default 60 to limit its 10-second user interruption to three times a day: once at logon in the morning, once around lunchtime, and once at the end of the work day.
|
SMS Component |
Timed Interval |
|---|---|
|
Inventory Agent |
24 hr |
|
Site Hierarchy Manager |
N/A |
|
Site Configuration Manager |
24 hr |
|
Senders |
N/A |
|
Inventory Data Loader |
N/A |
|
Scheduler |
N/A |
|
Despooler |
N/A |
|
Package Command Manager |
240 min |
For more information on using and configuring these components, see Appendix A of the SMS Administrator's Guide.
Assumptions made during event timing and their implications:
Standardizing software across the corporation (discussed earlier in this document) is crucial to software distribution in the plan discussed in this paper. If your environment does not permit software standardization, however, see the end of this section for recommendations on planning software distribution in a mixed environment.
For SMS design purposes, client software should be categorized as standard or nonstandard. Standard is company or business unit-wide software (Windows NT, Microsoft Office, SAP, PDM, or SPRY). Nonstandard is software used by few or not on the Standard list.
Standard software is installed initially from the loadset, with slight variations depending on business unit needs. SMS is needed to distribute standard software in three cases:
While standard software is electronically distributed only infrequently, it still should be distributed to each SMS Site server. This provides backup, and can be particularly useful in disaster recovery. Whenever a user requests a standard software load, the SMS administrator can schedule an immediate SMS job to run the installation from the user's local SMS site server, which already has the standard software in uncompressed form. If the user's site server is down, the SMS administrator can redirect the installation to be run from the nearest working site server.
This approach uses more disk space on site-level servers, but can save bandwidth by not transmitting standard software across the WAN to satisfy user requests. It also circumvents the delay (several hours) from the time the SMS administrator creates a new SMS package to the time it arrives and is decompressed on the distribution server: users can install standard software within 15 minutes of requesting it.
Nonstandard software can also be staged on distribution servers if the increased disk usage is justified by the number of users.
Here are some recommendations for staging standard software or distributing a new version to many users:
By default, SMS distribution jobs target machines, or groups of machines, for distribution and installation of software. Groups can be created easily by querying the SMS database. For example, query on the machines running Excel 4, then target that group for Excel 5 installation.
Use an SMS "Sharing Package" to target groups of users based on their NT account groups (SAP users, accountants, managers, etc.). A package shares a Windows Program Group to execute a network-resident application, or shares instructions to install an application locally.
Assumptions of software distribution and their implications:
When deciding how to deploy software distribution in your SMS environment:
SMS Help Desk and Diagnostics utilities provide direct control and monitoring of remote clients running MS-DOS, Windows version 3.1, Windows for Workgroups version 3.11 and Windows 95. The Diagnostic utilities enable you to view a remote client's current configuration; the Help Desk utilities provide direct access to a client.
The Diagnostics are run from within the Personal Computer Properties dialog box of the SMS Administrator, but for security purposes the Help Desk utilities are disabled by default and can be enabled only by a user at the remote client you want to control. SMS supports remote control across a RAS connection and across IPX and IP routed networks.
Remote troubleshooting is not supported across an SNA link nor on clients running Macintosh or Windows NT. In addition, SMS does not support running multiple remote troubleshooting sessions from a single SMS Administrator tool computer.
Before you can use the remote troubleshooting utilities on an SMS client:
Diagnostic Utilities include: CMOS Info, Device Drivers, ROM Info, Interrupt Vectors, DOS Memory, Ping Test, Windows Memory, Windows Modules, Windows Tasks, Windows Classes, Global Heap and GDI Heap.
Help Desk utilities include: Remote Control, Remote Reboot, Remote Chat, File Transfer, and Remote Execute
For more information on these utilities, remote troubleshooting, configuring protocol settings, configuring remote support across a router, and setting up help desk options at the target client see Chapter 15 of the SMS Administrator's Guide.
Windows Program Groups are shared by groups of users to launch network-resident applications. All locally-resident applications have a Program Group, and SMS can be used to manage them.
For example, an administrator can use a single SMS Sharing Package to send all members in an NT group called SAPUSERS a Windows Program Group called SAP, which contains icons that launch SAP from a network server. When SAPUSERS members log on (to any machine in the enterprise) the SAP Program Group appears on their desktop. (It does not appear for nonmembers.) Users who roam the network, logging into several machines at different locations, still get the SAP Program Group. If several users alternate using a single machine, the SAP Program Group appears for SAPUSERS members.
Assumptions of program group control and their implications:
Proper SMS system design reduces maintenance.
The central SQL database server requires regular backup, but since it resides in the central data center this job can easily be added to a computer operator's regular duties. Perform a full backup each week, with incremental backups throughout the week.
The SMS system itself requires minimal maintenance. It also provides operational stability: if any portion of the system besides the central database goes down, minimal functionality is lost.
The Windows NT Performance Monitor should be used regularly to assess performance of various system components for retuning as needed.
Stage3 Alpha testing, as defined in the Test Plan, introduces the recommended SMS design to small groups of users in a controlled manner.
Testing process objectives:
Testing process phases:
The basic assumption for Stage3 testing is that the network design meets the assumptions defined in the SMS design document. Also, the SMS team should have documented details of the network design to work from.
Note
The system tested in these final stages before rollout is not production. Refining the SMS design based on these test results may involve re-installation.
Figure 5: SMS Alpha configuration
The new Windows NT network infrastructure must be in place and tested prior to SMS installation. SMS administrative accounts and directory replication are configured and tested first.
SMS requires dedicated servers for the central site and the SQL Server. Primary site servers use existing account domain BDCs, but may be moved to dedicated machines depending on performance. All resource domain controllers should be configured with at least 16 MB RAM and 2 GB disk above the minimum hardware requirements anticipated for resource sharing; all servers should be equipped with a chosen standard modem (for backup async site-to-site communications) and have access to a secure dial-out service.
See your SMS documentation for more information on hardware requirements for SMS site servers.
Note
The BDCs already exist in the NT Domain
|
Resource |
Tasks |
|---|---|
|
Implementation specialist |
all |
|
Implementation specialist |
all |
|
IT personnel |
all |
|
Documentation support personnel |
process documentation, helpdesk support |
These are the test system installation tasks:
For this test to succeed, users must be working in their production environment. Set up the testing schedule to minimize intrusion and downtime for the user community. Before starting testing, hold a brief session to inform users exactly what to expect, when, and why, and to demonstrate the SMS client software and familiarize them with the test. Set up the test environment so that users launch SMSLS.BAT from within a separate logon script; this makes it possible to disable SMS on users' systems if testing encounters severe problems. Remove SMS from each user's system after testing and before rollout.
Design configuration tables such as the ones below to show how to install the test system. Install the central site first, then the primary sites, then the secondary sites.
|
Windows NT server settings |
Systems Management server settings |
|---|---|
|
Must be a DC of the account domain. |
SMS volume must be NTFS |
|
Create SMSAdmin account in the account domain (full admin rights), add SMSAdmin to SMSADMINS group. |
Site code is CSS. Site name is [Corporation Name]. |
|
Add SMSADMINS group to "Logon As A Service" user rights. |
SQL database server is \\SMSDB. |
|
Add Repluser account for NT Replicator Service and add to REPLICATOR group. |
Database Name is SMS (caps). SQL Server logon is xxx/xxx. |
|
Contains master LOGON.BAT file in: \winnt35\system32\repl\export\scripts. |
Contains master SMSLS.INI file in: \winnt35\system32\repl\export\scripts. |
|
Configure Replicator Service to export \winnt35\system32\repl\export\scripts to all IT BDCs and all other account domain controllers |
|
| Synchronize time with Time Service. |
|
| Ensure IT domain is trusted from all other domains. |
|
|
Windows NT Server settings |
SQL Server settings |
|---|---|
|
Can be a PDC or BDC for any domain. |
A SQL Device called SMS houses the central database (SMS_Data). A second device houses the SMS log file (SMS_Log). |
|
Servername is \\SMSDB. |
Create SQL Devices for each primary site server (SMS_{3 digit site code}. Create SMS Devices for each primary site's log file (SMS_{3 digit site code}_Log). |
|
SQL Admin accounts configured for SMSAdmin. |
Create databases on corresponding devices for SMS data. |
|
Synchronize time with CSS (Net Set Time). |
Set Maximum User Connections = xxx. |
|
| Configure TEMPDB size = xxx. |
|
| Set number of SQL Connections = xxx. |
|
| Configure memory option = xxx. |
|
| Configure open objects option = xxx. |
|
Windows NT Server settings |
Systems Management Server settings |
|---|---|
|
Should be a PDC or BDC for one of the resource domains it will manage. |
SMS volume must be NTFS. |
|
Add SMSADMINS group to local Administrators group. |
Site code is 3-letter code as described above. |
|
Add SMSADMINS group to "Logon As A Service" user rights. |
Site name is city specific. |
|
Synchronize time with CSS (Net Set Time). |
SQL database server is \\SMSDB. |
|
| SQL database name is SMS_xxx_Data where xxx is the site code |
|
| SQL log file name is SMS_xxx_Log where xxx is the site code |
|
Windows NT Server settings |
Systems Management Server settings |
|---|---|
|
Should be a PDC or BDC for one of the resource domains it will manage. |
SMS volume must be NTFS. |
|
Add SMSADMINS group to local Administrators group. |
Each site code must be unique. If there are many secondary sites, create their 3-letter codes by combining the letter of the parent primary site with a 2-digit number. Assign the 2-digit numbers sequentially |
|
Add SMSADMINS group to "Logon As A Service" user rights. |
Site name is building or campus-specific. |
|
Synchronize time with CSS (Net Set Time). |
No direct SQL database (it is reported through parent-site). |
|
Windows NT Workstation settings |
Systems Management Server client settings |
|---|---|
|
Must be a member of a valid resource domain through Control Panel/Networks setting. |
User completes User Information MIF upon initial installation. |
|
Must Logon to Windows NTW "from" a valid account domain to run LOGON.BAT. |
Set PCM interval to 240 minutes. |
|
Synchronize time with CSS (Net Set Time). |
User may set default Remote Control options. |
|
Windows 3.x settings |
Systems Management Server client settings |
|---|---|
|
Must be a member of a valid resource domain through Control Panel/Networks setting. |
User completes User Information MIF upon initial installation. |
|
Must Logon "from" a valid account domain to run LOGON.BAT. |
Set PCM interval to 240 minutes. |
|
Synchronize time with CSS (Net Set Time) |
User may set default Remote Control options. |
|
Non-Windows NT clients should check: SYSTEM.INI Device=\windows\vuser.386 TimerCriticalSection= NetHeapSize= WIN.INI Load=SMSRUNx.EXE AUTOEXEC.BAT CLIENT.BAT SMS.INI SMS ID Domain settings Logon server designation Helpdesk options Package Command Manager options CLIENT.BAT SMSRUNx.INI |
Check these functional areas, using the recommendations defined in the SMS document as task lists:
Record all network and SMS configuration settings:
Next, document test results with the original settings you recommended. Change network and SMS settings as needed to achieve desired SMS performance. Document configuration changes before re-testing.
NOTE
Configuration changes made for one purpose may adversely affect results in another area. Record default settings so you can reinstall the SMS system if necessary.
As testing proceeds, have a documentation specialist write up operational guidelines and procedures for using SMS for help desk support:
Also document administrative guidelines, including:
Test results can help you refine the SMS design and operational guidelines to optimize client and server performance, and to achieve a well integrated, non-intrusive solution. Focus on minimizing impact on users and optimizing overall system performance.
When testing is over, completely uninstall all components of the test system. The "refined" design is now the final SMS design, and should be documented accordingly. Use this final design to develop the rollout plan.
These resources can help you to plan and deploy SMS in your enterprise.
|
Resource |
Availability |
|---|---|
|
SMS Administrator's Guide |
Included with SMS Documentation |
|
Windows NT Resource Kit |
TechNet CD or MS Press |
|
Windows 95 Resource Kit |
TechNet CD or MS Press |
|
Systems Management Server and NT Knowledge Bases |
TechNet CD or Online Services |
This paper has presented an overview of the planning, testing and implementation of a Microsoft Systems Management Server solution for a large enterprise. There are numerous sources of information (listed above) to help you find out more about the general concepts and specific tasks involved in creating an SMS solution. Appendix A, following, has some general information on SMS and what it can offer systems planners and support personnel. If you are interested in learning more about SMS, please contact Microsoft.
This appendix contains general information on Systems Manager Server features and benefits. It is excerpted from the Microsoft Systems Management Server Reviewer's Guide.
Although businesses today spend large amounts of money to upgrade, maintain, and support software on desktop computers, they sometimes still fight a losing battle. Large businesses try to maintain thousands of desktop PCs that may be located all over the world. Medium-sized businesses often grow until they have a variety of systems distributed over several locations and supported by personnel who cannot keep up. Smaller businesses may see the value of desktop PCs, yet have no resources to maintain or even out-source them.
Data collected by the Gartner Group indicates that the capital cost of acquiring personal computers for a networked environment varies from 10%-18% of the total cost of ownership (depending on the platform) over the five year life cycle of the machines. The following chart shows the typical cost of ownership of a Windows-based personal computer over five years.
TOTAL COST OF ONE PC (5 years)
|
Capital |
$5,670 |
|
Support |
7,045 |
|
Administration |
5,832 |
|
Operations |
22,892 |
|
TOTAL |
$41,439 |
|
Source: Gartner Group, August, 1994 |
|
Figure 1: Typical five-year cost of ownership for Windows-based personal computer
The vast majority of the cost is for support, administration, and operations. Microsoft Systems Management Server dramatically reduces the cost of managing distributed desktop PCs because it is the most comprehensive solution available for centralized PC management on any size network--from 10-users to large enterprises. Systems Management Server is a client/server system that enables centralized management of networked computers, removing the need for support personnel to go to desktops to determine configuration, install or upgrade software, or troubleshoot problems.
Systems Management Server offers enhancements for businesses of every size:
Many currently available solutions can perform some of the desktop PC management services required by IS professionals, but they are limited in functionality and applicability. Systems Management Server, on the other hand, provides:
Systems management on mainframe computers has been available for some time. It consists of managing data, applications, and the operating system, as well as performing tasks such as system scheduling, making sure there is enough capacity, and charging different departments for computer time. Systems management typically is local: everything is inside one computer room, or, in the case of a large company, two or three computer rooms around the world. This approach has allowed for fully automated or "lights out" management.
However, as businesses deploy more and more personal computers, systems management has lagged behind. While some basic issues have remained the same, managing ever growing distributed environments has created new problems. Administrators need effective ways to control software versions, manage users, automate repetitive tasks, and manage different configuration files for every machine. It can be difficult to inventory all the PCs within a large enterprise, and more difficult still to determine their hardware and software. Yet to install or upgrade software throughout the enterprise, support personnel have to make sure that versions are correct for each user and that individual machines are capable of running the new software.
Even with the best planning, things can go wrong. Support personnel need tools to locate and diagnose problems so that machine down time is minimized. Support costs should be reduced by diagnosing and resolving problems from one centralized location. These things need to be accomplished in existing environments, and in the future as business needs change.
Solving these types of business problems is what systems management is all about. Microsoft Systems Management Server offers these advantages:
Traditional network management focuses on the network's physical and logical infrastructure (hubs, bridges, and routers) as well as the transports that connect them. Its applications have to create a graphical map of the network, automatically detect devices, provide warnings, and manage other events from a central location.
Systems management, on the other hand, focuses on the end node and the systems and software running on the PC. Network management is still important, and vendors such as Computer Associates, Digital, Hewlett-Packard, IBM, Legent, and Network Managers complement Systems Management Server with tools that manage network infrastructure. Microsoft is working with a number of vendors to integrate their network management products into the Systems Management Server framework.
Two types of IS professionals directly benefit from Systems Management Server:
Many businesses today have deployed Windows 3.1 in their environment with a number of productivity and business applications running on PCs linked to a networked file server (such as Novell NetWare, Microsoft Windows NT Server, LAN Manager, and IBM LAN Server) used for file and print serving. The IS staff must, among other duties, manage configuration files such as the initialization files WIN.INI and SYSTEM.INI. Each machine can easily have more than 20 of these, each with a specific configuration, and the administrator must know their location and contents at all times. Systems Management Server makes it easy to monitor each PC's configuration files from a central location. This can reduce help desk calls by correcting some problems before the user is even aware of them.
New software often costs more to deploy and support than it does to purchase and license. This is especially true when upgrading to major new releases, such as Windows 95 or Office 95. Systems Management Server makes possible automatic, unattended upgrades to any new software package, and allows the administrator to target machines to be upgraded, specify configuration options for machine, schedule the upgrade, and, of course, learn the status of the installation. This drastically reduces costs and problems.
Many businesses need to integrate systems management with existing network management solutions, including physical network management. Microsoft is working with a number of companies to integrate Systems Management Server into their network management applications, so that they can reach desktop PCs as well--thus providing a complete, complementary management solution. This form of integration can mean that from within the network management topology map an operator can double-click on an icon to review the full Systems Management Server properties of a machine and can take control of the remote machine and perform all Systems Management Server functions. In addition, important systems management information that is recorded within the Systems Management Server system can be redirected to the network management console when appropriate (for example, if the file server is very low on disk space).
Systems Management Server features benefit computer professionals who deal with the cost and complexity of building, maintaining and managing businesses that use PCs in a distributed network of any size. The table below presents a quick overview of major features and benefits.
|
Key product feature |
Major product benefits |
|---|---|
|
PC and server inventory |
Automatically identifies and maintains a central inventory of PCs and servers. Automatically installs the client management agent on the client machine; no need to visit each machine. Performs detailed hardware and software inventory, including historical changes and collected files. Software audit identifies software packages based on an extensible database. Collects any DMTF-compatible hardware characteristics and other administrator-defined inventory information. |
|
Software distribution and installation |
Distributes and installs software on individual PCs and servers at remote sites. Allows administrators to drag and drop centrally defined packages on target systems. Automatically installs software on individual PCs at the time specified by the administrator. Installs software on specific servers to be automatically shared by specific users (based on user names or user groups). Allows administrators to define standard desktops that users always receive when they connect to the network, independent of location. Schedules any command on specific PCs using scripting tools such as Microsoft Test. (For example, you can automatically run virus scanning software every Saturday at midnight on all 486 PCs with 500 MB or larger disks.) |
|
Software metering |
Tracks software licenses used by installing software on individual PCs. Windows NT Server 3.5x can enforce concurrent use software licenses. Systems Management Server can automatically connect concurrent users to available servers, ensuring that users have access to all licenses across multiple servers. Windows NT Server's Performance Monitor provides detailed graphs and logs of concurrent application usage to help manage license requirements. |
|
Diagnostic and remote control tools |
Remotely control screen, keyboard, and mouse. Monitor critical system information, execute programs, or reboot individual MS-DOS or Windows-based PCs in real-time from across the LAN or WAN. Monitor performance and events, and manage users and services of remote Windows NT Workstations and Windows NT Servers. |
|
Network packet decoding |
Remotely capture, filter, decode, analyze, edit and replay network protocol packets including TCP suite, IPX/SPX, NetBIOS, AppleTalk suite, NCP, and SMB. Remote capture agents run on any Windows NT Workstation or Windows NT Server. |
|
Security |
Control access to each Systems Management Server function. Network Monitor agents support password protection for additional security. Users determine permissions for remote control functions and are alerted when remote control is active. |
| Benefit: Works with your existing systems | |
|---|---|
|
Client operating systems supported |
MS-DOS 5.0 and later Windows 3.1 Windows for Workgroups 3.11 Windows NT Workstation 3.1 and 3.5 Windows 95 OS/2 2.x and OS/2 Warp Macintosh System 7.x |
|
Server operating systems supported |
Windows NT Server 3.1 and 3.5x LAN Manager 2.1 and later NetWare 3.1x and 4.x LAN Server 3.x and 4.0 |
|
Wide area network protocols supported |
Any network protocol supported by Windows NT, including TCP/IP and IPX LU 6.2 provided by Microsoft SNA Server Remote access protocols including ISDN, X.25, and asynch |
|
Additional support from third parties |
PathWorks servers (available from Digital) UNIX: AIX, HP-UX, OSF/1, Sun OS, Solaris, and Ultrix (available from Digital) VMS (available from Digital) |
| Benefit: An open foundation that can be extended easily | |
|---|---|
|
Large third part support |
More than 25 independent software vendors (ISVs) have announced plans to integrate their products with Systems Management Server including: Software recognition technology from Tally Systems Enterprise storage management from Arcada Software metering from Express Systems |
|
Network management products integration |
Traditional network management vendors are in the process of integrating their products with Systems Management Server. Examples are: Digital's PolyCenter Manager on NetView, Hewlett-Packard Open View, IBM NetView/6000, Network Manager's NMC Vision, and Compaq's Asset Control. |
|
Support for standard interfaces |
Systems Management Server supports other management standards, such as Simple Network Management Protocol (SNMP) and IBM's Netview. The Systems Management Server database can be accessed from any ODBC application, enabling reports of inventory information to be quickly generated. Systems Management Server offers support for the Desktop Management Interface (DMI), created by the Desktop Management Task Force (DMTF). |
|
Services offered by Service Providers |
Corporate Software, InfoNet, and Software Spectrum all provide a range of software distribution and management services that integrate with Systems Management Server. |
| System requirements | |
|---|---|
|
Server requirements |
Windows NT Server 3.5x 486/66, Pentium, or RISC-based processor supported by Windows NT Server 3.5 20 MB RAM minimum (28 MB is recommended if a server is also running Microsoft SQL Server) 100 MB free disk space (more recommended for larger environments) Access to any CD-ROM drive supported by Windows NT Server 3.5 A single SQL Server 4.21a or 6.0. Additional SQL Servers are optional at remote sites. |
|
Remote management console |
Windows NT Workstation 3.1 and 3.5x Windows NT Server 3.1 and 3.5x |
|
Distribution |
Any Microsoft authorized reseller or Solution Provider |
|
Warranty period |
90 days |
|
Sales support |
(800) 227-4679 |
About the Author
Paul Bethany is a Senior Consultant wtih Microsoft Consulting Services, Philadelphia.
Microsoft Consulting Services offers analysis, design and implementation services for deployment of Microsoft Systems Management Server and other Microsoft BackOffice solutions tailored to meet the needs of your organization. For more information call MCS at 1-800-426-9400 in the US, (905) 712-0333 in Canada, or contact your local Microsoft subsidiary.
Microsoft TechNet
December 1995
Volume 3, Issue 12
| Click Here to Search TechNet Web Contents | TechNet CD Overview |
| Microsoft TechNet Credit Card Order Form At this time we can only support electronic orders in the US and Canada. International ordering information.
|
| Go To TechNet Home Page
| ©1996 Microsoft Corporation |  Go To Microsoft Home Page |