Group Policy Rule


Keep the following rules in mind before you apply the Group Policies:

1. Group Policies can be applied to AD-Leaf objects such as users and computers but NOT security or distribution Group.

2. Users and Computers MUST reside in the OU where you have configured Group Policy.

3. Group Policies can use GROUPS to filter the scope of policy settings.

4. By default Group Policies are applied to the following groups:

Authenticated Users                                        

5. If the security properties are default….then Group Policy settings should apply to administrators or you because by default when you create a GPO the following Security Settings permissions are set:
*Apply Group Policy* and *Read* Permission to the following Groups:-

Authenticated Users                                        
Domain Admins                                            
Enterprise Admins

5. Group Policy processing depends on Client-Side-Extensions stored in
HKEY_LOCAL_MACHINE\Software\Microsoft\Windows NT\CurrentVersion\Winlogon\GPTExtensions << all GUID listed for Client-Side-Extensions.

CSCs are used to process GPOs from Domain Controller. Winlogon.exe will capture a list of GPOs.

As per M$ recommendation you should remove *Authenticated Users* group and create a new Group > add all members to this group and use FILETERING technique. Now generally what happens all user objects are member of

Authenticated Users Group and the settings are mixed because from Domain Level to………child OU the settings are applied to Authenticated Users Group………so for example :-

If you have configured anything in the parent OU and also configured in Child OU…and all users are member of Authenticated Users Group….settings are meesed up and then Group Policy rule is applied:

Policy Settings at Parent OU                  Policy Settings at Child OU                    Result
If NOT Configured                                    If Configured                                       Child’s setting applied
If Configured                                           If Configured and Do not conflict            Both Settings
If Configured                                           If Configured and Conflicts                    Child’s setting applied
If Configured                                           If Not Configured                                  Parent’s Setting applied
If NOT Configured                                    If Not Configured                                  No Settings (This is default)

Configuring Time Service

By default, only the first domain controller or so-called Root domain controller and finally so-called “PDC Emulator” is configured to be a Reliable Time Source.

If it doesn’t exist you need to create it to make it ReliableTimeSource for other client computers and domain controllers.

Let me explain something:

By default client machines use *default heirarchy” to synchronize time. Clients will only sync with their own domain controllers in the domain. This is default bahviour and by design and to keep time closer between all PCs.

PDC is the 2nd highest stratum. Client will try to sync time with their own domain controller *unless* specifically you specify to do so. Becuase PDC is configured an authoritative server by default. It is configured using *ReliableTimeSource” entry in registry.


1     External NTP time source
2     PDC emulator of the forest root domain
3     Domain controllers in the forest root domain or PDC emulators in child domains
4     Workstations and member servers in the forest root domain or domain controllers in child domains
5     Workstations and member servers in child domains

Computers choose a time source according to a specific order of preference. This order, from most preferred to least preferred. The following table displays the preferences for Selecting a Time Source:

Preference     Computer                                     Location      Reliability of Time Source
1     Parent domain controller                              In-site                      Reliable
2     Local domain controller                                In-site                      Reliable
3     Parent domain controller                              In-site                      Not reliable
4     Local PDC emulator                                      In-site                     Not reliable
5     Parent domain controller                               Out-of-site               Reliable
6     Local domain controller                                 Out-of-site               Reliable
7     Parent domain controller                               Out-of-site               Not reliable
8     Local PDC emulator                                      Out-of-site                Not reliable

There is nothing much you need to do with *ReliableTimeSource* entry in registry. Simply edit the value and set it to 1 to make it Reliable time source for all computers in your network.

Moreover, you can also configure your PDC or Root Domain Controller to sync with hardware as a source time server but it is recommended that you configure your PDC to sync with an external time source.

How to configure an Authoritative Time server in Windows 2000:

Which DNS Server should you use ?


The DNS which ships with Windows 2000/2003 server.


1. DNS supports Dynamic registration of SRV records registered by a Active Directory server or a domain controller during promotion. With the help of SRV records client machines can find domain controllers in your network.

2. DNS supports *Secure Dynamic updates*. Unauthorized access is deniend.

3. Exchange server needs internal DNS or AD DNS to locate Global Catalog servers.

4. AD-Integrated Zone. If you have more than one domain controller (recommended) you need not worry about zone replication. AD-replication will take care of DNS zone replication also.

5. If you use DHCP with AD no other DHCP will be able to service client requests comming from different network. It’s because DHCP server is authorized in AD.

