AppDeploy: Articles: Custom Deployment Scripts

Home > Articles > Custom Deployment Scripts: Pluses and Minuses

 Custom Deployment Scripts: Pluses and Minuses

If you take a look at the survey on our home page, you'll see that a surprising number of visitors use a custom script to handle their network software deployments. Why is this? Many have tried one of the more well known products like SMS or Tivoli, ran into problems and in the process of scripting solutions around the problems, developed an entire scripted solution. Cost is another key reason for going with a customized deployment, purchasing deployment software and client licenses become an increasing issue as the size of the network to be managed grows in size. Automation must exist, configuration management is impossible to maintain without some level of centralized management. Increasing the cost of many commercial off the shelf (COTS) products is the fact that so many include a suite of applications or some framework, which by definition, is very complex and even more often expensive. A final reason, not often considered, is that until AppDeploySM there was nowhere to learn of the competition to the more recognized products and their capabilities. Being that the market for application deployment tools is still very immature, there has been little information to assist administrators in making an educated choice which best meets their needs.

However there are also several reasons not to go with a customized solution. One large one is support. A COTS product provides you with a help desk, regular updates, documentation, and in some cases training and technical papers. The support that comes with a customized deployment script is limited to what can be accomplished by the individuals familiar with the script. This brings to light the largest problem, normally there are only a small number of people intimately familiar enough with the script to troubleshoot problems and implement enhancements. The retention of these individuals cannot be guaranteed.  For this reason, thorough documentation is essential. It is very common that documentation for custom deployment scripts is poor or non-existent. Optimally, documentation would pull apart and explain the script to a level that anyone could understand. Finally, almost all scripted solutions rely on the population and placement of text files that can be easy to confuse as compared to the simplicity of a graphical user interface. Blinding the operator of the script from seeing exactly what actions are taking place can have potentially catastrophic effects for inexperienced operators.

            Take some steps toward a making an educated assessment of your situation. In the creation and use of custom deployment scripts, sufficient experience should be on hand to develop a proper set of requirements for a COTS replacement. A list of what you need in a replacement is essential. There may be no product that meets your requirements; there may also be some essential functionality you didn’t consider. This may be an exercise fraught with resistance by those who generated and maintain the custom script. However these are the people who know the requirements best, and are therefore essential in the process of building and researching a COTS replacement.

If and when solutions are uncovered, it may still not be the right time to make a switch. Financially there may not be the money available for the product and there may be increased deployment activity taking place that requires you to stay on track until a later date.  But don’t catch yourself waiting for the time when no deployments of updates, fixes or new software is taking place- that day may never come.

Bob Kelly

Be the first to comment

AppDeploy - HKEY_CURRENT_USER - Pushing User Profile Settings

Home > Articles > HKCU - Pushing User Profile Settings

HKCU - Pushing User Profile Settings

HKCU (HKEY_CURRENT_USER) settings introduce a different set of problems in deployment. These registry settings are stored in each individual user profile and that makes getting them to everyone a bigger problem than simply installing files and registry settings to a machine. Most well written applications that use HKCU to store user preferences will detect the hive and default values don’t exist when first run. The application should then create and populate its HKCU information with defaults automatically. However, some applications that are not written so well may need to have its desired settings present in order to function properly. More often pushing HKCU settings becomes a task for those wishing to deploy a nonstandard set of default user settings with an application. There are two basic ways to complete this task, through a logon script or through system policy settings.

Most networks use a logon script of some kind. If not, a script can still be used in the same way by adding it to the “All Users” startup group. Either way you do it, you will be sure to want the script to run only once for each user. To do this, the script should first check for a footprint left behind by its initial execution before running, this will prevent it from running over and over again. The footprint can be any change performed by the script that can then be checked for to show the script has been run before. It is a good idea to keep these footprints located in a central area so that they may be checked for later with greater ease. An example:

If $FOOTPRINTS\Change1 = "Complete" Then Goto "End" EndIf
If Exist "$FOOTPRINTS" <> 0 AddKey "$FOOTPRINTS" EndIf
SetValue ("$FOOTPRINTS", "Change1", "Complete", "REG_SZ")

In the above example the script will only run once for each user. The footprint area in the registry will be created if it doesn’t exist. The example is written in KixTart, but can be just as easily written as a simple batch file, in Perl or in any other scripting language. Here the Windows NT “REG” command is used to implement some previously defined registry entries.

The second way to implement user settings, and in some cases the better way, is to use system policies. System policies force registry entries and can do so to all users, or members of specified NT groups. Remember that this method forces settings, so anything set here will always overwrite any settings made by users.

Most think of system policies as what is presented in the default templates provided by Windows NT. However additional settings can be used as well by creating a custom template. For example:


