Simple Scripting Customizes SMS Software Distribution
The case study in this white paper is a first person story
by Scott Binner, a new SMS administrator, and also a new WinBatch customer. He
describes how he learned SMS. When he ran up against problems, he answered them
with WinBatch scripting. Sample WinBatch scripts are included to show how
WinBatch handles software distribution when used with SMS.
SMS Overview
SMS inventories Windows PC hardware and software. It can
also push software installation packages out to client PCs. Packages can be
furnished as part of the original software product. They can be built with
software dedicated to this purpose. The most flexible option is to prepare
packages with a scripting language.
WinBatch Overview
WinBatch is a scripting tool designed for controlling
everything on a Windows PC. This includes software applications, data
manipulation, network administration activities, and Internet tasks. It can use
simple pre-built dialogs for user interaction. It can also construct graphical
dialogs for more demanding tasks.
Functions in WinBatch run in a linear sequence. This is
well suited for controlling software installations. The diagnostic capabilities
in WinBatch can diagnose and fix local hardware configurations. It can test
operation of the PC, network connections and more. Extensive function support
makes it easier to manage Microsoft and Netware networks. In short, whatever
the difficulties in a software installation, Over a decade of experience gives
the assurance that WinBatch has an answer.
Customizing SMS Software Distribution Packages with
WinBatch
Scott discovered that he needed to customize SMS in order
to roll out silent software installations on thousands of PCs. Microsoft’s SMS
could push out software deployment packages, but somehow there were always a
few failed installations and unhappy clients.
Truly silent deployments became a reality when Binner created
a prevention script made with WinBatch. It ran first to detect wayward PC
configurations, exit from the installation, and send a report on the incident.
With no training, Binner eliminated a long-standing source
of irritation and negative client experience with his company’s IT
administration.
Evaluating WinBatch
After reading this case study, you might like to see if
WinBatch can work for you. The most efficient way is to first download and
install one of WindowWare’s free, 100% functional demos. Get them from
http://www.winbatch.com/download.html.
After this software is installed, you will see a
directory with access to a short tutorial. You can run winbatch.exe from the
Windows Run dialog any time to see the same choices.
SMS Package Creation and WinBatch
in an Enterprise Environment
by Scott Binner
Starting Cold
It’s been just one year since I
took over SMS 2.0 for a global corporation. My experience started with learning
how SMS worked. This progressed to pushing software packages out to thousands
of PCs.
Along the way, I needed a scripting tool to package
software for push distribution. I also needed the ability to handle a diverse
population of PCs and users. This case study covers my experience with WinBatch
scripting in distributing SMS packages to a large installed base of Windows
desktop PCs.
Whenever someone mentioned scripting to me, I always associated
it with the world of the IT administrator. I was by no means a programmer, but I
saw scripting as synonymous with Microsoft SMS. I started out with very little
knowledge. But soon I found that I could reliably push software out to
thousands of PCs with SMS and WinBatch—a PC scripting language and general
purpose utility maker.
WinBatch had several critical capabilities:
- Quickly modifying and testing packages without having to compile
code.
- Deploying packages from source directories instead of from
distribution points..
- Deploying multiple packages at once
- Identifying, logging and repairing errors.
- Recording software installation information in the Registry
- Installing different types of files
- Managing user and group permissions
- Manipulating vendor-supplied installation routines
The learning curve for SMS is pretty steep, but the
support is outstanding – except for one thing; package creation. There are a
lot of resources for every facet of SMS, but no single resource for creating a
solid, reliable package for deployment.
Many software vendors provide tools for creating an
administrative install of sorts, but like most administrators, I want as little
user interaction as possible and a few customizations. Many products will do
the “before and after” snapshot of an install. I have found that this not the
most effect way of dealing with silent software deployment. The scripts these
products create are difficult to work with. This process does not allow for
much control and that can be disasterous with multiple Windows platforms.
The Winbatch Answer
SMS creates a unique environment for software installs. It
also presents scripting challenges. Once a software distribution package has
been sent out to distribution points it is scheduled for deployment. From this
point on, the process is out your hands. The results of doing things wrong,
even a little wrong, quickly mushroom into massive headaches.
Since there is no “right” way to make a package, a lot of
the process is left to creativity and invention. Your only salvation is a
flexible and powerful scripting tool. Here are some basic concepts and examples
that should give you an idea of what has to be taken into account:
Plan on exception handling
Why would we
start the planning a package with a means to exit the package? I always provide
a means to get out of the script if something should fail. Since a package runs
unattended on thousands of PCs at once, one would rather have a deployment exit
than crash any one of those thousand PCs. I always think of the “what if?” when
writing my script. This is more of a programmer’s philosophy, but it is a
necessity with large deployments.
Check for "issues"
In the example here, the presence of a previous copy of
the software results in an uninstall rather than an install! The script I use looks
for the software executable. If it is found, it displays a message on the
screen, and exits the entire install. Those well versed in SMS would likely say
that the collection created for the deployment could exclude PCs with this
file, but I have seen SMS miss a few. I learned quickly to always provide a
safe and quiet exit for packages. This has the additional benefit of allowing for
a proper exit code to report to the SMS server.
;This section checks for a current install of the VPN client
Existing = FileExist ("C:\Program Files\Cisco Systems\VPN Client\ipsecdialer.exe")
If Existing == @TRUE
Message ("Attention","The Cisco VPN Dialer is already installed on this system!")
Exit
EndIf
; The rest of your script here
; And the script exits here
Exit
Editors note: If the executable file could be in another
location, WinBatch has a file search extender that can search throughout a
directory structure. Another function can get a list of local hard drives for
use in searching through more complex hardware configurations
Exception Handling: System Timeouts
When deploying a script to install software on multiple PCs, you have to take into
account performance differences between PCs. Since software vendors might not
provide tools for silent and/or quiet installation, you may have to resort to
using SendKey commands for certain portions of your install job. Since
software on a very slow PC may take longer than five seconds to launch a
window, the SendKeysTo command can fail. WinBatch has a WinWaitExist function
that can wait for any set time before continuing with the keystrokes. A simple
loop can have Winbatch wait for the window before sending the command.
;Example: Sending Keystrokes without checking for existence of target window.
SendKeysTo ("Welcome","{ENTER}")
SendKeysTo ("Software License agreement","{ENTER}")
SendKeysTo ("Setup Complete","{DOWN}{ENTER}")
;Example: Sending Keystrokes after checking for existence of target window.
; WinWaitExist Waits 20 seconds for a window with the
; indicated title string. Returns 0 if unsuccessful.
Response = WinWaitExist("Welcome",20)
Terminate(response == 0,"Installation Ending","Installation stopped. Performance too slow.")
SendKeysTo ("Welcome","{ENTER}")
Response = WinWaitExist("Software License Agreement",20)
Terminate(response == 0,"Installation Ending","Installation stopped. Performance too slow.")
SendKeysTo ("Software License Agreement","{ENTER}")
Response = WinWaitExist("Setup Complete",20)
Terminate(response == 0,"Installation Ending","Installation stopped. Performance too slow.")
SendKeysTo ("Setup Complete","{DOWN}{ENTER}")
Message("Automatic Software Installation","The software was successfully installed.")
Exit
Editor’s Notes:
1. Exception reporting can be accomplished
in several ways. The ODBC functions can update a SQL database. WinBatch
Internet extenders can notify by email.
2. In the case of services not using the LocalSystem account, keystrokes
cannot be used in a script running as a
service. However, the WinBatch Control Manager extender can manipulate windows
through direct control. The WinBatch Roboscripter utility automates script
construction when this kind of low level control is needed.
Handling Permissions
The user PC must have the necessary permissions. These
include permissions to connect to the SMS database, SMS distribution points,
and of course, the local machine with a domain account.
SMS will run the package under elevated permissions using a
local account created by an SMS agent. However, permission settings on
distribution points must be taken into consideration. For example, distribution
points may be Netware applications or may be shared between Unix and Windows
environments. This can cause deployment failure.
Write permission" differences between platforms cause many
problems. While clients that initiate the installation run the package under their
own security context, it will belong to the domain administrators group. But that
domain administrator group may not have write permissions to the distribution
point in a multiple domain environment. To deal with this problem, it may be necessary
to copy the install script to the local hard drive and then perform the installation
from there. This method avoids permission issues related to distribution
points.
; Example: Simple script to copy a package and run it locally.
; Patches.exe is a compressed file that has contains
; “Msdun13.exe”, it self extracts from the distribution point
; to the location of C:\VPN\Patches\Msdun13.exe
; MSdun13.exe now runs under local admin authority vs.
; needing domain permissions for the distribution point
; (again this is only a concern when multiple domains are involved)
RunWait ("\\server\distribution\Patches.exe","C:\VPN\Patches\Msdun13.exe")
Run("C:\VPN\Patches\Msdun13.exe","/q")
Managing Registry Settings
Windows revolves
around its registry. There are many aspects of software packaging that use the
registry. Winbatch can make all the changes that are not available with Active
Directory and Group Policy via SMS.
[Editor’s note: WinBatch can also make changes through OLE
automation, an ADSI extender, WMI, and networking extenders providing group
policy and security functions.]
The following example queries the registry. It determines
the operating system. It can run any software in the context of a particular
operating system.
Why would you do this considering SMS has default queries
and collections that segregate systems by their OS? Simple, it is simply more
efficient to roll out enterprise wide security changes, network settings
changes, internet proxy changes, and virus fixes -– the uses are endless. As a
plus, small scripts with registry changes require little bandwidth. They can be
deployed in mass without effecting network performance.
;Note: Also see the WinVersion function
ErrorMode(@OFF) ; protect against minor errors here
a=RegQueryValue(@REGMACHINE,"SOFTWARE\Microsoft\Windows NT\CurrentVersion[ProductName]")
b=RegQueryValue(@REGMACHINE,"SOFTWARE\Microsoft\Windows NT\CurrentVersion[CurrentBuildNumber]")
c=RegQueryValue(@REGMACHINE,"SOFTWARE\Microsoft\Windows\CurrentVersion[ProductName]")
ErrorMode(@CANCEL)
If a=="Microsoft Windows XP"
;Do something for XP
EndIf
If a=="Microsoft Windows 2000"
;Do something for 2000
EndIf
;Determining NT4 OS using build number
If b=="1381"
;Do something for NT4
EndIf
If c=="Microsoft Windows 98"
;Do something for 98
EndIf
If c=="Microsoft Windows ME"
;Do something for ME
EndIf
If c=="Microsoft Windows 95"
;Do something for 95
EndIf
:CANCEL
Exit
Instead of accomplishing registry editing from a script,
one can always export the key or keys I need from one system, name it after the
OS, and then run it from the script.
Example
Run ("REGEDIT.EXE","/S DNS_W95.REG")
would be inserted after
the Windows 95 menu and the *.reg file I had exported would be placed in the
same folder with the compiled script and sent to the distribution points. This
is simple and fast. Deleting keys or values would require scripting because
REGEDIT commands do not delete keys or values, they only add keys or change
existing keys. [Editor’s note: the WinBatch technical support database contains
samples of WinBatch scripts that delete registry entries.]
An example of this would be
RegDelValue(@REGMACHINE,"SOFTWARE\Microsoft\Windows NT\CurrentVersion\Winlogon[GinaDLL]")
Multiple Programs
Since SMS can run
another program prior to the intended package, you can create a simple script
to make any change to a system you would like and have that script run first.
Then run your intended install such as a silent install of IE 6.0. This allows
you the freedom to add enhancements to your deployment without have to get into
the intricacies of incorporating the script into MSI files. You can create a
Microsoft package in the paint by numbers format they they provide. Then you
can package it with a script that runs first. For service packs, managers often
us a dialog to warn users of the amount of time an install can take. Adding
this with WinBatch is both simple and efficient.
As you find various fixes, patches, and enhancements; the
ideas provided above will give you a good start to successful package
deployment. There are number of great resources for SMS itself. Winbatch help
files provide more than enough information for nearly any deployment script. It
is better to understand package creation as an art form vs. an IT task. Good
luck.
WinBatch Scripting Hints
Case Study: Test for presence of a file.
Task: Check for presence of a file before installing
software.
This two line script will check for a file and quit if it
is found. This will work for the simple case where the file will be found in
only one location. More complex user configuration problems may need more
robust solutions. See the following sections for more.
myFile = "C:\Program Files\Cisco Systems\VPN Client\ipsecdialer.exe"
If FileExist(myFile) Then Exit
Testing for Presence of Files
For common tasks like finding files anywhere on a hard
drive, WinBatch provides per-built solutions. The file search “extender” provides
a recursive search capability. It can find files with specific names, or with certain
content.
AddExtender("wsrch34i.dll")
; Look for a file. Quit the script if it is found.
; Continue with the script if the file is not found.
handle = SrchInit("C:\","myfile.ext","","",24)
; The 24 directs a search through subdirectories
; and hidden files are included.
foundfile=SrchNext(handle)
; Free search handle
SrchFree(handle)
If foundfile =="" Then Exit ; file not found
;Continue with script
Listing and accessing local hard drives
A file might be on one of any local drives. The DiskScan
function can return a list of drives, either removeable or fixed.
MyDrives = DiskScan(2) ; 2 specifies local fixed drives.
numDrives = ItemCount(myDrives,@TAB)
For iDrive=1 To numDrives
thisDrive=ItemExtract(iDrive,mydrives,@TAB)
;Process (or search this drive
Message("Debug",StrCat("Drive Found ",thisdrive))
Next
Exit
Using WinBatch Registry functions to find files
This WinBatch script gets a list of local software that can be
uninstalled.
;This WinBatch script gets a list of local software that can be uninstalled.
key=RegOpenKey(@REGMACHINE,"Software\Microsoft\Windows\CurrentVersion\Uninstall")
list=RegQueryKeys(key)
RegCloseKey(key)
;Display list
AskItemlist("List of uninstallable items",list,@TAB,@SORTED,@SINGLE)
Using WinBatch to find registered application files.
;This WinBatch script gets a list of registered installed software
AppPathKey="Software\Microsoft\Windows\CurrentVersion\App Paths"
key=RegOpenKey(@REGMACHINE,AppPathKey)
list=RegQueryKeys(key)
RegCloseKey(key)
;Display list
item=AskItemlist("List of registered softwatr",list,@TAB,@SORTED,@SINGLE)
;obtain further info
exelocation=RegQueryStr(@REGMACHINE,StrCat(AppPathKey,"\",item,"[]"))
pathinfo=RegQueryStr(@REGMACHINE,StrCat(AppPathKey,"\",item,"[Path]"))
Message(item,StrCat("Location: ",exelocation,@CRLF,@CRLF,"Path: ",pathinfo))
Using WinBatch for SMS-like Silent Software Distribution
WinBatch scripts can be compiled to run as services When
run in administrative context, the service can update software on the PC
automatically. See article W14961 in the WinBatch tech support database on
http://techsupt.winbatch.com. Also see article W13494 for more ways to achieve
SMS-like capabilities with WinBatch alone.
Sync'ing WinBatch Scripts used to Package Software
Installations
Run("\\server\dir\setup.exe","")
; SendKeysTo("Title of Window","keystrokes or {named keys in braces}")
SendKeysTo("Welcome", "{enter}")
SendKeysTo("~Software License agreement", "{enter}")
; Title is case sensitive. Precede it with a tilde “~ “ to use
; the title string as a partial, but acceptable, title.
SendKeysTo("~Setup Complete", "{down}{enter}")
Code sample with script timing:
Run("\\server\dir\setup.exe","")
myResult = WinWaitExist("~Welcome",15)
; timeout = 15 seconds.
; More than 15 seconds indicates system problems.
If myResult == 0
Message("Software Package","Very slow PC. Installation incomplete.")
Exit
EndIf
SendKeysTo("~Welcome","{enter}")
WinWaitExist("~Software License agreement",-1)
SendKeysTo("~Software License agreement", "{enter} ");
WinWaitExist("~Setup Complete",-1)
SendKeysTo("~Setup Complete", "{down}{enter}")
| 
