Microsoft KB Archive/107244

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

Article ID: 107244

Article Last Modified on 1/24/2005

-

APPLIES TO


 * Microsoft Systems Management Server 1.0 Standard Edition

-



This article was previously published under Q107244



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(r) Systems Management Server (SMS)

Release Notes Contents 1. Patching Windows NT(TM) Server on the Site Server 2. Site Upgrade 3. SMS Service Account 4. SMS Administrator 5. SMS Database Manager 6. SMSLS.INI 7. IBM(r) LAN Server 8. Novell(r) NetWare(r) 9. Clients Running MS-DOS(r) 10. Clients Running Windows for Workgroups 11. Macintosh(r) 12. OS/2(r) 13. Troubleshooting Client Operations 14. Services 15. Inventory 16. Audited Software 17. Outboxes 18. Creating and Distributing Packages 19. Program Group Control 20. Using Network Applications 21. Troubleshooting Network Applications 22. Installing Applications on Clients 23. Notes on Installing Specific Applications 24. Using SMS to Install Operating Systems on Clients 25. Remote Troubleshooting Utilities 26. Network Monitor 27. Automatically Configure Workstation Logon Scripts 28. Diskless Clients 29. Backup and Restoration 30. Miscellaneous Notes 31. Additional Online Documentation 32. SMS Administrator's Guide Errata 33. Using SMS with Other Language Versions of Windows NT

Microsoft(r) Systems Management Server (SMS) Release Notes

1. Patching Windows NT(TM) Server on the Site Server Before running SMS, you should update Windows NT Server on your site servers with some new versions of Windows NT files supplied on the SMS CD-ROM. This is especially important for SMS site servers that run Network Monitor or that use Gateway Services for NetWare to communicate with NetWare computers.

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.

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) Select Windows NT Patch of Redirector and choose the Properties button.

6) In the Command Line Properties dialog box, select both the Automated  Command Line and System (Background) Task options.

7) Choose OK to close all the open dialog boxes.

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

To run the patch program manually on a computer, change directories to the PATCHES\NT subdirectory of the SMS CD-ROM, and type patch. Then reboot the computer for the changes to take effect.

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).

2. Site Upgrade When you upgrade a site, the SMS Setup program does not install the SMS Setup program. You can manually copy the SMS Setup program (SETUP.EXE) from the SMSSETUP\platform.BIN of the SMS CD-ROM (where platform is the processor type of the site server) to the SITE.SRV\platform.BIN directory on the site server.

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.

3. SMS Service Account Within a site, if you set up any trust relationships between domains, you should have just one SMS Service Account in one master domain at the site.

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.

4. SMS Administrator On site servers, a user must log on to the site server computer with a user account that is a member of the Administrators local group in the site server domain. On site servers, the SMS Administrator (and other utilities such as SMS Service Manager, SMS Security Manager, and so on) can only be installed in the SITE.SRV directory. For security purposes, the Site Configuration Manager assigns permissions for the SITE.SRV directory to only the Administrators local group. No other group or user can run a program from the SITE.SRV directory. If you want to give other users the ability to run the SMS Administrator, you should install the SMS Administrator on a computer running Windows NT that is not the site server.

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.

5. SMS Database Manager The SMS Database Manager is provided so that you remove the Audited Software group when you want to perform a software audit that contains only the latest audited software. If you do not use the SMS Database Manager to remove the Audited Software group, the SMS site database will store the cumulative inventory for the Audited Software group (that is, any updates will simply be added to the current record for the group). The SMS Database Manager (DBCLEAN.EXE) is installed in the SITE.SRV\platform.BIN directory (where platform is the processor type of the computer where it is installed) on any computer where the SMS Administrator is installed.

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.

6. SMSLS.INI The default SMSLS.INI file is placed in the SITE.SRV\MAINCFG.BOX directory on the site server. If you want to use SMSLS.INI to map clients to domains, modify the version in this location. If you have enabled the Automatically Configure Workstation Logon Scripts option, the Site Configuration Manager copies the SMSLS.INI file from this location to the REPL$ share of SMS logon servers running LAN Manager and Windows NT Server. If you have not enabled the Automatically Configure Workstation Logon Scripts option, you must manually copy the SMSLS.INI file to the NETLOGON shares of the SMS logon servers.

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.

7. IBM(r) LAN Server You must restore package shares on LAN Server package servers after those servers have been restarted. LAN Server does not directly support persistent shares. When you restart the LAN Server package server, the shares on the computer are not restored, and you must restore them yourself. The shares to restore are SMS_PKGx and all the shares for shared packages and workstation packages. It is a good idea to note the names and paths of these shares while the server is running, so you can restore them after the server is restarted.

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.