CATEGORY !!MicrosoftIE
CATEGORY !!ConnectionTab 
KEYNAME "Software\Policies\Microsoft\Internet Explorer\Control Panel" 
POLICY !!ProxyEnable
            KEYNAME "Software\Microsoft\Windows\CurrentVersion\Internet Settings"
            VALUENAME "ProxyEnable"
            VALUEON NUMERIC 1
            VALUEOFF NUMERIC 0

A good source of detailed information on creating a custom policy template can be found at: http://msdn.microsoft.com/library/winresource/dnwin95/s646d.htm. An excellent overview of system policies can be found at: http://www.microsoft.com/SYSPRO/win98/Reskit/Part2/wrkc08.asp.

By default system policies are always implemented if present, this can be controlled by the following registry entry:


UpdateMode is a REG_DWORD with the data values:  
0 - A policy file is not downloaded from a server and is not applied.
1 - NTconfig.pol is downloaded (if present) from the NetLogon share of the %LogonServer% and applied.
2 - The UNC path of the policy file is read from NetworkPath and if present, downloaded and applied.

NetworkPath is a REG_SZ value that contains the full UNC path to the policy file. It is only used if UpdateMode is a 2. Example: \\ServerName\ShareName\Policy.pol

The System Policy Editor is not included in the floppy disk version of Windows 95. You can download Policy.exe that contains Poledit.exe. Please see the following article in the Microsoft Knowledge Base for information about downloading Policy.exe: Q135315 

One additional thing to keep in mind is what settings are present in the default user profile. Unless these scripts or policies are to remain in place to cover any new users, which is perfectly acceptable, the default user profile should be modified to incorporate any desired changes. Remember there are two default profiles to update, both the local and network default profiles.

The time will come when pushing user settings becomes necessary. If each machine is used by just one user, and packages are pushed in a way that the user actually performs the installation- HKCU settings can be pushed with the installation package itself. This is rarely the case though, and it is only a matter of time before a particular HKCU setting must be implemented.

Bob Kelly 1/23/00

Be the first to comment

AppDeploy: Case Study: Womens Club Drive Imaging

Case Study: The Women's Club Drive Imaging

Practical Use of PowerQuest Drive Image

In Chantilly, Virginia the Women's Club fitness center has a three room nursery that contains three computers for the children to play educational games on. The problem was, the nursery staff was not experienced enough with computers to be able to fix the many problems that these computers would cause them. Several of the common problems they faced were due to improper shutdowns of the computer, resulting in corruption of application and system files. A rebuild was the only way to correct this problem, but it would take someone hours to rebuild the machine and reload all the software when there was someone around who was able to do so.

AppDeploySM proposed a hard drive imaging solution. PowerQuest's Drive Image was inexpensive and fast. If a computer had problems, a quick reimaging of the computer's hard drive  would solve any software related problem they could be faced with. The three machines they had were all identical in hardware, so one image would solve the problems of any of machines in the nursery.

We took one of the computers and reloaded it from scratch. Windows 98 and several children's games were installed. Using Microsoft's TweakUI from the Windows 98 resource kit power toys collection, the Windows desktop was modified to hinder children from accidentally getting into things they shouldn't. Once everything was installed and all the latest drivers and updates were applied, we installed Drive Image to begin the imaging process.

It didn't go quite as smooth as we had hoped. For one thing the computer only had one drive and one partition. Luckily we had Partition Magic to create a second partition of sufficient size to store the image file to be created, this is a must as you cannot create an image of a drive and store the image file on the same partition. The image turned out to be bigger than the 650 megabytes we wanted to store on a CD-R, so we created a second image and this time we specified that the image be broken up into 650mb pieces within the advanced user options. We got the image burned onto two discs, labeled them and then used Drive Image to create boot disks for the process.

The software creates two boot diskettes, one to boot the machine and load the necessary drivers (in our case a CD-ROM driver) and a second which contained the DOS application which would perform the application of the image. There were already two CDs involved and we wanted to keep things as simple as possible for the nursery staff who would be performing the image loads. After some playing we were able to fit the system files (so the disk would be bootable), the CD-ROM driver (so the image could be read from the CD), and the Drive Image application onto a single floppy.

We were then disappointed to find that the command-line support for the Drive Image application was very limited. It was hoped that because the task performed would be identical each time, the boot disk would be able to specify the options desired, leaving the nursery staff to only add a second CD when prompted. Instead we created a list of options to choose through the mouse driven menus that initiate the loading of the image.

In the beginning it was hopped that a bootable CD would be able to perform the application of the image with no interaction, but due to the limitations of the product's command line support and the size of the image itself, this goal was not possible to meet with the added limitation of needing an inexpensive solution. In the end the Women's Club nursery has a solution which is relatively simple to perform, and which for under $100 per computer, is saving them from problems they would otherwise be unable to solve on their own.

Bob Kelly

Be the first to comment
Showing 3261 - 3263 of 3263 results

Talk About Networking