Anda di halaman 1dari 36

1) Which DC Is Selected When Promoting A Member Server To DC?

When you promote a member server to Domain Controller using

Dcpromo.exe, the Dcpromo.exe contacts a domain controller available
in the domain to replicate the AD Database. If there is only one DC
then it always contacts that DC for AD database but what if there are
more than one DC?

The Dcpromo process always contacts the DC available in its own site
first. If there is no DC in its own site then a DC from the nearest site is
contacted. You can check the Dcpromo process and see which DC it
contacted during the promotion by opening the DCPROMO.LOG file
found at %SystemRoot%\Debug folder. The log file will contain the
following lines for the source DC:

07/30 11:58:24 [INFO] Located domain controller for domain

07/30 11:58:24 [INFO] Using site Default-First-Site-Name for

server \\

2) FRS D2/D4 - When Should You Use Them?

D2 and D4 are used to restore a SYSVOL Replica Set in Active Directory

domain. The D2 is generally called Non-Authoritative and D4 is called
Authoritative. These two terms are used by the File Replicatoin Service
and set in registry keys of the domain controllers. When these two
values are used in an Active Directory domain, the DC on which you
have set the D4 Flag is called the Authoritative Server for the SYSVOL
Replica Set and acts the Primary Member for D2 DCs. The D2 DCs
will then sync the SYSVOL Replica Set contents when you restart the
FRS service on these computers. They will contact the D4 DC to
compare and sync the changed files. This process is called D4-D2

When should you use them?

Don't just go ahead with D4/D2. D4/D2 shall be the last resort except
the followings:

• FRS computer is throwing JOURNAL WRAP Errors in the FRS Event

• Junction Points have been changed or deleted
• File/folders are morphed

For troubleshooting FRS and when you to use D4/D2, please check the
following Knowledge Base at Microsoft site:

3) How To Know The Primary Member of A SYSVOL Replica Set?

The Primary Member is used by all the domain controllers to sync the
SYSVOL Replica Set. The first DC in a domain is always the FRS Primary
Member. This is useful when you want to perform a D4 operation on
SYSVOL Replica Set.


• Log on to a DC.
• Use ADSIEdit.msc snap-in
• Navigate to the following location:

Domain NC > CN=System > CN=File Replication Service >

CN=Domain System Volume(SYSVOL share) Properties

• Go to Attribute Editor and check the attribute by name:


The above attribute will have the DC name on which the FRS was
initially started and created the SYSVOL folder. If you ever encounter
any problem and want to initate a D4/D2 operation on SYSVOL Replica
Set then always use this DC as the Primary DC for D4 and other
Domain Controllers as the D2. When you restart FRS, the D2 DCs will
sync from the D4 DC.

4) A Quick Tip To Make Sure FRS Is Working In A Domain

FRS (File Replication Service) is used to replicate Scripts and Group

Policy in Active Directory. FRS is dependent on Active Directory
Connection Objects. FRS is multimaster technology meaning any
domain controller can make changes to the Replica Set. This tip
explains a simple mechanism you can use to make sure the FRS is
working or all the domain controllers are receiving the changed file. In
this example, we assume we have four domain controllers: RootDC1,


• Create a Text file on each DC at the location: %SystemRoot


• On RootDC1, RootDC1.txt
• On ADC2, ADC2.txt
• On ADC3, ADC3.txt
• On ADC4, ADC4.txt
• Wait for at least 5 minutes
• Log on to each DC and check all the four files you created.

If all DCs have the files you had created in its Netlogon share then that
means the FRS is working properly. If you see two or three files but not
all the files on a DC then check for which DC it hasn't received the file
and then troubleshoot using the more advanced tools available at
Microsoft site.

5) How To Force Users To Log On To The Domain?

Generally, if client computers are not able to contact a domain

controller, they will be logged on to the local computer using their
cached credentials stored at the registry. You can delete the
Cached Credentials to force them to log on the domain:

This mechanism is very useful in the following scenario:

• When you are doing capacity planning to add an additional

domain controller and want all the users to log on the domain.
• When you want users to update their LastLogonTimeStamp
value in the domain.
• When you want to apply an urgent Group Policy setting.

To delete the Cached Credentials:

• Open a Command Prompt

• Run "Psexec.exe -s -i regedit.exe" without quotes
• Navigate to HKLM\SECURITY\Cache
• Delete all NL$1 through NL$10

6) A Quick Tip to designate a domain controller for client


This is useful when you have domain application which frequently

requires access to one of the domain controllers. Since the domain
controller is busy responding to application requests, sometimes it may
fail to respond to client authentication requests. To alleviate this, you
may designate a domain controller for client authentications so that
clients always use this domain controller as their primary
authenticator. When clients query DNS Server for the domain
controllers, they get a list of domain controllers with priority.

For example, query returns: IN SRV 10 50 389 IN SRV 10 50 389 IN SRV 10 50 389

In above example, 10 is the priority and 50 is the weight of the Clients will always use for
authentication purpose if it is available on the network. If you want
your client machines to always use then change
the priority of in DNS management snap-in.

Clients will always use the server name with lowest priority first. For
example, you have changed SRV priority of Server2 from 10 to 6. After
changing the priority, the DNS query will return the list of domain
controllers in the following order: IN SRV 6 50 389 IN SRV 10 50 389 IN SRV 10 50 389

For more information on SRV Records, please check out here:

Description of DNS SRV Records.

The SRV resource record allows administrators to use several servers for a single domain, to move
services from host to host easily, and to designate some hosts as primary servers for a service and
others as backups.

7) DynamicSiteName and SiteName – Which site a client computer

belongs to?

Overview of DC Locator Service: When a client computer logs on to the

domain, the DC Locator service running at the client computer tries to
search the nearest Domain Controller by querying the local computer
registry for DynamicSiteName. The site name is stored in a registry
entry called “DynamicSiteName” at
HKLM\System\CurrentControlSet\Services\Netlogon\Parameters key.
DC Locator Service uses this information to query DNS Server to find
the domain controllers in that site. It appends the site name to the
query. If DynamicSiteName registry entry is not present or this is the
first time a client computer is logging on to the domain, the DC Locator
service sends out a domain-wide DNS query to find any domain
controllers. Based on the subnet information, the DNS Server will
return a list of domain controllers in a site closet to the client
computer. After receiving response from the DNS Server, the DC
Locator stores the Site Name information at the above mentioned
registry key. Next time, DC Locator Service doesn’t send a domain-

wide DNS query. Instead it uses DynamicSiteName to query the
domain controllers in that site only.

If you want your client computers to belong to a specific site each time
they log on to the domain, you should create the following registry
entry on the local computer:

Key: Syetem\CurrentControlSet\Services\Netlogon\Parameters
Name: SiteName
Type: REG_SZ
Value: After adding the above registry entry, the DynamicSiteName
value is ignored. DC Locator Service always uses the value stored in
SiteName registry entry to query the domain controllers in that site.

