Preinstallation Requirements

[Previous] [Next]

In this section, we'll explore the specific hardware and software requirements for SMS sites and site systems, beginning with Microsoft SQL Server because it is an integral part of SMS and because the SQL Server database serves as the repository for most of the data that SMS collects. To that end, we will explore database size and security considerations as well as SQL Server optimization considerations. We will also explore the hardware and software requirements of the Windows NT server that will become your SMS site server.

SQL Server Requirements

SMS 2.0 requires a server running SQL Server 6.5 with Service Pack 4 or later applied or SQL Server 7.0. In SQL Server 6.5, databases and their corresponding transaction logs are created and maintained in devices. A SQL device represents a placeholder, or predefined storage space, for the database and for its transaction log. SMS requires separate devices for the SMS database and for the transaction log. As with SMS 1.2, if SQL Server is installed on the same computer as the SMS site server, SMS can create the database and log devices for you. If SQL Server is installed on a separate computer, you must create the database and log devices before you install SMS 2.0.

NOTE
If you are using SQL Server 6.5 with Service Pack 4, you will also need to copy an updated file from the SMS 2.0 CD to avoid potential general protection faults. Copy the file Sqlcrt60.dll from the Sqlsetup\Sqlhotfix<platform> folder on the SMS 2.0 CD to the Mssql\Binn folder on the SQL server. SQL Server 6.5 with Service Pack 5 and SQL Server 7.0 are not affected.

SQL Server 7.0 does not require the creation of devices for the database and log files. Instead, the database and transaction logs are maintained in separate files. Again, if SMS 2.0 is to be installed on the same computer as SQL Server, SMS 2.0 can create the database and log files for you. If not, you will need to create the files ahead of time.

If you install SMS 2.0 on the same computer as SQL Server, SMS 2.0 will not only create the devices for you, but it will also tune SQL Server for use with SMS 2.0. This does not, of course, relieve you of all responsibility for maintaining the SQL server, but it does ease some of the setup concerns regarding SQL Server, which is especially helpful if you have little experience with SQL Server.

MORE INFO
While a working knowledge of SQL Server is not required to install and work with SMS 2.0, in the long run, you will need a good working knowledge of at least SQL Server administration tasks. SMS 2.0 is not itself a database server; rather, it acts as a front end to the SMS database maintained in SQL Server. Therefore, many database maintenance tasks will need to be initiated through SQL Server. Consider taking a class in SQL Server administration, such as Microsoft-certified course 832, "System Administration for Microsoft SQL Server 7.0," or 867, "System Administration for Microsoft SQL Server 6.5."

If SQL Server is not already installed on the proposed site server, the SMS 2.0 installation process will prompt you for the SQL Server 6.5 or 7.0 source files and will install a dedicated SQL Server database for itself. In the case of SQL Server 6.5, the installation will also automatically apply SQL Server Service Pack 4.

The burning question then becomes, "Which is better: installing SQL Server on the same computer as the site server, or installing it on a separate server?" Well, it all depends. Microsoft recommends that you have a dedicated installation of SQL Server just for SMS 2.0. This is because of the significant increase in information SMS 2.0 now stores in the database, the over 200 SQL transactions and triggers related to SMS 2.0 processes and services, the 50 connection accounts required just for the site server, the resource requirements of SQL Server itself, and the fact that SMS 2.0 installs Windows Management Instrumentation (WMI) on the SQL Server and uses it to provide access to the database for the SMS Administrator Console.

