Home > Articles > Operating Systems, Server > Microsoft Servers

Changing Windows Administrator Passwords Across The Enterprise: Automate The Gosh-Durned Process

📄 Contents

  1. Changing Administrator Passwords Across the Enterprise: Automate the Bejesus Out Of the Process
  2. Going Further
  • Print
  • + Share This
When the word comes down that every Windows Admin password in the company has to be changed, life can get ugly for the IT department. Lynn Greiner shows you how to automate the process, so that you don't have to walk from one computer, to another, to another.
Like this article? We recommend

When the word comes down to change the local admin password on every machine on the network, life can get ugly for an administrator.

Usually, the edict arrives after someone who knew the existing password leaves the company on, shall we say, unfriendly terms. Eliminating all possibility of access becomes an emergency, as management worries, rightly or not, about possible electronic vandalism. Mind you, changing the local administrator password is a good thing to do from time to time anyhow, in the interest of security.

If there are only a few machines, it's easy enough — although tedious — to go from system to system to enter a new password. But for a network of any size, the task quickly becomes unmanageable.

That's when the frantic hunt for tools that will help begins.

Fear not. There are ways to make the job easier, even painless, with a little bit of work upfront. You don't have to be a programming guru, or spend a lot of money. Plenty of others, far more skilled than we, have already found many solutions to this annoying and time-consuming problem. Here's a look at a few of them.

If you're lucky enough to work in a company that has installed Microsoft System Management Server or some other enterprise management product, you already have everything you need. These tools can easily touch every machine on the network; check the documentation for specific instructions.

For the rest of us, it's going to take a bit of scripting.

The Easy Script

For this exercise, I'm assuming that the computers are part of a domain. You need domain administrator privileges, and access to the Microsoft management Console Active Directory Users and Computers console.

Let's get started.

First, write a little batch file containing the single line:

NET USER Administrator %1

This command changes the Administrator password to whatever value you enter as the parameter when the batch file is run. Because it needs administrator privileges, it must be run as a Startup script, not as a login script, which only has the privileges of the user who is logging in.

Be sure to save the file on the server, where it is accessible to systems logging onto the domain. If you are supporting legacy clients running Windows NT 4.0 or Windows 9x, save it in the Netlogon share on your server.

Now, to run this file against every PC on your network, create a Group Policy Object (GPO):

  • In the Users and Computers console, right click the OU on which you want to operate.
  • Select Properties from the context menu.
  • On the Group Policies tab, select New to create a new policy, give it a name, then click Edit.
  • Under the new policy, click the plus sign next to Computer Configuration.
  • Click the plus sign next to Computer Settings.
  • Click Scripts (Startup/Shutdown), then double-click Startup in the right pane.
  • Click Add.
  • Browse to the batch file you just created, and add it to the policy.
  • In the Script Parameters field, enter the password you want assigned to all machines.
  • OK your way out.

It is also critical that you test any new GPO before trying to deploy it to all systems; it's entirely too easy to completely foul up your network with a problematic policy. Create a test OU and add a machine or two that you're not worried about wounding. Apply the policy to this OU first to make sure it is working properly. Be sure to place the test OU under an existing one, and allow any currently applied policies to be inherited. If you don't, conflicts will not be detected and you may have a nasty surprise when you put your new policy into production.

  • + Share This
  • 🔖 Save To Your Account