8) Checking the Location of Domain FSMO Roles

When dealing with Active Directory on a domain that is unfamiliar, you

may be placed in a situation where you have to verify the location of
the domains FSMO roles. One of the quickest ways to do this is through
the netdom utility which is part of the Windows Server 2003 support
tools package.

You can view the location of all five FSMO roles by using this
command: Netdom query fsmo

9) Creating Dummy (Test) Users

Occasionally when testing a prototype Active Directory environment,

you may need to create a large number of dummy domain users for
testing purposes. You could go through the pain of creating a CSV file
and using LDIFDE to create them, but here’s a much easier way.
Simply use the FOR command together with DSADD to create users
named user1, user2, user3 and so on. For example, to create 100
dummy users in the Vancouver OU of the domain, run the
following at a command prompt on your domain controller:

for /L %d in (1,1,100) do dsadd user cn=user


Alternatively, you can replace % with %% and run the command within
a batch file:

for /L %%d in (1,1,100) do dsadd user cn=user%


10) Troubleshooting the Domain Controller Locater Process

The process used by Windows computers to find a domain controller to

authenticate to is one that is not completely problem fee. In the case
that you experience this, here are a couple of quick steps you can do
to track down where the problem lies.

1. Verify that you have network connectivity, and IP address, and

can ping the domain controller you are trying to authenticate to.
2. Use the command: nltest /dsgetdc:domainname to ensure that
the domain controller can be found for the domain specified.
3. Ensure that the server can be found in DNS with the command:
4. Ensure that the SRV records for the domain controller are
registered in DNS correctly with the command: nslookup
5. Use the Microsoft network monitor utility or another packet
analysis application to see the exact step the domain controller
locater process is failing on.

When troubleshooting this type of problem, it is always a good idea to

understand how the process works in the first place. You can get a
really good overview of this process by checking out the Microsoft KB
article here:

11) Understanding the DNS Resolver Host File

DNS relies heavily upon its caching abilities both on the client and
server level. Not only is this essential for basic functionality but it also
helps to improve the performance of the protocol. The DNS client
cache (also called the DNS resolver cache) stores any query response
it receives from a DNS server in its cache.

Each DNS client also contains a static file that contains hostname-to-IP
address mappings. This file is called the Hosts file and can be found at
C:\Windows\System32\Drivers\Etc. Any entry in this file is
automatically preloaded into the DNS resolver cache.

Aside from being a supplement to standard DNS caching, the hosts file
has several other uses such as being used to block access to known
malicious servers and domains by redirecting those DNS names to
known good sites.

The DNS resolver host file is something that can also be a very
appealing target to potential malicious activity. This is seen quite often

in spyware and adware infections where known good addresses such
as are redirected to rogue advertising servers.

12) Using the Employee-ID attribute in Active Directory

Active Directory has an Employee-ID attribute for user objects but

unfortunately this attribute is not exposed in UI (i.e. in Active Directory
Users and Computers) so you can't easily configure it if you want to
use it. You can of course configure this attribute of a user account
using one of the command-line tools for managing Active Directory
such as LDIFDE or DSMOD, and you could also use ADSIEdit or even
ADSI scripts to configure it. What you may not be aware of however is
that you can programmatically extend ADUC to expose this attribute in
the UI. To learn how to do this, download the ADSI SDK and install it
and look in the Samples\DSUI\userext\userproppage where you can
learn how to create an extension for employee ID and thumbnail photo.

13) Finding global catalog servers

How can you quickly find the global catalog servers in your domain?
Two command-line tools can be helpful here:

1. First, you can type repadmin.exe /options * and use IS_GC for
current domain options.

2. And second, you can type nltest /dsgetdc:corp /GC

14) Prevent accidental deletion of OUs

Someone asked me if you could prevent admins from accidentally

deleting OUs in Active Directory as the consequences of doing so could
be very bad indeed. The answer of course is that No, you can't prevent
admins from doing anything because they're admins! You need to train
your admins properly and ensure you hire people who are careful and

However, one small but very nice feature of Active Directory in

Windows Server 2008 (formerly called Longhorn) is that when you try
and delete an OU you are prompted with an Are You Sure warning
message. For more information about Active Directory in Windows
Server 2008, see my book Introducing Windows Server 2008.

14) Editing the DNS Root Hints Files

In order for DNS server recursion to work properly, the DNS server
needs to know where to begin looking for names in the DNS

namespace. This information is made available through root hints.
These are resource records used by the DNS service to locate servers
authoritative for the root of the DNS domain namespace tree.

Be default, Windows 2003 DNS servers use a preset root hints file
stored at C:\Windows\System32\Dns\Cache.dns. This file contains a
listing of all of the addresses of the root servers in the Internet DNS
namespace. This means that if you are using the DNS server service to
resolve Internet-based DNS names, the root hints file doesn’t need to
be modified at all. However, if you are using DNS service on a private
network you can edit or replace this file with similar records that point
to your own internal DNS root servers.

It is important to note that DNS root servers should not use root hints
at all, and by default Windows Server 2003 automatically deletes the
Cache.dns file in these scenarios.

15) Missing Delegation tab

To enable a remote Windows Server 2003 server for EFS file

encryption, you need to right-click the remote server in Active
Directory Users and Computers, select Properties, select the
Delegation tab, and enable the Trust this computer for delegation to
specified services only option. At least, these are the steps you should
follow according to

The other day an IT guy I know tried to do this but when he opened the
properties of the remote server in ADUC, there was no Delegation tab!
Why? Because he hadn't raised his domain yet to Windows Server
2003 domain functional level.

Moral: Those "smart" properties sheets, which add or remove tabs

based on other configuration settings, can be confusing! Plus you can't
always trust the documentation because sometimes it assumes things.
Oh well.

16) Finding schema differences

Here's an interesting issue one consultant told me about. He had heard

that a company wanted to migrate some user and computer accounts
from one Active Directory forest to another forest. So far so good,
right? But the original (first) forest had had some modifications made
to its AD schema to extend the schema in order to support several
third-party applications, and unfortunately the documentation on what

modifications had been made to the schema were…let's say…sorely

The company wanted to know if there was some way of finding out
what differences there were between the schema of the original forest
and the schema of the new forest. After some searching around, the
consultant came up with Schema Analyzer, a tool included with ADAM
(Active Directory in Application Mode) and using this tool the company
could compare the two schemas and determine which classes and
attributes were present in the original schema that were not present in
the new schema. Then the company could use this information to
create the necessary classes and attributes in the new schema.

For more information about Schema Analyzer and ADAM, see

Introducing ADAM.

17) Dumping group memberships

Unfortunately there's no built-in tool in Windows Server 2003 that can