8. Novell(r) NetWare(r) For NetWare 4.x logon servers, you must make additional changes to the system login script when you use the Automatically Configure Workstation Logon Scripts option.

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 %\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 %\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.

9. Clients Running MS-DOS SMS supports MS-DOS version 5.0 and later. On pages xxx-xxxi of the SMS Administrator's Guide, the text states that SMS provides support for MS-DOS version 3.3 or later. The text should state the MS-DOS version 5.0 or later is supported.

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.

10. Clients Running Windows for Workgroups SMS clients that run Windows for Workgroups must have the latest version of the VREDIR.386 file. This file is dated 9-04-94 at 8:07 A.M. You can get this file from the PATCHES\WFW directory on the SMS CD-ROM. This version of this file is also shipped on the Windows NT Server CD-ROM. If you already updated this file from that CD, you do not need to update it again from the SMS CD-ROM.

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.

11. Macintosh(r) The Apple Installer is required to install the appropriate SMS files to a Macintosh client. The Apple Installer is not supplied with this copy of SMS. After SMS Setup has completed on a primary site server, follow the directions below to add this file to the server. You must complete the steps below before adding any Macintosh clients to SMS, and before adding any secondary sites that have Macintosh clients.

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(r) Office version 4.2          M_OFF42.PDF Microsoft(r) Word version 6.0            M_WRD60.PDF Microsoft(r) Word version 5.1a           M_WRD51a.PDF Microsoft(r) Excel version 5.0           M_EXC50.PDF Microsoft(r) Excel version 4.0           M_EXC40.PDF Microsoft(r) PowerPoint(r) version 4.0     M_PPT40.PDF Microsoft(r) PowerPoint(r) version 3.0     M_PPT30.PDF Microsoft(r) Project version 3.0         M_PRJ30.PDF Microsoft(r) Works version 4.0a          M_WRK40a.PDF

12. OS/2(r) 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 WindowsTM 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.

SMSOS2AG.EXE provides network support for Package Command Manager in the WindowsTM 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.

On OS/2 computers, the Client Setup program requires that OS/2 be installed on drive C.

13. Troubleshooting Client Operations If you are having trouble installing or running SMS client software, check for the following (also, refer to Appendix A in the Microsoft Systems Management Server Administrator's Guide):

The appropriate Windows network drivers are installed. Examine the network = entry in the Windows SYSTEM.INI file. One of the following entries should be present: lanman21.drv, wfwnet.drv, msnet.drv, or netware.drv. If the appropriate driver is not loaded, Package Command Manager and Program Group Control will not start. Make sure that the login account on the client has read access to the SMS logon server's SMS_SHR. For problems with Run Command On Workstation packages: Make sure that packages are designated for the appropriate operating systems. For example, if a package is targeted for clients running MS-DOS, it will not appear on clients running Windows version 3.1.

The date and time on the client must be consistent with the SMS server's date and time. If these values are not the same, a situation can occur where the package expiration time has already passed by the time the package arrives.

Check the event log for failure explanations. Likely problems include insufficient disk space on a client or a network connection failure. In the latter case, try to make the network connection with the net use command.

For shared packages (network applications), see "Troubleshooting Network Application" later in this document.

14. Services Only use the Very Fast mode for the Response setting in the Services dialog box for test purposes or for very small sites. The Very Fast mode places a heavy load on the site server--especially if the site is large.

15. Inventory On clients running MS-DOS, Windows version 3.1, and Windows for Workgroups, the Inventory Agent always reports the protocol that it used to connect to the SMS logon server where it is running from. If information about other protocols is available to the Inventory Agent, it will also report these protocols.

On clients running Windows for Workgroups or LAN Manager, you must run the SMSLS batch file or Inventory Agent using the Full (or Enhanced) Redirector. If you use the Basic Redirector, the Inventory Agent will not be able to report inventory and will prompt you for an SMSID (press the Enter key) or terminate with an error that says your drive may be full. To solve this problem, start the network software using the Full or Enhanced Redirector.

If you have clients that have both NetWare and LAN Manager networking capabilities, you should set up SMS to use only one of those network operating systems on those clients. Note that SMS supports only one network operating system at a time on a client.

To deliberately have users not run logon scripts (especially with dual LAN Manager and NetWare stacks):

Both: Create a user group and add the users who you don't want to run the script.

NetWare: Modify the system logon script for each server so that members of the group skip the SMS script commands. Or you can modify SCRIPT.SCR so that members of the group skip the SMS script commands.

LAN Manager: Through User Manager, modify the logon scripts for the entire group to point to a different logon script name that has no file extension.

To handle computers with duplicate SMSIDs, remove and reinstall SMS on the computers where you want to create a new SMSID. If two or more clients have the same SMSID, you can generate a new SMSID for those computers by 1) removing SMS from the computers where you want to create a new SMSID and 2) readding the computer to the site. You can remove SMS from a client by using the Client Setup program with the /R switch. You can manually add a computer by running the SMSLS batch file from the SMS_SHR of an SMS logon server. For more information about removing SMS from a client, see "Removing SMS Components from Clients" in Chapter 3 of the SMS Administrator's Guide. For more information about manually adding clients to a site, see "Manually Adding Clients to a Site" in Chapter 3 of the SMS Administrator's Guide.

