qzaidi

qUICKLY Explained: Domain or Forest Restore - So Did U Recover Schema Master, Rid, Remaining Roles

2012-06-29T11:54:00Z

Hello and thanks for visiting my blog again.

Lately, I have been involved with discussions around recovery processes and steps for Active Directory, whether it is recovering from an accidental deletion of an object or a TOTAL meaning Forest Recovery.

While we don’t expect any company to actually have to recover their entire forest or any single domain in the forest, it is however important to understand the steps needed, in case (the chance of this happening is less likely than the chance of you not getting to an important meeting you have been planning for months). Well, either can happen… <silence>… so let’s look at Q’s (remember Star Trek and my second blog) acronym that will save the day or at least get you back up and running – time that is needed to recover the minimal services can be important so do test in a lab if concerned with how long it may take your environment to be restored from a backup. Now then,

Q’s Acronym for Forest Recovery: S D U R S M R R R

So Did U Recover Schema Master, Rid, Remaining Roles

Now your domain/forest recovery can be as simple as remembering the above statement and yes each first character of the above statement is a step that needs to be done in order to properly restore your environment. Let’s quickly see what each step is:

So - SYSVOL is ready (depends on FRS or DFSR being used)

Did - DNS Cleanup

U - Un-GC

Recover - Raise the rIDAvailablePool

Schema - Seize fSMO Roles

Master - Metadata cleanup

Rid - Reset the domain controller computer object password - twice

Remaining - Reset the krbtgt account password – twice

Roles - Reset the trust password (all and any)

Easy, isn’t it? The only thing remaining to understand is the details of each step. The steps are needed once for each domain, on the first Domain Controller that is being restored. These steps are done when you logon to the restored and only Domain Controller as a member of Domain Admins or Enterprise Admins group. Below are some links to help with each step (no point in reinventing the wheel so quickly explaining the Q’s Acronym):

Step 1: So (SYSVOL is ready):

For FRS, use Authoritative Restore from http://support.microsoft.com/kb/290762

For DFSR, use LastRestoreID and SYSVOL REG_SZ as authoritative from http://msdn.microsoft.com/en-us/library/bb891959(VS.85).aspx#lastrestoreid

Verify that SYSVOL and NETLOGON are shared before going to Step 2 (though u can, but before proceeding its best to have this DC sharing SYSVOL and NETLOGON), you can use 'net share' to check or event logs

Step 2: Did (DNS Cleanup):

Cleanup or remove DNS entries including SRV records related to all other DCs in the domain, except the one being restored

Step 3: U (Un-GC)

Un-GC the restored domain controller from AD Sites and Services. Notice: Until the DC is made a Global Catalog and is ready, you will not be a member of Enterprise Admins group. See http://technet.microsoft.com/en-us/library/cc755257.aspx

Step 4: Raise (Raise the rIDAvailablePool)

You would need to raise the value of this attribute by 100,000 for each day since the disaster (recommended value of 100,000) to prevent duplicate SIDs in the domain. Details are http://technet.microsoft.com/en-us/library/cc781218(v=WS.10).aspx#RaiseRIDPool

Step 5: Schema (Seize fSMO Roles)

Use the Seize FSMO roles section in http://support.microsoft.com/kb/255504 even if the restored domain controller was a FSMO Owner, I would seize all the roles on it (again)

Step 6: Master (Metadata Cleanup)

Note first that if the restored Domain Controller is Windows Server 2008 or above, the n you can simply delete the computer object of all other domain controllers in the domain using AD Users and Computers, checking the box that the domain controller cannot be gracefully demoted etc.

You can also use http://support.microsoft.com/kb/216498 or http://technet.microsoft.com/en-us/library/cc781218(v=WS.10).aspx#BKMK_CleanMetadata to cleanup data related to other domain controllers in the domain

Step 7: Rid (Reset the domain controller computer object password - twice)

Netdom to the rescue:

netdom resetpwd /server:<domain controller name> /userD:administrator /passwordd:*

http://technet.microsoft.com/en-us/library/cc781218(v=WS.10).aspx#BKMK_ResetComputerPassword

Step 8: Remaining (Reset the krbtgt account password – twice)

Use AD Users and Computers snap-in, enable Advance Features and right click Reset Password, or http://technet.microsoft.com/en-us/library/cc781218(v=WS.10).aspx#BKMK_ResetTrustPassword

Please take a note of ‘Changing The Krbtgt Password May Fail When A Custom Password Filter Is Installed’ at http://support.microsoft.com/kb/2549833

Step 9: Roles (Reset the trust password (all and any))

If the environment is a multi-domain forest, then use the below on the parent domain:

netdom trust <parent domain name> /domain:<child domain name> /resetOneSide /passwordT:<password> /userO:administrator /passwordO:*

and for the child domain (when restoring the first domain controller in the child domain):

netdom trust <child domain name> /domain:<parent domain name> /resetOneSide /passwordT:<password> /userO:administrator /passwordO:*

See http://technet.microsoft.com/en-us/library/cc781218(v=WS.10).aspx#BKMK_ResetTrustPassword

Once you are done with Step 9 which is needed in multi-domain forests or Step 8 in a single-domain forest, do enable Global Catalog on the Domain Controller. Also, as a best practice, reset the Administrator Password and other important account passwords as well as DSRM Admin Password. Once your first domain controller is up, it is also recommended to take a backup of this DC. Further domain controllers can then be promoted using DCPROMO. Hope this has been a good qUICKLY Recovery of your Domain / Forest. Till next time, :)

qUICKLY Explained: Migrate Your SYSVOL Replication from FRS to DFSR

2012-01-16T10:46:00Z

Hello there, long time since I updated my blog, you can blame all my customers that have been asking for Upgrade and all the things related to it, hehe, no please don’t. Today, I’d like to quickly explain a proper step by step process to migrate your domain SYSVOL from File Replication Service (FRS) to Distributed File System Replication (DFSR). To learn about the benefits and advantages of using DFSR, please see http://technet.microsoft.com/en-us/library/cc794837(WS.10).aspx

