Microsoft Systems Management Server README.TXT (Part 1 of 2)

• Microsoft Systems Management Server version 1.0

SUMMARY

This article contains the text from the Microsoft Systems Management Server version 1.0 README.TXT file (part 1 of 2).

MORE INFORMATION

      README.TXT
      Microsoft® Systems Management Server (SMS)

Microsoft® Systems Management Server (SMS) Release Notes

1. Patching Windows NT(TM) Server on the Site Server Before running SMS,

The files that are updated are NDIS.SYS, NWAPI32.DLL, and NWRDR.SYS. The update to NDIS.SYS fixes a problem with Network Monitor on ring networks. The other two files fix problems with enumerating NetWare user groups and getting the correct version number of NetWare servers.

Although these updates are essential only for primary or secondary site servers that either run Network Monitor or that use Gateway Services for NetWare to communicate with NetWare computers, Microsoft recommends that you apply the update to all computers running Windows NT including clients.

SMS provides two utility programs (for Windows NT and for Windows for Workgroups) and a PDF so that you can update Windows NT easily. The PDF is PATCHRDR.PDF. This PDF contains package commands for both Windows NT (Windows NT Patch of Redirector) and Windows for Workgroups (WFW Patch of Redirector).

For the Windows NT update, the files and the utility program PATCH.EXE are located in the PATCHES\NT subdirectory of the SMS CD-ROM. For the Windows for Workgroups update, the files and the utility program PATCH.EXE are located inthe PATCHES\WFW subdirectory of the SMS CD-ROM.

To use the PDF, perform the following steps:

1) Set up the package source directory:

   a. Create a package source directory.
   b. Create an NT subdirectory and a WFW subdirectory beneath the package
      source directory.
   c. Copy all the files from the PATCHES\NT directory on the SMS CD-ROM to
      the NT subdirectory of the package source directory.
   d. Copy all the files from the PATCHES\WFW directory on the SMS CD-ROM
      to the WFW subdirectory of the package source directory.

   button in Package Properties, then choosing PATCHRDR.PDF from the list.

4) In the source directory box, type the path to the package source

   directory you created in step 1.

6) In the Command Line Properties dialog box, select both the Automated

   Command Line and System (Background) Task options.

8) Create Run Command On Workstation jobs to run the appropriate package

   command on the appropriate computers.

This causes the appropriate files (listed in the PATCHLST.000 file) to be updated. The files are updated only if the versions of these files on the SMS CD-ROM are newer than the versions already on the computer. Note that the old versions of these files are retained, but their file extensions are changed to an unused 3 digit number.

If you have a Windows NT version 3.5 system and OpenGL is not installed, the patch utility may not run because it believes that you are trying to patch a Windows NT 3.1 version system. If you know for certain that you are running version 3.5 of Windows NT Server or Windows NT Workstation on your computer, you may safely override this check by using the -f option (patch -f).

1. Site Upgrade

When you upgrade a site, make sure that you close all SMS administration utilities on the site server (such as the SMS Administrator, SMS Security Manager, and so on) before you begin the upgrade. These utilities may lock SMS system files so that they cannot be replaced by Setup.

Before you can upgrade a secondary site, all secondary sites must be active. Therefore, you must resolve any problems with secondary sites, or allow components to finish being added to a secondary site, before you can upgrade a secondary site. You can check on a site's status by looking at the icon representing the site in the Sites window of the SMS Administrator.

1. SMS Service Account

Within a site, if you set up your Windows NT(TM) domains using a trust model (such as the single master domain model), you should set up a single SMS Service Account in the master domain, and have other domains use this trusted account. Do not set up other SMS Service Accounts in the other domains. Note that all domains in the site must trust the master domain (which contains the SMS Service Account). In addition, the SMS Service Account in the master domain should be a member of the Administrators local group in all domains at the site, and have Log On As A Service rights in all domains at the site.