Installing SQL Server on the same computer as the site server will provide more efficient access to the database for the site server and will significantly reduce network traffic involved with SMS-SQL transactions. However, this arrangement will also require an increased investment in hardware on the proposed site server computer to accommodate the resource requirements for both SMS 2.0 and SQL Server. This cost will be felt in three areas:

  • Processing memory (RAM) SMS 2.0 requires a minimum of 64 MB of RAM, with 128 MB recommended and, quite frankly, 256 MB standard. SQL Server requires a minimum of 32 MB of RAM and is driven largely by the size of the databases it will maintain. So the total RAM requirement will be significant. On the other hand, RAM is relatively inexpensive.
  • Disk storage and I/O SMS 2.0 requires a minimum of 1 GB of disk storage, with a recommended size of 6 GB. SQL Server can require up to 266 MB, depending on the type of installation, and this does not take into account the amount of storage required for the database itself. SMS 2.0 has an automatic minimum of 50 MB for the database and 20 MB for the transaction log. Most SMS 2.0 and SQL processes are disk intensive, so the faster the disk access, the better the performance gained. Unlike RAM, disk upgrades can be costly. For example, hardware-based redundant array of independent disk (RAID) systems offering disk mirroring (RAID 1) and/or disk striping with parity (RAID 5) provide excellent I/O performance as well as fault tolerance in the event of a disk failure. However, such a system can cost $10,000 or more.
  • Processor The type of processor used will obviously affect the performance of the site server. SMS 2.0 requires at least a 133-MHz processor, while SQL Server 7.0 requires at least a 166-MHz processor. Both support the Alpha platform, which provides better performance and more efficient processing. However, you may lose some SMS 2.0 functionality. For example, software metering is not supported on an Alpha-platform site server. The newer Pentium III 500MHz processors in a dual-processor system would be preferable for optimum performance. Again, these types of systems are not inexpensive.

Ultimately you will need to balance resource requirements, network traffic concerns, and overall performance considerations when deciding whether to use a single computer for both SQL Server and SMS 2.0 or to use separate computers.

Sizing the Database

SMS 2.0 requires a minimum database device size (for SQL Server 6.5) or file size (for SQL Server 7.0) of 50 MB and a transaction log device or file size of 20 MB. Microsoft recommends anticipating between 100 KB and 200 KB per client for the database. The transaction log should be at least 20 percent of the database size. Additional factors in determining the amount of database space required include the amount of hardware and software inventory collected, the number of packages, programs and advertisements that will be deployed, the size and number of collections, the type and number of discovered resources, and the number of queries and status messages to be maintained.

The Microsoft Systems Management Server Version 2.0 Release Notes offer the following formula for determining database size:

7.4 MB + (x * 70 KB) where x = number of clients

This formula is based on a weekly hardware and software inventory schedule, default aging (the number of days)of discovery and inventory out of the database, and 20 status messages reported by each client each week. If we apply this formula to a single site with 1000 clients, we get:

7.4 MB + (1000 * 70 KB) = 77.4 MB

Using the base value of 100 KB per client, we would require 100 MB. As you can see, sizing the database is not an exact science, and it will require that you monitor database usage periodically.

TIP
The Microsoft Systems Management Server Version 2.0 Release Notes comes on the SMS 2.0 CD and is installed with SMS 2.0. You can access it through the Systems Management program group.

As if this weren't enough to consider, don't forget your site hierarchy. If you have identified child sites, these sites will report their inventory, discovery records, status messages, and site configuration to their parent site. You must allow space for this additional information in the parent site's SMS database. Needless to say, the greatest cause for concern regarding database space will be at the central site, as it will collect and maintain database information for every site below it in the site hierarchy.

Database Security

Two basic types of security are available for the SQL Server database: integrated and standard. Integrated security indicates that SQL Server will use a Windows NT domain account to provide access to the database. Standard security indicates that you will create or identify a SQL login ID within SQL Server itself that will provide access to the database. The default SQL login ID is sa, which stands for system administrator and has no password assigned.

If you use integrated security, you can create a Windows NT account that SMS will use to create and access the database in SQL Server and then map that account to the sa account using the SQL Security Manager, or you can let SMS use the existing SMS Service account. The SMS Service account (named SMSService by default) is created when you install SMS and is the default account that site server services use to manage Windows NT site systems. By default, all members of the Administrators group in the SQL Server are mapped to the sa account. If the SQL Server is a member of the same domain as the SMS site server, SMS can use the SMS Service account to access the database, as this account becomes a member of the Domain Admins global group in the Windows NT domain, which is, by default, a member of the local Administrators group on every member server in the domain. If the SQL Server is not a member of the same domain, you can either establish a trust relationship between the domain in which the SQL Server resides and the domain in which the SMS site server resides, and add the Domain Admins group from the SMS domain to the Administrators local group on the SQL Server, or you can explicitly create a duplicate account (and password) in the SQL domain so that Windows NT pass-through authentication can allow access to the SQL Server and thus the database.

If you use standard security, use the SQL Server Enterprise Manager to create the SQL login ID and assign it access to the database. You will then provide the SQL login ID to SMS 2.0 during setup.

