/bundles/itninjaweb/img/Breadcrumb_cap_w.png

Blogs

AppDeploy - Imaging Windows 2000

Home > Articles > Imaging Windows 2000

 Imaging Windows 2000
 

Deployment of a new client operating system is obviously a significant change for a network. The smoothest path to Windows 2000 is to upgrade your existing workstations using Microsoft’s extensive unattended setup options. In this way, you can keep the applications and settings in place that will ease the change on users. However, for many the upgrade to Windows 2000 is an opportunity to start fresh.

Years of installations, upgrades, removals and fixes leave a workstation in a state prone to various problems. Deploying a new drive image to workstations may be the answer to crushing the mess that has become of your workstations and at the same time allow you to standardize your new Windows 2000 baseline.  Here we will cover some tips and things to watch out for when imaging Windows 2000.

You may not be able to use the same image on all of your workstations. The hardware abstraction layer (HAL) for one computer will not work on a machine of a conflicting hardware configuration. Microsoft managed to reduce the number of scenarios where this would be an issue to two cases: Advanced Configuration and Power Interface (ACPI) and non-ACPI HALs are not compatible.

Not long ago, there were issues between uniprocessor and multiprocessor computers as well. An image may now be created on a multiprocessor computer, and then by implementing options available in SysPrep, the Windows 2000 installation will determine if a one or more processors are running and automatically use the correct kernel files following the Mini-Setup stage of the installation. 

As for the ACPI and non-ACPI compatibility issues, it is reportedly acceptable to image the lowest common denominator. An image with no power management (non-ACPI) can be applied to all workstations, but those workstations with power management features (ACPI) will loose those benefits. The opposite is not true; you cannot image a machine that does not have power management features (non-ACPI) using an image created on a machine that had such features (ACPI). The conversion from APM to ACPI is possible only through a reinstallation of Windows 2000.

The image may be a bit larger than expected, and there are a couple of reasons for this. The main culprit is the new Windows File Protection (WFP) feature in Windows 2000 that stores copies of system files in a “DLLcache” folder on the boot volume. When any of these protected files are removed or replaced, WFP will take the copy from the DLLcache and put it back again to ensure these desired files are always in place. The problem is that this DLLcache folder is hundreds of megabytes in size (the default setting is 400mb or approximately 2700 files.)  This problem is compounded further by the fact that when a Windows 2000 service pack is applied, instead of updating the files in the DLLcache, a second copy of the files are placed on the system. The System File Checker (SFC) tool checks the service pack location first and then the main DLLcache folder to find the desired files enforced by WFP. This second copy means that this feature may consume even more space.

This default setting may be adjusted by changing the size of the “SFCQuota” value in the registry (See knowledge base article Q222193 for details.) If by reducing the size of the cache, WFP detects a deletion or replacement of a file that it does not have a copy of in its DLLcache, it will look to the installation point for this file. If the installation were performed from a CD, the user would be prompted to insert the CD. However if the source were a network location available to the workstation, the files would be obtained from that point without prompting the user for media. This is a trade off that will have to be considered prior to deployment, if the space is available locally, it is best to keep these system-protected files locally.

Another reason the image may be so large is that the page file is part of the image. SysDiff contains an option called, “KeepPageFile” and by default this value is set to zero, which tells SysPrep to regenerate the page file. It does not however remove the page file from the image as indicated in the documentation. You can however, use the "Clear Virtual Memory Page File When System Shuts Down" policy in Windows 2000's Local Computer Policy to zero both the pagefile and the hibernation file (hiberfil.sys) which will free considerable space.

SysDiff for Windows 2000 is much more robust than its NT predecessor. SysPrep now supports a new “-pnp” switch that informs the Mini-Setup to rerun the full PnP device enumeration and installation on the computer. If plug and play does not detect all components on a networks range of hardware, it can be further manipulated to do so. Non-plug and play devices must have their drivers contained within the image.

SysPrep requires that the mass storage controller on the master computer be identical to the controller on the destination computer.  To support other mass storage devices for your image, they may be identified manually in the Sysprep.inf file before creating the master image. A section named, “SysprepMassStorage” must be added to the Sysprep.inf file listing each hardware id and its associated device INF file. One of the drawbacks of this is that the devices will be present on all machines the image is applied to. This may be cause for some confusion for some inventory software. The undocumented SysPrep switch, “-clean” may be used to remove unused mass storage devices. Those who worked with Windows NT unattended installs will be familiar with commandlines.txt, which is essentially a batch file executed following an unattended installation. This feature is now available to SysPrep itself and can be used to automate any number of scripted actions following the application of a new image. In this case adding “sysprep.exe –clean” will automatically remove unused mass storage devices following the Mini-Setup.

Support for the imaging of Windows 2000 is greatly improved, but as with any process there are always hurdles to overcome. Be sure to check back to AppDeploySM for more information on this and related issues in the future. Share your problems and solutions on imaging at our imaging forum!

Bob Kelly
9.3.2000
AppDeploySM

 
Be the first to comment

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
3/30/2000

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:

$FOOTPRINTS = "HKEY_CURRENT_USER\Software\UserPackages"
If $FOOTPRINTS\Change1 = "Complete" Then Goto "End" EndIf
Shell "REGEDIT CHANGE1.REG"
If Exist "$FOOTPRINTS" <> 0 AddKey "$FOOTPRINTS" EndIf
SetValue ("$FOOTPRINTS", "Change1", "Complete", "REG_SZ")
:End
Exit

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:

CLASS USER 

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
                       
END POLICY
           
END CATEGORY 
END CATEGORY

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:

HKEY_LOCAL_MACHINE\System\CurrentControlSet\Control\Update

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
11.5.99

Be the first to comment
Showing 3176 - 3179 of 3179 results