http://www.microsoft.com/TechNet/boes/bo/sms/technote/sm204.htm (PC Press Internet CD, 03/1996)
| Updated: March 14,1996 |  Go To TechNet Home Page |
Executive Summary
Hardware and Software Inventory
Software Distribution
Software Sharing
Diagnostic Utilities
Troubleshooting
SQL Server
Conclusion
Distributing computing power throughout the enterprise can result in greater efficiency and productivity, which can help you be more competitive. Unfortunately, it also means more hardware and more software used in more different configurations, and that means management headaches and higher costs for:
· Keeping track of your hardware and software
· Distributing and installing software throughout your organization
· Monitoring and troubleshooting computers anywhere in your organization
In today's distributed-computing environment, if you have to physically touch a computer to count it, install software on it, or figure out what's wrong with it, you're in trouble. At the very least, you're missing out on opportunities for significant cost savings.
Key to success in any enterprise system is the day to day operation of the system and products providing systems management capabilities are no different. Server administrators have long understood the need for sound strategies in order to provide quality service. Systems management administrators will also need to establishing a strategy that can maximize the benefit while minimizing the required effort. If not, the promise system management provides will go unrealized.
What is a strategy when talking about SMS? It should be a simple systematic approach to administration that helps the technology deliver on the promise of distributed computing management. The goals of this strategy should be:
· Maximize central administration
· Minimize manual intervention
· Encourage standards
Inventory is the base functionality for SMS, the core that everything is built upon. This makes the strategy and administration of inventory extremely important within SMS. Now the good news, it's basically a free lunch. Establish a few rules up front, setup the configuration code and it will take care of itself. Creating an inventory strategy does have a level of complexity involved, but that is caused by the number of options available. When wading though the options trying to determine which way to go, always refer back to the three strategy goals.
· Maximize central administration
· Minimize manual intervention
· Encourage standards
SMS provides several methods for workstation configuration from automated to manual and variations in between. So just how should the workstation configuration be accomplished? First lets break down the three major approaches.
1. Logon servers can be automatically detected with logon scripts automatically modified to run the client setup and inventory modules. Logon servers can be automatically detected and added to the site.
2. The same code setup automatically by SMS can be placed on a central server that each user then executes via a logon script. Logon servers can be configured as needed.
3. Logon servers can also be linked to manually and then have the setup code executed from the logon server. Logon servers can be configured as needed.
Letting the three strategy goals drive our selection process, take a closer look at each option.
Most existing environments will prohibit the use of option 1 where SMS does all of the work. This is especially true when the NT Server setup uses the Master Account Domain model. All of the user accounts will be in one account file. It is unlikely that all accounts will need to be turned on for SMS at the same time, therefore automatically adding the SMS script to every account will not be desirable. Also there will probably be some servers in resource domains that will not need to become SMS logon servers.
Option 3 provides no automation. Two of the three design goals would not be meet, therefore not a good choice.
Option 2 provides the best of both worlds. Create a directory containing the proper files needed to workstation configuration and see that it is replicated to all NT Server account servers so that it can be called from the users logon script. It is obvious at this point that creating a standard for logon scripts is desirable if one doesn't already exist. Chapter 3 of the SMS Administrators Guide gives details the components needed to provide client setup.
· SMSLS.BAT
· SETLSX.COM (where X refers to 16, 32I, 32A, 32M
or OS2 depending on processor)
· CLRLEVEL.COM
· CHOICE.COM
· DOSVER.COM
· NETSPEED.COM
· NETSPEED.DAT
· SMSLS.INI
After selecting an automated setup method to deliver the client code to a workstation the use of the SMSLS.INI file should be considered. This file is used to map a workstation to an SMS logon server. Again Chapter 3 of the SMS Administrators Guide documents the use of this file. The SETLS program will use this file to determine where the inventory of each workstation gets mapped. Planning the SMSLS.INI file is essentially mapping the inventory to the proper place in the hierarchy.
The idea is that for certain groupings a machine can then be mapped ro an SMS logon server. The supported groupings are:
· workgroup
· domain
· machine name
· other domain
· win.ini file entry
The main method is to provide a mapping of domain=SMSdomain as in the following example where all workstations in the workgroup MIS will be mapped to a logon server in the MISMAIN domain.[workgroup]MIS=MISMAIN
In this instance an SMS logon server in the MISMAIN domain will be selected via a domain enumeration API. These APIs, being broadcast in nature, will provide greater selection flexible than sometimes needed. An undocumented trick to keep in mind is that by placing a server name on the right side of the equal sign, you can direct the workstation to a specific logon server bypassing the use of the enumerate API calls. The following example directs workgroup MIS to a logon server MIS1.[workgroup]MIS=\\MIS1
When a site contains only one server in a domain or you want a group of workstations to select a specific logon server, this is a powerful technique.
A final point about the SMSLS.INI file is the way that SMSLS.EXE parses the file. The search is linear though the file trying each match as it is found until successfully connecting to a logon server. This gives the ability to provide redundant paths for workstation mapping. The following example takes workstations in the workgroup MIS and tries to map to a logon server in the MISMAIN domain. If no logon server is found then it tries the logon server MISBACKUP. If that is not found it then searches for a logon server in the domain MISSPARE.[workgroup]MIS=MISMAINMIS=\\MISBACKUPMIS=MISSPARE
Now that the SMS workstation code is set to install on the workstation the administrator has control over which components get installed. This control is on a per site basis and accomplished by updating the clients dialog box. This dialog is reached through the clients button in the site properties dialog box.
The configuration options are many with each component having either:
· Install the component on the workstation and automatically start
· Install the component but don't automatically start
· Don't install the component.
Frequently the first approach is to install all components and automatically start them. After a small amount of time it will be realized that not all components are going to be used and it's inconvenient to the user to have everything automatically start. The reaction is to then select the "don't install the component" option for the unneeded items. Then when the component is needed you have to go back and change it's setting. While SMS provides the ability to do all this with little administrative effort, consider the effect on the workstation. The client setup code will constantly be adding and deleting files and changing settings.
The better strategy would be to install all components even if they are not planned to be used now, chances are at some point in time you will want them. Set the start automatic option on the components needed now. Then when you want to use a new component, either the user can start it from the desktop, or the site properties can be changed to automatically start the new component. OK, so what advantage does this provide? First, the workstation configuration code will download the files the first time the workstation is setup. This means the user is only interrupted for the file transfer one time. Second, the disk space required for the code will be allocated and you won't have to worry about having space available when you suddenly need to use a new feature of SMS. The space needed for SMS is not excessive but everyone knows how much of a problem disk space can be, there is never enough. Lastly, when you need a component in a hurry that you normally don't use, like remote control, won't have to wait for system turn around time to get it there. The user can just go to the program group and launch the app.
The Inventory dialog box, shown below, presents three elements that need to be considered to complete the basic inventory strategy.
Inventory frequency makes up two of the three elements. Hardware and software inventory frequency can be controlled independently so the first decision is if hardware and software inventory have different needs. Thinking about what each is used for would lead you to believe that software inventory needs to be more up to date than hardware. After all, software inventory will be used to control software installation and upgrades. Of course you can't forget that in order to install or upgrade software you need to make sure that enough disk space exists, so hardware inventory is suddenly important. Usually the best approach is to set the hardware and software frequency the same. The exact frequency that is best may vary from company to company, but many current implementations have found once every 7 days to work best for them.
When determining what frequency to use a subtle point about how the inventory is collected needs to be made. The inventory code runs every time that the smsls.bat file executes, by running an invdos, invmac, invwin32 or invos2 exe. The first thing the inventory exe does is determine if inventory should be taken. This is done by comparing the time of the last inventory scan which is stored in the sms.ini file, to the rule entry in the domain.ini file at the server. This means the inventory executable will be run every time even if inventory is not actually going to be taken. This may be hard to understand, especially to the user.
Another subtle element of inventory collection is the "Every Workstation Logon" option for hardware and software inventory. This description is something of a misnomer. When this option is selected what it really means is that every time the inventory executable is run inventory will be collected.
The last configurable inventory parameters are the "Inventory Strategy When Network is Slow" options:
· Take Inventory Anyway
· Prompt Workstation Users
· Don't Take Inventory
These options give the administrator the ability to treat workstations on slow links within the site differently than the rest. The link speed is determined by the netspeed executable that is run from the SMSLS.BAT file. When looking at the slow link strategy consider the amount of software current being inventoried. When a lot of software is being inventoried the times will start to get longer. When running at normal net speeds it won't be noticeable, but over a slow link it will. If workstations will be part of a site and running across a slow link, then you will need to select "Take Inventory Anyway" to make sure that they are getting inventoried. In this case you really need to keep the inventory times low by not trying to inventory for to much software. If the workstation will just be across slow links occasionally as with portables, then select "Don't Take Inventory". The "Prompt Workstation Users" option requires manual intervention and puts the strategy into the hands of the users. Opt for the reducing software being inventoried option as mentioned previously.
The ability to extend the inventory is a powerful feature of SMS, but again with flexibility comes the warning. Carefully choose the strategy for use. The easiest way to extend the inventory is with the MIF form generator program. This gives the ability to create a form that the MIF entry program uses. The MIF entry program allows the user to fill out a form that when accepted by the user will create a MIF. The problem is that this approach is manual. In order to keep with the automated enterprise aspect of the system keep the number of MIF forms presented to the user though this approach to a minimum. Again this extension is only as good as the user input.
The MIF approach could be used in some automated fashion to extend the inventory without user intervention. Several corporations are currently using this automated MIF approach to extend the inventory for many different elements from server hardware characteristics to automated software scans.
Nothing offers a greater opportunity for benefit within SMS than the ability to automatically install and upgrade software. Most PCs in corporations today have some form of software installed locally. Applications such as word processors, spreadsheets, mail and on and on. This software must be installed, upgraded with new releases and supported.
Most current approaches involve having the user work with disks, or in rare occasions from the server, to install or upgrade their workstation. Or worse yet, an individual will be sent around from machine to machine and perform the action for the user. Both approaches are very costly and in the case of the first you have someone spending time away from their primary duties. Now add these issues to the problem of performing the work in a repeatable fashion and it is easy to see the benefits that SMS can provide.
So what is involved in setting a strategy for software installation? First, understand the details of how software is distributed though the sites, logon server and distribution server so existing resources are used effectively. Second, understand what is involved in creating a custom script to distribute software.
The details of distributing software are defined through the job dialog screen shown below.
While there is much to understand about distributing a job each of the four sections of the job screen has a key point to remember.
The Job Target section is the heart of the job distribution strategy because it defines where the software is to be distributed. The "Query Results" mechanism is used to distribute a job based upon a predefined query. This mechanism should be considered as the primary way to control a job. The reason the query approach is the way to go revolves around how SMS implements each option. The query is resolved when the job actually executes while all other options determine which workstation meet the criteria when the job is created. The query approach thus provides a more up to date view of the workstations and guarantees that the job will reach the workstations that need it. The "Machine Group" approach is more appropriate for distributing to servers where the target group is more static and well defined.
The Send Phase is used to control the distribution of the compressed package. A compressed package is used to move the software from the source location to sites where the distribution servers, that will ultimately receive the contents of the package, are located. The "Only If Not Previously Sent" option helps when you want to distribute the package to a distribution server that was not part of the original job. This way the overhead of recompressing and resending the package will be avoided. The other option of "Even If Previously Sent" is essential when you need to make a minor change to the package source. Creating a job with this option will recompress and redistribute the package so that all sites will be updated with the new modules. This avoids the need to create a new package and job to distribute when changes are needed at the source directory.
The Distribute Phase controls the second step of the distribution process, the decompression of the package to the distribution servers. "Put On Specified Distribution Servers" is used to tell SMS which distribution servers to decompress the package to. The best approach is to create machine groups to contain the distribution severs based on what makes sense for distributing software. This will lessen the reliance on the default servers machine group.
Once the job is created and executing keeping track of the status will be essential to know if a problem exists. The job status details screen provides several elements to help track the status.
In the type field the Arrival, Server and Completion entries can be used to track the package status from the source to the distribution servers. The Workstation entry will be key to understanding what has occurred at the workstation. There will be a separate entry for every workstation that gets the software. The point to remember is that the workstations entry status will reflect the current state of the job at the workstation. If the job has not been set to expire then the workstation will be able to rerun the job over and over. The status field in the job status details screen will be updated appropriately. When the workstation first runs the job and it is successful the status will show success, but if the workstation reexecutes the job and it fails that status will then be reflected in the job status details. You can use this information to determine when all workstations have successfully installed the software and the job can then be canceled keeping anyone from reexecuting the job.
SMS provides scripts to distribute most Microsoft products, but a large advantage of software distribution will be products developed internally by the corporation. To accomplish this scripting will need to be done. Scripting can take on several forms:
· Batch files
· Custom setup programs
· Microsoft Test scripts
· Other 3rd party scripting products
When using the more sophisticated scripting tools it is a good idea to develop a strategy. The following items have been used in developing a Microsoft Test based strategy, but should also work for other technologies.
· Create a Template, defining standards, to be used by all scripts
written
· Approach is based around breaking installation into discrete
measurable steps
· Uses INI file read at stript startup to define key elements
of status MIF
· Provides checks for appropriate disk space availability as step
1 in the process
· On an upgrade start by backing up the current software
· Each step provides a descriptive status for failures
· Rollback capability based around undoing each step to replace
the environment on a failure at any step
· Create a status MIF file
Creating a status MIF is essential in being able to troubleshoot
custom installations. The following example provides a status
MIF file used in a Microsoft Test script. The regular variables
are read from and INI file at the time the script executes. The
success or failure status information is determined through the
script execution and filled out when the MIF file is created.
SUB CreateMIFile(sMIFMessage as String) '************************************************************' This routine will create the MIF file used to report status' back to SMS for the job. '************************************************************ DIM iReturn as Integer DIM hMIFile as Integer ' ' Open the MIF file. ' hMIFile = FREEFILE OPEN GetWindowsDir+"SMSMIF.TXT" FOR OUTPUT AS #hMIFile ' ' Create the contents of the MIF file. ' PRINT #hMIFile, "START COMPONENT" PRINT #hMIFile, , "NAME = " ; CHR$(34) ; "WORKSTATION" ; CHR$(34) PRINT #hMIFile, , "START GROUP" PRINT #hMIFile, , , "NAME = " ; CHR$(34) ; "ComponentID" ; CHR$(34) PRINT #hMIFile, , , "ID = 1" PRINT #hMIFile, , , "CLASS= " ; CHR$(34) ; "DMTF|ComponentID|1.0" ; CHR$(34) PRINT #hMIFile, , , "START ATTRIBUTE" PRINT #hMIFile, , , , "NAME = " ; CHR$(34) ; "Manufacturer" ; CHR$(34) PRINT #hMIFile, , , , "ID = 1" PRINT #hMIFile, , , , "ACCESS = READ-ONLY" PRINT #hMIFile, , , , "STORAGE= SPECIFIC" PRINT #hMIFile, , , , "TYPE = STRING(64)" PRINT #hMIFile, , , , "VALUE = " ; CHR$(34) ; sManufacturer ; CHR$(34) PRINT #hMIFile, , , "END ATTRIBUTE" PRINT #hMIFile, , , "START ATTRIBUTE" PRINT #hMIFile, , , , "NAME = " ; CHR$(34) ; "Product" ; CHR$(34) PRINT #hMIFile, , , , "ID = 2" PRINT #hMIFile, , , , "ACCESS = READ-ONLY" PRINT #hMIFile, , , , "STORAGE= SPECIFIC" PRINT #hMIFile, , , , "TYPE = STRING(64)" PRINT #hMIFile, , , , "VALUE = " ; CHR$(34) ; sProductName ; CHR$(34) PRINT #hMIFile, , , "END ATTRIBUTE" PRINT #hMIFile, , , "START ATTRIBUTE" PRINT #hMIFile, , , , "NAME = " ; CHR$(34) ; "Version" ; CHR$(34) PRINT #hMIFile, , , , "ID = 3" PRINT #hMIFile, , , , "ACCESS = READ-ONLY" PRINT #hMIFile, , , , "STORAGE= SPECIFIC" PRINT #hMIFile, , , , "TYPE = STRING(64)" PRINT #hMIFile, , , , "VALUE = " ; CHR$(34) ; sVersion ; CHR$(34) PRINT #hMIFile, , , "END ATTRIBUTE" PRINT #hMIFile, , , "START ATTRIBUTE" PRINT #hMIFile, , , , "NAME = " ; CHR$(34) ; "Serial Number" ; CHR$(34) PRINT #hMIFile, , , , "ID = 4" PRINT #hMIFile, , , , "ACCESS = READ-ONLY" PRINT #hMIFile, , , , "STORAGE= SPECIFIC" PRINT #hMIFile, , , , "TYPE = STRING(64)" PRINT #hMIFile, , , , "VALUE = " ; CHR$(34) ; sUserName ; " at " ; sCompanyName ; CHR$(34) PRINT #hMIFile, , , "END ATTRIBUTE" PRINT #hMIFile, , , "START ATTRIBUTE" PRINT #hMIFile, , , , "NAME = " ; CHR$(34) ; "Installation" ; CHR$(34) PRINT #hMIFile, , , , "ID = 5" PRINT #hMIFile, , , , "ACCESS = READ-ONLY" PRINT #hMIFile, , , , "STORAGE = SPECIFIC" PRINT #hMIFile, , , , "TYPE = STRING(64)" PRINT #hMIFile, , , , "VALUE = " ; CHR$(34) ; DATETIME$ ; CHR$(34) PRINT #hMIFile, , , "END ATTRIBUTE" PRINT #hMIFile, , "END GROUP" PRINT #hMIFile, , "START GROUP" PRINT #hMIFile, , , "NAME = " ; CHR$(34) ; "InstallStatus" ; CHR$(34) PRINT #hMIFile, , , "ID = 2" PRINT #hMIFile, , , "CLASS = " ; CHR$(34) ; "MICROSOFT|JOBSTATUS|1.0" ; CHR$(34) PRINT #hMIFile, , , "START ATTRIBUTE" PRINT #hMIFile, , , , "NAME = " ; CHR$(34) ; "Status" ; CHR$(34) PRINT #hMIFile, , , , "ID = 1" PRINT #hMIFile, , , , "ACCESS = READ-ONLY" PRINT #hMIFile, , , , "STORAGE = SPECIFIC" PRINT #hMIFile, , , , "TYPE = STRING(32)" If ( sMIFMessage = "Success" ) Then PRINT #hMIFile, , , , "VALUE = " ; CHR$(34) ; "Success" ; CHR$(34) Else PRINT #hMIFile, , , , "VALUE = " ; CHR$(34) ; "Failed" ; CHR$(34) End if PRINT #hMIFile, , , "END ATTRIBUTE" PRINT #hMIFile, , , "START ATTRIBUTE" PRINT #hMIFile, , , , "NAME = " ; CHR$(34) ; "Description" ; CHR$(34) PRINT #hMIFile, , , , "ID = 2" PRINT #hMIFile, , , , "ACCESS = READ-ONLY" PRINT #hMIFile, , , , "STORAGE = SPECIFIC" PRINT #hMIFile, , , , "TYPE = STRING(120)" PRINT #hMIFile, , , , "VALUE = " ; CHR$(34) ; sMIFMessage ; CHR$(34) PRINT #hMIFile, , , "END ATTRIBUTE" PRINT #hMIFile, , "END GROUP" PRINT #hMIFile, "END COMPONENT" CLOSE hMIFile Copy GetWindowsDir+"SMSMIF.TXT" TO GetWindowsDir+sMIFile ENDSUB
Providing applications from a server in a shared environment can be an attractive reason to use SMS. While SMS has gone a long way to make shared applications easy to use with many nice features, the actual technology of shared applications is still immature. Many potential problems exist in this environment with today's OLE enabled applications.
Two elements of the shared application need to be understood to make sure that a proper strategy is established.
· The use of Global Groups to control access
· The approach for selecting which distribution server will be used
The job setup dialog is very similar to the setup details of a software distribution described earlier. In fact the same guides suggested in the section on software distribution for the Send Phase and Distribute Phase apply. The difference is the Job target section. In a Share Package On Server Job, the package is only moved to a site and distribution servers so no need to define individual workstations exist. Taking this a step further shared applications are not controlled by workstation information, but rather by user information.
The NTS global group becomes the controlling factor for shared applications. A program group is created and package(s) are selected to be mapped to the program group. From this a subset of the applications within the package(s) individual applications can be selected. Now for the key, NTS global group(s) are assigned to the program group. Membership in the global group determines who has the ability to execute the applications defined by the program group.
Create The Program Group
Define The Applications From The Package
Assign The Global Groups
When the user logs in to a workstation and runs the Program Group Control application, it determines which shared applications the user should have. It then creates program groups or deletes old groups on the desktop for the user. The fact that global groups define access to the applications means something interesting happens. The users desktop view of shared applications follow the user to any workstation on the network. This also can present an adverse side effect. If the user logs on to a workstation in a site where the application was not sent to a distribution server at that site, the desktop will still be setup as if the application is available. This is an issue that needs to be understood when sending the application to distribution servers, especially when the Master Account Domain model is used.
Shared applications work by distributing the application to one or more distribution servers. Users are given access to the application by creating a program group that grants access to global groups. This sets up a scenario where an application can be distributed to multiple distribution servers and access being granted to certain global groups. When a user runs the program group control application, it gathers a list of available application servers from the logon server. From this list a random selection produces a server from which the program group control application will use for the shared application. Now the key to all this is the random selection of the server.
Consider the case where the global group used covers the entire population of users, say domain users. The distribution servers used when distributing the application cover the entire hierarchy, which cross several slow network line speeds. A user could end up reaching across a slow link to get to a server when one is sitting on the same segment as the user.
One can quickly see that when implementing shared applications the actual server environment needs to be known, otherwise the desired effect may not be obtained. The keys are how the NTS domain is setup, physical network layout, distribution servers used and global group assignment to shared applications.
SMS provides a wealth of diagnostic utilities and for the most part they don't require a strategy to be used effectively. The bad news is that the tools cover a wide range of skills required to be used effectively. The low end helpdesk tools are easy to use and understand - remote execute, remote file transfer, remote boot and remote control. The mid range helpdesk tools are easy to use but require windows knowledge to comprehend - Windows memory, Windows classes, Global Heap, GDI Heap and others. Finally the high end that require high skill levels to operate and understand - Network Monitor.
Since most of these utilities will not be used by the same individuals administering the major components of SMS, some guidelines need to be established. The SMS security manager utility is provided to help setup security for the administrator UI. The security manager utility will help segregate the users of these features from the other SMS features.
The remote control program has several requirements to run. A TSR program is required for the Administrators UI to connect to a work station with the remote control utility. Proper SMS setup and operation will load the TSR. Since remote control requires the TSR to run properly, you need to make sure no other programs conflict.
The remote control agent uses a special NetBIOS name. In a TCP/IP environment over a routed network, where name query requests are unresponsive, since IP-level broadcasts to not pass, a special configuration is required. The LMHOSTS file can create this mapping by placing the NetBIOS name on the client of the remote query and the proper name on the administrator UI workstation. The client needs to have the 16th character in the name represented with a D. On the administrator UI the 16th character of the name is represented with a C. This is documented in the Administrators Guide, Chapter 15 Remote Troubleshooting Utilities.
The network monitor utility provides a full featured software sniffer. The program is launched from a personal computer properties screen. With this as the starting point for the network monitor program it will be configured, via the filter capability, for monitoring all traffic to and from that workstation. After the network monitor program is running it can be manipulated as a stand alone software sniffer. The network monitor utility is a powerful troubleshooting tool in the hands of an experienced user.
One caveat is that for the network monitor to work you need a network adapter card that supports promiscuous mode.
Like most other areas of SMS there is a wealth of tools and techniques for troubleshooting. Many of these can be found on the SMS CD and have been developed by or as a result of PSS. They are located in the PSSTOOLS directory. Below is a sample of some of the most useful utilities.
CLEANSMS.BAT Used to clean SMS files off clients. Usage: Type "cleansms d", where "d:" is the drive where your ms\sms\bin directory lives. When used on NT you will need to type "y" when asked for permission to delete a directory. Afterwards, there are instructions letting you know what's left to be done. Note: Due to the wide application of this utility, you will notice error messages such as "Unable to delete/find file" this is normal and is not a cause for concern. DUMPSEND.EXE This will display the contents of a send request. Usage: "dumpsend filename" A send request file is composed of a series of records, these records are: * send request data record gives information such as: destination site, priority, job name, job id, outbox location * cancel record is this sendreq canceled or not * action code record retry, deleted... * address record (multiple records allowed) includes all the undecipherable encrypted names as well as the gateway and destination addresses. * package file record name of package file * instruction file record name of instruction file * sender record includes information about what the sender history ie status, time of last event, start time, number of times a sender took this sendreq, size of sendreq * access record file access information * ssps record information about the remote site install MIFCHECK.EXE This is a MIF parser/syntax checker for use in verifying text MIFs before submitting them to the system. It reports syntax and semantic errors. It is designed to help ISVs who are writing MIFs for new components for SHIC to report. SENDCODE.EXE Used to send service control codes to SMS services.
A major troubleshooting tool in SMS is the trace file. Each SMS service can be monitored via a trace file. Tracing does have a small amount of overhead involved, but when troubleshooting a problem it is essential. The trace file size is set and trace information is logged until that size is reached. Then a backup of the file is created and logging begins again until the maximum size is reached. This provides a history equivalent to two times the maximum size.
The service manager program show above provides the capability needed to control the SMS system services and the trace files. The service manager can start and stop each service individually. A caveat about the service manager pertains to the services displayed. SMS actually only has 5 services but the service manager shows many more. Some of the services in the service manager are actually threads of the SMS Executive service and are started and stopped based on that service. The same can be done for the trace files. The service manager can also control remote SMS systems.
All messages are logged to the NT Event viewer as well as the SMS database. In fact the messages in SMS are displayed in a format that is consistent with the NT Event viewer. Since message can be viewed through the administrators UI there is little reason to use the NT Event viewer to look at SMS messages.
As with all messages, SQL Server messages are written to the SMS database. The only time one would really need to view the SQL Server error log file is in cases of extreme SQL Server errors. Make the SQL Error Log the last step in the troubleshooting process and only when the problem is recognized to be SQL Server related.
The SMS system is a very complex SQL Server database program. As such, the SQL Server database needs to have basic disaster recovery concepts applied. A sound backup schedule needs to be setup and maintained. The standard SQL Server DBCC monitoring approaches should also be used.
Follow the suggestions in the SQL Server Administrators Guide for proper operations. There are sound guides to scheduling backups and tips for using DBCC in the SQL Server documentation.
Try to minimize administration points in the system and set standards for administration tasks. Develop a sound inventory strategy. Understand the software distribution process as it relates to distribution servers. This is especially important for network shared applications. Utilize the software distribution capabilities by creating custom scripts for distributing internally developed applications. Learn all available troubleshooting tools and techniques. Learn the system flow of SMS to help augment the troubleshooting tools.
SMS provides the needed set of features for systems management. In fact the amount of features can be overwhelming to any administrator. With the wealth of different features SMS will often be administered by many different administrators. All of these facts point out the importance of understanding the functionality in depth and establishing sound strategies for administration of each. Follow these simple guidelines and realizing the benefits of systems management will be easy.
When searching for more information on SMS administration don't forget the SMS Administrators manual. Two appendix sections are very helpful in understanding the overall design.
· Appendix B: SMS Client Reference
· Appendix C: SMS System Flow
© 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 |