Moreover, you can use NT4 DNS with Service Pack 4 or later. It supports both SRV and Dynamic Updates.

So for BIND DNS you must be running atleast 4.9.7 version which supports SRV and meets the minimum requirements for Active Directory Support. However, BIND 8.2.1 and later support dynamic updates and incremental zone transfers, in addition to the SRV records.

Based on the tests performed by various vendors and Microsoft, the recommended BIND version that proves to work best with Active Directory is BIND 8.2.2. Keep in mind that BIND DNS servers do not support Active Directory integrated zones—-So basically this is the difference between using MS DNS and External DNS to support Active Directory. In addition to SRV and Dynmaic Support, replication is also effected if you create an AD-Integrated Zone which can replicate with Directory Replication and no overehead of planning for DNS Replication. BINDs are limited to primary and secondary zones.

So using MS DNS gives the following benefits: –

If you implement networks that require secure updates.

If you want to take benefit of Active Directory replication.

If you want to integrate DHCP with DNS for Low-level clients to register their Host records in MS DNS.

MS support for DNS is better than external DNS servers.

Many articles have been written on MS DNS+Active Directory (Troubleshooting articles)

Have a look at these articles:

Active Directory design consideration:

DNS and Active Directory:

Securing DNS by design:

Frequently asked questions about DNS

How to delegate basic server administration to Junior Admins


Here is a complete list of articles for delegating controls to admins:


You can delegate permissions to junior Admins using MMC Taskpads.

How to use Adminpak.msi to install a specific server administration tool in Windows

HOW TO: Delegate Administrative Authority in Windows 2000

HOW TO: Create and Edit a Taskpad View in a Saved MMC Console in Windows 2000

Default Security Concerns in Active Directory Delegation

Delegate Control Wizard Cannot Be Used to Remove Groups or Users

Administrative Tool Menu Is Sensitive to User’s Permissions

In a Server 2003 domain, you can ignore the part about editing dssec.dat:

How To Delegate the Unlock Account Right

A must read for Domain Administrators:

Design Considerations for Delegation of Administration in Active Directory

*Achieving Autonomy and Isolation with Forests, Domains, and Organizational Units*

Using scripts you can set delegation on properties if you want:

Part 1

Part 2

You can find security attributes for each object in Chapter -6 of *Inside Active Directory-Second Edition*
Here it is: An online version of this book.

Inter-Site Topology Generator Invalid


ISTG has invalid on all Domain Controller on the network after you demote a DC and trasfer roles and then rebuild it.

If demoted Domain Controller is the first DC in site – If yes then this DC holds the role – ISTG Server.

Initially the first server in the site becomes the ISTG owner and this this role is communicated by normal AD replication.

Moreover, this role is not changed automatically. Server holding ISTG role notifies other domain controllers about its presence by writing the *InterSiteTopologyGenerator* attribute in Configuration Naming Context at a specified interval.

Another fact is that another DC as an ISTG server doesn’t take over unless it knows that DC hold ISTG server has failed.

To correct this issue:

You can edit the following registry value to modify this behaviour:

Value Name: KCC site generator renewal interval (minutes)
Value Data: Number of minutes between updates to Active Directory

Value Name: KCC site generator fail-over (minutes)
Value Data: Time that must elapse before a new ISTG is selected, in minutes.

When it is safe to remove DNS Server (Active Directory Integrated)


Not necessarily all points only No. 2 applies to Primary Server.

I have posted basic guidelines for removing DNS server from the network.

Here is a list of points for your review:

You can safely remove any DNS server running in your network BUT you should not if the following conditions are true:

1. If this DNS server is authoritative for a Active Directory domain or DNS Domain Zone.

If you remove any DNS server that is authoritative for any domain zone configured in your network. It will remove the SRV records from zone and connectivity to domain controllers through DNS server.

2. If this is the primary DNS Server and you have configured rest of DNS servers on other DCs to work as secondary DNS Servers then you should not remove this DNS server. Doing so will cause replication failures. Secondary servers will be inoperable.

3. If any domain is delegated under this DNS server.

4. If this DNS server contains the SOA records for other authoritative DNS Server for zone.

5. Your clients are configured to use this DNS server. Removing this DNS server from operation will cause problems,

clients won’t be able to log on to network or find domain controllers.

The above are the basic guidelines to consider while removing a DNS server from your network.

