http://www.microsoft.com/TechNet/boes/bo/sms/technote/sm202.htm (PC Press Internet CD, 03/1996)
| Updated: March 14,1996 |  Go To TechNet Home Page |
Presented by: Thomas J. Prisk
Tom is president of Caswell and Collins
Consulting, Inc., focusing on training and consulting for Systems
Management Server and Windows NT. He is a Microsoft Certified
Trainer, and was formerly a Network Systems Engineer with Microsoft
and IBM.
Overview
Organization
A Brief Terminology Review
Installation and Configuration
Inventory Collection
Software Distribution
Shared Applications
Remote Control
Diagnostic Tools
Summary
We would like to think that once we install an application or an operating system it will run flawlessly and forever. All of this without human intervention of course. Except for the uninitiated, we all know that this is not the case. There are many of us who have spent hours on support lines, and reading stacks of manuals late at night trying to find that magical parameter or command to get this application or that OS back on line.
Fortunately, SMS was designed with the support professional in mind. There are many built in mechanisms that help maintain the integrity of an SMS installation. However, there are still going to be times that we have to roll up our sleeves and get out our manuals. This document is not intended to be a rehashing of the Administrator's Guide, but rather a concise reference for individuals with little or no hands on experience with SMS. Enclosed in the following pages you will find some support and troubleshooting tips which will save you time and effort while administering and troubleshooting your SMS installation. Many of he tips and techniques in this document are not in the SMS Administrator's Guide.
Document Contents
Organization
Support and troubleshooting will be broken down into the following
six groups: installation and configuration, inventory collection,
software distribution, shared applications, remote control, and
diagnostic tools. Each of these groups will be further broken
down as needed. A small section entitled A Brief Terminology
Review has been included to help those new to SMS. Please
refer to the glossary in the SMS Administrator's Guide
for more details. Screen shots have been included for clarity
where necessary. Please note that key points in the flow
of information both within and between SMS sites will be discussed
in this document. For detailed SMS operational system flow
information please refer to Appendix C: "SMS System Flow"
in the SMS Administrator's Guide.
· An SMS Hierarchy is made up of one or more sites which are organized in an inverted tree structure.
· An SMS Site is the basic SMS Hierarchy's organizational unit. It is made up of one or more Domains.
Sites are organized into an SMS Hierarchy by setting up parent-child relationships between the sites.
· A Parent Site will contain all the pertinent information about its child sites, as well as have the ability to control many operations at the child sites.
· A Child Site automatically reports pertinent site information to their respective parent sites.
There are two types of sites: primary and secondary.
· A Primary Site has an associated SMS database in which it stores its system, inventory, package, job, and status information. A Primary Site can be a parent only (in which case it is called the Central Site), a parent and child simultaneously, or a child site only. A site of this type in created by running the SMS setup application off the SMS CD.
· A Secondary Site performs the same functions as a Primary Site except that it does not have an associated SMS database which it controls. Its site information is stored in the SMS database of its immediate parent site. Since it does not have an associated SMS database, a Secondary Site cannot have any child sites. A Secondary Site is created by its immediate parent.
· A Domain is an organizational unit made up of servers and workstations. The three types of Domains are Windows NT, LAN Manager, and Novell NetWare.
These are four types of SMS Servers, and the roles they perform:.
· A Site Server is the computer which controls the SMS site. It handles the coordination of information and services both within the site. Each site has one and only one site server. This computer must be a Windows NT Server V3.5
· A Logon Server is a server which supports the SMS clients within its domain. It is a repository of instructions for the client agents, as well as the initial point of collection for SMS client inventory information. Each domain must contain at least one Logon Server. A Logon Server can be either a Windows NT, LAN Manager, or Novell NetWare server.
· A Distribution Server is a server which acts as a software repository for the client agents when they execute software distribution and shared application packages. A Distribution Server can be either a Windows NT, LAN Manager, or Novell NetWare server.
· A Package defines the objects needed by the client agents. There are three types of Packages:
· An Inventory Package defines what software to look for on the clients.
· A Workstation Package defines the software and command lines that will be distributed to the clients.
· A Sharing Package defines the software and program items that will be used by the clients.
· A Job is an instance of a Package (except inventory) which is targeted at a specific set of client machines (software distribution), or sites (shared applications), including start time, priority, and repetition.
· A Program Group is used to create collections of program items defined in Sharing Packages, and associate them with groups of users.
The first area to concentrate on is the machine that will become the SMS Site Server. This is the machine onto which you will be installing SMS. Before you can proceed with the SMS installation, the following must be completed at the Site Server machine:
· Install Windows NT Server 3.5. Make sure that it is either a primary or backup domain controller. Do NOT install it as a standalone server (the default during Windows NT Server 3.5 installation) since it must contain the domain user account database. Make sure that it has at least one NTFS partition which is at least 100Mb in size. This area will hold the code required to operate the Site Server. However, it does not take into account space required for the SMS database, applications, or working space. 500 Mb would be a reasonable minimum for all site server needs. This number mainly depends on how much software distribution and application sharing needs to be done at that site.
· If this server was ever a member of a previous SMS installation, either as a Site Server, Logon Server, Distribution Server, or an SMS client, make sure that the old SMS.INI file is removed from the C:\ directory. Remember that it is a hidden file. Also, using the Windows NT registry editor (REGEDT32.EXE), remove any residual SMS keys from \HKEY_LOCAL_MACHINE. Do this by choosing the "Find Key" option in the "View" menu, and searching for all occurrences of SMS. Make sure that the "Match Whole World Only" check box is NOT selected.
The SMS Service Account must also be created before installation can proceed. When creating this account make sure that it is part of the global Domain Administrators group and that it has the "Log on as a Service" right. If you are using Windows NT trust relationships, make sure that any trusting domains that will participate in the SMS site have added the SMS Service Account (from their trusted domain(s)) to their local Administrators group. Also, at the trusting domains, grant the "Log on as a Service" right to these same SMS Service Account(s). If this is not done, information and services may not be installed on SMS servers within these trusting domains.
There are two important settings that need to be reconfigured at the SQL Server for Windows NT V4.2.1A machine that will hold the site's SMS database. These are the number of user connections and the number of memory units allocated for SQL Server. Both of these values are set by using the SQL Administrator Win32 tool. Open this tool and select the "System" button. Next select the "Manage" menu, and then "Configure SQL Server...". Then modify the "memory" and "user connections" values as follows:
· Memory. SQL Server allocates memory for its use in 2k pages. By default this number is 3,072 units. This number should be increased to at least 5,000 units. this will give SQL Server about 10Mb of memory to use.
· User Connections. The SMS installation program requests 25 SQL connections during installation. This is the default value! This number should be set ahead of time using the SQL Administrator Win32 tool. It is more than likely that more user connections will be required. The SMS services running on the Site Server require approximately five connections to the SMS database SQL Server. In addition each administrator for that site, while they are attached (running the SMS Administrator tool), requires approximately five connections. With multiple administrators connecting to the same SQL Server, it is possible to run out of connections. If this happens it is possible that the SMS services will be unable to perform their tasks, resulting in errors at the site. For that reason make sure that ,in addition to the connections required by the SMS services, you allow at least five connections per administrator on that SQL Server. Connecting to the SMS database with the SMS User Interface causes these connections to be established. So if an administrator is not actively managing the site, make sure that they shutdown the SMS Administrator tool. thereby releasing the connections.
Once the pre-installation steps are out of the way, the installation itself is very simple to perform. There are a few things to point out at this stage concerning installation options.
The first choice during the installation is whether to "Install Primary Site", or to "Install Admin Tools". The first choice is self explanatory, and the second choice gives you the opportunity to install the SMS Administrator tool on any Windows NT 3.x machine. This allows an SMS site to have multiple administrators. Their access permissions can be set using the SMS Security Manager tool. See the SMS Administrator's Guide pp. 130-137. If you want to be able to remote control clients from this machine, it must have a protocol in common with the target client as well as the SQL Server housing the SMS database containing the target client's information.
When installing Site Servers in an environment utilizing Windows NT trust relationships care has to be taken when entering the SMS service account information during the setup process. If the target Site Server's machine account is in a trusting domain, and the SMS service account is in one of this domain's trusted domains, the service account name entered during setup must be prefixed by the trusted domain name followed by a backslash. For example: POTOMAC\hermes, where POTOMAC is the trusted domain in which the SMS service account, hermes, is defined. Do not forget to give POTOMAC\hermes. the "log on as a service" right, and add this account to the local Administrators group in the trusting domain.
On occasion during setup an error message window may appear on the screen with information concerning the failure to install an SMS service for example. If this occurs and you are given an option to "Retry" or "Continue", do so. Many times the retry will work and the setup process will continue. If the setup process ultimately fails then the SMSSETUP.LOG file, located on C:\, should be checked to determine why the setup process failed. If reinstallation is necessary it is recommended that a complete cleanup of the site server occur before attempting to run the setup process.
If all goes well, and it usually does, the setup process will end with a message window stating that the installation was successful. There are some things that you should check to verify that this is in fact the case.
The absolute first thing to do is to insure that all the services and components are installed and running. This is done by starting the SMS Services Manager tool in the SMS program group. The following five services and nine SMS_EXECUTIVE components must appear and be running:
· SMS_HIERARCHY_MANAGER
· SMS_SITE_CONFIG_MANAGER
· SMS_INVENTORY_AGENT_NT
· SMS_PACKAGE_COMMAND_MANAGER_??
· SMS_EXECUTIVE
· Maintenance Manager
· Inventory Processor
· Site Reporter
· Scheduler
· Despooler
· Inventory Data Loader
· Applications Manager
· Alerter
· LAN Sender
If a service or component listed above does not appear in the SMS Services Manager tool's window then shutdown and restart the Windows NT Site Server. If the missing services or components do not appear then a site reset must be performed. This can be done by running SMS Setup and choosing "Operations" and then "Reset Site". Please note that SMS_HIERARCHY_MANAGER, and SMS_SITE_CONFIG_MANAGER are both automatically started services, while the SMS_EXECUTIVE's service startup is set to manual. The SMS_SITE_CONFIG_MANAGER will start up the three manual startup services, no administrator intervention is required.
Use File Manager to determine whether all of the required subdirectories and shares were created. The SMS root directory, d:\SMS, will be added on your NTFS installation partition indicated by d:. The following subdirectories will appear under the SMS root directory:
· HELPER.SRV, LOGON.SRV, LOGS, PRIMSITE.SRV, SITE.SRV
The following shares are created on the Site Server during the setup process:
· SMS_SHRd, SMS_SHR, SMS_SITE
The Site Server's SMS ID should equal xxx00001, where xxx equals the Site Server's site code. If the last digit is greater than one it may be an indication of a problem with inventory processing.
Finally, check the SMS Administrator tool's "Events" window for any service, component, permission, or database errors. Be sure to look at the Event's details for a complete description of the problem. Please note that it may take a while for the error information to be processed, and be displayed in the "Events" window.
Configuration of a Site Server is a fairly simple thing to accomplish, and is explained in great detail in the SMS Administrator's Guide. There are however some things to keep in mind while working within the Site Properties window.
In order to make changes to the Site Server's properties, you have to first select the "Proposed" radio button in the specific property's window, and next make the additions, deletions, and/or changes that are needed. Finally you must commit the changes answering "Yes" when asked "Are you sure that you want to update this site?" If you answer "No" to this prompt, then the changes you requested will be lost and never put into effect.
A very important point to make is that the completion of your configuration request is not going to immediately. It depends on many factors: service speed, and processing load being examples. How do we know when the new changes that were requested have taken effect? The answer is when the "Current" settings are equal to the "Proposed" settings for that particular property.
Please note that the diagram referenced below traces the flow of how these site properties are updated. Pay attention to the trace logs for the SMS_HIERARCHY_MANAGER, and the SMS_SITE_CONFIG_MANAGER if there are configuration problems. Please note that there should be only one master site configuration file (not shown) permanently located in the d:\SMS\SITE.SRV\SITE.CFG\ directory. The files with the (*.CT1) and (*.CT2) extensions are temporary and should be automatically removed by SMS during the configuration process.
The Site Property Update Process
In Steps 2,3, & 4 the SMS_HIERARCHY_MANAGER reads the proposed configuration changes from the site database, and sends them (*.CT1) to the SMS_SITE_CONFIG_MANAGER which then modifies the Site Server's Windows NT registry to reflect the changes requested; Steps 5 & 6. The SMS_HIERARCHY_MANAGER then updates the database; Step 7. Steps 1 & 8 show the SMS Administrator tool interacting with the SMS database to view the "Proposed" and "Current" settings.
The following concerns the "Automatically Configure Workstation Logon Scripts" check box in the "Clients" windows in the "Site Properties" window for a particular site. An SMS Domain that is either Windows NT or LAN Manager will only support this option if the SMS Domain is configured to "Automatically Detect Logon Servers" i.e. make every Windows NT or LAN Manager server in the domain an SMS Logon Server. If the Logon Servers in the SMS Domain are specifically added then the Site Server will not be able to auto configure them for logon scripts. This restriction does not apply to Novell servers. The files and logon script information can be added manually in this case. Care must be taken when auto detecting logon servers in an SMS Domain. This option can not be used if you want a domain to span multiple SMS sites.
This next section concerns the addition and removal of sites from within the SMS Hierarchy. The first topic will look at the addition of a site, either primary or secondary, to an existing SMS Hierarchy. The following topic will be the removal of a site. Site removal will be covered in more detail since there are more "things to watch out for" during this operation.
Attaching a Primary Site (child) to a Parent Site is a straight forward process. The key is the establishing of the required addresses at the parent and the child sites. The addresses are created in the "Site Properties" windows at both sites. Before the parent-child relationship can be established, an address to the child site has to be created at the parent, and vice versa. Remember that information has to flow up and down the entire SMS Hierarchy. This implies that a site has to address all of its direct descendants, and its immediate parent. Also keep in mind that sites do not need to address their peers or sites not directly in their path. Please see the example below.
Required Addressing Example
When a Secondary Site is created by its immediate parent, the addressing between the two sites is created automatically. Any addresses outside the immediate parent-child relationship must be added manually.
When removing a Primary Site from the SMS Hierarchy please refer to pp. 179-180 in the SMS Administrator's Guide. A few pointers follow. First, at the site being removed, check the parent site settings in the "Site Properties" window. When the "Current" and "Proposed" properties both read "Standalone Site", then the site has been successfully detached. Second, any child sites attached to the site being removed, must now be detached. This is done the same way as described above. After all the child sites have been detached the primary site to be removed has now been isolated from all the sites in the SMS Hierarchy. Third, the address of the site to be removed can be deleted from any site that formerly had an established address to the site to be removed. Fourth, the children of this site should now be reattached to a new parent(s). Keep in mind that some addressing changes may be necessary. Fifth, go ahead and deinstall the site to be removed. This will remove SMS from the machine. Finally, the removed site's inventory information must be removed from its former parent site's inventory, and its parent's parent, and so on until the inventory is removed from the Central Site. This is done by running an "Ad Hoc Query" at each of these site where the Architecture is set to "Personal Computer", Group is set to "Identification", and Attribute is set to "Site". The Operator should be set to "is like", and the Value should equal the site code of the site that was removed. Next highlight all the entries in the "Query Results" windows and choose Delete. The Primary Site has now been completely removed.
If a Primary Site is deinstalled without the above steps being taken, it will be necessary to remove the deleted site's information from its former parent. This is accomplished by running PREINST.EXE at the parent site. By running the following at the command prompt: preinst /DELSITE {chl site code, par site code}
The deinstalled site's information is removed from the site. PREINST.EXE can be found in d:\SMS\SITE.SRV\X86.BIN\. For more details in PREINST.EXE please see Appendix A: "SMS System Reference" in the SMS Administrator's Guide
Secondary Sites can never be detached or removed, but only deleted. This is done at its parent Primary Site; never just delete files from the Secondary Site Server.
Inventory collection can be broken down into two general areas. The first is the definition and distribution of inventory collection information to the site's Logon Servers, so that it may be read by the inventory agent running on the clients. The second phase of inventory collection involves the client agent writing collected inventory data to the Logon Server where it is then picked up by and processed at the Site Server. It is also the Site Server which finally adds the inventory information into that site's SMS database, and, if it has a parent site, passes the inventory information up the SMS Hierarchy until it reaches the Central Site. The definition, distribution, collection and management of the inventory process is covered in detail in Chapter 6: "Inventory" in the SMS Administrator's Guide. The following information will help clarify various aspects of the inventory collection process.
When defining the Inventory Package make sure that the package name is descriptive because this is what will show up in the client's "Software" inventory window. For example use Excel 5.0a not XL. When defining the search criteria wildcards are not supported. Looking for "*.EXE" will not fly. Do not forget to check "Inventory This Package"; this is disabled by default. Unless this box is checked this package's information will not get compiled into the master inventory list (PACKAGE.RUL) at the Site Server. Use "Collect This File" sparingly. Each file targeted for collection that is found on a client will get moved to the Logon and Site Servers each time a software scan is performed on the client. These collected files are also stored on the Site Server and are passed up the SMS Hierarchy to its parent and so on. These files take up space! So do not collect EXCEL.EXE and PPTVIEW.DLL. Collect files like SMS.INI, AUTOEXEC.BAT, or WIN.INI.
Inventory Packages defined at a Parent Site are automatically passed down the SMS Hierarchy to its children, grand children and so on the effect being cumulative. For example if there are three sites in a parent-child-grandchild relationship, and an Inventory Package for Excel 5.0a has been created at each site; then after the parents have sent their definitions to their children the parent would have one Excel 5.0a Inventory Package, the child site two, and the grandchild three (all with different SMS ID's). The picture below represents the Packages windows at the grandchild site. Note the three occurrences of Excel 5.0c. The Excel 5.0c package will show up three times in the inventory information for a client in this site that was found to have Excel 5.0c.
The "Grandchild" Site's Packages Window
Keep in mind that it takes time for the inventory instruction file (PKG_16.CFG) to get out on the logon servers for the agents to read them. So when new Inventory Packages are created at the site note the date and time, and then use File Manager to check the Logon Servers and note when the instruction file is modified; this date/time stamp will be later than the date and time when the new package(s) were created. If this is not the case, then the new package information has not yet been received at the Logon Servers, and will not be scanned for at this time.
The Inventory Configuration Process
Step 1 the Inventory Package is defined using the SMS Administrator tool. Note that in Step 2 the Application Manager recompiles the master file (PACKAGE.RUL) each time an Inventory Package is added, deleted, or modified. There is one and only one such file per site. It is a text file. It gets converted to a binary file (PKG_16.CFG) and placed on every Logon Server in the site by the Maintenance Manager (Step 3). This whole process does not require the administrator to create a job. Step 4, an internal SMS job is created to send the Package information to the child sites.
The actual collection process starts at the client machine. This is where the Inventory Agent runs and performs its hardware and software scan. Please note that the diagram referenced below traces the Inventory process flow in more detail. Inventory collection continues at the Site Server where the inventory information is collected and processed.
There are different Inventory Agents for each of the supported client operating systems located on the Logon Servers in the d:\SMS\LOGON.SRV\X86.BIN subdirectory. For troubleshooting purposes the /V switch should be used when running the agent. This causes the agent to go into "verbose" or trace mode while running a hardware and software scan. This can be accomplished by modifying the SMSLS.BAT file on the Logon Server. The output should be piped to a text file since the information will probably scroll off the screen too fast. An example using the DOS/Windows agent: invdos /V > SCAN.TXT.
The text file can then be read to determine if the agent encountered any problems.
For troubleshooting the remainder of the process, use File Manager to follow the movement of the files described below, use the trace logs of the components involved, and finally check the SMS Administrator tool's "Events" window for any error messages.
The Inventory Reporting Process
Step 1, he agent writes the inventory information (*.RAW) to an SMS Logon Server; this file includes the collected files. Step 2, Maintenance Manager collects the files from the Logon Server. Step 3, the (*.RAW) file get converted to a (*.MIF) file; text file approximately 20-40 Kb in size, and read into the database (Step 4). Step 5, the change information gets reported to a parent site if applicable.
Clients can be moved from a domain in one site, to a different domain in the same or different site. This is accomplished by running SMSLS.BAT, either through logon scripts or manually, from a logon server in the new domain. After 3 consecutive times (default) the clients SMS.INI file will be updated to reflect the new domain information, and the client's inventory information will now appear under its new domain. The original SMS ID, stored in the SMS.INI file on the client, will be retained however.
The [LogonHistory] section of the client's SMS.INI file tracks the number of consecutive times the SMSLS.BAT file has been run at the particular domains. If a different domain is used before the False Logon Limit (default=3) is reached, then the counter is set back to 1. The False Logon Limit setting is stored in the Site Server's Registry and is passed to the DOMAIN.INI file on all the site's Logon Servers under the [SMS] section where the entry reads InvAgtFalseLogonCount = x. (See pp. 210-211 in the SMS Administrator's Guide for more details.)
Whenever a client runs SMSLS.BAT in a new domain, or the Logon History counter is less than x-1, where x is the False Logon Limit, then a hardware/software scan will not occur. This fact is displayed on the client's screen when SMSLS.BAT is run, but it usually flies by too fast to read. This means that if the user keeps logging into different domains without hitting the limit, a scan will not occur and the client's inventory information will not be updated. The information in the SMS.INI file can of course be edited to change the counter value. Set the False Logon Limit to a large value if there will be large numbers of clients logging into other domains for limited periods of time. For example laptops being used at another site during a business trip.
Please note that there is not a utility to do bulk movement of inventory information from one domain to another, nor one to move a domain from one site to another.
Every machine in the SMS Hierarchy has an SMS.INI file in the root of its primary partition. Note that is a hidden file. This file contains important information concerning the client that is used by the SMS client agents to interact with other SMS components. The most important piece of information contained in the SMS.INI file is the SMS Unique ID entry. The machine's UID is assigned the first time SMSLS.BAT is run from a Logon Server. This UID uniquely identifies that machine in the SMS Hierarchy. These UID's are assumed to be permanently assigned, and the values will not be reused. The first three characters represent the site code of the domain into which the machine was initially scanned. The remaining five positions represent an incrementally assigned number tracked by the Site Server. In addition to the SMS UID, SMS also uses the machine name and net card ID to help uniquely identify a machine. The SMS UID takes precedence. These three values are used by SMS to track the machines in the SMS Hierarchy.
The following section describes how SMS deals with the loss of the SMS.INI file, or the changing of the machine name or net card.
What if the machine's SMS.INI file is deleted from its root directory, but the machine name and net card ID remain the same?
The next time that SMSLS.BAT is run from the machine, a new SMS.INI file will be created with a new SMS UID. This will cause a new inventory record to be written in the SMS database. This record will reflect the new SMS UID, and will have the original machine name and net card ID. A level 3 warning message will appear in the "Events" windows warning the administrator that a new machine has been added to inventory, but the machine name and/or net card ID values match those in another record. It is up to the administrator to resolve the conflict. If the machine's original SMS.INI file was collected at the Site Server or backed up somewhere else, then it can be copied over the new SMS.INI file on the client, and the new inventory record deleted from the "Sites" window. The other alternative is to just delete the original inventory record from the "Sites" window. This is not recommended however since it may affect the availability of Run Command on Workstation Jobs (SW distribution) for the machine.
What if the SMS.INI file remains untouched, but the machine name and/or the net card ID change?
After the next inventory scan, the new machine name and/or the new net card ID will overwrite the old value in the inventory record, and send a level 3 warning message to the "Events" window stating that the machine has some attributes that have changed, and shows the old and new values of the three identifiers. In this case the SMS UID's will match. A new inventory record is not generated.
What happens if the SMS.INI file is deleted, the machine name changed, and the netcard ID changed?
For all intents and purposes SMS considers this a new machine. A warning message will not be generated since all three of the identifiers are different.
The definition, distribution, and management of the software distribution process is covered in detail in Chapters 8, 10, 11, and 12 in the SMS Administrator's Guide. The following information will help clarify various aspects of the software distribution process.
Keep in mind that most of the information in this section pertaining to the creation of packages and jobs, and the movement of the software to the Distribution Servers, will also apply in the next section: Shared Applications.
The Software Distribution Process
Step 1 the Workstations Package and Jobs are defined using the SMS Administrator tool. Step 2, the Scheduler Component creates the package, instruction, and send request files; this includes the compression of the package files. Step 3, the package file and instructions get sent to the target sites. Step 4, the Despooler component at the target sites decompress the package files and instructions. Step 5, the Site Server places the software and instructions on the Distribution Servers and Logon servers respectively. Step 6, the PCM agent on the client reads the instructions from the Logon Server, creating a list of Packages to install. When any of them are executed then PCM connects to a Distribution Server and execute the Command Line.
A few things to watch for when defining a Workstations Package in the SMS Administrator tool's Packages window.. Please note that all Package definitions are sent to all of a site's descendants. Also, the command line and source code defined in the Package will not be compressed and sent until a Job is created that actually uses the Package.
· In the Source Directory field in "Setup Package for Workstations" window make sure that the complete path is specified. When the Package is used in a Job and the Site Server begins to compress the source code; it will compress all files and all subdirectories that are in the Source Directory. An example follows.
Assuming that we want to create an Excel 5.0c Package, we would fill in the Source Directory field as shown below. \\GETTYSBURG\EXCEL contains all the Excel 5.0c source code which is contained in subdirectories \DISK1, \DISK2, ..., DISK9. Everything from \EXCEL on down will be compressed, sent to the receiving sites, decompressed at the Site Servers, and then sent to the Distribution Servers. This is the correct shared path information.
The following is an example of what not to do. In this example the Excel 5.0c source code is located in a directory called \APPS along with Word 5.0, PowerPoint 4.0, and various other applications. When defining the Excel 5.0c Package, \\GETTYSBURG\APPS was selected as the source shared directory. This will cause all the subdirectories that are in the \APPS subdirectory to be compressed and sent to the receiving sites. In this case we are sending Excel 5.0c, but also Word, PowerPoint, etc.
Note that a Workstation Package's source directory has to contain at least one file. A command like dir can not be placed in the Command Line field by itself. However, a batch file DIR.BAT whose only line of code is dir, can be placed in the Source Director, and the Command Line field set to DIR.BAT.
· In the "Command Line Properties" window make sure the Command Line path is complete. It should be a continuation of the Source Directory field from the previous screen. Continuing the previous example, we would enter DISK1\SETUP.EXE in the Command Line field, not just SETUP.EXE. Remember SETUP.EXE is located on DISK1 not in the root of the Source Directory; \\GETTYSBURG\EXCEL in this example. If SETUP.EXE is not found in the path specified in the Command Line, then it will search for the next instance of SETUP.EXE on the client machine's C:\ directory! If Excel 5.0c SETUP.EXE can't be found chances are Windows 3.1 SETUP.EXE will be run on the client.
· The "Automated Command Line" check box by itself will not enable an application to install itself automatically on the client. An installation script needs to be called from the command line, and a Mandatory Job sent to the client. "ACL" by itself is for informational purposes, letting the user know if their input is required to install an application on their machine.
· Do not forget to check the "Supported Platforms" check boxes. A client can be a target for a job, but if the client's platform type is not supported, then the Package Command Line will not show up at the client when the Package Command Manager (client agent) is run.
Command Line Properties
The jobs are used to distribute packages to SMS client machines. A few things to watch for when defining a Run Command Job in the SMS Administrator tool's Jobs window. See the picture below for reference.
· The Job Target is instantiated when the Job begins to process i.e. when it goes Active, not when the Job is created. If any new machines are added to the site's inventory after the Job has gone Active, then they will not be included in the Job Target for that Job. Another Job with the same properties would have to be executed at a later time.
· Make sure you select the appropriate Command Name in the "Run Workstation Command" drop down box in the Run Phase section of the Job Details window. A job can have one and only one Command Name selected. To send another Command Name another Job, using the same Package, must be sent.
· The "Offer After" date/time is when the Package will begin to be offered to the client i.e. when it will start to show up in the client's Package Command Manager window. The PCM compares the "Offer After" date/time to the current date/time to determine if the command is available. It determines the current date/time by checking the client's internal clock. If the client's internal clock is set to 01/01/1980, then the package will take about fifteen years to show up in the PCM window. Run the following command at the client to synchronize its clock with that of a server.
net time \\server_name /SET /Y
· The "Mandatory After" date/time setting is self explanatory. Keep in mind that in order to make a Package "install automatically", the Package's Command Line should be set to "Automated", an installation script is included and indicated in the Command Line properties, and that the "Offer After" and "Mandatory" date/time settings are the same.
· Finally note that Packages can be sent out in stages, each stage requiring a separate job using the same Package and Job Target. The first Job would be created and executed with the Distribute and Run Phase check boxes off. The action in this case will be the sending of the package information from the originating site to the receiving site(s). A period of a few hours or days may elapse before the next Job is created. This gives large jobs time to get to their destination sites, and administrators time to troubleshoot the Send Phase. A second Job is created, only this time the Distribute Phase has been enabled, and the Send Phase is set to "Only if Not Previously Sent". Since it was previously sent (Job One) it will not be sent again. This second Job will cause the software to be moved to the Distribution Servers. Note that the Run Phase check box is still off. Again, a period of time can be given to allow the software to get to all the Distribution Servers in the Job's Target. After distribution has completed another Job can be created which will enable the Run Phase, sending the PCM instructions to the Logon Servers so that the client's can now invoke the Package.
· A Job in the Pending state can be modified, but Jobs that have gone Active can not be modified.
Job Details
· Attention also has to be paid to "Schedule" properties under the "Job Properties" window.
· The "Start After" date/time is when the Job begins to process at the sending Site Server. This is different than the "Offer After" date/time described above, and does not indicated when the Package files are sent to the receiving Site Servers
· The "Priority" setting has nothing to do with when the Job begins to process at the Site Server. It pertains to the priority settings on the Site Server's Outboxes. Please see pp. 190-191 in the SMS Administrator's Guide for more details on Outbox scheduling.
· "Job Status" information tracks the progress of the Job. It will show the target sites, and the details for each target site will reveal the targeted Distribution Servers and Clients in that site for this particular Job. "Run Command on Workstation" Jobs will stay active until all the clients have executed the Command Line, or the Job is deleted. This means that a "Run Command on Workstation" Job could be Active for quite a while. Queries can also be run to determine this information.
Job Status Details
Type=Workstation, Status=None means that the Job's Command Line has not yet been executed by PCM at the client. Also note that the workstation's Domain|SMS UID combination is used as identification, not the machine name. A status of Completed implies that whatever executed at the client terminated properly. Exiting SETUP.EXE is properly terminating the application.
If PCM seem to be misbehaving make sure the following are checked:
· In the Package definition check to see if the client's platform is supported.
· In the Job definition make sure the client is part of the target i.e. run the query. Make sure that the "Offer After" date has arrived, or that the "Expires After" date has passed.
· At the Logon Servers in the client's site, make sure that an instruction file exists for the client. The file name will be SMS_UID.INS, located under d:\SMS\LOGON.SRV\PCMINS.BOX\.
· Look for errors in the SMS Administrator tool's "Events" window.
· On the client make sure that the system date/time setting is current. Also check the C:\MS\SMS\PCMHIST.REG file to see its Job execution history.
· For on-line troubleshooting information see the "Package Command Manager" section under the "Troubleshooting" section in the SMS Help program.
There will be times when a Package becomes obsolete and has to be removed from the SMS Hierarchy, or a Package's software has to be removed from some of the Distribution Servers which house it. In order to accomplish these goals a Remove Package From Server Job has to be run. These Jobs remove a particular Package's software from some or all of the Distribution Servers. This applies to both Workstation and Sharing Packages.
The Package's software will be removed from the Distribution Servers targeted in the Remove Package From Server Job. If the RPFS Job targets all the Distribution Servers where the software resides, then it will also remove the (*.WKS) or (*.SRV) file from d:\SMS\SITE.SRV\DESPOOLR.BOX\STORE. This is the master copy of the Package's software which was received from the sending site.
If a Package is to be completely removed from the SMS Hierarchy, then the RPFS Job must be run before the Package is deleted from the "Packages" window. If the Package definition was inadvertently deleted from the "Packages" window then the Package can not be chosen while creating the RPFS Job. This means that the administrator will have to manually remove the Package's software from the Distribution Servers.
Any active or pending Jobs using the Package which is the target for termination should be canceled. Finally the Package should be deleted from the "Packages" window. This will remove the software from the d:\SMS\SITE.SRV\SENDER.BOX\TOSEND directory on the Site Server. This will also cause the Package definition information to be removed from the Child Sites.
The definition, distribution, and management of the software distribution process is covered in detail in Chapters 9, 10, 11, and 13 in the SMS Administrator's Guide. The following information will help clarify various aspects of the shared applications process.
Most of the information in this section pertaining to the creation of packages and jobs, and the movement of the software to the Distribution Servers, was covered in the previous section.
The Shared Applications Process
Step 1 the Sharing Package and Jobs are defined using the SMS Administrator tool. This will eventually get the software onto the Distribution Server. Step 2 is the definition of the Program Groups. Steps 1 and 2 can be done independently of each other. Step 3, is the movement of the software to the Distribution Servers. The software is placed in a shared directory. Step 4, the Program Group Control agent on the client reads the instructions from the Logon Server and updates the SMS-based Windows program groups on the client desktop. When an application is started, PGC connects to a Distribution Server and runs the application. When the user ends the application, PGC drops any connections to the Distribution Server.
Distributing the Program Group Configuration
This diagram details the creation and distribution of the Program Group Configuration information. This configuration information gets compiled and distributed much like that for Inventory Packages. Step 1 the Program Groups are defined using the SMS Administrator tool. Step 2, the Application Manager then compiles (*.HAF) and (*.HGF) files and in Step 3 the Maintenance Manager moves them to all the Logon Servers in the site. Step 4, these files are used by the Program Group Control agent on the client to create and manage the SMS-based Windows program groups and program items, and to connect to the Distribution Servers.
A few things to watch for when defining a Sharing Package in the SMS Administrator tool's Packages window. Please note that all Package definitions are sent to all of a site's descendants. Also, the command line and source code defined in the Package will not be compressed and sent until a Job is created that actually uses the Package.
· In the Source Directory field in "Setup Package for Sharing" window make sure that the complete path is specified. Make sure to select only the share needed just as in the Software Distribution process.
· Be sure to use network installations of the applications for the source code. Don't forget to add \SMSPROXY to source directory when using the Microsoft supplied Package Definition Files.
· The Share Name field in "Setup Package for Sharing" is where the administrator defines the package share name for the networked application directory which will be created on the target Distribution Servers. This is not the source director share name. If the package share name already exists on the Distribution Server, then the Despooler uses the existing share overwriting existing files. Share names are limited to 8 characters, though subdirectories of the share can be greater than 8 characters.
· The name that is entered into the Description field in the "Program Item Properties" window is the name that will appear under the program item icon on the client's desktop.
· Use caution with "Run Local Copy if Present". If checked it will look for a file matching the "Command Line" entry. For example the program item is setup to run Excel 5.0 off a Distribution Server; the "Run Local Copy if Present" box has been checked. A user executes the program item on the client machine, where a local copy of EXCEL.EXE is found. The local copy executes, unfortunately it is Excel 4.0.
· Do not forget to pick the "Supported Platforms" or the program item will not show up on the appropriate desktops.
The jobs are used to distribute the network applications to the Distribution Servers. The Program Group definition is handled independently. It is the SMS administrator's responsibility to coordinate the creation of the Jobs and the Program Groups. A few things to watch for when defining a Share Package Job in the SMS Administrator tool's Jobs window. See the picture below for reference.
· The Job Target is instantiated when the Job begins to process i.e. when it goes Active, not when the Job is created. The Job Target can only be a site or a Site Group. The ultimate target for Share Package Jobs are users not machines.
· Finally note that Packages can be sent out in stages, each stage requiring a separate job using the same Package and Job Target. The first Job would be created and executed with the Distribute check box off. The action in this case will be the sending of the package information from the originating site to the receiving site(s). A period of a few hours or days may elapse before the next Job is created. This gives large jobs time to get to their destination sites, and administrators time to troubleshoot the Send Phase. A second Job is created, only this time the Distribute Phase has been enabled, and the Send Phase is set to "Only if Not Previously Sent". Since it was previously sent (Job One) it will not be sent again. This second Job will cause the software to be moved to the Distribution Servers.
· A Job in the Pending state can be modified, but Jobs that have gone Active can not be modified.
Job Details
· Attention also has to be paid to "Schedule" properties under the "Job Properties" window. Please see the Run Command on Workstation Jobs section above for details since they are identical.
· "Job Status" information tracks the progress of the Job. It will show the target sites, and the details for each target site will reveal the targeted Distribution Servers in that site for this particular Job. "Share Package on server Jobs" will stay active until all the Distribution Servers have received the software. Queries can also be run to determine this information.
Defining Program Groups involve adding Shared Program Items, defined in the Shared Packages, to the Program Group definition. Then the Program Group is associated with the User Group(s) that will have access to it. The User Groups correspond to the user groups on the Logon Servers in the site's Domains. In the case of LAN Manager and Novell NetWare they are the user groups. In the case of Windows NT they are only the global user groups. This is to support Windows NT Trusts. Global user groups from outside the Site Server's Domain will have their domain's prefix in front of it. For example, the global Domain Admins group from a Windows NT Domain called AKITA (not the Site Server's Domain) would appear in the "User Groups" window as AKITA\Domain Admins. The group information is retrieved from all domains in the site by the Site Configuration Manager service, based upon the User Group Reporting interval (default = 24 hours). Please see Appendix A: "SMS System Reference" in the SMS Administrator's Guide for more information on forcing site reporting.
Make sure that the (*.HAF) and (*.HGF) files make it to the Logon Servers, d:\SMS\LOGON.SRV\APPCTL.BOX\DATABASE\. If not, the PGC will not update the client desktops.
Remember that the Package definition and Program Group definitions are independent of each other. So if the Package's software is on the Distribution Server(s) then the modification of the Program Groups is the only step necessary to determine which User groups get what Program Groups and Items. Another Job does not have to be created unless software has to be placed on more Distribution Servers.
If PGC seem to be misbehaving make sure the following are checked:
· In the Package definition, check to see if the client's platform is supported.
· The (*.HAF) and (*.HGF) files are stored on the Logon Servers on d:\SMS\LOGON.SRV\APPCTL.BOX\DATABASE\. Look at the time stamp on these files to verify that they have been updated by the Site Server. Until the updated files reach the Logon Servers the PGC will be working with old information.
· Make sure that the networked software is on the Distribution Servers before creating the Program Groups.
· Look for errors in the SMS Administrator tool's "Events" window, or in the SMSLOG.TXT file on C:\WINDOWS\ on the client.
· Use VIEWNAD.EXE and NADUSER.EXE to examine (*.HAF) and (*.HGF) files on logon servers.
· Make sure there are [SERVER] entries in client's SMS.INI file. This tells PGC which Logon Servers to get the Program Group information from.
· For on-line troubleshooting information see the "Program Group Control" section under the "Troubleshooting" section in the SMS Help program.
A common NetBIOS or IPX protocol is required on the SMS Administrator machine and on the client. In addition, since the client can only use one protocol at a time for remote control, the protocol that matches must be loaded at the client using the /L switch on USERTSR.EXE. (See the next section for details). For example the SMS Administrator machine is running only TCP/IP, and the client machine is running NetBEUI and TCP/IP; NetBEUI being loaded first and TCP/IP second. Do they have common protocols? Yes, but remote control will not work since by default the client will use NetBEUI for remote control. To remedy the situation, the usertsr statement in the client's CLIENT.BAT file has to be modified to USERTSR /L2.
· The SMS Administrator Machine searches its first four loaded protocols. To change the order go into Control Panel, Network, "Bindings" on the SMS Administrator Windows NT machine.
· An entry in the SMS Administrator machine's LMHOST file referencing the client is required for remote TCP/IP connections.
· Try using Diagnostics before Help Desk, since it requires less overhead, when trying to determine if remote access is functioning.
· The client agent, USERTSR.EXE, uses the first loaded protocol by default. This is a moot point with USERIPX.EXE since it only supports IPX/SPX. Use the /L switch on USERTSR.EXE to choose a protocol stack other than LANA 0 i.e. the one loaded first. For example if NetBEUI is the second protocol that is loaded (LANA base =2), then the line must read USERTSR /L2.
· The USERTSR/USERIPX invocation command is located in C:\MS\SMS\BIN\ CLIENT.BAT. CLIENT.BAT is called from AUTOEXEC.BAT
· Reboot the machine after it is scanned for the first time to allow USERxxx.EXE to load, and the "SMS Client" program Group to be created.
· Do not forget to start WUSER.EXE on Windows 3.1 and Windows for Workgroups 3.11 machines. Use the Remote Control tool in the "SMS Client" program group at the client to start it.
· By default the Remote Viewer Options at the client are disabled, meaning remote control will not be possible. Use the Help Desk Options tool in the "SMS Client" program group at the client to enable remote control.
· Remote control over TCP/IP requires that the stack have NETBIOS support.
For online troubleshooting information see the "Remote Control" section under the "Troubleshooting" section in the SMS Help program.
Use the SMS Administrator tool's "Events" window to look for problems. Pay particular attention to the severity level 3 messages; these are the ones with the stop sign. Error messages in this window can be sorted or filtered, or queries can be created using the "SMS Event" architecture.
Microsoft provides a suite of diagnostic tools on the SMS CD located under the \PSSTOOLS subdirectory. Please see the file TOOLS.DOC; this is the file provided by Microsoft which describes the tools provided. The tools to get most familiar with are the ones that were mention in the above sections.
For online troubleshooting information see the "Troubleshooting" and "Reference" sections under the SMS Help program item.
The following are not tools but rather miscellaneous hints that were not covered in any of the above sections.
· When logging into the SMS Site database make sure that the correct database name is entered. It is case sensitive. Also make sure that the user account (not the database login ID) is defined or has permissions on the machine that houses the SMS database.
· If SMS runs out of disk space during processing it will just stop until more space is made available. Most of the time this will have no ill effects. When creating the compressed package file at the sending site for Run Command on Workstation or Share Package on Server jobs, the worst case for disk space is about four times the size of the source files assuming compression is enabled.
· When deinstalling SMS from a client machine, verify that the following have been done:
· Delete the C:\MS directory
· Delete the SMS.INI file from C:\
· Remove the C:\MS\SMS\BIN\SMSRUN16.EXE portion of the load statement in the [Windows] section of the WIN.INI file of Windows 3.1, and Windows for Workgroups 3.11 machines.
· Remove the call CLIENT.BAT line from the AUTOEXEC.BAT file.
· Remove the SMS Client and any other SMS-based program Groups from Windows machines.
· On Windows for Workgroups 3.11 machines run REGEDIT.EXE /V, and delete any references to SMS from the Registry window.
· SMS does not support dual boot machines. In order to use dual boot, multiple SMS.INI files would have to be used, renaming them depending on which operating system is being loaded. For example with Windows NT and DOS dual boot, the machine would be scanned in initial while running Windows NT. This creates an SMS.INI file. In order to scan this machine while running DOS, the SMS.INI file would be renamed SMS.NT for instance, the machine booted into DOS, and the machine scanned creating another SMS.INI file. Rename this file SMS.DOS. Then rename the appropriate SMS.* file to SMS.INI depending on which operating system will be used.
· The SMS Administrator's windows do not dynamically refresh. One must choose "F5" or "Options", "Refresh" to repaint the window.
· SMSVIEW.EXE can be used to create views from the SMS database tables. These views will present the data in the SMS database in a more usable format. An ODBC based front end tool like Access 2.0 or Excel 5.0 can be used to attach to the SMS database views. Information can them be processed at the front end tool and used to create detailed reports or incorporated into another application.
· Use the SMS Security Manager tool to give people different SMS admin rights at that site.
SMS has many built in recovery features; this is good but don't use them as a crutch. The main support effort will be centered around the Site Server(s) due to the large concentration of information and services. Always read the "Events" window at the sites, this is how SMS keeps you informed. If an error is detected not the Job and/or Package ID, and which SMS Service or Component reported the error. Use the diagnostics tool discussed above to isolate and fix the problem. When trying to isolate the problem; remember that all the processing takes place on the Site Servers and the clients; the Logon and Distribution Servers act as repositories for instructions and software. Understand the Servers, Services, Components and basic information flows. Don't get hung up on details. Keep an eye on disk space, especially on the Site and Distribution Servers. When in doubt RTM (read the manual)!
Do not ignore the network infrastructure: network OS, bridges, hubs, routers, etc. SMS is only as healthy as the underlying network
You can not fix anything unless you know your tools. Practice!
As a final reminder; planning is your most powerful tool!
© 1995 Microsoft Corporation.
THESE MATERIALS ARE PROVIDED "AS-IS," FOR INFORMATIONAL
PURPOSES ONLY.
NEITHER MICROSOFT NOR ITS SUPPLIERS MAKES ANY WARRANTY, EXPRESS
OR IMPLIED WITH RESPECT TO THE CONTENT OF THESE MATERIALS OR THE
ACCURACY OF ANY INFORMATION CONTAINED HEREIN, INCLUDING, WITHOUT
LIMITATION, THE IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS
FOR A PARTICULAR PURPOSE. BECAUSE SOME STATES/JURISDICTIONS DO
NOT ALLOW EXCLUSIONS OF IMPLIED WARRANTIES, THE ABOVE LIMITATION
MAY NOT APPLY TO YOU.
NEITHER MICROSOFT NOR ITS SUPPLIERS SHALL HAVE ANY LIABILITY FOR
ANY DAMAGES WHATSOEVER INCLUDING CONSEQUENTIAL INCIDENTAL, DIRECT,
INDIRECT, SPECIAL, AND LOSS PROFITS. BECAUSE SOME STATES/JURISDICTIONS
DO NOT ALLOW THE EXCLUSION OF CONSEQUENTIAL OR INCIDENTAL DAMAGES
THE ABOVE LIMITATION MAY NOT APPLY TO YOU. IN ANY EVENT, MICROSOFT'S
AND ITS SUPPLIERS' ENTIRE LIABILITY IN ANY MANNER ARISING OUT
OF THESE MATERIALS, WHETHER BY TORT, CONTRACT, OR OTHERWISE SHALL
NOT EXCEED THE SUGGESTED RETAIL PRICE OF THESE MATERIALS.
 |
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 |