let you dump all groups and their membership from Active Directory,
though there are a few older Resource Kit tools you can fiddle with to
do this e.g. showmbrs.exe, addusrs.exe and so on.

A better way of doing this however is to use DumpSec.exe, a tool

available from SomarSoft at

18) Port 445 and trust creation

In order to create a trust between two domains, you need to have TCP
port 445 (the Microsoft SMB port) open on both sides. Having open
ports though (especially for SMB traffic) is an invitation to attacks by
worms and other malware, so the few ports you need to keep open the
better, right?

What's not often known though is that once the trust has been
established between the two domains, port 445 can then be closed
since the port only needs to be open during trust creation. See Domain
and Forest Trust Tools and Settings for details.

18) Using AGPM for Advanced Group Policy Delegation

The Advanced Group Policy Management (AGPM) tool from Microsoft is

a great new tool that goes well beyond the abilities of the traditionally
used Group Policy Management Console (GPMC).

One of the strengths of the AGPM tool is how it has extended the

delegation of group policy objects. One of these features is the more
granular control over delegation. The AGPM has its own delegation
model which allows for more specific settings giving greater leverage
over delegation assignments. AGPM also allows for a new feature in the
offline editing of GPO’s. This means that group policy administrators
will now have to check-in and check-out GPO’s for editing. This not only
provides better security but also prevents multiple people from editing
the same live GPO at the same time.

19) Change Management Using AGPM

The Advanced Group Policy Management (AGPM) tool from Microsoft is

a great new tool that goes well beyond the abilities of the traditionally
used Group Policy Management Console (GPMC).

One of the more notable features of AGPM is its change management

functionality. In larger networks you may have several people who are
responsible for maintaining group policy objects and if this is the case
then it is nearly impossible to keep up with when they are modified.
Using AGPM change management you can keep track of who made
changes to a GPO, when the change was made, and what the change
was. Not only that, but you can also generate change reports that give
a detailed view of all of the changes that have taken place to a GPO in
a simple to read HTML format.

20) Enabling Windows Firewall on domain controllers

You can enable Windows Firewall on your domain controllers for

enhanced security, but you need to do it right, otherwise problems can
arise such as not being able to join client machines to your domain.
Here's how you need to configure Windows Firewall on a domain

Enable the File And Print Sharing exception.

Enable program exceptions for lsass.exe and ntfrs.exe.exe which are

found under %windir%\system32.

Enable port exceptions for ports 53 (TCP and UDP), 88 (TCP and UDP),
123 (UDP), 135 (TCP), 137 (TCP), 389 (UDP), 464 (TCP and UDP) and
636 (TCP).

21) Identifying Unused Accounts

A company I know wanted to identify any user accounts belonging to

users who had not logged onto the network for an extended period of

- 10 -
time. After discussing several options, they came up with the following
solution: use the DSQUERY computer -inactive NumberOfWeeks
command to identify all machines that were not logged on to Active
Directory during the specified NumberOfweeks.

Note that the command above should be used if your domain is

running at the Windows Server 2003 functional level. If your domain
still has Windows 2000 computers in it and is running in the mixed-
mode functional level, use DSQUERY computer -stalepwd
NumberOfDays instead.

22) Schema vs. Enterprise vs. Domain Admins

You have to choose who will be your domain admins very carefully,
even in a multi-domain environment. That’s because there are exploits
that can enable Domain Admins to make themselves into Enterprise
Admins or even Schema Admins! And this works even if you are a
Domain Admin in a child domain! What this means that if you need
true separation of admin powers, you need to deploy multiple forests.
That’s because the forest is the only real security boundary in Active
Directory. Domains are not true security boundaries. And this is also
reason that Microsoft has stopped promoting the idea of an empty
forest root domain where only Enterprise Admins reside, since these
exploits can enable a Domain Admin in a child domain to easily
become an Enterprise Admin and own the forest.

23) Exempting User Accounts from Domain Password Policies

In an Active Directory environment, password policies for users

accounts are determined by the Group Policy settings found under
Computer Configuration\Windows Settings\Security Settings\Account
Policies\Password Policy. These policy settings (there are six of them)
apply uniformly to all users in the domain. In other words, you can’t
exempt a particular user account from these policy settings even if you
wanted to.

With one exception: by enabling the Password Never Expires on the

Accounts tab of a user account’s Properties sheet in Active Directory
Users and Computers, you can override (for that user) the domain-wide
policy setting for Maximum Password Age. It’s usually best to reserve
this option only for custom service accounts however.

24) Preventing Orphaned GPO’s

There are various different reasons why you might want to remove a
computer from a domain within your network. Regardless of the

- 11 -
reason, you have to be careful that you take notice of group policy
being applied to the computer in order to prevent “orphaned” GPO’s.

An orphaned GPO is the result of what happens when you remove a

computer from a domain without removing its applied Group Policy
Objects. In order to prevent this from happening, it is a good idea to
first move the computer in Active Directory into an OU that has no
GPO’s applied to it before removing it from the domain completely. It is
also a good idea to make sure that this OU is blocking policy
inheritance from OU’s above it. Doing this will completely ensure that
you all group policy settings are removed from the computer in

25) Forcing Group Policy to Run at Startup

If you have ever done any work with group policy you may notice that
it sometimes takes two or three reboots of a client computer before
some policies take effect. This is pretty commonly seen with software
installation and folder redirection policies more than any other. This
delay is caused by a “feature” of Windows XP called “Fast Logon
Optimization”. This means that group policy is processed at the same
time as when the processor is performing other tasks to get the
computer booted up into a usable state.

The solution to this problem is disabling fast logon optimization with

another GPO. You can find this setting under Computer
Configuration\Administrative Templates\System\Logon. Here, you can
enable “Always wait for the network at computer startup and logon”.
This could potentially increase the time it takes for your computers to
log on, but it will also ensure that group policy gets its chance to be

26) Group Membership in Multi-Forest Scenarios

If your organization has deployed Active Directory in a multi-forest

scenario (for example through a merger or acquisition with another
company) and you need to add users or groups in one forest to a group
in the other forest, the group in the other forest must be a domain
local group. You might thing from reading the Microsoft documentation
at that you
could also use universal groups for this purpose since it says there that
“A universal group can contain other universal groups, global groups
and accounts from any domain in any forest”. However, this is
incorrect—universal groups can only contain users or groups from the
same forest, not from different forests.

- 12 -
Mitch Tulloch was lead author for the Windows Vista Resource Kit from
Microsoft Press, which is THE book for IT pros who want to deploy,
maintain and support Windows Vista in mid- and large-sized network
environments. For more information see

27) Active Directory replication in a multilingual environment

If you have a large organization and plan on deploying a single Active

