Windows 2000 Computer Startup Scripts
By Dick Lewis
Simplify administration tasks with startup scripts
This article is from the January 2003 issue of Windows Scripting Solutions.
Windows 2000's Group Policy Object (GPO) computer startup scripts let you perform a world of tasks on client computers that logon scripts and centralized server scripts can't undertake. Logon scripts run under the authority of the logged-on user account, which limits the types of tasks that these scripts can perform. Scripts launched from a central administrative server or workstation can run in a service-account context and thus have more powerful rights, but they must run against an entire domain or a static list of computer names. In addition, server-launched code can use only utilities that you can launch remotely, so several built-in commands such as net.exe aren't available with server-launched code. Also, if you run a script to roll out a policy change to a list of computer names, machines that are powered off often don't receive the change; you must constantly log failures so that you can rerun the script against these PCs.
Under Windows 2000, you can add PCs to a computer group or an organizational unit (OU) and use an Active Directory (AD) GPO to run the script on the group or OU. If you add nodes to the group or OU, the new nodes are automatically subject to the GPO. And GPO-delivered scripts run each time a system processes the GPO, so each time a user starts a computer, the applicable startup scripts run. This functionality is especially beneficial in environments that have laptops that might be connected only sporadically to the network. Computers won't miss any remotely scripted changes because each time they boot, they run any startup scripts created for the OUs or filtered groups of which the computers are members.
I've compiled a few FAQs to show how you can use GPO computer startup scripts. The discussion assumes that you're familiar with using the Microsoft Management Console (MMC) Active Directory Users and Computers snap-in to create GPOs and add computer startup scripts. (For a step-by-step explanation of how to add a script to a GPO, see the Web sidebar "Adding Startup Scripts to GPOs" at https://www.winscriptingsolutions.com, InstantDoc ID 27330.) The startup script tips and code snippets that follow will be most useful in network environments in which users typically shut down and restart their computers daily.
Can I use a startup script to change local administrator account passwords?
You can use startup scripts to change Administrator account passwords on machines that are members of a computer group that uses a common password. The following command-shell code changes a computer's Administrator password when a user reboots.
Net user Administrator %1
"Adding Startup Scripts to GPOs" gives a detailed account of adding this script to a GPO. You first need to create a computer group that contains all the OU member computers to which you want to push out the new password. Then, you add the script to that GPO. You also need to set permissions so that only the desired computer group has Read and Apply Group Policy permissions for the new GPO. The next time a computer in the designated group starts up, the script will run and change the Administrator password on that node. Whenever you need to push out another new password, modify the password argument that's passed to your one-line script. If you assign your permissions correctly and remove the Authenticated Users group's Read and Apply Group Policy permissions as "Adding Startup Scripts to GPOs" describes, GPO Administrators will be the only users who can access the password. Record and secure your old passwords for a few change cycles in case you need to access an old computer that has been off the network.
Can I change the administrator password to a unique password?
Yes. You'll need to use a startup script that accesses a database or file that maintains this password data. Here is an example of a comma-separated value (CSV) file that contains machine names and passwords, with one computer name and password set on each line.
Pc111777,bambam1 Pc111778,barney12
Set permissions so that the designated computer group can read this file but Authenticated Users can't.
The following startup script locates and applies the new password to a particular PC. If the file doesn't list the PC for which you want to change the password, the script applies a default password. If desired, you can write the results of the password change activity to a log file.
Set PW=defaultPW
for /f "tokens=1,2 delims=," %%i
in ('find /I "%computername%"
^< Pwlist.txt') do (Set PW=%%j)
Net User Administrator %PW%
I need to modify the registry on a group of computers in an OU. I want the change to occur only once on each machine, and I need to track any machines that haven't been modified. Can I use a startup script to accomplish this task?
You can use the RunOnce section of the registry to accomplish tasks one time, but that method won't give you the tracking you require. Instead, create a computer group and populate this group with all the computers that need the registry modification. Give the computer group Read, Write, Apply Group Policy, and Add/Remove self as a member permissions, and clear the Allow check box for the Authenticated Users group's Read and Apply Group Policy permissions.
Create the registry modification script. At the end of the script, add the following line to delete the computer from the computer group
cusrmgr -dlg Group_Name -m DC_Name -u Domain_Name\%COMPUTERNAME%$
(Cusrmgr is a Microsoft Windows 2000 Server Resource Kit utility. Place a copy of this utility in the startup script location.) When the computer reboots, it will run the script that modifies the registry and removes it from the computer group. To see which computers haven't had the registry change applied, open the group. The computers remaining in the group haven't been modified. You could also include code that adds the computer to a second computer group after removing it from the first group so that one group contains all the computers that have received the registry changes and another shows the computers that haven't received the change.
We have a test lab with 10 computers that five developers use. The developers need Administrators rights on any machine they log on to, and the computers are constantly being reloaded. How can we do this?
You could add the five developers' user accounts to the Administrators group on these computers, but that group membership would be lost each time the computers were reloaded. A better method is to put the computers in an OU and use a startup script that adds to the Administrators group on each reboot the individual user IDs or a group that contains the developers. Use the following code to add individual users to the Administrators group:
Net Localgroup Administrators "Domain_Name\Developer1" /Add Net Localgroup Administrators "Domain_Name\Developer2" /Add Net Localgroup Administrators "Domain_Name\Developer3" /Add Net Localgroup Administrators "Domain_Name\Developer4" /Add Net Localgroup Administrators "Domain_Name\Developer5" /Add And use Net Localgroup Administrators "Domain_Name\Developers_Group" /Add
to add a group of developers to the Administrators group. You can also use GPO Restricted Groups to accomplish this task.
About 50 users have been added to the Administrators group on some conference room computers in my organization. How can I remove all the current users from the Administrators group and prevent the addition of unauthorized users in the future?
Users are often given local Administrators group permissions on conference room computers so that they can install and run demonstration software. These users can then grant the same permissions to other users, resulting in computers with many users with administrative permissions. These computers can become hopelessly bogged down by multiple users adding demonstration software. You can use the following computer startup script to clear the Administrators group and restore a few authorized administrators.
for /f "tokens=*" %%i in ('Net
Localgroup Administrators
^| find /I /V "Alias"
^| find /I /V "Members"
^| find /I /V "------"
^| find /I /V "successfully"
^| find /V "Administrator"')
Do Net Localgroup
Administrators "%%i" /Delete
Net Localgroup Administrators
"SpecialAdmins" /Add
Because the script runs at each startup, it keeps the Administrators group free of unauthorized accounts and lets only the designated group of users be administrators on these machines.
I can't get my computer startup scripts to run. What might be causing the problem? Also, my scripts run in hidden mode, so how do I debug them?
A computer startup script can fail if the computer can't access certain user environment variables. Because computer startup scripts run before logon, user variables such as username, temp, and logonserver are unavailable. Make sure the variables you're using are local to the script or are system variables. Also, if you have several GPOs or scripts running on an OU, be sure that the scripts don't conflict. For example, a script that removes all the users and groups from the Power Users group could undo a script that adds a HelpDeskGroup to the same group.
You can set a processing order for a GPO's scripts. You can also use a launching script to call your scripts in an order you determine. The following lines of code, which you can add to a batch file assigned to the GPO, call and run four other scripts in the specified order.
Start /Wait script1.bat Start /Wait script2.bat Start /Wait script3.bat Start /Wait script4.bat
(You'll need to place all the scripts in the same scripts server location.)
If your scripts are in separate GPOs, you might need to do some testing to determine the effective run order and if necessary, reorder their execution. If you have several GPO scripts that run at different OU levels in your domain, remember that processing begins at the bottom of the tree and works upward.
To run a script in visible mode so that you can debug it, comment out the @ECHO OFF command at the beginning of the script, and set the GPO's properties to run script in visible mode. Put a pause at the end of the script so that you can view the results while the window stays open, or use the sleep command to keep the script open for 5 to 10 extra seconds so that you can see any error messages. After the script is working properly, be sure to remove any pause or sleep commands.
I created a GPO with a computer startup script, and the GPO didn't take effect immediately. However, the GPO worked fine the next day. What's going on?
You probably have some replication delay problems. When testing scripts, run them in visible mode to be sure they're actually running. Nothing is more frustrating than trying to figure out why your script isn't working when the script isn't even running because replication hasn't occurred.
What's the best way to test my computer startup scripts on a small group of test computers without causing problems for my entire domain or production OU?
The best way to determine whether new GPOs and scripts are working correctly is to add the test computers to a sub-OU that you create within your production OU. Don't block policy inheritance to the sub-OU, or you won't get an accurate picture of how the new policies and scripts interact with your current policies and scripts. After your policies and scripts are working correctly on one test computer, add other computers to the test until you determine that your results are correct. Carefully document what each GPO and associated scripts accomplish.
When you're done testing, move the test computers to another OU, but leave the test OU in place with the GPO and scripts available. This arrangement will give you a "last known good" configuration for the GPO and scripts for a specific task. If you need to accomplish a similar task in the future, you have a relevant working environment to start from.
Keep On Scripting
I hope I've presented a few ideas to get your creative juices flowing. Computer startup scripts are definitely a powerful tool for managing local computer group memberships and offer new power for Windows XP and Windows 2000 systems administrators.
© 2003 Windows Scripting Solutions. All rights reserved.
Try a sample issue of Windows Scripting Solutions, a monthly print newsletter, at: https://www.winscriptingsolutions.com/.
Keep up to date on the latest Windows and .NET issues with a free email newsletter. Click here to subscribe: https://email.winnetmag.com/winnetmag/winnetmag_prefctr.asp.
We at Microsoft Corporation hope that the information in this work is valuable to you. Your use of the information contained in this work, however, is at your sole risk. All information in this work is provided "as -is", without any warranty, whether express or implied, of its accuracy, completeness, fitness for a particular purpose, title or non-infringement, and none of the third-party products or information mentioned in the work are authored, recommended, supported or guaranteed by Microsoft Corporation. Microsoft Corporation shall not be liable for any damages you may sustain by using this information, whether direct, indirect, special, incidental or consequential, even if it has been advised of the possibility of such damages. All prices for products mentioned in this document are subject to change without notice.
.gif "Link")