The Inventory Strategy When Network Is Slow setting takes effect when the next Logon Script Configuration Interval elapses. By default, this interval is 24 hours. You can confirm that the Site Configuration Manager has updated this setting at the site by looking in the Site Configuration Manager's trace log (look for NETSPEED.COM and NETSPEED.DAT).

If a computer running MS-DOS or Windows has an inventory report that has no changes from the previous inventory, the Inventory Processor does not create a Delta-MIF to report the time of the inventory scan. Instead, the Inventory Processor waits for the inventory heartbeat period to elapse (compares the last inventory report with the time of the current inventory report) before it sends a Delta-MIF reporting no change and the scan time. By default, the heartbeat period is 4 days. This means that the Last Hardware Scan and Last Software Scan dates displayed in the Workstation Status section of the Personal Computer Properties window could be different from the date of the actual most recent scan by as much as the heartbeat period. Note if a change occurs in a computer's inventory, the Inventory Processor creates a Delta-MIF reporting the change and the scan time.

If the Inventory Data Loader sends a resync command to a client and there has been no change to the inventory, the client will not report a resync inventory until the inventory heartbeat period has elapsed (4 days, by default).

16. Audited Software If you want to customize the AUDIT.RUL file, you should rename the rule file to a different filename. If you upgrade the site, SMS Setup will overwrite the AUDIT.RUL file with the version on the SMS CD-ROM.

RUL2CFG.BAT requires only one parameter. On page 219 of the SMS Administrator's Guide, the text states that RUL2CFG.BAT requires 2 parameters. RUL2CFG.BAT requires only the package rule filename. The CFG file is not requires because the AUDIT programs must always have a CFG file named AUDIT.CFG.

If you do not use the SMS Database Manager to remove the Audited Software group, the SMS site database will store the cumulative inventory for the Audited Software group (that is, any updates will simply be added to the current record for the group). The SMS Database Manager (DBCLEAN.EXE) is provided so that you remove the Audited Software group when you want to perform a software audit that contains only the latest audited software.

Before you create a job using the Audit 1.00 package, you must run RUL2CFG.EXE to create the AUDIT.CFG file used for the software auditing package. You must do this the first time you create a job with the package. If you make changes to the package rule file, you should also run RUL2CFG.EXE again to update the AUDIT.CFG file.

The RUL2CFG.BAT file puts the AUDIT.CFG files it creates into the PRIMSITE.SRV\AUDIT\PACKAGE\ platform.BIN directories (where platform is the processor type). The AUDIT.CFG file is not placed in the PRIMSITE.SRV\AUDIT\PACKAGE directory as stated in the documentation. Also, package auditing using the RUL2CFG.BAT file in the default location (PRIMSITE.SRV\AUDIT) works only if the source directory for the package auditing is the PRIMSITE.SRV\AUDIT\PACKAGE directory.

For package inventory rules or the package rule file, do not enclose a clause containing OR operators with parentheses. Parentheses (grouping) around clauses containing an OR operator in inventory rules or the package rule file cannot be compiled by RUL2CFG.EXE nor Maintenance Manager.

The package rule file does not support an implicit AND clause before a set of OR clauses. The RUL2CFG.EXE compiler will not compile a package rule file containing an AND clause before a set of OR clauses. If you place the AND clause after the OR clauses, the RUL2CFG.EXE compiler will successfully compile the CFG file.

The following rule will fail to compile: file "file1" (    file "file2"     or     file "file3"     or     file "file4" )

However, the following rule will compile: (    file "file2"     or     file "file3"     or     file "file4" ) file "file1"