Directory domain in a multilingual environment (for example, a single
domain that spans national geographical boundaries) then you might
be wondering how this could impact Active Directory replication. For
example, what if you have one domain controller running the English
version of Windows Server 2003 and another domain controller running
the German version, with both domain controllers belonging to the
same domain? Fortunately, it turns out there are no issues at all with
doing this i.e. Active Directory replication is unaffected by having
domain controllers running different language versions of Windows
Server 2003.

Mitch Tulloch was lead author for the Windows Vista Resource Kit from
Microsoft Press, which is THE book for IT pros who want to deploy,
maintain and support Windows Vista in mid- and large-sized network
environments. For more information see

28) Prevent saving to desktop

I don’t know about your company, but when I look at users’ desktops
they are usually covered with files, shortcuts, and other junk. Why do
they save stuff to their desktops instead of saving it in My Documents
where it belongs? Who knows…

But is there any way of preventing users from saving files on their
desktops? Yes there is: use Folder Redirection policy to redirect the
Desktop folder within a user’s profile to a read-only file share on
network server. Note that to redirect this to read-only share you have
to use following redirection option: uncheck the "Move folder contents"
option and uncheck the "Set ACLs" boxes. As an additional benefit of
using this approach, you can also populate the initial contents of users’
desktops if you need to do so.

29) Disabling network configuration settings using Group Policy

Ever wanted to do any of the following using Group Policy?

- 13 -
Disable File and Print Sharing for Microsoft Networks
Disable Client for Microsoft Networks
Disable NetBIOS over TCPIP

Well, you can’t do it using normal Group Policy settings, but you can do
it as follows: Create a batch file that contains netsh.exe commands to
perform the network configuration actions you want to perform, then
use Group Policy to deploy this batch file to client machines as a
startup script.

30) Check for problems with GPOs

Want to proactively check for problems with GPOs before they start
affecting your environment? GPOs can become unlinked, corrupted,
and misbehave in various ways, so here are a few things you can do to
check them:

Run the script GetReportsForAllGPOs.wsf (found under C:\Program

Files\GPMC\Scripts\ when you have the GPMC installed).

Run the ListAllGPOs.wsf script with the /v switch.

Run the BackupAllGPOs.wsf script.

31) Comparing RSoP before and after

Have you ever wanted to compare Resultant Set of Policy (RSoP)

information before and after making some change to your Group Policy
infrastructure? There’s no simple way of doing this using the Group
Policy Management Console (GPMC), but there is a workaround. First,
before you make your changes, run the Group Policy Results wizard
from within GPMC and save the resulting RSoP info as an HTML report.
Then make your changes i.e. add/remove GPOs, change GPO settings,
and so on. Now run the GP Results wizard again and save it as another
HTML report. Then use the windiff utility (see to compare the
two files.

32) Pre-staging computer accounts

When you join a Windows computer to a domain, by default the

computer account for the computer gets placed into the Computers
container. Unfortunately the Computers container is not an
organizational unit (OU) so you can’t link a Group Policy Object to it,
and as a result computers that join a domain like this are placed into

- 14 -
an unmanaged state, which might contravene your company’s security

The solution is to pre-stage your computer accounts by pre-creating

these accounts within an OU that has a GPO linked to it to enforce
policy. Just use Active Directory Users and Computers to create
computer accounts in the OU that have the same names as the
computers that you will be joining to the domain. Then, when each
computer joins the domain, it will check whether a pre-staged
computer account is present, and if it is then it will use that computer
account instead of creating one within the Computers container.

33) Group Policy in mixed environments

Ever had a need to push out Group Policy settings to one client
platform but not to another? For example, say you have a mixed
Windows XP/2000 desktop computer environment and you want your
Windows XP machines to receive some policy but not your Windows
2000 machines. How can you do this?

The easiest way is to put different computers in different OUs i.e.

Windows XP computer accounts in one OU and Windows 2000
computer accounts in another. Then you can link separate GPOs to
each OU and configure policy for them differently.

But what if you can’t do this? What if your computer accounts are
mixed together in a single OU and need to stay that way? Well, what
you could do is to create two new security groups, one called Windows
2000 Computers and the other called Windows XP Computers. Make all
your Windows 2000 computer accounts members of the first group,
and all your Windows XP computer accounts members of the second.
Then use Group Policy security filtering to ensure that the GPO only
applies to members of one group or the other as required. See my
tutorial at
Policy-Security-Filtering.html for more information.

34) How to remove unwanted local user accounts

Say your network of Windows computers used to be a workgroup and

you changed it to a domain. Now you have a bunch of workstations
that can be accessed by both local user accounts (from their time as
part of a workgroup) and domain user accounts (stored in Active
Directory). Is there any way you can prevent users from continuing to
log on using their old local user accounts stored on their machines?

- 15 -
The preferred solution is to delete the local user accounts from each
workstation that has them. A possible alternative is to use Group Policy
to manipulate the Log On Locally user right to prevent anyone except
domain users from logging on to desktop computers targeted by such
policy. The Log On Locally user right is found under Computer
Configuration \ Windows Settings \ Security Settings \ Local Policies \
User Rights Assignment. But the Log On Locally approach should be
carefully tested on a test network before using it on your product
network to ensure no unpredictable effects result from implementing it
in your environment.

Another approach worth exploring is to use a script to delete unwanted

local user accounts from your computers. A sample script that does
this and which you can customize further if needed can be found at
fault.mspx?mfr=true on the Windows Script Repository. By deploying
this script to targeted desktop computers using Group Policy, you
should be able to remove all unnecessary local accounts from these

Finally, here’s a social engineering way of doing it—configure password

policies on the OU where the machines reside that have such local user
accounts. Configure the policy so that users have to enter a long,
complex password and they have to change it every day to something
new (and enforce password history using its maximum value to
prevent them from re-using their old passwords). GPOs that have
password policies configured and which are linked to OUs will affect
only local user accounts for machines in that OU, so users who try to
use their old local user accounts will have to frequently change their
passwords and will likely get tired of doing so after a while!

35) Setting Up Disk Quotas with Group Policy

The disk quotas feature in Windows 2003 Server is a great way to

manage disk space. Getting this setup for a small network is usually a
breeze, but with larger networks it can take quite some time to create
a quota entry for every user. Luckily, we can use group policy to make
this process a lot faster.

In order to accomplish this task, create a new GPO and browse to

Computer Configuration > Administrative Templates > System > Disk
Quotas. There are several configurable aspect of disk quotas here, but
in order to use any of them you have to make sure the first item in the
list, “Enable disk quotas” is enabled. After doing this you can configure
all of the options you could normally configure in regards to disk
quotes. These include the default quota limits, the quota warning and

- 16 -
limit settings, and the quota logging settings. After you have
customized this GPO to your liking all that is left is to apply it to the
organizational unit of your choice.

36) Get control of your severs using Startup/Shutdown Script

In many situations we need to reset the Local Administrator password