If you set up your Windows NT domains without setting up a trust model, you should avoid setting up any trust relationships and you should use a local domain account for the SMS Service Account. In addition, you must create an SMS Service Account in each domain at the site. In each domain, the SMS Service Account must be a member of the Administrators local group and have Log On As A Service rights in all domains at the site.

1. SMS Administrator

When you use the Limit To Sites control in the Execute Query, Job Details, and other dialog boxes, the list displays only the yellow primary site icon. This icon is used to denote a site in general. It is not used to differentiate between a primary site and a secondary site.

1. SMS Database Manager

Before you use the SMS Database Manager to change or remove items in a database, make sure that there are no administrators using the SMS Administrator to access that database.

1. SMSLS.INI

For computers running Windows NT that are part of a domain, SETLS uses the domain as the workgroup if a WORKGROUP=DOMAIN mapping is specified in the SMSLS.INI file. For example, if the computer is in the SMSDOM domain and the SMSLS.INI file has SMSDOM = CENTRAL mapping for WORKGROUP, the computer running Windows NT is added to the site in the CENTRAL domain. You can also use the [WIN.INI] section to map computers running Windows NT to domains.

Also, for LAN Server clients, you may need to use SMSLS.INI to successfully report inventory to a LAN Server domain. If SMSLS.CMD and SETLSOS2 are unable to find the current logon server, you must define the LAN Server domain(s) in both the [Domain] and [Workgroup] sections of the SMSLS.INI file. For example, if the user is logged on to the IBMLSDOM domain the SMSLS.INI file should have IBMLSDOM = IBMLSDOM mapping in both the [Domain] and [Workgroup] sections.

1. IBM® LAN Server

Site Configuration Manager restores shares after a LAN Server logon server has been restarted. LAN Server does not directly support persistent shares. When you restart the LAN Server computer, the shares on the logon server are not restored. The Site Configuration Manager will restore these shares (SMS_SHR and SMS_SHRx) on the LAN Server computer during its watchdog cycle. If you don't want to wait for the watchdog cycle, you can restore these shares yourself at startup.

SMSOS2AG.EXE (called the SMS_NET_MAPPER service in Beta versions of SMS) is run as an executable file instead of running as a service. On OS/2 2.1x clients, Client Setup configures SMSOS2AG.EXE to run as an executable program from STARTUP.CMD. Be sure that SMSOS2AG.EXE appears in STARTUP.CMD after the commands to start the network. SMSOS2AG.EXE provides network support for Package Command Manager in the Windows(TM) subsystem of OS/2. Note that SMSOS2AG.EXE does not have an 8 character limit for the package server or logon server for LAN Manager.

If you have an IBM LAN Server domain in an SMS site, and you want to use the SMS ability to automatically configure logon scripts, you must do the following:

a) Be sure you have selected the Use All Detected Servers option in the Domain Properties dialog box for the domain. To access this dialog box, select the site in the Sites window and choose Properties from the File menu. Then choose the Domains button, then choose the Properties button in the Domains dialog box.

b) On the domain's primary domain controller, you must create the REPL$ share by typing net share repl$=c:\ibmlan\repl\export. Note that the primary domain controller must be the export server for the logon scripts.

c) On the primary domain controller, create a SCRIPTS subdirectory under the IBMLAN\REPL\EXPORT directory.

d) If the primary domain controller does not already have a REPL.INI file in the EXPORT directory, create one with the following entries EXTENT = TREE INTEGRITY = FILE If a REPL.INI file already exists, you do not have to change its settings.

e) In the [Replicator] section of the IBMLAN.INI file on the primary domain controller, add these two lines (if they do not already appear): REPLICATE = BOTH EXPORTPATH = C:\IBMLAN\REPL\EXPORT

f) In the [Replicator] section of the IBMLAN.INI file on the backup domain controllers, make sure the settings configure the backup domain controllers to import replicated files from the primary domain controller (the default IBMLAN.INI settings allow this).