Tuning SQL Server

If you install SQL Server as part of the SMS 2.0 setup process, SMS will set SQL Server parameters to their optimum settings for you. However, if you install SQL Server yourself you should pay attention to some specific SQL Server configuration parameters and set them appropriately before installing SMS 2.0. Table 2-1 lists these parameters and provide guidelines as to how they should be set.

Table 2-1. SQL Server configuration parameters

Parameter Guidelines
User Connections SMS 2.0 requires a minimum of 40 user connections for the site server and 2 connections for each SMS Administrator Console you plan to install. It also requires 5 additional user connections for each instance of the SMS Administrator Console, if more than five consoles will be running concurrently on your site. You can set SMS 2.0 to calculate this number and configure it automatically during setup. Each installation of SMS 2.0 requires 20 user connections. In SQL Server 6.5, each user connection allocates 40 KB of RAM. In SQL 7.0, this allocation is made dynamically at the time of the connection, providing more efficient memory management.
Open Objects This parameter indicates the number of tables, views, stored procedures, and the like that can be open at a time. If you exceed the specified number of open objects, SQL Server must close some objects before it can open others, resulting in a performance hit. For most sites, although the default is 500, you may want to set this parameter to 1000. For large sites, this number could be 5000 or more. Use SQL Server Performance Monitor counters to track the number of open objects in use to determine the optimum number for the SMS site. Note that SQL Server 7.0 sizes this number automatically.
Memory This parameter indicates the amount of RAM that should be used for database caching and management. SMS automatically allocates 16 MB of RAM for SQL Server use. In SQL Server 6.5, memory is allocated in memory units of 2 KB. Set this value to at least 8192 (16 MB). Increasing this number may improve SQL Server performance, but it may also detract from other server operations (such as SMS site server).

SQL Server 7.0 allocates memory dynamically in 8-KB units. You can define a range for SQL Server to use.

Locks This parameter prevents users from accessing and updating the same data at the same time. Because of the volume of information contained in the database, Microsoft recommends setting this value from 5000 to 10,000 depending on the size of the database and the number of SMS Administrator Consoles.
tempdb Size The temporary database and log are used to manage queries and sorts. By default, the tempdb database and log information are maintained in the same SQL device. (Please see Chapter 18 for details on the SQL device.) For best performance, both should be kept in this default location. Note that this is contrary to what the Systems Management Server Administrator's Guide recommends for high volumes of activity. This recommendation was later corrected in the Microsoft Systems Management Server Version 2.0 Release Notes.

Set the tempdb data device size in SQL Server 6.5 to at least 20 percent of the SMS database device size. Set the tempdb log device size to at least 20 percent of the tempdb data device size. In SQL Server 7.0, as you have by now surmised, the tempdb database is sized dynamically.

While system clock synchronizing is not a function of SQL Server per se, it is nevertheless important that you synchronize the system clocks between the SQL Server and the SMS site server if they are installed on separate computers. When an SMS service or process schedules a task, it will use the SQL Server's system clock to trigger the task.

REAL WORLD  Synchronizing System Clocks

Conventional and unconventional wisdom alike suggest that you identify a time server for your SMS site that synchronizes the system clocks not only between the SQL Server and the SMS site server, but also among all SMS site systems and SMS clients. This should be an essential part of your deployment strategy for SMS 2.0. SMS services use the SQL Server system clock when scheduling tasks. However, SMS clients and site systems will look to their own system clocks when determining when scheduled tasks should run. Scheduling tasks is perhaps most critical with SMS clients.

When you advertise a program to a collection of SMS clients, you can assign a schedule for that program to run, or you can make the program mandatory to run at an assigned time. Advertised Programs Client Agent, the SMS client agent that checks for available advertisements, will determine whether the program is scheduled to run at an assigned time or a mandatory time. However, the agent will determine this schedule based on the system clock of the SMS client. If the system clock is inaccurate for some reason, the program may not run at the expected time, and may never run.

Here's an example. Suppose you have a user who obtains trial software that is time-stamped to run for a specific trial period—say, 120 days. The user decides that she likes the product, but she does not want to actually buy it. To keep using the software beyond the proscribed time period, the easy thing to do is to set the system clock back—perhaps a couple months, or perhaps a year. Not touching on the legal or ethical issues involved here, this tampering can wreak havoc on your advertised programs. As you can see, something scheduled to run today may in fact never run on this user's SMS clients.