and add Domain Admins to the Local Administrator group on a server
or client machine without visiting each machines. If you don’t know the
password and don’t have access to the severs, you can run this simple
script as a Startup/Shutdown script (Computer Configuration-
>Windows Settings-> Scripts (Startup/Shutdown) in conjunction with
Group Policy. Create batch file (.bat extension) using notepad and add
the following commands:

Net User Administrator <your password>

Net Localgroup /Add “Administrators” “Domain Admins”

The first command changes the Administrator password to <your

password>. The second command will add the Domain Admins group
to the Local Administers group on the local machine. Add this batch file
as either a Startup or Shutdown script. Leave it there for a while or
enable the “force restart” of the servers. Have fun!

37) Forcing Active Directory Replication

There may be some instances where you need to force replication

between Active Directory replication partners. There are several ways
that this can be accomplished. The method we are going to look at is
forcing replication through the Microsoft Management Console (MMC).

1. Go to Start > Programs > Administrative Tools > and open the
“Active Directory Sites and Services” MMC.
2. Expand the “Sites” container in the left pane by clicking the plus
(+) to the left of it.
3. Expand the container that represents the name of the site
containing the server that needs to be synchronized.
4. Expand the “Servers” container and then expand the target
server to display the NTDS settings object.
5. Click the “NTDS Settings” option. In the right pane should now be
a list of the target server’s replication partners.
6. Right click a connection object in the right pane and click
“Replicate Now”.

- 17 -
38) Authoritative vs. Non-Authoritative Restoration of Active

It is any network administrator’s worst nightmare; your domain

controller has crashed. So where do you go from here? Well, hopefully
you have been doing your backups properly. If that is the case you
shouldn’t have too much to worry about. However, during the
restoration process you have to make the decision on whether to do an
authoritative or non-authoritative restoration. The clock is ticking,
which one do you choose?

Non-Authoritative Restoration
Used most commonly in cases when a DC because of a hardware or
software related reasons, this is the default directory services restore
mode selection. In this mode, the operating system restores the
domain controller’s contents from the backup. After this, the domain
controller then through replication receives all directory changes that
have been made since the backup from the other domain controllers in
the network.

Authoritative Restoration
An authoritative restore is most commonly used in cases in which a
change was made within the directory that must be reversed, such as
deleting an organization unit by mistake. This process restores the DC
from the backup and then replicates to and overwrites all other domain
controllers in the network to match the restored DC. The especially
valuable thing about this is that you can choose to only make certain
objects within the directory authoritative. For example, if you delete an
OU by mistake you can choose to make it authoritative. This will
replicate the deleted OU back to all of the other DC’s in the network
and then use all of the other information from these other DC’s to
update the newly restored server back up to date.

39) Default GPO Permissions

I cannot stress enough how important it is to correctly set permissions

for the Group Policy Objects you create. In this sense, it is very
important that you know what permissions are assigned to a Group
Policy Object by default. They are as follows:

Authenticated Users – Read, Apply Group Policy, Special Permissions

Creator Owner – Special Permissions
Domain Administrators – Read, Write, Create All Child Objects,
Delete All Child Objects, Special Permissions
Enterprise Administrators – Read, Write, Create All Child Objects,
Delete All Child Objects, Special Permissions

- 18 -
Enterprise Domain Controllers – Read, Special Permissions
System – Read, Write, Create All Child Objects, Delete All Child
Objects, Special Permissions

It is also important to know that only the Domain Administrators,

Enterprise Administrators, and Group Policy Creator Owner groups
have permission to create new GPO’s be default. Any user who needs
the ability to create GPO’s will need to be added to one of these
groups. It is generally best practice to add these users to the Group
Policy Creator Owner group so that they have fill administrative
permissions over only the GPO’s they create.

40) Increase file server performance

One simple way to get better file server performance is to make sure
you use a separate server as your file server. In other words, don't use
your domain controller as your file server. Why, you might ask. After
all, domain controllers don't do all that much most of the time--
everyone logs on in the morning, downloads GPOs, and the DC goes
quiet, right?

Well, if you are running Windows Server 2003 then SMB signing is
turned on by default for security reasons to safeguard network
communciations between client computers and DCs by protecting
against man in the middle attacks and SMB packet replay attacks. But
SMB signing also means that all packets in a TCP session that are
exchanged between clients and DCs are serialized i.e. packet 1 must
be acknowledged as received before packet 2 is sent, and so on. And
this can have a huge impact if you try to transfer a large file between a
client and a DC.

Rather than disable SMB signing, which would expose your domain
controller to possible attack, why not migrate your file server functions
to a separate machine instead.

40) Why do we still need WINS?

Why, in this age of Windows Server 2003 R2, is it *still* a good idea to
run WINS servers on your Active Directory network? Doesn't AD use
DNS for name resolution? Yes. Isn't NetBIOS obsolete? Yes. Do any
applications still use NetBIOS? Unfortunately, yes! Some of the
common apps that need WINS servers in order to run effectively are:

- My Network Places (or Network Neighborhood) to quickly repopulate

this browse list as the Browser service is still based on NetBIOS.

- 19 -
- Any third-party network applications that leverage the browse list to
find network resources users can attach to. You can probably track
these puppies down by monitoring activity on your WINS servers by
logging perfmon counters on them.

41) How to change membership in groups based on attributes of users

in AD automatically

If your company has a complicated structure, you may need to filter

members of your security or distribution groups automatically based
on changes to some attribute of users in Active Directory – let's say

There is a simple way how to do it: create a grp.txt file whose content
would be names of departments, and second a changemembership.bat
file in the same path, where inside would be:

FOR /F %%i in (grp.txt) do dsquery * domainroot -filter

"(&(objectCategory=user)(department=%%i))" | dsmod group "CN=%
%i,ou=Distribution Lists,dc=company,dc=com"

chmbr Prerequisities: your group name must be the same as name of

your department (customize rest of CN path as you require), or you
need to think another way to associate your users with groups. I want
just to show you the capability of AD in right usage.

41) Web-based AD management

If you're looking for a web-based tool for managing Active Directory as

an alternative to the somtimes cumbersome MMC consoles included
with Windows Server 2003, you might want to check out Phat
Consulting's Directory Manager. You can use this tool to perform the
usual AD administration tasks and also automate certain tasks, all
using a well-organized web-based interface.

42) Pruning Old Computer Accounts in AD

In large organizations the task of keeping Active Directory cleansed

of inactive computer accounts can be daunting. Using the dsquery
command we can easily find all of the computers in the directory
that have not been logged into in a given time interval.

As an example, the following command will find all computers in

Active Directory that have not been logged into during the past 8

- 20 -
dsquery computer -inactive 8 -limit 0

After reviewing this list to make sure these computers no longer

exist on your network you can use the following command to find
and delete them:

dsquery computer -inactive 8 -limit 0 | dsrm