g) Also in the IBMLAN.INI of the primary domain controller and backup domain controllers in the domain, add replicator to the Srvservices line in the [Server] section, so that the Replicator service starts automatically when the server starts.

h) Restart the Replicator service on the primary domain controller and all backup domain controllers in the domain.

You are now ready to automatically configure logon scripts within SMS. SMS will set SMSLS.CMD as the script for users who don't currently have scripts, and append SMSLS to the scripts of those users who do already have logon scripts.

1. Novell® NetWare®

NetWare 4.x login scripts require an explicit mapping when accessing a volume on the NetWare server. This means that you need to add some lines to the SMS commands that were added to the system login script by the Site Configuration Manager.

After the Site Configuration Manager has configured the system login script on NetWare 4.x logon servers, you must add lines to the SMS commands to map a drive to the volume containing the SMS logon server (LOGON.SRV) directory on the logon server.

On NetWare servers, the Site Configuration Manager adds the following lines to the system login script (these lines work correctly on NetWare 3.x servers):

REM Microsoft Systems Management Server (start)

REM SMS 1.0 set SMS_LOGON="SMSVOL:smsroot\logon.srv" INCLUDE %<SMS_LOGON>\SMSLS.SCR set SMS_LOGON=

REM Microsoft Systems Management Server (end)

Where SMSVOL:smsroot is the volume and directory name for where SMS is installed on the logon server. For NetWare 4.x, the SMS lines in the login script must have the following form:

REM Microsoft Systems Management Server (start)

REM SMS 1.0 map root X:= SMSVOL:smsroot\logon.srv set SMS_LOGON="X:" INCLUDE %<SMS_LOGON>\SMSLS.SCR map rem X: set SMS_LOGON=

REM Microsoft Systems Management Server (end)

Where SMSVOL:smsroot is the volume and directory name for where SMS is installed on the logon server.

1. Clients Running MS-DOS

SMS provides only MS-DOS support for clients running Microsoft Network Client for MS-DOS version 3.0. (Microsoft Network Client for MS-DOS version 3.0 is provided on the Windows NT Server CD-ROM.) SMS does not support SMS components within the Windows 3.1 environment on clients that run Microsoft Network Client for MS-DOS version 3.0. For full SMS support on clients running Windows 3.1, the client should use LAN Manager version 2.1 or later Enhanced Workstation or Windows for Workgroups.

In addition, the Microsoft Network Client for MS-DOS version 3.0 has the following limitations:

a. You cannot use the remote troubleshooting utilities on these clients using NWLINK. You can use remote troubleshooting utilities on these clients over NetBEUI or TCP/IP.

b. SMS will not be able to read the network card ID of these computers, so this information will not be shown in the inventory for these computers.

1. Clients Running Windows for Workgroups

For SMS, the latest version of this file is required to correct a problem where Windows for Workgroups clients lose connections when running the SMSLS script at logon time. A PDF to automatically update Windows for Workgroups computers is also provided.

To use the PDF, perform the following steps: 1) Set up the package source directory:

a. Create a package source directory.

b. Create an NT subdirectory and a WFW subdirectory beneath the package source directory.

c. If you are also using the PDF for updating Windows NT, copy all the files from the PATCHES\NT directory on the SMS CD-ROM to the NT subdirectory of the package source directory.

d. Copy all the files from the PATCHES\WFW directory on the SMS CD-ROM to the WFW subdirectory of the package source directory.

2) Create a package. When you do so, import the PDF by choosing the Import button in Package Properties, then choosing PATCHRDR.PDF from the list.

3) Choose the Workstations button.

4) In the source directory box, type the path to the package source directory you created in step 1.

5) If you are using the package for updating Windows NT, select Windows NT Patch of Redirector and choose the Properties button. In the Command Line Properties dialog box, select both the Automated Command Line and System (Background) Task options.

6) Choose OK until you have exited all dialog boxes.

7) Create Run Command On Workstation jobs to run the appropriate package command on the appropriate computers.