There are different stages of SYSVOL migration and each stage has a purpose, the whole idea behind these stages is to create a roadmap where you can decide to move forward or to return back to FRS if something unforeseeable happens. We all know how important SYSVOL is, that is, it contains your entire domain Policies (GPTs) as well as Scripts. Not going into detail of SYSVOL, let’s just look at these stages, also called Stable States, and look at what happens at each state. Remember the last stage is where you cannot reverse from.

There are 4 Stable States of SYSVOL migration to DFSR, though there are total of 9 but we will focus on these Stable States and understand each one separately. I will list the commands as well as the process that happens when you run these commands. We will also see how to check if domain controllers have successfully arrived at a particular state. Also, we will look at Active Directory objects i.e. changes in Active Directory, some DFS parameters, as well as file system changes related to SYSVOL. The 4 Stable States are (drum roll please)….

State 0: Start
State 1: Prepared
State 2: Redirected
State 3: Eliminated

Commands we will use are:

DFSRMIG.EXE (tool to migrate my domain SYSVOL to DFSR)
Repadmin (look at object/attribute changes as well as synchronizing these changes to all domain controllers in my domain)
DFSRDIAG (tool to poll these changes from Active Directory, otherswise by default DFS changes are polled once an hour – and this being qUICKLY blog, you get the idea)

So, first, what are the requirements before we take our first step to this beautiful replication engine, well, the requirements are:

Your Active Directory must be in a healthy state i.e. no issues regarding Active Directory replication between all domain controllers
Your SYSVOL must be healthy as well i.e. no Journal Wraps on any domain controllers and healthy replication of SYSVOL
Your Domain Functional Level (DFL) must be set to Windows Server 2008 or higher i.e. no Windows Server 2003 or older domain controllers
It is preferred to do the migration on PDC Emulator as it is the authority on SYSVOL, though any domain controller in your domain could be used which will attempt to contact PDCe every time and replication will take care of all the steps.
Each domain in your environment would need the same steps to migrate to DFSR. SYSVOL is domain based and hence all the above requirements apply to each domain that you plan to migrate to DFSR

Right then, let’s look at the 4 Stable States in a bit more detail, quickly:

State 0: START

The value of CN=msDFSR-Flags,CN=DFSR-GlobalSettings,CN=SYSTEM,DC=DomainName is 0
Instruct all domain controllers to create necessary DFSR objects, in registry, in Active Directory under SYSTEM container

State 1: PREPARED

Set the value of CN= msDFSR-Flags,CN=DFSR-GlobalSettings,CN=SYSTEM,DC=DomainName to 16
Instruct all domain controllers to copy the current SYSVOL location to another folder called SYSVOL_DFSR in the same parent folder

State 2: REDIRECTED

Set the value of CN= msDFSR-Flags,CN=DFSR-GlobalSettings,CN=SYSTEM,DC=DomainName to 32
Instruct all domain controllers to change the share SYSVOL to point to this new folder SYSVOL_DFSR. Take another copy of SYSVOL before sharing this folder (just in case, there was a modification in SYSVOL between Step 1 and Step 2)

State 3: ELIMINATED (irreversible step aka no going back)

Set the value of CN= msDFSR-Flags,CN=DFSR-GlobalSettings,CN=SYSTEM,DC=DomainName to 48
Instruct all domain controllers to delete SYSVOL folder, stop FRS service and use DFSR to replicate the share SYSVOL which is now pointing to SYSVOL_DFSR.

As I mentioned above in State 3 that it is irreversible meaning no going back, however if you were at State 2, you could initiate command to State 1 or State 0 and the appropriate steps would be taken by every domain controller to undo what was done as part of this migration process.

Before I can say ‘we are done’, let me share some more details and the commands for each step, as well as how to speed things up (not necessarily recommended, but if you know what you are doing, then you create your own recommendations J), why you ask, well since we are making changes to DFSR in the database, the content is polled once an hour by the service but we can manually poll these updates from AD. For migration of your SYSVOL replication to DFSR, below is all you need !!!

Requirements:

First, let’s make sure our DFL is atleast Windows Server 2008.

Open DSA.MSC and check it manually by right clicking on the Active Directory Users and Computers and selecting Raise Domain Functional Level
Invoke Active Directory Module for Windows PowerShell as an administrator, and run Get-ADDomain, check the Domain Mode

Now, we can migrate (assuming AD and SYSVOL replication is healthy already). My environment is a single domain forest called Contoso.com with two domain controllers ContosoDC1 and ContosoDC2.

State 0: START

1. Open a Command Prompt as an Administrator and type the command ‘dfsrmig /CreateGlobalObjects’

2. Notice the creation of DFSR-GlobalSettings container in System container

3. We can now poll AD for the changes we just made on both ContosoDC1 and ContosoDC2

4. Check the migration state of all domain controllers by ‘dfsrmig /GetMigrationState’

State 1: PREPARED

5. Moving to the next state, by typing ‘dfsrmig /SetGlobalState 1’

6. To speed things up, we can replicate just the object where these changes are being made by using the command ‘repadmin /resplsingleobj * contosodc1 “CN=DFSR-GlobalSettings,CN=System,DC=Contoso,DC=Com”

7. Let’s verify the value for msDFSR-Flags, 16 is Prepared

8. We can again, poll AD for the changes we just made on both ContosoDC1 and ContosoDC2

9. Let’s replicate inbound from our domain controller ContosoDC1

10. Check the migration state of all domain controllers by ‘dfsrmig /GetMigrationState’

11. Notice the copy of SYSVOL folder into SYSVOL_DFSR in C:\Windows or wherever the SYSVOL is placed.

12. Check that the current shared folder still points to C:\Windows\SYSVOL\Sysvol