Windows 2000/2003/XP computers may not load raoming profiles from a trusted domain.

You may face this issue. Sometimes member computers running Windows XP/2000/2003 may not load roaming profile from a trusted domain.

They should be able to log as long as the following conditions are true:

1. DNS settings are incorrect as suggested on some of your client computers.

2. Workstation service is not running on client computer.

3. Server service is not running on server.

4. Roaming Profile Share is not shared on server.

5. Permissions are not shared properly.

6. All Users and Default Users folders in Documents and Settings are missing if this is the first time user is logging on to this computer.

7. IPC$ share is missing on Client computer or Server.


You can find the exact cause by enabling the User Profile Debugging:

Enable User Profile Logging. You will know the problem.;EN-US;221833

Moving FSMO roles, DNS and DHCP from one Domain Controller to another Domain Controller machine.

Sometimes you may need to move your DNS, DHCP and AD to another machine. You can follow the steps outlined below to make this happen:

Scenario: You want to move everything on DC3.

If your DNS zone is AD-Integrated:

1. On DC3 install DNS > make it AD-Intergrated > wait for Active Directory replication or force replication from AD sites snap-in so that all DNS records and SRVs are replicated to this DNS server (DC3).

2. Next transfer FSMO Roles.

The reason why you need to transfer FSMO roles in second step is: All AD Tools, clients and Windows built-in Services that rely on FQDN will always query authoritative DNS server for this zone ( to find FSMO roles or domain controllers.

3. Finally install DHCP on DC3 > and follow the article given below to transfer DHCP database. DHCP is not an issue with DNS+ADS.

Make sure you follow the basic guidelines on DC3 for DNS Setup:

1. On DC3 for DNS server: Make sure DNS server is pointing to server IP address in TCP/IP Property so that it can register its SRV and A records.

2. Client machines must use this IP address (As a Primary DNS server) to locate domain controllers and receive Group Policy settings.

3. Configure Forwarders on DNS server to forward DNS query requests to other DNS servers such as ISP DNS Server or any other DNS server in your domain or forest. Do not put ISP DNS Server in TCP/IP Property. You need to delete root zone (“.”) to configure forwarders.

4. Make sure Dynamic or Secure Dynamic update is enabled on authoritative Zone.

5. Make sure SOA record in DNS zone is pointing to correct DNS server IP Address.

6. Issue Ipconfig /registerdns from command prompt to register A records of server in zone.

7. If there are two LAN cards make sure Internal NIC of the server is listed first in Binding Order.

Moving DHCP Database:

How to move DHCP database from one server to another:;en-us;130642

Trust Relationship between Domain and Member

When you log on to domain you may receive the following error:

 The trust relationship between this workstation and the primary domain failed.

This may happen because of the following reasons:

1. Machine account for the member computer wasn’t updated with PDC within 30 days or maximumpasswordage registry entry was set too low and that time PDC wasn’t available.

2. Member computer account is not known by domain and has lost its GUID.

This is absloutely a Netlogon Secure channel issue.

To recover from this:

1. Start Windows 2000 Server.

2. Let the login screen come up. (Do not try to get in). TCP/IP stack is loaded properly here.

3. Next use *Netdom* utility (remotely) to reset computer account for this workstation. You can do so from a member computer or PDC itself.


You can run this command remotely on a computer that interacts with desktop using PSEXEC from

Netdom utility is part of Support Tools.

Sometimes you may get above error if Netlogon service is stopped for no reason. You can start this service using MMC console from a member computer.

Copy Group Policy Settings.



You need more than one Group Policy Objects and few settings are similar and few are not but the amount of configuration is time consuming. You can avail this by copying the Group Policy settings from SYSVOL folder to destination GPO.

You will see policy contents of GPO created in SYSVOL folder in Policies sub-folder and then copy them to the newly created GPO.

This is how you do it:

A. First note down the GUID of Old GPO you want to copy:

1. Open ADUC
2. Right click on OU > Property
3. Switch to Group Policy tab
4. Click GPO > Property > note down the GUID of this GPO.

B. Next create the new GPO and find out the GUID in the same manner.

C. Follow the steps outlined below to copy contents of old GPO to new GPO you created in step B.

1. Finally goto SYSVOL\\policies\GUID of old GPO
2. Copy the contents of this GPO.
3. Next goto SYSVOL\\policies\GUID of new GPO
4. Paste the contents here or overwrite.

D. Finally make whatever changes you want to make to the copied policy.