The DSQUERY utility comes with the Windows Server 2003 Support
Tools package (Adminpak.msi) which can be installed directly from
your Windows Server 2003 installation media or downloaded from
the Microsoft website.

The standard disclaimer applies to this as to when you delete

anything in Active Directory. You should always check the list of
computers to be deleted twice before you perform that action. Just
because your CEO hasn’t logged into his laptop in a couple of
months doesn’t mean he won’t in the near future, and he may not
be too happy to find he no longer has network access!

43) Avoiding Legacy Built-in Groups

Microsoft documentation on this isn't clear, but built-in local groups like
Account Operators, Server Operators, and others found in the Builtin
container of Active Directory are legacy groups that are basically only
there to maintain backward compatibility with Windows NT.

If you want to grant users rights to perform certain tasks like create
new accounts, reset passwords, and so on, avoid using these built-in
groups and use Active Directory delegation instead. Delegation gives
you greater control over which groups of users you can assign to
perform different kinds of admin-level tasks, and it's easy to use as
well, just right-click on an OU and select Delegate Control and a wizard
opens to walk you through the process.

44) Who's logged on?

A frequently asked question concerning Active Directory-based

networks is, How can I tell who is currently logged on to my network?
Unfortunately Active Directory itself has no built-in functionality to
determine this, but there's a free tool from Microsoft that can help in
this regard. The tool is called LimitLogon.exe and its main purpose is to
limit the number of concurrent user logins to a domain, but it can also
be used to keep track of all logins in a domain.

- 21 -
LimitLogon is an unsupported tool and can be downloaded here from
Microsoft. There's also a FAQ on that explains how the tool is
used. As usual, use unsupported tools with caution and try them out in
a test environment first before using them on your production network.

45) Configuring Wireless Security Settings via GPO

Windows Server 2003 provides functionality via group policy to

configure wireless settings for clients in your organization. These
settings can only being configured from Active Directory Users and
Computers or the Microsoft Group Policy Management Console running
on a Windows 2003 Server.

Several wireless policy options are available including:

• Limit connections to Infrastructure or Ad-Hoc networks only

• Automatically connect to non-preferred networks
• IEEE 802.1x
• Authentication type (Shared or Open)
• EAP Type

Usage of these extensions is good practice for anyone administering a

sizable wireless network infrastructure.

46) Managing SRV Records in DNS

Active Directory uses SRV records in DNS for locating domain

controllers so users can log on and so on. But if something goes wrong
and your DNS database becomes corrupted, these records can be
difficult to recreate.

Joeware has come to the rescue here with a new utility called
DNSSrvRec that you can use to create and delete SRV records easily.
You can download this utility for free from

47) Quick tips on troubleshooting FSMO roles

Here are some tips on troubleshooting FSMO roles, presented in the

form of a pop-quiz. See how you score on it, answers are at the

- 22 -
1. I can't add a new domain to my forest. Which FSMO role might be

2. I tried running adprep /domain but it failed. Which FSMO role might
be down?

3. Some users changed their password but now they can't log on.
Which FSMO role might be down?

4. The clocks on my servers don't seem to be synchronized properly.

Which FSMO role might be down?

5. I tried upgrading a Windows 2000 domain controller to Windows

Server 2003 but the DNS application partition wasn't created. Which
FSMO role might be down?


1. Domain Naming Master 2. Infrastructure Master 3. PDC Emulator

4. PDC Emulator 5. Domain Naming Master

48) Using a Batch File for Resetting Domain Passwords

In some organizations the need may arise for a member of staff to be

able to reset passwords for users without having to access the Active
Directory users and computers snap-in. One solution for this is to setup
a batch file that will allow the staff member to do this in an automated
fashion. This can be accomplished by using the often underestimated
NET command.

The following file named “pwreset.bat” will do exactly what we wish to


@echo off
SET /P usr=Please enter the username you wish to reset the password
net user %usr% * /DOMAIN

Once you run pwreset.bat the file prompts the staff member for the
username of the account they wish to reset. After this it prompts for
what the password should be set to, then requests the password be
typed a second time for confirmation purposes. Once this is done the
user account is updated on the domain controller and you are good to

48) Avoiding Group Policy Bloat

- 23 -
Group Policy is a great tool for managing the configurations and
security of your desktop computers, but in very large environments
there can be some performance problems with it. Specifically, let's say
you have a large company with thousands or workers and a complex
administrative structure but with only a single Active Directory domain
deployed. This means you may literally have hundreds of
organizational units (OUs) in your domain, with OUs nested within
other OUs to several levels. Then let's say you've linked Group Policy
Objects (GPOs) to most of these OUs, some perhaps with several GPOs
linked, so you can satisfy all the security requirements of your

The problem that now arises is that each GPO is stored in the SYSVOL
share of each domain controller in your domain. These GPOs can be
found at %systemroot%\sysvol\domainname\Policies\POLICYGUID
where POLICYGUID is the globally unique identifier of the GPO. Now
Group Policy has grown considerably in power and flexibility since it
was first released for Windows 2000, and that's fine but it also means
that you can now manage several thousand policy settings using it.
That means the ADM files for Group Policy have also grown, and are
now at the point where they occupy almost 2 MB of disk space. Now
these ADM files are also copied to each GPO on each domain controller
and are stored in the folder %systemroot
%\sysvol\domainname\Policies\POLICYGUID\Adm. This means that
every GPO in your domain occupies at least 2 MB of disk space in the
SYSVOL share EVEN IF there are no actual policy settings configured in
that GPO! Think of what this can mean regarding (a) disk utilization on
your domain controllers and (b) file replication of the SYSVOL share
between domain controllers.

Fortunately, Windows Server 2003 provides you with some flexibility in

this matter by configuring two (you guessed it) the Group Policy setting
"Always use local ADM files for Group Policy Object Editor"
which is found under Computer Configuration, Administrative
Templates, System, Group Policy. By enabling this policy you can
prevent ADM files from being stored in GPOs on SYSVOL and save disk
space. If you enable this policy setting then also enable the setting
"Turn off Automatic Update of ADM files" which is found under User
Configuration, Administrative Templates, System, Group Policy as that
way the Group Policy Object Editor can use the local ADM files stored in
the %windir%\inf folder on the machine where you are running the

49) When to use and not use universal group membership


- 24 -
Windows Server 2003 includes a new feature called universal group
membership caching (UGMC) to locally cache a user's membership in
universal groups on the domain controller authenticating the user. This
can be useful in branch office scenarios where you don't want to
deploy a global catalog (GC) because of the extra WAN traffic that the
GC needs to replicate with other domain controllers in the domain. The
cached membership for UGMC is then refreshed every 8 hours to keep
it up to date.

UGMC is enabled on a per-site basis in AD as follows: Open Active