Package rule file (AUDIT.RUL) does not support an explicit AND operator. The RUL2CFG.EXE compiler will not compile a package rule file containing an explicit AND operator. If you use no operator between two files, this is treated as an implicit AND operator. To combine file rules with AND operators, simply list them one after the other without an operator.

The following rule will fail to compile: file "file1" AND file "file2"

However, the following rule will compile: file "file1" file "file2"

17. Outboxes You cannot move Outboxes to another drive or server. Additionally, you cannot rename Outboxes.

18. Creating and Distributing Packages When you create a package, in the Workstation Command Line box you can type a path relative to the package source directory. For example, if the package source directory is C:\APP, and the command line you want to run is C:\APP\SETUP\SETUP.EXE, you can type setup\setup.exe in the Workstation Command Line box.

When you use either a Run Command On Workstation job or a Share Package On Server job for a package created using a PDF, clients that run the job may be rebooted when the job runs. Usually, a client reboots only the first time it receives a package created with a PDF. On some clients running Windows NT Workstation version 3.1, the reboot may damage data in files held open by other applications running at the same time. This happens only on clients running Windows NT Workstation version 3.1. When you create a job to install a Microsoft application that has a PDF, you must copy the application's SMSPROXY directory to the package source directory. Copy the PRIMSITE.SRC\IMPORT.SRC\appname\SMSPROXY directory (and its contents) to the package source directory you create for the application. You must perform this step when creating a package to either install the application on clients or to set the application up on a server as a shared application.

When you send a Share Package On Server job to install a shared application for which SMS supplies a PDF and the target computers include at least one client running Windows NT version 3.1, the job status will appear as "Retry," even if all the target computers have run the command successfully. When you see a Share Package On Server job with "Retry" status, check the Job Status Details dialog box to get more accurate information about the overall job status. You can also contact the users of the clients running Windows NT version 3.1 to determine if the software was installed correctly.

If you used a Beta version of SMS to create and distribute a package for an ACME application (an application for which a PDF is supplied), you should delete these packages before you use this version of SMS. You should create a remove package job for each of the old packages, wait until those jobs finish, then delete the packages in the SMS Administrator. Then you can reimport the new PDFs, rebuild the packages and program groups, and resend the packages.

19. Program Group Control After you initially install SMS on the site server domain and add a client to the site server domain, you may see the following message when running Program Group Control:

Program Group Control: Could not open the application database due to a SMS profile error.

If you add a client to the site by running the SMSLS batch file (or Client Setup) from a logon server with no servers in the [Servers] section, Program Group Control will display this message.

After you initially install SMS on the site server domain, you should ensure that all the logon servers are listed in the [Servers] section of the DOMAIN.INI file on the SMS_SHR share of each logon server in the site server domain. Normally, this can take up to 30 minutes (longer if there are a large number of servers in the site server domain).

You can correct this error by running the SMSLS batch file or Client Setup again when there are one or more servers listed in the [Servers] section of DOMAIN.INI.

When a user who uses network applications logs on, the user may see the following message:

Failed to connect to SMS network server. Cannot determine which groups the users belong to. Please contact your administrator.

This means the client cannot see any of the package servers that it is supposed to see. To correct this problem: a) Examine the SMSERROR.TXT file in the Windows directory on the client. This file may contain more specific information regarding the failure. There may be sufficient information here for you to correct the problem.  b) Examine the [servers] section of the SMS.INI file on the client. Set up a network connection to the SMS_SHR share of one of the servers listed in this section. Within the SMS_SHR share, change to the APPCTL.BOX\DATABASE directory and look for files with the .HAF and .HGF extensions. If there are no files with these extensions, the site administrator may not have distributed a program group for the network applications to this site, or the client may not have the appropriate security credentials to see files in the share.

For shared network applications, SMS does not install program items in program groups other than the program groups SMS creates. If an application normally installs an icon in another program group (such as Startup), you can copy the necessary program item from an SMS program group to the other program group. For applications with program items in non-SMS program groups, you should also make sure the Drive Mode setting for the package properties is either Runs With UNC Name or Requires Specific Drive Letter.

After you upgrade the SMS software on an SMS logon server, all clients must run SMSLS.BAT (or the user must run their logon script, if that script runs SMSLS.BAT) before trying to run any shared applications made available by SMS.

Additional query words: prodsms sms

Keywords: kbarttypeinf KB107244

-

[mailto:TECHNET@MICROSOFT.COM Send feedback to Microsoft]

© Microsoft Corporation. All rights reserved.