The steps involved in creating devices, databases, security accounts, and so on are outlined in Chapter 18.

CAUTION
A final thought about SQL Server preparations: be sure to set SQL Server services to autostart after installing SQL Server manually. If you don't, you could be in for a big surprise after you install SMS 2.0 and then restart the server.

Site Server Requirements

SMS 2.0 site servers have specific hardware and software requirements, including disk space, memory, processor, and operating system requirements. In this section, we'll examine these requirements, as well as explore other platform considerations, such as Windows Terminal Server and Cluster Server support.

Hardware Requirements

SMS 2.0 has the following hardware and platform requirements:

  • Be sure that your computer hardware is included on the Windows NT Hardware Compatibility List (HCL). It is sometimes possible to install Windows NT Server 4.0 on computers whose hardware components may not be on the HCL. However, when you install a Microsoft BackOffice product onto such a server, you may experience anomalous activity—such as the "blue screen of death." It's not worth the gamble.
  • The server platform can be Intel, Alpha, or a compatible system.
  • SMS 2.0 requires a minimum processor type of Pentium 133 MHz. The more powerful (and plentiful) the processor, the better performance you will see. A dual-processor Pentium III 500 MHz is recommended if your budget allows, or a dual-processor Alpha-based server.
  • SMS 2.0 requires a minimum of 64 MB to 96 MB of RAM. Of this, 16 MB is automatically allocated to SQL Server. SMS 2.0 running on a 64-MB server is not a pretty sight. As RAM is a relatively inexpensive upgrade, you should install at least 256 MB, testing performance under various load conditions and then upgrading RAM as necessary.
  • SMS 2.0 must be installed on a Windows NT file system (NTFS) partition. SMS 2.0 uses NTFS permissions to secure access to SMS directories and shares.
  • SMS 2.0 requires that a minimum of 500 MB of hard disk space be available on the NTFS partition, as well as 100 MB of free space on the operating system partition. While SMS 2.0 will install under this configuration, this configuration also implies that you are working with a relatively small stand-alone SMS site. Microsoft recommends starting at 1 GB and working up from there, depending on such factors as the system roles the site server will employ, the number of clients and resources that will be managed, and the number of packages, programs, and advertisements that will be generated. For example, 2 GB of free space may be sufficient if the site server functions as a logon point and a CAP in a medium-sized stand-alone site. However, if the site server will also function as a distribution point, you will almost certainly require additional disk space for storing the package files.

NOTE
A medium-sized stand-alone site refers to a site with a few thousand clients that is collecting hardware and software inventory, status messages, and discovery data based on the SMS 2.0 default settings. The assumption is that the site averages two to three packages a week of about 20 to 30 MB in size, and two to three advertisements a week. These examples should be taken as soft guidelines only. As always, you must test your SMS 2.0 configuration within the unique requirements of your own organization and modify it to provide you with satisfactory performance parameters.

  • Microsoft also recommends a higher video resolution than you might have on most servers running Windows NT 4.0. SMS 2.0 will function just fine with a standard VGA resolution monitor. However, if you plan to use the SMS Administrator Console on the site server itself for regular site tasks, consider setting video resolution to at least 256 colors, 800 by 600 pixels.
  • Microsoft also always mentions the following two devices in its requirements list, although it's hard to imagine purchasing a server nowadays without them: a mouse and a CD-ROM drive. (Performing SMS 2.0 tasks using only keyboard shortcuts is possible, but would be ill-advised.)

SMS 2.0 and Alpha-Platform Support

SMS 2.0 does support the Alpha-platform computer system, but keep the following limitations in mind:

  • SMS 2.0 supports Alpha servers using Windows NT 4.0 only if Windows NT 4.0 Service Pack 4 or later has been applied, as well as Microsoft Windows 2000 servers that are not running Active Directory.
  • SMS 2.0 does not support Alpha servers or workstations if they are using Windows NT 3.51 or earlier.
  • Alpha site systems do not support the software metering function of SMS 2.0. However, Alpha clients using TCP/IP are supported as valid software metering clients.
  • If a parent or child site to an Alpha site server has enabled software metering, the Alpha site server will be unable to forward software metering data from either the parent or the child.