1. Macintosh®

You must use version 3.4 or later of the Apple Installer. A valid version of the Apple Installer can be found on any set of System 7.1 or System 7.5 Macintosh operating system disks.

To copy the file to your site server, from a computer running Windows NT Server Services for Macintosh (SFM), create a Macintosh share using MacFile in the File Manager on an NTFS partition. (Warning: a FAT partition does not store Macintosh files correctly and will fail.) From a Macintosh computer, insert the install disk that contains the Apple Installer. Mount the Macintosh share volume from the computer running Windows NT Server. Copy the Apple Installer file from the disk to the share volume. Then use the File Manager to copy the file to the SITE.SRV\MAINCFG.BOX\CLIENT.SRC\MAC.BIN directory.

If this is a primary site with no secondary sites, the Installer file will automatically be copied to the MAC.BIN directory in the logon share. If there are secondary sites connected, then the Installer may not be automatically copied to all sites. If this is the case, a change to the date of the SYSTEM.MAP file in the SMS directory will cause all files to be updated, including secondary sites. After copying the Installer to the correct path, you can modify the SYSTEM.MAP file date by using a text editor to open the SYSTEM.MAP file and save the file with no changes made.

For Run Command On Workstation jobs targeted for Macintosh clients, the Despooler gives the package volume (SMS_PKGx where x is the drive where the package is installed) all permissions (See Files, See Folders, and Make Changes) to Everyone. If you want to change permissions, you must manually set the permissions on the package volume and its subfolders. When a package directory is shared as a Macintosh volume, the permissions set in the Access dialog box of the Setup Package For Workstations dialog box for a package are ignored for the Macintosh volume. However, the Despooler always sets the permissions for the package's Windows NT share to the permissions specified in the Access dialog box.

For Macintosh clients, the Client Software settings in the Clients dialog box are ignored. When the SMS client software is installed on a Macintosh client, the Installer always installs the Inventory Agent, Package Command Manager, and MIF Entry program (MIFMAC) on the computer's hard disk. The Installer also configures the computer to run the INVMAC program automatically during system startup. The INVMAC program automatically starts the Package Command Manager. The MIF Entry program must be started manually by the user.

If you have two Macintosh computers with identical computer names in two different zones, and both of these computers have been added to the same SMS domain, then you should not use the Machine Path to specify a Run Command On Workstation job to go to just one of these computers. If you do use a Machine Path to specify the computer name for the job, the job will go to both of these computers, and you cannot control which one it will go to.

You can use PDFs supplied with SMS to distribute packages to Macintosh clients. The applications for which PDFs are supplied, and the names of each file, are listed at the end of this section.

When you set up the package source directory for one of these applications, press the command key while double-clicking the Setup icon. Continue pressing the command key until the first dialog box appears. For more information on setting up the package source directory for these applications, see the README file for each application for information on setting up the application on the network.

Two options for installation on the client are offered. One option allows the user to install a complete version on their Macintosh. The other option allows the user to install a version that runs from a network share volume. For Macintosh applications shared this way, all users will run the application directly from the server with the package source directory (unlike PC applications, which can be distributed to several servers for load balancing).

The following table lists each application for which PDFs are supplied, and the PDF to use when installing the application. Use the same PDF for both installing the application on Macintosh clients, and for installing the application for shared use on a server.

Application                             PDF File
Microsoft® Office version 4.2           M_OFF42.PDF
Microsoft® Word version 6.0             M_WRD60.PDF
Microsoft® Word version 5.1a            M_WRD51a.PDF
Microsoft® Excel version 5.0            M_EXC50.PDF
Microsoft® Excel version 4.0            M_EXC40.PDF
Microsoft® PowerPoint® version 4.0      M_PPT40.PDF
Microsoft® PowerPoint® version 3.0      M_PPT30.PDF
Microsoft® Project version 3.0          M_PRJ30.PDF
Microsoft® Works version 4.0a           M_WRK40a.PDF