# Use Group Policy to Change the Password for the Local Administrator Account on Multiple Machines

With the stricter security requirements that many of my customers have been facing lately, the question about how to change the local administrator password on 10’s, 100’s, or even 1000’s of windows machines has come up several times recently. With the introduction of Group Policy Preferences, this has become a very easy task. Here are some instructions on how to accomplish this with a minimum amount of work on the part of the administrator.

NOTES: These procedures involve making changes to group policies. Thorough testing should always be performed in a lab environment prior to making any changes to group policy in a production environment. Also, GPP’s are not supported in Windows 2000, so these procedures are only useful on XP SP2 and later operating systems.

1. Ensure that the managed clients have the update installed to support group policy preferences. These updates are on Windows Update and can also be found here: http://support.microsoft.com/?kbid=943729

2. On either a Windows Server 2008 server, or on a Vista SP1 client, enable the RSAT (Remote Server Administration) tools. On Vista SP1, they must be installed first, whereas on Server 2008 they only need to be enabled. After installing, enable them by using the Turn On Features option in the Programs and Features applet in the control panel. The RSAT tools can be downloaded here: http://support.microsoft.com/?kbid=941314  Note that just installing the update will not add anything to the Administrative Tools menu. You must also turn the feature on:

Tip: In most open windows in Vista and later operating systems, there is a search box in the upper right hand corner. If you’re not sure how or where to configure a setting, type in a keyword in the search box. In Control Panel, for example, type in something like “screensaver” (without the quotes). You will instantly see relevant settings displayed to help you modify your screensaver. You can save yourself tons of time when looking for features and settings by using this handy search capability.

3. Using the GPMC tool on either Windows Server 2008 or on the Vista SP1 machine with RSAT, note the new Preferences section when editing a group policy:

4. Under Computer Configuration, expand Preferences, Control Panel Settings, and then right-click on Local Users and Groups. Choose New, Local User:

5. Leave the Action drop-down set to Update. From the drop down box for User Name, select Administrator (built-in). Type in a password to reset the password for this account. NOTE: You MUST type in a new password for this step to work. If you do not, the changes will not be made. Optional: UNCHECK the box for Password Never Expires. The end result of these settings will be to have an expiring local password for the built-in admin account, and for the password to be changed to the new value.

You can also use this section to perform other changes, such as renaming the Administrator account or modifying other local accounts.

6. Note the additional settings available via the Common tab:

There is also a good whitepaper on this topic located here. This whitepaper covers GPP’s in more detail, along with their many capabilities.

NOTE: When using Group Policy Preferences, keep in mind that the stored password is obfuscated. From a security standpoint, it would be best to use this procedure to change the password using a separate group policy. Then, once finished, delete the group policy so that the stored password (although obfuscated) is also deleted.

Read the complete @> Jim Ratsch’s Technical Ramblings : How to change the password for the local administrator account on multiple machines (the easy way without scripting)

# Proper FSMO role placement basically boils down to a few simple rules, tips, and exceptions

Since FSMO roles are crucial for the proper functioning of an AD-based network, it’s a good idea to get them right from the planning stage of your deployment. By default, when you install the first DC of your forest root domain, this first DC holds all five FSMO roles. When you install the first DC of any other domain in your forest, that DC will hold all three domain FSMO roles (PDC Emulator, RID Master, and Infrastructure Master). Depending on the complexity of your network, however, this default roles assignment may not be appropriate,

so you need to transfer some of your roles to a different machine to achieve optimal FSMO-role placement on your network.

Rule 1: The PDC Emulator and RID Master roles should be on the same machine because the PDC Emulator is a large consumer of RIDs.

Tip: Since the PDC Emulator is the role that does the most work by far of any FSMO role, if the machine holding the PDC Emulator role is heavily utilized then move this role and the RID Master role to a different DC, preferable not a global catalog server (GC) since those are often heavily used also.

Rule 2: The Infrastructure Master should not be placed on a GC.

Tip: Make sure the Infrastructure Master has a GC in the same site as a direct replication partner.
Exception 1: It’s OK to put the Infrastructure Master on a GC if your forest has only one domain.
Exception 2: It’s OK to put the Infrastructure Master on a GC if every DC in your forest has the GC.

Rule 3: For simpler management, the Schema Master and Domain Naming Master can be on the same machine, which should also be a GC.
Exception: If you’ve raised your forest functional level to Windows Server 2003, the Domain Naming Master doesn’t need to be on a GC, but it should at least be a direct replication partner with a GC in the same site.

Rule 4: Proactively check from time to time to confirm that all FSMO roles are available or write a script to do this automatically.
Tip: If any FSMO role holders at a remote site are unavailable, check first to see if your WAN link is down.

# Folder Shares Disappearing

Resolution: This happens only when IPC$share is missing in your server. Clients make remote connections with the help of IPC$ and Namedpipes slots. This is a default administrative share. This should appear in each machine on the network or your network is not going to function properly or clinets can’t connect to each other.

These shares are lost when the value of “AutoShareServer” is 0 in registry key: HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\LanManServer\Parameters

It should be 1.

When it happens simply restart “Server service” from services.msc snap-in. It is just to make sure that there is nothing wrong with Administrative Shares (IPC\$).