State 2: REDIRECTED

13. Move to Redirected state by typing ‘dfsrmig /SetGlobalState 2’

14. This time the share SYSVOL is pointing to the copied one i.e. C:\Windows\SYSVOL_DFSR\Sysvol

State 3: ELIMINATED (irreversible step aka no going back)

15. Finally, we can get to Eliminated state by typing ‘dfsrmig /SetGlobalState 3’. Notice the message.

16. Note that the previous SYSVOL is deleted.

Welcome to wonderful world of DFSR J

qUICKLY Explained: What are Abandoned Objects and How to Remove them?

2011-04-01T12:42:00Z

Hello everyone, been a while since I did a qUICKLY Blog, all I can say is I was extremely busy with Active Directory and customers who use it :), which is almost every company in the world. so today I am writing about something new which you may not be aware of. This blog is not about all the advantages (there are a lot) for Read-Only Domain Controllers, but something I came across and wanted to explain how this could happen. The topic is about Abandoned Objects.

Abandoned objects are objects in the Active Directory database (NTDS.DIT) of Read-Only Domain Controllers which are not present on the existing Writeable Domain Controllers in the domain. These objects were once created on a Writable domain controller, got replicated to Read-Only domain controller but not to any other Writable domain controllers in the domain. The originating domain controller is no longer present to replicate these objects with another Writable domain controller.

These objects on the Read-Only domain controller are called Abandoned Objects and cannot be removed as the only deletion/modification to any objects in Active Directory can be done on Writable Domain Controllers where they do not exist.

How can it happen?

Consider a situation where there are 3 Domain Controllers in the domain. The three domain controllers and their details are:

2008-RWDC1 Windows Server 2008 or R2 Writable Domain Controller

2008-RWDC2 Windows Server 2008 or R2 Writable Domain Controller

2008-RODC1 Windows Server 2008 or R2 Read-Only Domain Controller

2008-RWDC1 is down or not reachable. You create an object on 2008-RWDC2 which gets replicated to 2008-RODC1. Now before 2008-RWDC1 comes online and replicates with its partner 2008-RWDC2, something goes wrong with 2008-RWDC2 such as it crashes, cannot boot, gets demoted forcefully or formatted etc. At this point when 2008-RWDC1 comes online, you will most likely do a metadata cleanup of 2008-RWDC2 so the NTDS server references to this domain controller are removed. You may also restore the OS with Active Directory on 2008-RWDC2 from backup which may not have the object(s) that you recently created which got replicated only to 2008-RODC1. These objects will not replicate from the Read-Only domain controller to the Writable domain controller i.e. the object will not replicate from 2008-RODC1 to 2008-RWDC1.

The objects will always stay and cannot be updated/removed etc on the 2008-RODC1. If you were to create the same DN/RDN of the object on a Writable domain controller such as 2008-RWDC1 or 2008-RWDC2 (after it is recovered, re-installed etc.), these objects will cause conflict on the Read-Only domain controller 2008-RODC1 and will be renamed with CNF or have DUPLICATE value under Account tab for user accounts.

Non-Authoritative restore of 2008-RODC1 will not remove those objects either unless the backup of 2008-RODC1 does not have these objects in it. 'Database Restored from Backup' switch and a System State Backup of the Read-Only domain controller at the time these objects exist will also not work.

So, How can I remove these abandoned objects?

The only solution to remove these abandoned objects is to demote and promote the Read-Only domain controller 2008-RODC1 or to restore the backup in which these objects do not exist. However, there is no problem if these objects just stay - as in all of these cases, they are conflict objects which are renamed to include their GUID in the distinguishedName as well as sAMAccountName is set to DUPLICATE$. Ofcourse you will like to have clean and consistent information on all domain controllers, for which you will have to demote and re-promote the RODC.

qUICKLY Explained: GlobalNames Zone

2011-01-08T17:34:00Z

Welcome to another edition of qUICKLY Explained, this time we look at GlobalNames Zone or GNZ for DNS Servers running Windows Server 2008 or R2.

In the past, a lot of companies have installed in their network a name resolution service called WINS (Windows Internet Naming Service).

WINS is an old service which relies on NetBIOS over TCP / IP (NetBT). Since the introduction of Microsoft Active Directory, the name resolution has been delegated to DNS (Domain Name Services). There was a time when WINS was preferred over DNS due to it being Dynamic in nature and DNS had to be managed statically. Ages ago, DNS was also made dynamic and hence the need to have two naming resolution mechanisms does not make sense any more. Environments that still rely on non-Windows or single-label names are unfortunately forced to using WINS. Evolution of communication protocols and depletion of IPv4 addresses required us to start looking at IPV6 protocols which expand the whole IP space to accommodate virtually any number of devices. Now if there is any need for WINS in an environment, remember that it is not compatible with IPv6 and is therefore becoming obsolete.

IPV6 is included in all flavors of Windows Server 2008 and R2. Microsoft has also introduced a new type of Zone called GlobalNames or GNZ which is checked by DNS for any query before the normal DNS Zones like _msdcs.ForestName and DomainName. This new type of Zone can be used in place of WINS to provide single-label name resolution for devices that would otherwise not register their records dynamically with the normal DNS Zones. I don't mean to imply that GNZ is an abnormal zone J. GNZ is a solution where your DNS servers are now able to provide name resolution for single-label names.

In order to use this new zone, you have to do the following two steps:

1. Create the GlobalNames Zone (either via GUI or Command line), and

2. Enable support for this Zone on the DNS Server (remember, GNZ can only be used on Windows Server 2008 or R2)

1. Create the GlobalNames Zone (using the Graphical interface):

1. Open DNS - from Adminstrative Tools.

2. In the console tree, right-click the DNS-server, and then click New Zone

3. On the New Zone Wizard starts, click Next.

4. On the Zone Type page, make sure that the Primary zone and Store the Zone in Active Directory (available only if DNS-server is a writable domain controller) are checked, and then click Next.

5. Click To all DNS-servers in this forest: <ForestName>, and then click Next.

6. Select Forward Lookup Zone, and then click Next.

7. In the Name box, enter the zone GlobalNames, and then click Next. Its one word "GlobalNames" without ""

8. Select Do not allow dynamic updates and click Next.

9. Click Finish.

Create the GlobalNames Zone (using the Command line):

Open a command prompt with elevated permissions. Click Start, point to All Programs, Accessories, then right-click Command Prompt, and then click Run as administrator. At the command prompt, type the following command and press ENTER:
Dnscmd ServerName /ZoneAdd GlobalNames / DsPrimary /DP /forest

2. Enable Support for this Zone on the DNS Server:

Open the command prompt as an Administrator, and enter the following:
Dnscmd ServerName /config /Enableglobalnamessupport 1

To implement the GNZ consider the below prerequisites:

All authoritative DNS servers must be running Windows Server 2008. It is not necessary that all domain controllers are Windows Server 2008, except for those that are authoritative DNS for the domain.
The domain must not be an area formerly called GlobalNames
For the proper functioning of the GNZ, each DNS server should contain a complete and authoritative copy of the zone.

To simplify administration it is recommended to integrate GNZ with Active Directory which takes care of Replication and Security of the data.

Now simply create records in GNZ

Right click on GNZ from the context menu and select New Alias (CNAME)
Create a new alias using the name and the DNS record source
Test the system to verify proper operation.

Please look at the following technet article on Deploying a GlobalNames Zone:

http://technet.microsoft.com/en-us/library/cc731744.aspx

Download the DNS GlobalNames Zone Deployment doc with examples here:

http://download.microsoft.com/download/e/2/0/e2090852-3b7f-40a3-9883-07a427af1560/DNS-GlobalNames-Zone-Deployment.doc

Diagram below shows how a DNS Server responds to any single label query when GNZ is used. When a Client queries the DNS Server for a single label name, if the DNS hosts a GlobalNames zone, this zone is checked first for a match, if a record exists, this is replied back to the Client. If not, then the normal FQDN zone is checked, appending the DNS Suffix.

qUICKLY Explained: Managed Service Account

2010-10-24T11:47:23Z

Hi again, q here with more of the qUICKLY explained blog and this time how about we touch on user accounts in AD for the sole and exclusive purpose of running services on member servers and other devices on the network. These accounts are used for service isolation and provide a false sense of security while running these services. A big caveat is that these accounts are set with their passwords never to expire cause if the password expires, the service can no longer run and you would have to manually update the service using the now new password. This would cause a lot of maintenance work to prevent service outages not to mention that if someone has the account and password he can use it to logon interactively or gain access to resources. You will be surprised how many companies use user objects they call service accounts with password never expires set and membership of Domain Admins group.

Windows Server 2008 R2 provides a new class of accounts called msDS-ManagedServiceAccount or simply Managed Service Account (MSA). These class of accounts have automatic password management as well as other tasks such as Service Principal Names management. You can read about SPNs in my other blog of course qUICKLY Explained. So as I was saying MSAs do not require manual updates on the password and/or SPNs registered under the account. Now you are probably wondering, wow, cool, we can create a MSA for each type of service in the environment and assign these accounts to run those services, well, not quiet, cause while the purpose of MSA is exactly that, the current limitation is these accounts can only be installed and used on a single Windows Server 2008 R2 or Windows 7 machine. However, they still provide complete hassle-free password updating and SPN registration which means you as an administrator do not need to perform any action on them.

In order to use MSAs, your Domain Functional Level must be Windows Server 2008 R2 as these accounts are domain specific just like any user/machine accounts. This requirement is only for automatic SPN management so if your environment has Windows Server 2003 or Windows Server 2008, you can still use MSA but in this case only the password of the MSA will be managed automatically and not the SPN. So to take full advantage of MSA, make sure you have the following requirements met:

Domain Functional Level = Windows Server 2008 R2
Can only be used/installed on Windows Server 2008 R2 or Windows 7
Cannot be used/installed on more than one machine - no sharing allowed
Install Active Directory Module for Windows PowerShell (RSAT component of Windows Server 2008 R2 or Windows 7)
Microsoft .Net Framework 3.51

Windows PowerShell cmdlets should be used for creating, installing, resetting password, and uninstalling MSAs. To create an MSA, use New-ADServiceAccount. To install MSA on a member machine, use Install-ADServiceAccount. Use Reset-ADServiceAccountPassword to reset the password and Remove-ADServiceAccount to delete an MSA. Of course there are a lot of switches for these cmdlets for instance you can specify the -path parameter with New-ADServiceAccount <MSA_Name> to create MSA in a specific OU. By default all MSAs are created in "Managed Service Account" container.

Managed Service Account passwords are changed when either:

1. At the time the machine account password changes, 30 days default. This is defined via GPO "Domain Member: Maximum machine account password age" under "Computer Configuration\Windows Settings\Security Settings\Local Policies\Security Options".
The default is 30 days. The minimum supported value is 1 day.

2. Reset-ADServiceAccountPassword PS cmdlet is used or command nltest/sc_change_pwd:<domain> is used.

Once an MSA is created and installed on a member computer, you can use Services.msc to specify this account to run a service. Just remember to use a $ at the end of the MSA in the properties of the service.

qUICKLY Explained: Active Directory Recycle Bin

2010-10-23T16:05:00Z

Hello everyone, "q" here, in my last blog on Authoritative Restore, one of the reader "M" suggested I do a blog on AD Recycle Bin so I figure why not :). I am sure you will find lots of information on technet and blog sites regarding what AD Recycle Bin is, what the requirements are, how to enable it etc etc. I will just do a qUICK explanation and hope I can add value with this blog.

So for me to write something about AD Recycle Bin, the two things that we must understand first are

1. Difference between Authoritative and non-Authoritative Restore of AD
2. Tombstone Lifetime (TSL) - duration that allows all domain controllers to have the knowledge of an object getting deleted.

In the past (before 2008 R2 FFL and enabling AD Recycle Bin), there were two methods of recovering deleted objects in AD.

Microsoft supported method of Authoritative Restore which required restoring AD database on a Domain Controller using a backup which contained the objects with the attributes you wanted to recover AND marking this object as authoritative using NTDSUTIL. (http://support.microsoft.com/kb/840001)
Tombstone reanimation using LDP and changing the two attributes of deleted object i.e. isDeleted and distinguishedName (http://go.microsoft.com/fwlink/?LinkID=125452)

I am not going into the details of the above two methods as I am sure this is common knowledge by now. In terms of being able to recover objects from accidental or even intentional deletions in AD, Microsoft has provided a new feature called AD Recycle Bin. AD Recycle Bin requires that your AD environment is at Windows Server 2008 R2 Forest Functional Level and then you enable this feature (disabled by default) either by Enable-ADOptionalFeature PowerShell cmdlet or LDP.

Before you enable AD Recycle Bin, it's always good to know the gotchas. For example, once you enable AD Recycle Bin, you cannot disable it and after you enable it, your NTDS.DIT (AD Database) will grow by 10-20% on every Domain Controller in the forest. But another point to remember is that NTDS.DIT size may continue to grow as you delete objects. Why you ask? Simply because unlike before where all the attributes would be stripped except ObjectSID, lastknownparent, distinguishedName (DN) would be mangled and the object getting moved to the hidden Deleted Objects container, now the object becomes logically deleted which means the object is moved to the Deleted Objects container with its DN mangled only. A deleted object remains in the Deleted Objects container in this logically deleted state throughout the duration of the deleted object lifetime. These objects can be viewed in LDP by enabling the Return recycled objects Control.

Deleted object lifetime is determined by the value of the msDS-deletedObjectLifetime attribute. Tombstone lifetime is determined by the value of the tombstoneLifetime attribute. By default, msDS-deletedObjectLifetime attribute is set to null. When msDS-deletedObjectLifetime attribute is set to null, the deleted object lifetime is set to the value of the tombstone lifetime which in Windows Server 2003 and above is 180 days.

Hence, with AD Recycle Bin, you have 6 months to recover a deleted object with all its attributes as they were at the time of deletion, this is a huge advantage and benefit as you no longer need to find a valid, tested, recent backup of AD that has all the properties of an object at the time of deletion. For example, I have a user account that was added to a group and then deleted, the only backup I have is from last night which does not have this latest change of group membership so if I were to restore the user from my backup, it will not be a member of this group. AD Recycle Bin helps in this and you can all agree that this is absolutely a better solution of ensuring all properties are recovered which were present at the time of deletion. So AD Recycle Bin is a must have for Windows Server 2008 R2 FFL environments.

There are two attributes that need to be covered quickly in order to understand deletion of objects with AD Recycle Bin enabled. These attributes are:

IsDeleted
IsRecycled

When an object is deleted, the IsDeleted attribute is set to TRUE. Within the duration of msDS-deletedObjectLifetime, an object can be recovered and become a live object again. After this value expires, most of the attributes of the deleted object are stripped away similar to a deletion prior to AD Recycle Bin and also at this time IsRecycled attribute gets set to TRUE also. AD Recycle bin can only be used to recover a deleted object only when isDeleted = TRUE and isRecycled = False; this state of an object is called a Recycled Object (new state in Windows Server 200 R2). When both of these attributes are TRUE, the object is referred to as a Deleted Object. From this point on you cannot use AD Recycle Bin and to recover it now, you will have to use Authoritative Restore procedure of a backup before IsRecycled was set to TRUE. This Recycled Object stays in Deleted Objects container for the duration of Tombstone Lifetime (180 days by default) and when this duration expires, a process called Garbage Collection (runs every 12 hours by default) physically deletes it from the AD database.

Hope this qUICK explanation helps M, Cheers :)

qUICKLY Explained: Service Principal Name: Registration, Duplication

2010-10-12T15:29:00Z

Hello, its "q" again and ready to write something quickly regarding Service Principal Names (SPN).

Service Principal Names are registered by services in order for clients to identify them in a domain. Before a client can connect to a service, it must compose the SPN for that instance of service, connect to the service, and finally present the SPN for authentication via Kerberos. The client specifies the components of the SPN using known data or data retrieved from sources other than the service itself.

Each instance of a service registers its own unique SPN. There can be multiple unique SPNs for a given service used for authentication by the clients. The format of the SPN is that it includes the hostname of the computer where the service is running, the service class, and the port number:

<service class>/<host>:<port>/<service name>

e.g. MSSQLSvc/MySQLServer1.MyDomain.com:1433

The SPN syntax has four elements: two required elements and two additional elements. In this form, "<service class>" and "<host>" are required. "<port>" and "<service name>" are optional

e.g. MyService/host1.contoso.com/CN=Server1,OU=Servers,DC=Contoso,DC=com

MyService/host2.contoso.com/CN=Server2,OU=Servers,DC=Contoso,DC=com

Or using NetBIOS

MyService/host1/CN=Server1,OU=Servers,DC=Contoso,DC=com

MyService/host2/CN=Server2,OU=Servers,DC=Contoso,DC=com

For more information about SPN format, see Name Formats for Unique SPNs.

So how do these SPNs get registered? and how can I easily find them for a particular object in AD? SPNs must be registered on an object the service instance uses to run. For Win32 services, a service installer specifies the logon account when an instance of the service is installed. The installer then composes the SPNs and writes them as a property of the account object in Active Directory Domain Services called servicePrincipalName. If the logon account of a service instance changes, the SPNs must be re-registered under the new account. For more information on this, see How a Service Registers its SPNs.

An SPN must be unique in the forest in which it is registered. If it is not unique, authentication can and will fail for clients accessing this service as there are more than one instances registered with the same SPN. It is similar to having two hosts registered with the same IP, though this causes conflict on the network, duplicate SPNs will cause Kerberos/authentication issues.

Below table summarizes each element of the SPN.

Element	Description
"<service class>"	A string that identifies the general class of service; for example, "SqlServer". There are well-known service class names, such as "www" for a Web service or "ldap" for a directory service. In general, this can be any string that is unique to the service class. Be aware that the SPN syntax uses a forward slash (/) to separate elements, so this character cannot appear in a service class name.
"<host>"	The name of the computer on which the service is running. This can be a fully-qualified DNS name or a NetBIOS name. Be aware that NetBIOS names are not guaranteed to be unique in a forest, so an SPN that contains a NetBIOS name may not be unique.
"<port>"	An optional port number to differentiate between multiple instances of the same service class on a single host computer. Omit this component if the service uses the default port for its service class.
"<service name>"	An optional name used in the SPNs of a replicable service to identify the data or services provided by the service or the domain served by the service. This component can have one of the following formats: The distinguished name or objectGUID of an object in Active Directory Domain Services, such as a service connection point (SCP). The DNS name of the domain for a service that provides a specified service for a domain as a whole. The DNS name of an SRV or MX record.

Be aware that if the DNS name of a computer changes, the system updates the "<host>" element for all registered SPNs for that host in the forest.

For duplicate SPN events, look for Event ID 11 in the System Logs- Duplicate SPN, on domain controllers that say:

Event Type: Error
Event Source: KDC
Event Category: None
Event ID: 11
Date: 4/1/2002
Time: 1:40:14 PM
User: N/A
Computer: ComputerName
Description: There are multiple accounts with name host/mycomputer.mydomain.com of type 10.

For this, steps mentioned in the KB http://support.microsoft.com/kb/321044 can be used to remove any duplicates; I prefer the LDP method or even using ADSIEDIT.MSC assuming you know where the duplicate SPN is, so you can remove it from the ServicePrincipalName attribute of the account registering this SPN. But now that most of us should be running Windows Server 2008 or R2, there is an easier way to find these duplicate SPNs using SETSPN in 2008 / R2.

While SETSPN was part of Resource Kit in Windows 2000 / 2003, it is now part of the Windows Server 2008 / R2 OS and the new switches are:

Modifiers:
-F = perform the duplicate checking on forestwide level
-P = do not show progress (useful for redirecting output to file)

Switches:
-R = reset HOST ServicePrincipalName
Usage:   setspn -R computername
-A = add arbitrary SPN
Usage:   setspn -A SPN computername
-S = add arbitrary SPN after verifying no duplicates exist
Usage:   setspn -S SPN computername
-D = delete arbitrary SPN
Usage:   setspn -D SPN computername
-L = list registered SPNs
Usage:   setspn [-L] computername
-Q = query for existence of SPN
Usage:   setspn -Q SPN
-X = search for duplicate SPNs
Usage:   setspn -X

-X will allow you to find duplicate SPNs making troubleshooting easier for us.

qUICKLY Explained: Active Directory Authoritative Restore

2010-10-07T15:41:00Z

Hi, it's q again. This time I'd like to open the discussion on Active Directory (AD) Authoritative Restore. What is it, when do we need it, and how? So without further ado, let's try to answer the three questions.

What is an AD Authoritative Restore? As the name suggests, it is the process of restoring active directory or System State data of a domain controller to a previous state. I am sure you have lots of questions and comments on this, and we will cover some of them.

When do we need it? There can be a number of reasons for restoring AD authoritatively, one of the most common reasons are the woops, someone accidentally deletes an object. There have been cases when a rogue administrator intentionally deletes an important person's user account, we will not go there, hehe. We can always recreate the object but it's not the same object, even though we can populate the object with exact same properties and values as the deleted object had. However, the GUID and SID will never be the same, which are system controlled. For instance, if someone accidentally *wink* deletes a user object, I as an administrator in the domain or OU, can create a new user object with same information, membership of same groups, password etc., but the minute this user logs on to his machine, he will notice that something is different, his profile will not be the same, because his SID is not. All security principals get a unique SID value based on the domain SID and RID at the time of creation and unless they are moved to another domain, this value stays the same. When deleted, the SID is one of the few attributes which are kept. A lot more to discuss here... but again this is qUICK explanation. J

How do we restore an object authoritatively? Well, you have to have a valid, tested, and recent backup of AD data, also part of System State Backup (SSB). You can boot into AD Directory Service Repair Mode (DSRM) and restore using NTBACKUP or Windows Server Backup and marking the object as authoritative via NTDSUTIL. All the steps you need are in this KB here http://support.microsoft.com/kb/840001

The one thing I'd like to cover here qUICKLY is that an authoritative restore is simply a merge. Let's take an example of a user account who has the following information

displayName = "Test User", department = "Engineering", Title = "ESDE", Mobile = "8675309"

and you take a SSB of AD. Now someone makes the following modifications

department = "ENGG", and adds description = "qUICK Learner"

You can see that department information was changed and description was added, which did not have a value when we took the SSB. After restoring AD using this SSB, marking this user "Test User" as Authoritative (learn all about it from the above mentioned KB), what do we get. You guessed it:

displayName = "Test User", department = "Engineering", Title = "ESDE", Mobile = "8675309", description = "qUICK Learner"

Notice that department has the value from SSB and description is current. This is because of Version numbers on each and every attribute of an object and when an object is marked authoritative, its defined attributes' Versions are incremented by 100,000 for every day since the SSB to your current date, making sure this value is the most up to date. My personal favorite tip to see how this happens - check the meta of the user before and after doing Auth restore via LDP or Repadmin /Showobjmeta.

The whole game changes with AD Recycle Bin - new in Windows Server 2008 R2 FFL.

qUICKLY Explained: DNS SRV Records, Purpose and Functionality

2010-10-07T15:37:00Z

Hello everyone, "q" here, now you are wondering what is this q or who it is? Well a dear friend of mine and manager back at Chrysler WHQ (2000-2008) used to call me Q cause though my name starts with Q (Qasim) but the U after Q is MIA, plus I always liked it when he called me q, sorta like the "q" in Star Wars Trek (many thanx B.) who has control of time and mass and everything else. So from now on, I will use q to quickly write my blogJ. Today, we will quickly cover DNS SRV records, why you ask. Well, when I visit customers (region specific), I notice that there is often no clear understanding of what the SRV resource records are, who creates it, why and when they are needed and above all which ones are they. So, today, we will learn about DNS SRV records briefly aka quickly.

We all know that DNS provides hostname resolution and that this service is critical to Active Directory. It allows domain controllers as well as domain members to locate services in the domain. One of those services is Client / User authentication; and as we all know - Active Directory is a distributed database, one domain controller needs to find another in order to replicate the changes it makes to its local copy of AD Database (NTDS.DIT). DNS provides specific types of records for such services; these records are called SRV or Service Resource Records. SRV records map the name of a service to the server offering this service. Clients and domain controllers use these SRV records to find the IP addresses of authenticating domain controllers and replicating partners. I don't need to remind you that a DNS Server must allow dynamic updates to the zone where SRV records are to be created by domain controllers in a domain. DNS maintains zones and these zones allow Secure dynamic updates by default. If a DNS Server does not or is configured to NOT allow any dynamic updates, these SRV records will not be registered by domain controllers automatically. We will discuss this some other time.

Once you promote a server to a domain controller using DCPROMO, a text file containing all the appropriate records the domain controller will register in DNS gets created. This text file is in the %systemroot%\system32\config and is called NETLOGON.DNS. Whenever a domain controller starts, the NETLOGON service registers these records or refreshes these records in the primary zone held by the DNS. This way, you will always have the SRV records registered dynamically with the DNS Server. There are other means to do the same, for instance, you can stop and start the NETLOGON service manually or nltest /dsregdns etc.

So now, let's see what these records are and their function.

_ldap._tcp.<DNSDomainName> - Allows a client to locate a domain controller in the domain named by <DNSDomainName>. A client searching for a domain controller in the domain contoso.com would query the DNS server for _ldap._tcp.contoso.com
_ldap._tcp.<SiteName>._sites.<DNSDomainName> - Allows a client to find a domain controller in the domain and site specified (e.g., _ldap._tcp.lab._sites.contoso.com for a domain controller in the Lab site of contoso.com).
_ldap._tcp.pdc._ms-dcs.<DNSDomainName> - Allows a client to find the PDC emulator (FSMO) role holder of a domain. Only the PDC of the domain registers this record.
_ldap._tcp.gc._msdcs.<DNSForestName> - Allows a client to find a Global Catalog (GC) server. Only domain controllers serving as GC servers for the forest will register this name. If a server ceases to be a GC server, the server will deregister this record.
_ldap._tcp. ._sites.gc._msdcs.<DNSForestName> - Allows a client to find a GC server in the specified site (e.g., _ldap._tcp.lab._sites.gc._msdcs.contoso.com).
_ldap._tcp.<DomainGuid>.domains._msdcs.<DNSForestName> - Allows a client to find a domain controller in a domain based on the domain controller's globally unique ID. A GUID is a 128-bit (8 byte) number that generates automatically for referencing Active Directory objects.
<DNSDomainName> - Enables a client to find a domain controller through a normal Host record.

You can also use the NETLOGON.DNS file to import the records to non-Microsoft DNS Servers that support SRV records but do not allow dynamic updates. At this point we will not discuss weights, priority or port numbers for these services. Another qUICK explanation is required for that ;)

And a picture is worth a 1000 words

Cheers J

Enable Change Notifications between Sites – How and Why?

2010-09-23T13:33:00Z

Hello all, hope you guys are doing great. Today, I wanted to write a little about Change Notification, why you ask? Simply because one of my customer had a number of questions on what it is, why it’s there and what can be done to enable it for site links.

So, l will try to answer the 3 questions here.

First, what is Change Notification? Change Notification is the interval between an originating update on a domain controller and notification of this change to its partners. When this interval elapses, the domain controller initiates a notification to each intra-site replication partner that it has changes that need to be propagated. Another configurable parameter determines the number of seconds to pause between notifications to other partners if any. This parameter prevents simultaneous replies by the replication partners.

There are two values for the interval – one for the first partner, and other for the subsequent partners. When a change is made on a Domain Controller’s Active Directory database, before the change is replicated, the DC waits for a specific period of time before sending the Change Notification to its first partner, and then waits for another period of time before sending the Change Notification to another partner, this process continues until all partners are notified.

For intra-site replication partners, a DC waits 15 seconds (300 in W2K) before notifying its first replication partner and then another 3 seconds (30 in W2K) before sending this change notification to subsequent partners. These intervals can be modified by the below DWORD values in the registry key:

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\NTDS\Parameters

Replicator notify pause after modify (secs)

and

Replicator notify pause between DSAs (secs)

These DWORD values control how long to wait before sending the Change Notification after a modify operation on a Domain Controller to its first partner and then all subsequent partners in the same site. But what about my Domain Controllers in other sites?. We know that replication honors Replication Intervals set on the Site Link between two sites and the minimum interval that can be set via the AD Sites and Services snapin is 15 minutes. What if your environment can afford to enable these change notifications between your sites or specific sites because you have a large amount of bandwidth. For this you can enable Change Notifications between sites as well. To do this:

1. Open ADSIEdit.msc.

2. In ADSI Edit, expand the Configuration container.

3. Expand Sites, navigate to the Inter-Site Transports container, and select CN=IP.
Note: You cannot enable change notification for SMTP links.

4. Right-click the site link object for the sites where you want to enable change notification, e.g CN=DEFAULTSITELINK, click Properties.

5. In the Attribute Editor tab, double click on options.

a. If the Value(s) box shows <not set>, type 1

b. If the Value(s) box contains a value, you must derive the new value by using a Boolean BITWISE-OR calculation on the old value, as follows: old_value BITWISE-OR 1. For example, if the value in the Value(s) box is 2, calculate 0010 OR 0001 to equal 0011. Type the integer value of the result in the Edit Attribute box; for this example, the value is 3.

6. Click OK.

See PowerShell Script to Enable Change Notification @ http://gallery.technet.microsoft.com/scriptcenter/61cb88bb-8c61-477f-834e-79ed0c153669

or VBScript to Enable Change Notification for Site Links @ http://gallery.technet.microsoft.com/scriptcenter/390b54d2-cd49-4f46-92e0-c22ff6f25f1c

With Change Notification enabled between sites, changes propagate to the remote site with the same frequency that they are propagated within a site. The advantage of enabling Change Notification between sites are little to no conflicts. As a matter of fact, I have yet to see a Conflict object (will discuss some other time) between DCs in different sites if Change Notification is enabled between those sites. Plus if there are a lot of changes being made, these changes will not be queued up as they will be replicated with the same frequency as the domain controllers in the DC’s own site. What about disadvantage? Is there one? Well sure, it’s a possible and potential replication storm as all the domain controllers are part of the Change Notification intervals.

But what about compression? Replication within a site for AD is not compressed, while in remote sites, replication data is always compressed to take advantage of the low speed links and intervals set between them. So if you are one of those environments that are enjoying the fruits of enabling Change Notification between sites and would like to replicate data uncompressed vs. compressed, then here is another tip.

The value of Options attribute that we modified above, if the value is 1, then Change Notification is enabled with compression; and if you change the value to 5, then Change Notification is enabled without compression, hurrah J

Override the hardcoded LDAP Query limits introduced in Windows Server 2008 and Windows Server 2008 R2

2010-09-01T23:02:00Z

Hello Everyone:

This is Qasim Zaidi. First of all, welcome to my blog site.

Next, I am writing this blog (thanks to a colleague) since some of my customers are running into LDAP limitations which are now hardcoded in Windows Server 2008 and Windows Server 2008 R2. Though, ideally we would like to modify the paged queries but depending on the number of applications a customer might have, they might require months or even years to revamp their whole application coding strategy while in the meantime, they would also be upgrading their existing servers and domain controllers to Windows Server 2008 R2. So let's first see what we are talking about here...

According to http://support.microsoft.com/kb/2009267 titled Windows Server 2008 R2 or Windows Server 2008 domain controller returns only 5000 attributes in a LDAP response:

“An LDAP application may return less information when a query is sent to a Windows Server 2008 or Windows Server 2008 R2 domain controller than when sent to a Windows Server 2003 domain controller. The query results may appear truncated or incomplete. In some occasions you may not get any results.

If, for example, a LDAP application queries the members of a group, the Windows Server 2008 R2 or Windows Server 2008 domain controller only returns 5000 members, while the Windows Server 2003 domain controllers returns many more members…."

and

"… Hardcoded LDAP limitations have been introduced in Windows Server 2008 R2 and Windows Server 2008 to prevent overloading the domain controller”

What this means is that Windows Server 2008 R2 or Windows Server 2008 dictates MaxPageSize of 20,000 and MaxValRange of 5,000 therefore the maximum number of attributes a query can return is 5,000.

CAUTION: The below should be tested first for any impact on performance as stated in the above KB, and it is also recommended to use Paged Queries (RFC 2969), a standard which was introduced ~10 years ago.

To override the upper-limits introduced in Windows Server 2008/R2 and restore the old-style (no upper limit enforced behavior for LDAP Query Policy in Windows Server 2003), modify the dSHeuristic attribute in Active Directory. To do this, follow these steps:

1. Start ADSI Edit. To do this, open a command prompt in the Support Tools folder, type ADSIEDIT.MSC, press Enter

2. Right-click CN=Directory Service in the following location, and then click Properties: CN=Directory Service,CN=Windows NT,CN=Services,CN=Configuration,DC=forest root

3. Click the Attribute Editor tab, and then locate dSHeuristic in the Attributes list.
Note By default, the value of this attribute is not set.

4. Click dSHeuristic, and then click Edit.

5. Type 000000000100000001 in the Value box, and then click OK. See Note below.

6. Restart the Active Directory Domain Service (NTDS) or the domain controller.

Note If a value has already been set for this attribute, incorporate the existing settings into the new value. When you do this, note the following:

· The tenth character from the left must be 1. Twentieth bit must be 2, and so on.

· The eighteenth character from the left must be 1.

· None of the other characters of the existing value should be changed. For instance, if the existing value is 0000002 then the new value should be 000000200100000001

Microsoft Warning If you use the ADSI Edit snap-in, the LDP utility, or any other LDAP client, and you incorrectly modify the attributes of Active Directory objects, you can cause serious problems. These problems may require you to reinstall Microsoft Windows Server OS, Microsoft Exchange, or both Windows and Exchange. Microsoft cannot guarantee that problems that occur if you incorrectly modify Active Directory object attributes can be solved. Modify these attributes at your own risk. For more, please see below

Windows Server 2008 R2 or Windows Server 2008 domain controller returns only 5000 attributes in a LDAP response http://support.microsoft.com/kb/2009267

Change the LDAP Policy using NTDSUTIL, please follow http://support.microsoft.com/kb/315071

Please also see fLDAPBypassUpperBoundsOnLimits (2 bytes): dSHueristic Attribue

http://msdn.microsoft.com/enus/library/ms675656(VS.85).aspx

http://msdn.microsoft.com/en-us/library/cc223560(PROT.13).aspx