Software Requirements

In addition to the hardware requirements already outlined, you need to consider the following software requirements before beginning the SMS installation process:

  • The SMS 2.0 site server must be installed on a server running Windows NT 4.0 that is fully Y2K-compliant, meaning that Windows NT 4.0, Service Pack 4 must be applied. The server must have Microsoft Internet Explorer 4.01 with Service Pack 1 or later. SMS 2.0 uses Internet Explorer for its online help. Also, the server must be running Microsoft Data Access Components (MDAC) 2.0 with Service Pack 1. Microsoft has included all these on the SMS 2.0 CD. When you insert the CD, it will autorun and display four options. Choose the Install NT 4.0 SP4a option, as shown in Figure 2-1. (Alternatively, you could install these options directly from the Ntqfe\Nt4sp4a\I386 or Alpha directories on the SMS 2.0 CD.)

CAUTION
If Windows NT 4.0 Service Pack 5 is used to install the SMS 2.0 server, you must install MDAC 2.0 Service Pack 1 because it is not included in Windows NT 4.0 Service Pack 5.

    click to view at full size.

    Figure 2-1. The autorun screen that appears when you insert the SMS 2.0 CD.

  • The SMS site server can also be installed on servers running Windows NT 4.0, Enterprise Edition (again fully Y2K-compliant), and Windows 2000 servers that are members of an existing Windows NT 4.0 domain. SMS 2.0 does not currently support Windows 2000 servers running Active Directory for any site system role. Site servers cannot be implemented on any Novell NetWare platform.
  • SMS 2.0, as we've seen, requires SQL Server 6.5 with Service Pack 4 or later applied, or SQL Server 7.0. Either can be installed as part of the SMS 2.0 setup routine. See the section "SQL Server Requirements" earlier in this chapter for a discussion of the merits of having SMS 2.0 perform the SQL Server installation for you.

CAUTION
During its installation process, SQL Server does allow you to use spaces when naming the server. However, SMS 2.0 does not support this naming convention and installation of SMS will fail if you provide SMS with a SQL Server name that includes spaces.

The SMS 2.0 CD also contains a Windows NT 4.0 hotfix file that rectifies a memory leak that is sometimes caused by running the SNMPTest utility to obtain a load signature for the Windows NT Simple Network Management Protocol (SNMP) agent. As with all such hotfixes, this one should be applied only if you encounter this problem. Otherwise, wait for the next Windows NT Service Pack, which will include the same hotfix fully regression-tested. The file is named Smsfix.exe and can be found in the Ntqfe\Nthotfix\I386 or Alpha directory on the SMS 2.0 CD.

MORE INFO
This memory leak issue and the hotfix are discussed in Microsoft Knowledge Base Article #Q196270. You can find this article at http://support.microsoft.com/support/kb/articles/q196/2/70.asp.

Windows NT Terminal Server and Cluster Server Considerations

SMS 2.0 provides only limited support for Windows NT 4.0 Terminal Server in both server and client roles. The only site system role that SMS 2.0 supports is distribution point. Only five client features are supported: hardware inventory, software inventory, Network Monitor, remote Windows NT client installation, and manual client installation (provided the CHANGE USER /INSTALL command is executed on the client first).

SMS 2.0 does not directly support Cluster Server. If you do install SMS 2.0 on a Windows NT 4.0 Enterprise server using Cluster Server, be sure to take the following precautions:

  • Do not install the site server or any site systems on the shared drive of any cluster.
  • Install the site server or any site systems on only one side of a cluster. If one side of a cluster is a site system, the other side must be an SMS client.
  • Do not install SMS 2.0 at all if the domain controllers in the site are clustered. If you enable either the Windows Networking Logon Discovery or Windows Networking Logon Client Installation method, SMS 2.0 will by default set up all domain controllers as logon points, which would violate the second item in this list.



Microsoft Systems Management Server 2.0 Administrator's Companion
Microsoft Systems Management Server 2.0 Administrators Companion (IT-Administrators Companion)
ISBN: 0735608342
EAN: 2147483647
Year: 1999
Pages: 167

flylib.com © 2008-2017.
If you may any questions please contact us: flylib@qtcs.net