Moreover, when happens again, go to a client machine and try to access server using UNC path (\\IP_Address_of_SBS).

Also you may also want to look at your DNS configuration, if you are mapping using name of the server you can try mapping few user with IP address of the server. If this keeps them connected it might be DNS issue. There are variety of other things you can check, I would start with Network cable, next go to Switch or the hub, check the network cards drivers and firmwares on the server

# In-Place Upgrade from Windows Server 2003 Domain Controller to Windows Server 2008

1. On you Windows Server 2003 DC, insert the Windows Server 2008 DVD, and then open command prompt and run the following commands, make sure first to browse to the adprep directory inside the Windows 2008 DVD , in my case case, the F drive is the DVD Drive letter, so to browse to the adprep directory I would write the following inside cmd:cd f:\sources\adprerp

1. If the Install Windows page did not auto run before the previous step, double click on your DVD drive where you have inserted the Windows Server 2008 DVD, then Click on Install now

2. A please wait screen will be followed, then a page to decide what to do, either to go online and get the latest updates for installation or to skip going online by clicking on the Do not get the latest updates for installation option
3.  I will perform the updates later, so for the purpose of this article, I will click on Do not get the latest updates for installation
• Enter the product key, click Next
• Accept the license terms and click on Next
• What we need to do is to upgrade our server, so click on the Upgrade option

• The compatibility report will be displayed telling you what hardware might not function once upgrade is completed , also to check with software vendors to check if their software are compatible with Windows Server 2008. click Next
• Upgrade is now in process
• The Server will be restarted automatically several times, the Upgrade process will continue with the remaining operations:
• Expanding Files

After multiple restarts, the Upgrade process will be completed and you will be able to start using your Windows Server 2008.

• SummaryIn this article, I showed you how to do an in-place upgrade for Windows Server 2003 Domain Controller to Windows Server 2008. The steps are easy and straightforward, just make sure while reading the compatibility report, if any of the hardware/software installed on your Server are compatible with Windows Server 2008.

# Active Directory – Resetting secure channel.

Error:  Target principle name incorrect.

Resolution : Reset Machine Account Passwords :

Example: local computer (which happens to be a domain controller) is Server1, Peer Windows domain controller name is Server2.

If you run Netdom on Server1 with the following parameters, the password is changed locally and is simultaneously written on Server2, and replication propagates the change to other domain controllers:

Where server_name is the name of the server that is the PDC Emulator operations master role holder.

Note: This method only works for DC. If it’s member server, we have to disjoin and rejoin domain.

• Install the Windows Support Tools from the Support\Tools folder on the Windows CD-ROM on the domain controller whose password you want to reset.

• If you are attempting to reset the password for a Windows domain controller, it is necessary to stop the Kerberos Key Distribution Center service, Also The KDC must be disabled on the Server that has the problem.

• Stop the Key Distribution Center (KDC) service on Server1. To do so, open a Command Prompt, type net stop KDC, and press Enter.

• Load Kerbtray.exe. You can do so by clicking Start, clicking Run, and then typing c:\program files\resource kit\kerbtray.exe and pressing Enter. You should see a little green ticket icon in your system tray in the lower right corner of your desktop.

• Purge the ticket cache on Server1, right-click the green ticket icon in your system tray, and then click Purge Tickets. You should receive a confirmation that your ticket cache was purged. Click OK.

• Open cmd type: netdom /resetpwd /server:server2 /userd:domain.com\administrator /passwordd:xxxxx, and then press Enter.

• Restart the server whose password was changed (in this example, Server1).

• Synchronize the domain. To do so, open a command prompt, type repadmin /syncall, and then press Enter.

• Start the KDC service on Server1. To do so, open a command prompt, type net start KDC, and press Enter. This completes the process, and the domain controllers should be replicating success-fuly now

Required resources:

# How to remove\add workstation from\to domain remotely?

If you have 250 workstations which were a member of non-existing domain and new AD, and wanted to add them back to domain.

How you can remove and add workstations to domain, without performing this operation manually on every workstation?

Required resources:

1. Old (1.8) version of NETDOM.EXE tool which was originally released with Windows NT 4.0 Resources Kit. Now You can get it from Microsoft FTP server.
2. Latest version of NETDOM.EXE which is a part of support tools.
3. PSEXEC.EXE and PSSHUTDOWN.EXE tools from PSTools. First of them will allow us to execute command remotely and second will allow us to perform reboot of the remote machine after operation.

As a first step we need to pull the workstations out from domain. We can do this with old version of NETDOM.EXE (let’s call it netdom18.exe), as it allows us to move workstation to WORKGROUP. We will use PSEXEC to perform this operation remotely:

psexec \\STACJA -u STACJA\Administrator -c netdom18.exe MEMBER \\STACJA /JOINWorkgroup WORKGROUP

With -c switch our tool will get copied on remote machine before execution. This command will join workstation named STACJA to workgroup WORKGROUP. Now we have to perform remote reboot of this workstation as old version of NETDOM can’t do this automatically:

Now we have to add this workstation back to domain. If its account exists in domain maybe we should think about performing reset on this account. To add workstation to domain we will use current version of NETDOM.EXE: