Customizing the Windows NT 4.0 Upgrade Process
| Archived content. No warranty is made as to technical accuracy. Content may contain URLs that were valid when originally published, but now link to sites or pages that no longer exist. |
A Framework for Building and Managing Complex Automated Upgrades
Abstract
Although there are a number of tools and methods for building an automated Microsoft® Windows NT® 4.0 installation, these tools and methods apply to new installations only, and do not work on a system that is being upgraded from an earlier version of Windows NT to Windows NT 4.0.
This paper describes a framework for planning, building, developing, and deploying automated system upgrades in a complex business environment. It describes tools, techniques, and practices that were used successfully in a recent large-scale Windows NT 4.0 upgrade deployment. The paper presents the upgrade process as a series of logical steps, and describes deliverables, responsibilities, and procedures for each step along the way.
On This Page
Introduction
Planning the Bill of Materials
Organizing the Build Process
Building the Automated Upgrade
Testing the Final Build
Deploying a Pilot Upgrade
Choosing A Deployment Methodology
Conclusion
Appendix A: Utilities
Introduction
There are a number of tools and methods for building an automated Microsoft® Windows NT® 4.0 installation. These tools and methods are clearly documented in the Automating Windows NT Setup Deployment Guide, which can be downloaded from https://www.microsoft.com/ntworkstation/info/Deployment-guide.htm . Unfortunately, these tools and methods apply to new installations only, and do not work on a system that is being upgraded from an earlier version of Windows NT to Windows NT 4.0. Therefore, the intent of this paper is to describe a framework for planning, building, testing, and deploying automated system upgrades in complex business environments.
Who Needs this Framework?
If your goal is to deploy a minimal upgrade of the operating system, you may find your software deployment process to be fairly straightforward and simple to accomplish. However, if you wish to upgrade the operating system, apply service packs, install new version-specific features, and install new or upgraded business applications, you will most likely find the upgrade process to be complicated and challenging. The latter situation is the case in most organizations—most companies choose to combine all of their changes into a single deployment rather than incur the additional cost, risk, and disruption associated with a series of smaller deployments.
The primary reason for difficulty in deploying elaborate upgrades is that many of the features provided in Windows NT 4.0 automated installation tools are not designed to work in upgrade situations. For example, the only sections of Unattend.txt that are processed during a Windows NT 4.0 upgrade are [Unattended], [UserData], and [GuiUnattended]. In addition, the CmdLines.txt file is not processed at all during an upgrade. Unfortunately, this missing functionality is required to apply service packs, install new version-specific features, and install new or upgraded business applications.
Many system administrators dive in and develop an automated Windows NT 4.0 upgrade process unaware that critical functions are missing. They build their upgrade according to the documentation, test it, and discover that it doesn't work as it should. They then spend days trying to determine what they did wrong. Finally, using one method or another, they find out that a Windows NT 4.0 upgrade differs from a new Windows NT 4.0 installation, and that the functionality they were counting on to automate their upgrade is not available. Then they begin the lengthy process of discovering and testing ways to replace the missing functionality. The end result is that many organizations expend a great deal of time, effort, and frustration trying to determine what is wrong with their custom automated upgrade. After they determine the cause, they spend additional time trying to replace missing functionality—with varying results and no guarantee of success.
To eliminate this cycle, system administrators need tools and methods for developing and managing complex automated upgrades. New tools will be included in Windows 98 and Windows NT 5.0; however, if you are currently planning a large-scale Windows NT 4.0 upgrade, you cannot wait for these tools to become available.
This paper describes the tools, techniques, and practices that worked well in a recent large-scale Windows NT 4.0 upgrade deployment. The paper presents the upgrade process as a series of logical steps, and describes deliverables, responsibilities, and procedures for each step along the way. Major steps include:
Planning the Bill of Materials —During this step, you identify the components that need to be upgraded, and divide them into three logical categories.
Organizing the Build Process —During this step, you develop a set of upgrade requirements, assemble a collection of tools, and organize the upgrade directory.
Building the Automated Upgrade —This includes developing each portion of the automated upgrade, and then compiling a cumulative build after each major milestone.
Testing the Final Build —During this step, you set up a lab, identify participants and responsibilities, and test and certify all components.
Deploying a Pilot Upgrade — This involves a phased rollout of a pilot upgrade.
Choosing a Deployment Methodology —During this step, you choose whether to deploy your upgrade system-wide or to phase it in gradually.
Finally, this paper provides an appendix that describes the utilities used in a typical automated upgrade.
Planning the Bill of Materials
After you decide that you need to upgrade an installed base of Windows NT 3.x systems to Windows NT 4.0, you must decide which components will be included in the automated upgrade process. You may find it helpful to divide all of the potential components into three categories, and assign a Bill of Materials manager to each category. The three Bill of Materials (BOM) categories are:
Core Infrastructure
Application Infrastructure
Applications
The Bill of Materials managers are responsible for justifying the business or technical case for each component included in their respective categories, and for making sure that necessary components are included in the build. This division of responsibility allows the designer of the build process (often called "the packager") to concentrate on developing the build process rather than identifying components for each BOM category.
Core Infrastructure
The first Bill of Materials should consist of Core Infrastructure products. A Core Infrastructure component is necessary for the basic operation and management of the system. Core Infrastructure does not include line of business applications, productivity applications, or components that provide middleware application services. Your Core Infrastructure BOM should include the Windows NT 4.0 upgrade itself and any Service Packs. It should also include any components that enhance or enable system management. This means that UPS software, tape backup software, Windows NT Resource Kit utilities, Simple Network Management Protocol (SNMP), and so forth, are all considered Core Infrastructure components. Give careful consideration to components that enhance manageability.
You may need to review the entire list of Windows NT Resource Kit utilities to decide which services and components you will need to install to enhance manageability after the upgrade is complete. As a minimum, you should install the Remote Command Shell Service (RCMDSVC), Kixtart, the Windows Script Host (WSH), and Active Directory Services Interface (ADSI).
Applications Infrastructure
The second Bill of Materials is the Applications Infrastructure. To be included in the Applications Infrastructure BOM, a component must not be part of Core Infrastructure and must not be an end-user application. The Application Infrastructure BOM should include components that are not necessary for the basic operation and management of the system, but that do provide application services to the line of business applications that will run on the system. For example, Applications Infrastructure components that run on Windows NT Server include Microsoft BackOffice® products, middleware products, ODBC, and the Windows NT 4.0 Option Pack (which includes Internet Information Server 4.0, Microsoft Transaction Server 2.0, and Microsoft Message Queue Server 1.0). Other server-side examples include Active Server Pages, Microsoft Index Server, FrontPage Server Extensions, and Microsoft Netshow.
Application Infrastructure components enable the latest in application architecture; therefore, you should give some thought to keeping these components as up-to-date as possible. In general, application developers appreciate the functionality provided by these components, and are willing to try new ways of architecting their applications when they learn that the necessary Application Infrastructure is already in place on the target systems.
Applications
The third BOM is simply called Applications. To determine what is part of the Applications Bill of Materials, consider whether a component is used directly by end users during execution of a business process. Typically, all line of business applications and personal productivity tools fall into this category.
The next section describes a methodology and tools you can use to organize the build process.
Organizing the Build Process
Having a well-organized build process allows you to reduce the complexity of your system upgrade and increase the maintainability of your automated build program. These are important considerations as the size and complexity of your upgrade grows. If designed properly, your process can scale indefinitely to accommodate future hardware and software demands. You achieve this scalability by dividing the process into manageable phases that can handle system reboots smoothly and can maintain state between these reboots.
Build Process Requirements
Your first step in developing an automated upgrade is to develop installation routines for each of the Core Infrastructure BOM components. Each installation routine must be installed in the security context of the Administrator account, and must meet the following requirements:
It must complete successfully without requiring user interaction —Note that some software vendors provide a command-line switch that allows their setup programs to run unattended. Always check for this first. In other cases, you will need to use Visual Test or some other scripting technique to interact with the installation program's user interface.
It must be capable of running multiple times without requiring user interaction, even if the component has been installed successfully already —You may ask, "Why would anyone run the installation program for a component more than once?" The reality is that problems with scripted installations do occur. It may be a timing problem. It may be the Scheduler running a job that displays a window at the wrong time and steals a keystroke. Whatever the cause, your recoverability strategy depends largely on your program's ability to reboot the target computer and restart a certain phase of the automated upgrade. In many cases, the problem will not recur on the second try. If your scripted setup routines cannot accommodate repetition, your only choice is to restore a backup and start the process over again.
Note that many installation routines behave differently if they have been run once already—for example, they may display error messages. This can be problematic if you have used Visual Test or some other method of scripting the UI—the script you developed for a fresh installation doesn't work a second time because the dialogs presented by the setup program differ from those that the script expects. The script fails, stopping the setup program mid-process, and possibly interfering with the rest of your component installations.
To work around this problem, you can use Visual Test or another scripting tool to record two scripts—one script handles the first installation of the component, and the other handles reinstallation. Your automated setup program conditionally calls the proper script based on checks for certain marker files that indicate whether the installation has already been attempted previously.
Once you have met the requirements for automating each of component installations in the Core Infrastructure Bill of Materials, you are ready to assemble your Core Infrastructure build. However, to meet these requirements, it is likely that you will need a collection of automation tools, as described next.
Your Automation Toolkit
You will find that having a good selection of tools is useful when automating interactive installations and configuration changes. The following is a list of tools and techniques that are particularly applicable.
Regini.exe
This is included with the Windows NT Resource Kit. This tool is useful for automating configuration changes that are usually accomplished using Control Panel or other graphical user interface (GUI) tools. Regini.exe allows you to complete many configuration changes in batch mode. The key to using Regini.exe is knowing which registry settings are changed by the GUI tools. (You can use SysDiff.exe to determine which registry settings have changed; see below.)
Once you know which registry keys are changed, you can use RegIni.exe to automate the changes for you.
SysDiff.exe
Sysdiff.exe is included with the Windows NT Resource Kit. You can use Sysdiff to determine whether a GUI configuration tool (such as Control Panel) has changed any registry settings. Use the command SYSDIFF /dump to discover which registry keys have changed.
You can also use Sysdiff to apply a snapshot image of an installed package. Use the command SYSDIFF /snap to take a snapshot of a reference system's file system and registry prior to installing the new software. Next, use the GUI setup program to install the software. Then, use the command SYSDIFF /diff to take a post-installation picture of the reference system's file system and registry. Sysdiff.exe will then prepare a difference file. Use the command SYSDIFF /apply to apply this difference file to other systems.
See the Help file included with Sysdiff.exe for details and complete command line syntax.
Note: Using Sysdiff to apply system changes doesn't work for all installations. See the Automating Windows NT Setup Deployment Guide, which can be downloaded from https://www.microsoft.com/ntworkstation/info/Deployment-guide.htm . for information on how and when to use Sysdiff.exe.
Keystroke Recorder Programs
Programs that record keystrokes and mouse clicks allow you to build installation scripts. After recording a setup, you can start a GUI setup program on a new system, and playback the keystrokes and mouse clicks—without interacting with the second and subsequent computers. Examples of these keystroke recorder programs are the Scenario Recorder feature included with Rational Software's Visual Test, and the SENDKEY functions included with Microsoft Visual Basic and Wilson WindowWare's WinBatch program.
SMS Packager
If you are fortunate enough to have an SMS 1.2 license, you can download and legally use the SMS Installer. This software allows you to build automated installations similar to the Sysdiff method. In addition, it includes a scripting language that you can use to install services, and so forth. You can also use the SMS Installer to all of your files and directories into a single, compressed, self-extracting executable.
Build Process Directory Structure
Several of your component installation routines may require reboots. For example, the Windows NT 4.0 upgrade (WinNT32.exe) generates several reboots, and any Service Pack installations also require a reboot. How does an automated installation accommodate all of these reboots while maintaining its place in the process? The answer is described next.
Chances are that the components in your automated installation program can be divided neatly into these three categories:
Component installations or configuration changes that need to be made prior to the Windows NT 4.0 upgrade
The Windows NT 4.0 Upgrade (WinNT32.exe) itself
Component installations or configuration changes that need to be made after the Windows NT 4.0 upgrade
You can take advantage of these categories when creating your automated installation program. To do this, subdivide the Core Infrastructure Bill of Materials into the three categories as outlined above. On the file system that will hold the build process, create three subdirectories called PRE, UPGRADE, and POST1. In addition, create two other directories called POST2 and POST3; these will be used for the Applications Infrastructure BOM and the Applications BOM.
Your directory tree should look like the following:
\ PRE UPGRADE POST1 POST2 POST3
The following paragraphs provide detailed descriptions of the contents of each directory.
PRE
The PRE directory should contain all of the installation source files and scripts to be used prior to the operating system upgrade (WinNT32.exe). In addition, you should write a Process.bat file that arranges all of the automated installation and configuration routines in the proper order, and launches them sequentially. Make sure that the last four steps in your PRE Process.bat file perform the following functions:
Use the following command to set the Administrator account password to a known value
NET USER administrator password
(where *password* is a valid password)
Enable AutoAdminLogon (with the proper password) for the Administrator account. You can use the Autolog.bat file, discussed in the Appendix of this white paper, to accomplish this step.
Set the default windows shell to
drive:\UPGRADE\PROCESS.BAT
where *drive* is the location of the upgrade directory. You can use the ChgShell.bat file, discussed in the Appendix, to accomplish this step.
- Reboot the system. You can use the Reboot.bat file, discussed in the Appendix, to accomplish this step.
UPGRADE
The UPGRADE directory should contain all of the installation source files to be used during the actual Windows NT 4.0 upgrade. In addition, you should write a Process.bat file that uses the following command to start the upgrade process:
WINNT32.EXE /u:path_to_answer.txt /s:path_to_i386_directory /e:command_to_run_at_setup_finish
where
path_to_answer.txt is the path to the Answer text file. Prepare this file according the instructions in the Automating Windows NT Setup Deployment Guide. Remember, the only sections of Unattend.txt that are processed during a Windows NT 4.0 upgrade are [Unattended], [UserData], and [GuiUnattended]. In addition, the Cmdlines.txt file is not processed at all during an upgrade. The Answer file can be used to supply the missing key information.
path_to_i386_directory is the path to directory where the Windows NT 4.0 upgrade files are stored.
command_to_run_at_setup_finish is a batch file you have written and stored in the UPGRADE directory. This batch file should perform the following functions:
Enable AutoAdminLogon (with the proper password) for the Administrator account. You can use the Autolog.bat file to accomplish this step.
Set the default windows shell to drive**:\POST1\PROCESS.BAT**. You can use the ChgShell.bat file to accomplish this step.
WinNT32.exe will reboot the computer for you. When it restarts, the automated installation process will continue on to the Process.bat file in the POST1 directory.
Note: If you don't use **WINNT32.EXE /e:**command_to_run_at_setup_finish to set AutoAdminLogon and to change the default shell, the system will reboot but will not continue on to your POST1 Process.bat file.
POST1
The POST1 directory should contain all of the installation source files and scripts used after the actual operating system upgrade to complete the Core Infrastructure portion of the installation process. In addition, you should write a Process.bat file that arranges all of the automated installation and configuration routines in the proper order, and launches them sequentially. The last steps in your POST1 Process.bat file should perform the following functions:
Enable AutoAdminLogon (with the proper password) for the Administrator account. You can use the Autolog.bat file, discussed in the Appendix of this white paper, to accomplish this step.
Set the default windows shell to
drive:\POST2\PROCESS.BAT
where *drive* is the location of the upgrade directory. You can use the ChgShell.bat file, discussed in the Appendix, to accomplish this step.
- Reboot the system. You can use the Reboot.bat file, discussed in the Appendix, to accomplish this step.
POST2
The POST2 directory should contain all of the installation source files and scripts used during the Application Infrastructure phase of the process. In addition, you should write a Process.bat file that arranges all of the automated installation and configuration routines for components in the Applications Infrastructure BOM in the proper order, and launches them sequentially. If there are components in the Applications Infrastructure BOM that require reboots, the Applications Infrastructure installation phase can be spread over multiple directories in a manner similar to the way that the Core Infrastructure was spread across PRE, UPGRADE, and POST1.
If you do need to divide this portion of the automated installation because of a reboot, be sure to prepare for the next phase (POSTx ) before running the installation program for the component that will be performing the reboot. If you forget to prepare for the next phase, you will wind up running the same phase over and over again.
POST3
The POST3 directory should contain all of the installation source files and scripts used during the Application phase of the process. In addition, you should write a Process.bat file that arranges all of the automated installation and configuration routines for components in the Applications BOM in the proper order, and launches them sequentially. If there are components in the Applications BOM that require reboots, the Applications installation phase can be spread over multiple directories, each containing a Process.bat file that launches automated installation routines.
You will need to prepare the system for production use prior to performing the last reboot. This includes disabling AutoAdminLogon and changing the shell back to Explorer.exe. You can use the Autolog.bat and ChgShell.bat utilities (described in the Appendix) to do this as well.
UTILS
You may want to add a UTILS directory to hold tools such as Regini.exe, Sysdiff.exe, and Visual Test's MTRun.exe. This directory is optional.
Building the Automated Upgrade
This section describes the development and build steps for the three phases of the automated upgrade (Core Infrastructure, Application Infrastructure, and Application). It is helpful to build each major phase of the project separately—and test it on successively larger target systems—before moving on to the next phase in the process. Testing should be cumulative; that is, as each phase of the process is completed, you should add it to the previous tested phase to make sure that the entire upgrade program runs smoothly.
This approach is described more fully in the following paragraphs.
Core Infrastructure Build
Once you have your Core Infrastructure build working reliably, you should distribute the build process for testing on a larger sample of the target systems. Document any problems and incorporate fixes as you complete them. Then retest the build.
At some point, you will decide that your Core Infrastructure build is complete. At that point, you should freeze the build and move on to the process of automating the installation routines of the components in the Applications Infrastructure BOM.
Core and Applications Infrastructure Build
After you complete the automated installation of the Core Infrastructure, you should automate all of the installation routines for the Applications Infrastructure components. Make sure that they can:
Successfully complete without requiring any user interaction.
Run multiple times without requiring user interaction, even if a component has previously been successfully installed.
Be successfully installed in the security context of the Administrator account.
When you have completed these automated installation routines, add them to your Core Infrastructure build. Once integrated, begin testing the combined build on a larger sample of the target systems. Document any problems and integrate fixes as you complete them. Then retest the build.
Eventually, you will decide your combined Core and Applications Infrastructure build is complete. At that point, you should freeze the combined build and move on to the process of automating the installation routines of the components in the Applications BOM.
Core, Applications Infrastructure, and Applications Build
After you complete the automated installation of the Core and Application Infrastructure components, you should automate all of the installation routines for the Applications components. Make sure that they can:
Successfully complete without requiring any user interaction.
Run multiple times without requiring user interaction, even if a component has previously been successfully installed.
Be successfully installed in the security context of the Administrator account.
When you have completed these automated installation routines, add them to your Core + Applications Infrastructure build. Once integrated, begin testing the combined build on a larger sample of the target systems. Document any problems and integrate fixes as you complete them. Then retest the build.
Eventually, you will decide your combined build is complete. At that point, you should freeze the combined build and move on to final build testing.
Testing the Final Build
Formal testing of the final build is critical to the success of your deployment. During testing, you can verify the build process, and you can ensure that all owners of affected components have the opportunity to test and certify that their components function properly after the upgrade process is complete. This is their last chance to find problems and fix them. After this point, accountability and responsibility for discovering problems is assumed by the component owners who participated in the test.
The following paragraphs describe the requirements and responsibilities for a proper test and certification process.
The Lab
To conduct proper certification testing, you should set up a certification lab and include a representative sample of the target systems. Take care to make sure that the systems and conditions in the lab mirror the systems that will actually be upgraded.
Test Plans
Each component owner should have a written test plan that he or she will follow when certifying that a component performs as expected after the upgrade is complete.
Testing Coordinator
A Testing Coordinator should be appointed to schedule the component owner's use of the testing lab. The Testing Coordinator should also verify that component owners have written test plans, and should audit the test process by sitting with the owners and checking off steps in the test plan as the owner completes them. If everything is acceptable, the component owner and the Testing Coordinator both sign the test plan.
Testing Complete
Testing is complete after all component owners have completed their tests, and the Testing Coordinator has certified that everyone has executed their test plans properly. If problems have been discovered, the component owners and developers need to decide whether to fix the problems or remove the problem components from the build.
The next stage of testing—the pilot—moves the automated upgrade program out of the lab environment and allows you to test the upgrade on live systems with actual system users.
Deploying a Pilot Upgrade
A pilot program is a test rollout performed on a subset of the target systems, and is the last major step before full-scale deployment. Pilot programs allow further testing on live systems rather than a lab, and provide the opportunity for user feedback. At the close of a pilot program, your corporation can decide whether to deploy or not to deploy the automated upgrade program.
This section describes the steps involved in a pilot program, responsibility for the different processes, and requirements that must be met prior to deployment. When planning your pilot, you should plan for multiple phases, as described next.
Phase 1
The first phase in a pilot program should be a limited deployment that allows you to visit and view the upgrade process on each of the targeted systems. In phase 1, you should test and verify the following:
Package distribution process
Package installation process
Problem resolution process
Disaster recovery process
Status reporting process
Note that the package distribution, problem resolution, recovery, and reporting are not discussed in this document; however, you do need to devise workable processes for each of these areas.
Document any problems during the limited rollout, and integrate fixes prior to moving on to the next phase.
Phase 2
Phase 2 should be another small pilot that tests the fixes to problems found in Phase 1. After you have deployed this pilot upgrade, pay special attention to how the Core Infrastructure components, Application Infrastructure components, and Applications function over time. These components need to demonstrate long-term stability in a production environment .
Document any problems during this limited rollout, and integrate fixes prior to moving on to the next phase.
Phase 3
If others will be involved in deployment problem solving process, Phase 3 should be used as a training deployment so that the production deployment team becomes familiar with the various processes and techniques that will be used to fix problems that may arise during actual deployment. After Phase 3 is completed successfully, you can proceed with the actual deployment.
Choosing A Deployment Methodology
As a last step in designing an automated system upgrade, you must choose a deployment methodology. Generally, you can choose between a system-wide deployment and a phased managed approach. In a system-wide deployment, you upgrade all systems at once. In a phased managed approach, you upgrade a group of systems at a predetermined rate, reassessing the impact and the success at each step along the way and making adjustments and corrections to the rate of deployment as necessary.
In deciding between the two approaches, you should consider the risk involved, the business impact of a worst case scenario, recovery procedures, and the number of people that can be called into action to help resolve problems. Generally speaking, an operating system upgrade is considered a high-risk activity and a phased managed style of deployment is preferred.
Determining the Rate of Deployment
Once you have decided to use a phased managed style of deployment, you must decide how many systems you will upgrade per day. In most cases, you should use a slow start technique. Start with a small number, and increase that number daily until you reach a number that seems acceptable based on the number of problems encountered, resources available to fix those problems, and the targeted completion date. If you find that your resources are kept fully occupied by the number of issues that arise, then you know that you should keep the deployment rate at its current level.
Conclusion
While designing, developing, and deploying an automated upgrade to Windows NT 4.0 is a complex endeavor, it will allow you to upgrade your users from a central location with minimal desktop intervention. In the long-run, this approach will most likely prove cost-effective.
This paper describes the tools, techniques, and practices that worked well in a recent large-scale Windows NT 4.0 upgrade deployment; however, system differences and corporate development practices and requirements will impact your design decisions. For this reason, you should use the recommendations and suggestions included in this document as a reference framework only.
For More Information
For more information on deploying Windows NT 4.0, see the Automating Windows NT Setup Deployment Guide , which can be downloaded from https://www.microsoft.com/ntworkstation/info/Deployment-guide.htm.
For the latest information on Windows NT Server, check out our World Wide Web site at https://www.microsoft.com/ntserver, and the Windows NT Server Forum on the Microsoft Network (GO WORD: MSNTS).
Appendix A: Utilities
This appendix describes the tools used in the automated upgrade process.
Autolog.bat
Use Autolog.bat to turn AutoAdminLogon on and off. Autolog.bat requires Regini.exe.
Usage
To turn on automatic logon of the administrator:
autolog userid password
where:
userid is the user ID for the administrator account.
password is the administrator account password.
To turn off automatic logon of the administrator:
Autolog /none
Batch File Contents
REM CHECK SYNTAX
if not "%1"=="" goto SYNTAXOK
echo.
echo USAGE: %0 ?userid? ?password?
echo or
echo %0 /none
echo.
echo If "/none" is specified, the AUTOLOGON feature will
echo be turned off.
pause
GOTO END
:SYNTAXOK
if "%1%"=="/NONE" goto TURNITOFF
if "%1%"=="/none" goto TURNITOFF
:PROCEED
REM SETTING AUTOLOGON INFO FOR USER ACCOUNT IN PRODUCTION REGISTRY
REM TURN AUTOLOGON ON
echo \registry\machine\software\microsoft\windows nt
\currentversion\winlogon>c:\autolog.reg
echo autoadminlogon = reg_sz "1">>c:\autolog.reg
%0\..\regini c:\autolog.reg
REM SET DEFAULT USER ACCOUNT
echo \registry\machine\software\microsoft\windows nt
\currentversion\winlogon>c:\autolog.reg
echo defaultusername = reg_sz "%1">>c:\autolog.reg
%0\..\regini c:\autolog.reg
echo \registry\machine\software\microsoft\windows nt
\currentversion\winlogon>c:\autolog.reg
echo defaultpassword = reg_sz "%2">>c:\autolog.reg
%0\..\regini c:\autolog.reg
goto END
:TURNITOFF
REM TURN AUTOLOGON FEATURE OFF
echo \registry\machine\software\microsoft\windows nt
\currentversion\winlogon>c:\autolog.reg
echo autoadminlogon = reg_sz "0">>c:\autolog.reg
%0\..\regini c:\autolog.reg
echo \registry\machine\software\microsoft\windows nt
\currentversion\winlogon>c:\autolog.reg
echo defaultusername = reg_sz "">>c:\autolog.reg
%0\..\regini c:\autolog.reg
echo \registry\machine\software\microsoft\windows nt
\currentversion\winlogon>c:\autolog.reg
echo defaultpassword = reg_sz "">>c:\autolog.reg
%0\..\regini c:\autolog.reg
:END
echo.
Chgshell.bat
Use Chgshell.bat to set the Windows shell. It requires Regini.exe. Note that Progman.exe is the default.
Usage
To change the startup shell:
chgshell shell_program
where shell_program is the name of a valid shell program. (Be sure that this program exists before you run this command.)
Batch File Contents
REM CHECK SYNTAX
if not "%1"=="" goto SYNTAXOK
echo.
echo USAGE: %0 ?shell program?
echo.
echo USE THIS COMMAND PROCEEDURE TO CHANGE THE START UP SHELL
echo PROGMAN.EXE IS THE DEFAULT.
echo.
echo *** IMPORTANT ***
echo MAKE SURE THE SHELL PROGRAM EXISTS BEFORE RUNNING THIS COMMAND.
echo.
pause
GOTO END
:SYNTAXOK
goto PROCEED
REM CHECK FOR EXISTANCE OF THE SPECIFIED SHELL COMMAND
if exist %1 goto PROCEED
echo.
echo THE SPECIFIED SHELL COMMAND DOES NOT EXIST. PLEASE SPECIFY
echo A FULLY QUALIFIED PATH.
goto END
:PROCEED
REM UPDATE THE REGISTRY TO REFLECT THE NEW SHELL
echo \registry\machine\software\microsoft\windows nt\
currentversion\winlogon>c:\chgshell.reg
echo shell = reg_sz "%1 %2 %3 %4 %5 %6 %7 %8 %9">>c:\chgshell.reg
%0\..\regini.exe c:\chgshell.reg
:END
del c:\chgshell.reg
echo.
Reboot.bat
Use Reboot.bat to shut down and restart Windows NT. It requires Shutdown.exe. Note that Reboot.bat and Shutdown.exe should be in the same subdirectory.
Batch File Contents
%0\..\shutdown.exe /L /R /T:0 /Y /C
Ss.bat
Ss.bat is used to turn a screen saver off and on. In most cases you will want to prevent the target system's screen saver from starting and interfering with your automated upgrade process.
Usage
To turn the screen saver off:
ss.bat off
To turn the screen saver on:
ss.bat on
Batch File Contents
@echo off
if "%1"=="" goto ERROR
if "%1"=="on" goto ON
if "%1"=="ON" goto ON
if "%1"=="off" goto OFF
if "%1"=="OFF" goto OFF
goto ERROR
:OFF
REM PRESUMES KILL.EXE IS IN SAME SUBDIR AS SS.BAT
%0\..\kill *.scr
if exist %systemroot%\*.scr copy %systemroot%
\*.scr %systemroot%\*.sc_ >nul
if exist %systemroot%\*.scr del %systemroot%\*.scr >nul
if exist %systemroot%\system32\*.scr copy %systemroot%\system32
\*.scr %systemroot%\system32\*.sc_ >nul
if exist %systemroot%\system32\*.scr del %systemroot%\system32
\*.scr >nul
goto END
:ON
if exist %systemroot%\*.sc_ copy %systemroot%
\*.sc_ %systemroot%\*.scr >nul
if exist %systemroot%\system32\*.sc_ copy %systemroot%\system32
\*.sc_ %systemroot%\system32\*.scr >nul
goto END
:ERROR
echo.
echo USAGE: ss.bat off Turns Screen Saver Off
echo ss.bat on Turns Screen Saver On
:END
Postinf.bat
You can use Postinf.bat to apply registry changes that you specify in .inf file format.
Usage
postinf.bat infile.inf
where infile.inf is the name of a valid .inf program that contains the registry changes.
Batch File Contents
@ECHO Off start /wait rundll32 setupapi,InstallHinfSection DefaultInstall 128 %1
Scmwait.bat
Use Scmwait.bat to make your Process.bat files wait until the Service Control Manager has finished starting all of the services defined in the Service database. Scmwait.bat causes a batch file to pause until all services have started and the Service Control Manager has freed up the Services database.
Batch File Contents
@ECHO OFF start /b /wait net start Server cls
The information contained in this document represents the current view of Microsoft Corporation on the issues discussed as of the date of publication. Because Microsoft must respond to changing market conditions, it should not be interpreted to be a commitment on the part of Microsoft, and Microsoft cannot guarantee the accuracy of any information presented after the date of publication.
This White Paper is for informational purposes only. MICROSOFT MAKES NO WARRANTIES, EXPRESS OR IMPLIED, IN THIS DOCUMENT.
Other product or company names mentioned herein may be the trademarks of their respective owners.
Microsoft Corporation • One Microsoft Way • Redmond, WA 98052-6399 • USA
0198