Directory Sites and Services, expand the Sites node and select the site
where you want to enable UGMC, right-click NTDS Site Settings, select
Properties, and select the Enable Universal Group Membership Caching
check box. Then under Refresh cache from click a different site from
which the selected site will refresh its UG membership cache.

If UGMC can speed logons at remote sites then it sounds like a good
idea. But when is it better to simply deploy a GC at the remote office

1. When you have lots of WAN bandwidth available

2. When the membership of universal groups frequently changes

3. When you have Exchange Server deployed at the remote site

4. When the branch office and headquarters both belong to the same
AD site.

If any of these is true, it's best if you simply make one of the domain
controllers at your remote office a global catalog server.

50) More Grace Period for Restoring Active Directory

It's well-known that you should never restore a backup copy of Active
Directory older than the tombstone lifetime, which by default is 60
days. That's because after 60 days objects that have been deleted
from AD are scavanged and permantently deleted. You see, when you
delete something from AD it doesn't really get deleted, it just gets
tombstoned i.e. marked as deleted. Such tombstones have a lifetime of
60 days and after that they're cleaned out of the directory and gone

Unless you try and restore a backup of AD that's more than 60 days
old. The problem with doing this however is that you're likely to end up
with objects that have been permanently deleted suddenly coming

- 25 -
alive again, sort of like zombies in that Eddie Murphy movie. In fact, if
you do have to restore AD you should use as recent a backup copy as
you possibly have i.e. a day old at most. And even that can cause a
few hiccups on a large network since computer accounts have their
passwords randomly changed every 30 days for security reasons, so if
you have a lot of computers on your network then it's very likely that
even in a span of one day a few computer accounts will change, and
these machines will need to have their computer accounts reset. The
same goes for trust relationships, which also have their passwords
changed every 30 days, so you may need to delete and re-create a
trust or two in a multi-domain environment, though that's less likely.

What most admins don't know however is that this grace period for
restores of 60 days (the tombstone lifetime) has been lengthed in
W2K3 SP1 to 180 days--but only for domains where the first DC has
been dcpromo-ed on a standalone W2K3 SP1 machine. In other words,
if you already have a domain and you upgrade your DC with SP1, the
grace period is still 60 days.

51) When Delegation Doesn't Seem to Take

Delegation is a powerful feature of Active Directory that lets an

administrator grant users and groups the permissions and rights
needed to perform certain tasks. For example, you can delegate to a
junior admin the ability to reset the passwords on any account or to
view the properties of any account but not change these properties.
That can free you, the senior administrator, to focus on more pressing

Sometimes however delegation doesn't work as you expect. In

particular, in certain circumstances delegation won't "take" properly
and the permissions assigned by the Delegation of Control Wizard are
later mysteriously revoked.

This can happen when the account you are trying to delegate to is a
member of one of the protected groups i.e. Domain Admins, Server
Operators, Backup Operators, and similar built-in groups. These groups
are themselves designed to facilitiate delegation by automatically
granting certain user rights to any account that belongs to them as a
member. But the Delegation of Control Wizard works differently, and
the permission and rights assigned to an account by this wizard are
enforced once an hour by a special thread running on the PDC
Emulator, the big kahuna of domain controllers on your network. So
what happens is that if you delegate some task to Bob, and Bob is a
member of Backup Operators (either explicitely or through nesting of
some other group Bob belongs to), and if the delegation of the task to

- 26 -
Bob assigns permissions or rights that conflict with the implicit
permissions and rights granted to any member of Backup Operators,
then in less than an hour you're likely to see Bob's delegation revoked
and Bob unable to perform the task you delegated to him.

Watch out for this. You can avoid this problem by not using the
protected groups at all, except for the high-level ones of Enterprise,
Schema and Domain Admins. If you do choose to use the Operators
groups however, then make sure you carefully check the group
membership (explicit and nested) of a user or group before you
delegate a task to them using the Delegation of Control Wizard.

Final caveat: this tip applies to AD in Windows 2000 SP4 or later, and
Windows Server 2003.

52) Avoid Overuse of Protected Groups

Protected groups are special built-in groups that are used to assign
administrative rights to users. These groups include:

• Enterprise Admins
• Schema Admins
• Domain Admins
• Account Operators
• Sever Operators
• Backup Operators
• Print Operators

and a few others. If you want to assign someone certain privileges on

your server, you can make them a member of the appropriate
protected group. For example, to give someone the right to back up
files on your server you simply make them a member of Backup

This sound like a great idea but too much of a good thing can be bad
(as I know from experience the time I ate a whole pecan pie for
desert--I was sick afterwards). The problem is that Active Directory
keeps an eye on these groups to make sure that no-one changes the
rights they have or the permissions they have on resources. AD does
this by creating a special thread called AdminSdHolder/DsPropagator
and running this thread once each hour.

So what can go wrong with that? Well, if you have a lot of user
accounts that are members of different protected groups, then once
each hour you may see the CPU utilization on your PDC Emulator
domain controller go to 100% for a period of time as this thread does

- 27 -
it's housekeeping work. If you see this happening, you need to either
(a) move your PDC Emulator role to a beefier machine, or (b) reduce
the number of members of your protected groups.

In fact, apart from Enterprise/Schema/Domain Admins, you may not

want to use the other protected groups at all and instead create your
own security groups and assign the necessary rights to these groups
by configuring the appropraite Security Settings/Local Policies/User
Rights Assignment setting in Group Policy. These groups you create
yourself for backup, restore, printer, accounts and other second-tier
administration purposes will not have any effect on the CPU utilization
of your PDC Emulator.

53) Avoid Mapped Drives

I usually recommend that people create mapped drives on XP desktop

computers. Mapped drives were popular in Windows 3.x/9x days when
networks were small and admins wanted to make it easy for users to
find and save stuff on shared folders on a file server. Using a mapped
drive, a user could save a file to X: drive instead of having to
remember the UNC path (e.g. \\myserver\sales) for the share. Trouble
is, if you have a mapped drive but the underlying share is unavailable
for some reason (server down, network problem) then users can
experience frustrating delays during startup. That's because if you
have any mapped drives defined, XP tries to connect to these drives
during startup/logon. And the problem with mapped drives is that once
users catch on to their usefulness they tend to proliferate. Then if you
alter the underlying share structure on your network, users may end
up with drives mapped to nothing. That can also lead to delays in
starting some network apps as well.

So my recommendation is to avoid using mapped drives completely. If

your users are on an Active Directory network, publish your shares to
AD and teach users how to search AD for shares instead using My
Network Places.

54) Finding the Groups a User Belongs To

If you find that permissions are not working properly for a user on
some resource, it may be because of the groups the user belongs to.
Access to shared resources is usually granted to groups, not users, so
if you don't know all the groups a user belongs to, the permissions the
user has on the resource may not be what you expect.

It's not as easy as you may think to find out what groups a user
belongs to. Opening up the properties of their user account in Active

- 28 -
Directory Users and Computers, you can examine the Members Of tab
to try and determine this. But if your Active Directory network is
running in Windows Server 2003 domain or forest functional level,
groups can be nested within groups to any degree, and the Members
Of tab for a user only shows the immediate groups the user explicitely
belongs to, not groups he may belong to implicitly through nesting.

Fortunately, you can determine all the groups a user belongs to by

logging on as that user and typing whoami /groups at the command
prompt. This will display all groups the user belongs to, both explicitely
and implicitely, including special identities like Everyone and
Authenticated Users.

But there's a catch--if the user belongs to any distribution groups then
these memberships may not be displayed because whoami doesn't
show groups nested within distribution groups. And although this may
not seem an issue since permissions aren't directly assigned to
distribution groups, it can be an issue since this can hide permissions
on nested security groups. So don't nest distribution groups within
security groups as it can make group permissions troubleshooting
more difficult.

55) A Common Misconception Regarding Security Logs

Domain controllers host Active Directory, which manages the security

of your Windows-based networks. If you have several domain
controllers in the same domain, Active Directory information is
automatically replicated between them so that they all contain
identical (except for replication delay) copies of Active Directory and
therefore contain identical security information. But do they also
contain identical copies of the Security log?

No. That's a common misconception. Security logs are not replicated

between domain controllers. To see why, remember that a user is
always authenticated by some specific domain controller in a given
situation, so if logon/logoff auditing is enabled on all domain
controllers, a logon security event will only be logged to the actual
domain controller that handles the authentication of the user.

So don't assume AD replication means Security log replication!

56) Find All Locked-Out Accounts

You can use the Saved Queries feature of Windows Server 2003 to
query Active Directory for any locked-out accounts. Just open the
Active Directory Users and Computers console, right-click on Saved

- 29 -
Queries in the console tree and select New --> Query. Type a name
and description for the query, specify a query root (where in your
namespace your query begins searching), and click the Define Query
button. Since there's no default option for finding locked-out accounts
in the Common Queries box, select Custom Search instead to open the
Find Custom Search box. Then select the Advanced tab and enter the
following LDAP string in the Enter LDAP Query textbox:


Click OK twice to create and run the saved query.

The string works on Windows Server 2003 SP1.

Update: Here's another LDAP query that finds all locked out accounts:


57) Troubleshooting Universal Group Caching

If you experience problems with universal group caching you can

enable error logging for this feature by configuring the following
registry value:

HKLM\System\CurrentControlSet\Services\NTDS\Diagnostics\20 Group

Set this value to 5 to have full diagnostic information written to the

Directory Service event log.

58) Fast Searching of Active Directory

It takes about half a dozen steps to search Active Directory using the
Desktop Search Assistant on Windows XP. That's frustrating for most
users. Fortunately you can make their life easier by creating a new
shortcut on their desktops that has the following path:

%windir%\system32\rundll32.exe dsquery.dll,OpenQueryWindow

Name the new shortcut something like Search Active Directory and
you're done. Users can now open the Find Users, Contacts, and Groups
dialog by simply double-clicking on this shortcut, making it easier for
them to find resources in Active Directory.

59) Enabling Caching of Universal Groups

- 30 -
Universal groups are a powerful feature of Active Directory in Windows
2000 or later as they can contain almost anything, including domain
users, computers, global groups, and other universal groups from both
the local domain and any other domain in the forest, and you can nest
them to any degree as well. Universal groups have their downside
however, especially on networks running Windows 2000. This is
because by default only global catalog (GC) servers contain a list of all
universal groups in the forest. So, if you're using universal groups and
you try to log on to a domain, there needs to be a GC server available
to enumerate your universal group membership before you can be
authenticated to the domain.

This requirement that a GC server be available when a user logs on

particularly become an issue if you have a branch office connected by
a slow WAN link to headquarters and you've configured the remote
network as a separate site to have more control over replication traffic
between the two locations. By configuring universal group caching on
the domain controllers in your remote site, you ensure that a user's
universal group membership information is available when he tries to
log on and there is no GC available at the remote site. Enabling
universal group caching is easy. Just open Active Directory Sites and
Services, connect to a domain controller in the remote site, expand the
Sites container, expand the name of the site, right-click on NTDS Site
Settings, select Properties, and select the checkbox Enable Universal
Group Membership Caching. Then repeat this procedure for all other
domain controllers in the remote site.

60) TechNet Webcast: Best Practices for Planning Your

Migration to Microsoft Exchange 2003

The text of this article is placed on another server by address

61) TechNet Webcast: Windows Server 2003 Group Policy

Essentials - Level 200

The text of this article is placed on another server by address

62) TechNet Webcast: New Features of Microsoft Windows

Server 2003 Active Directory

The text of this article is placed on another server by address

- 31 -
63) TechNet Webcast: Windows Server 2003 Active Directory
Diagnostics, Troubleshooting and Recovery

The text of this article is placed on another server by address

64) Introduction to Windows Server 2003 Active Directory in

Application Mode

The text of this article is placed on another server by address

65) Technical Overview of Windows Server 2003 Active


The text of this article is placed on another server by address

66) TechNet Webcast: Microsoft Windows NT 4.0 and Microsoft

Windows Server 2003 Active Directory Interoperability

The text of this article is placed on another server by address

Article not looking right or info is missing? Let us know so that we can
fix it:

- 32 -
This article describes how to remove the Cluster service on a Windows Server 2003-based cluster.

The files for the Cluster service are installed, by default, on computers that run either Windows
Server 2003, Enterprise Edition or Windows Server 2003, Datacenter Edition. In earlier versions of
Windows, this feature had been in the Add/Remove Programs tool.

You cannot remove the Cluster service, but you can return it to an unconfigured state. To remove
the cluster service from a failover node, follow these steps:

1. Start Cluster Administrator (CluAdmin.exe).

2. Right-click the node, and then click Stop the Cluster service.

Note: Do not perform this step if this server is the last node in the cluster.

3. Right-click the node, and then click Evict Node.

This step returns the cluster to its original unconfigured state. You can re-add it later to the

same or to a different cluster.

To remove the cluster service from the last node, follow these steps:

1. Start Cluster Administrator (CluAdmin.exe).

2. Right-click the node, and then click Evict Node.

- 33 -
Note The cluster service must be running if the cluster was configured to use the “Enable

Kerberos authentication” option.

3. Delete the computer object (network name) from Active Directory, and replicate for

changes to take effect.

If you cannot start the Cluster service, or if you have trouble removing the node, you can manually

unconfigure the Cluster service:

1. Run the Cmd.exe program to open a command prompt.

2. At the command prompt, type cluster node nodename /forcecleanup, and then press


Note: If the Cluster service does not exist in the registry, the command does not respond.

To create a place holder, type the following line at the command line, and then press


sc create clussvc

- 34 -
- 35 -
- 36 -