Thursday, January 23, 2014

Windows Server 2012 - Active Directory - Backup and Restore, Part 3: Protect from accidental deletion

I wanted to test some 3rd party software to demonstrate what would perhaps be a "step up" even from the native Windows Server (2012) Recycle Bin. Unfortunately, it was not as simple as downloading the trial copy and taking a look. At present, I am still working to obtain such a trial copy with one company. If this is not possible, I'll either try another company or simply "move on" to something else.

In the meantime, I want to look at an option that could have been, perhaps, the first blog post of my "Backup and Restore" series even though it involves neither a backup nor a restore.
I'm referring to the protection of Active Directory objects from accidental deletion:
In the lines that follow, I'll present the feature and then some Powershell cmdlets to find protected (or unprotected) objects and adjust their status as necessary.

Objects in Active Directory can be protected from accidental deletion by displaying the advanced properties of an object, selecting the Object tab and checking the "Protect object against accidental deletion" box.
We can view the "Object" tab by enabling "Advanced Features"...

We then open the properties of the object, select the now visible "Object" tab and check the appropriate setting. In the example below, we protect the "ExchangeUsers" organizational unit:

This reduces the probability of someone deleting an object inadvertently.
 So... our inattentive administrator attempts to delete the object in question and sees a confirmation prompt:

Even if he ignores the warning and clicks OK, deletion of the object will fail:
So how does this work "behind the scenes"?

When we check the setting, an ACE (Access Control Entry) is added to the ACL (Access Control List) of the object. That entry is "Everyone" - Delete (and Delete-Subtree) - Deny.

In fact, if we examine the Security tab of the object, and explore the advanced properties, we see something like this: 
Here are the details:
This permission (Deny) is added when the setting is checked. Before the setting is checked, there is no entry for "Everyone" (but rather for "Authenticated users").
Without this useful setting, someone inattentive could click OK to confirm deletion.
With it enabled, that person would have to think about why they cannot delete the item, know or discover how to disable the protection, display advanced properties of the object, go to the object tab, uncheck the protect option and then attempt to delete the object again, with the confirmation giving them one last chance to reflect on what they are doing.

Managing the "Protect object from accidental deletion" setting with Powershell

We can protect various objects from deletion (not just organizational units): computers, groups and users as well. However, we may not want to protect all objects from deletion since this could complicate operations such as moving an object from one container to another (a move operation is, in fact, and copy operation followed by a deletion).
Moreover, it would not be feasible to check or uncheck this setting manually on perhaps hundreds of objects. Fortunately, PowerShell allows us to find both protected and unprotected objects and adjust the setting as desired.
Using organizational units in this example, the following cmdlets display, respectively, those protected from deletion and those that are unprotected:

PS C:\> Get-ADOrganizationalUnit -Filter * -Properties ProtectedFromAccidentalDeletion | where {$_.ProtectedFromAccidentalDeletion -eq $true} | fl name

name : ExchangeUsers
name : Staff
name : My Security Groups
name : MyTestGroups

PS C:\> Get-ADOrganizationalUnit -Filter * -Properties ProtectedFromAccidentalDeletion | where {$_.ProtectedFromAccidentalDeletion -eq $false} | fl name

name : Microsoft Exchange Security Groups
name : Domain Controllers
name : Servers
name : Contacts
name : Clients

Now I'll verify if my domain controllers are protected from accidental deletion:

PS C:\> Get-ADComputer -SearchBase "OU=Domain Controllers,DC=mynet,dc=lan" -Filter * -Properties ProtectedFromAccidentalDeletion | where {$_.ProtectedFromAccidentalDeletion -eq $true} | fl name

PS C:\> Get-ADComputer -SearchBase "OU=Domain Controllers,DC=mynet,dc=lan" -Filter * -Properties ProtectedFromAccidentalDeletion | where {$_.ProtectedFromAccidentalDeletion -eq $false} | fl name

name : DC2
name : DC5

The cmdlet is similar to the preceding cmdlet but we use the -SearchBase parameter to target the domain controllers organizational unit. We can see that the two domain controllers are not protected from accidental deletion. How can we protect them? Well, we could check the appropriate setting as shown above. If there is only an object or two, as is the case here, that would be acceptable. However, Powershell allows us to enable the feature on a multitude of objects with this cmdlet:

PS C:\> Get-ADComputer -SearchBase "OU=Domain Controllers,DC=mynet,dc=lan" -Filter * -Properties ProtectedFromAccidentalDeletion | where {$_.ProtectedFromAccidentalDeletion -eq $false} | Set-ADObject -ProtectedFromAccidentalDeletion $true
Note the last part of the entire command, after the second pipeline:
Set-ADObject -ProtectedFromAccidentalDeletion $true
This is the part that actually enables the protection.
Note: apparently, we must use the Set-ADObject cmdlet as opposed to the Set-ADComputer cmdlet:
PS C:\> Get-ADComputer -SearchBase "OU=Domain Controllers,DC=mynet,dc=lan" -Filter * -Properties ProtectedFromAccidentalDeletion | where {$_.ProtectedFromAccidentalDeletion -eq $false} | Set-ADComputer -ProtectedFromAccidentalDeletion $true

Set-ADComputer : A parameter cannot be found that matches parameter name 'ProtectedFromAccidentalDeletion'.
In any case, the domain controllers are now protected from accidental deletion:
PS C:\> Get-ADComputer -SearchBase "OU=Domain Controllers,DC=mynet,dc=lan" -Filter * -Properties ProtectedFromAccidentalDeletion | where {$_.ProtectedFromAccidentalDeletion -eq $true} | fl name

name : DC2
name : DC5
Note: the domain controllers OU could be protected as well by this method.
We can protect various types of objects from deletion using the example above (with Set-ADObject) by simply adjusting the type of object we are seeking in the first part of the command. We could use any of these variations:




These are some other variations that could be used:

Get-ADObject -filter {(ObjectClass -eq "user")} | Set-ADObject -ProtectedFromAccidentalDeletion:$true

Get-ADOrganizationalUnit -filter * | Set-ADObject -ProtectedFromAccidentalDeletion:$true

The first cmdlet would protect all users (based on the integrated LDAP query - rather than "Get-ADUser") and the second would protect all OUs. This may or may not be suitable in your organization.



AD DS: All OUs in this domain should be protected from accidental deletion

Sunday, January 12, 2014

Windows Server 2012 - Active Directory - Backup and Restore, Part 2: Recycle Bin

In my previous blog post, I restored a number of deleted Active Directory objects (users) with an "authoritative restore".
This was a two-part operation.
I first restored the entire system state (which may seem excessive for so few objects) and secondly performed the authoritative restore with ntdsutil.
It worked.
This procedure has been the traditional response to the accidental deletion of objects in Active Directory since its inception in 2000. We used ntbackup instead of Windows Server Backup and the syntax for ntdsutil has changed. For the most part, however, the general procedure has remained the same.
Since Windows 2008 R2 we have another option: the Active Directory Recycle Bin. Unfortunately, at least for those uncomfortable with the command line, this tool relied on PowerShell cmdlets. There was no GUI. One could not simply look for deleted objects in the recycle bin, select them, and click "Restore".
Windows Server 2012 improves the Active Directory Recycle Bin with the addition of a graphical user interface. This is the version that I will explore in the following lines. It will also constitute "Part 2" in my series of blog posts dedicated to backup and restore of Active Directory objects.
Use of the improved recycle bin has these pre-requisites:
  1. At least one domain controller running Windows 2012 Server.
  2. Forest Functional Level at Windows 2008 R2.
  3. The recycle bin feature must be enabled.
In my practice environment, the first two pre-requisites have already been met: we have a Windows 2012 server and I've just raised the FFL to Windows 2008 R2.
Next, I'll enable the Recycle Bin. We can do this in the Active Directory Administrative Center by right-clicking on the domain icon and selecting the "Enable Recycle Bin" option:

A message informs us that the change is irreversible: we cannot disable the Recycle Bin once enabled:

We then must restart ADAC:

Note: if the FFL was not at Windows 2008 R2 (or above) we could not enable the Recycle Bin. The option would be grayed out:

At this point we can test the feature. As in my previous blog post where the authoritative restore option was used, I'll delete a user - and then attempt to restore it from the Recycle Bin. Here is the status quo before deletion:

So, I delete user Aisha Bhari:

On the partner domain controller (a Windows 2008 R2 server), I verify that replication has taken place and that the user has indeed been deleted:

Restoring the user is rather simple. Enabling the Recycle Bin creates a new container in ADAC: Deleted Objects. If we want to restore an object, we open this container and find the object in question:

We right-click on the object and select restore:

We have a second option as well: Restore To

This can be used if we want to restore the object to a different container, perhaps if the original container no longer exists:

The results are immediate on the Windows 2012 server and almost immediate on the Windows 2008 R2 server as well. Replication does its work and Aisha Bhari is back:

Even better (as with the authoritative restore in the previous blog post), group membership is re-established:

In my opinion at least, this is a much faster and efficient method to restore Active Directory objects, especially since the arrival of the Windows Server 2012 graphical interface.
One word of caution however: deleted objects remain in the Deleted Objects folder for the duration of the tombstone lifetime, 180 days by default (since Windows 2003 SP1 - 60 days with earlier OS versions). After that period, the object will be purged from the Deleted Objects folder.
As a side-note - or end-note - I was curious to see if a restore from the Recycle Bin would modify the USN of the restored object. So I deleted and restored another user, Alan Reid, and this time noted the USN "before and after".



Between the deletion of the object and the restoration, about 5 minutes passed. The USN increased by 20,548 versions. I noted the time because with an authoritative restore, the USN is increased by 100,000 versions per day for each day since the last change to the object. I'm not certain what the calculation is for a restoration that would take place less than an hour after deletion or even if a Recycle Bin restore follows the same specifications.

Friday, January 10, 2014

Windows Server 2012 - Active Directory - Backup and Restore, Part 1: System State


For my next serie of blog posts, I want to examine aspects of backing up and restoring Active Directory.
I've always thought that the native options for backing up Active Directory were not "efficient".
I do not mean to say that they "do not work" but rather that they require a certain "effort" to accomplish, one may argue, what should or could be a short and simple operation.
Essentially, we have to backup the "system state" which includes not only the Active Directory database, and the SYSVOL data (in substance, group policy and scripts), but also the registry, system files, and the COM+ database. If the domain controller holds other roles, the system state could include even more elements.
So if we needed to restore a single user, we would have to restore the entire system state (and then perform an "authoritative restore" - which will be presented later). All that for a single user? Well, we could simply recreate the user. However, since that user would be associated with a new SID they would not have access to the resources that they did before the deletion. So we would have to recreate their group memberships, for example. There could be a number of other relationships that would need to be re-established as well, such as Exchange mailboxes (their own and possibly access to shared mailboxes).
So, recreating the user object is not a solution as simple as it might seem. It is even less optimal when multiple users have been deleted or when an entire OU has been deleted. Manual recreation of all the deleted objects could take hours, days or weeks.
On the other hand, restoring what amounts to an entire domain controller, and an entire Active Directory database that could be hundreds of megabytes in size (or even gigabytes), could seem equally excessive. Yet until Windows 2008 R2, that was the only choice, unless administrators opted for third-party software.
In the lines (and posts) that follow, I want to examine three Active Directory restore methods.
1. System State restore. This implies a System State backup.
2. Active Directory Recycle Bin.
3. Third-party software.

System State backup and restore

The first step, quite logically, is to perform a system state backup of the domain controller.
In fact, we have the option of performing a "Full Server Backup" which includes the System State as well.
The Full Server Backup has the advantage of allowing a bare metal restore of the domain controller. We would boot from the Windows Server 2012 media and essentially restore the image of the entire server from a .VHD file (since Windows 2008, the backup file exists in that format). A simple System State backup does not allow such a restore.
In any event, both types of backups can be performed in either the GUI or at the command line.
I'm going to choose the command line option:

PS C:\> wbadmin start backup -backuptarget:E: -allcritical -systemstate -vssfull -quiet

wbadmin is the Windows Server command line tool for backups since Windows 2008.
wbadmin start backup is the basic command to start a backup (self-explanatory).
We need to designate a target for the backup. This can be a local or external hard drive or a network share. I'll use an external hard drive for this post.
The following command is the equivalent of the "Bare Metal" option in the Windows Server Backup graphical interface. In summary, it backs up all volumes necessary for the complete restoration of the server. This would be, at minimum, the C: drive and then any other drives housing elements such as the Active Directory database or logs files, if these where stored elsewhere.


I have added the following parameter after having read that without it, we could not perform a simple system state restore from a Full Server Backup.


Bare Metal backup versus -allcritical

I have not tested the command without the -systemstate parameter to confirm that the assertion is exact but I can confirm that the command works just fine with the parameter, necessary or not.

As for the last two parameters...


This configures the backup so that all files are marked as backed up and that logs of previous backups may be deleted. It should be added if Windows Backup is the only backup software in use.


This simply suppresses some of the prompts that would otherwise display.

The resulting output (edited here) should look something like this:

Retrieving volume information...
This will back up System Reserved (350.00 MB),(C:) to E:.
The backup operation to E: is starting.
Creating a shadow copy of the volumes specified for backup...
Creating a backup of volume System Reserved (350.00 MB), copied (0%).
Creating a backup of volume System Reserved (350.00 MB), copied (62%).
The backup of volume System Reserved (350.00 MB) completed successfully.
Creating a backup of volume (C:), copied (0%).
Creating a backup of volume (C:), copied (2%).
Creating a backup of volume (C:), copied (4%).
Creating a backup of volume (C:), copied (7%).

Creating a backup of volume (C:), copied (94%).
Creating a backup of volume (C:), copied (96%).
Creating a backup of volume (C:), copied (99%).
The backup of volume (C:) completed successfully.
Summary of the backup operation:

The backup operation successfully completed.
The backup of volume System Reserved (350.00 MB) completed successfully.
The backup of volume (C:) completed successfully.
Log of files successfully backed up:

Now we have a backup.

Next, I'm going to delete three users: Aisha Bhari, Alannah Shaw and Alan Reid:

Note that they are also members of the "Marketing" group. After the restore, we will want to verify that group membership was re-established:

I won't waste space by posting another screenshot, but once the users are deleted they not only disappear (as expected) on DC5 but no longer appear in ADUC on DC2 less than a minute later. So replication acts immediately.
Now we learn that those users were not supposed to be deleted! Now we are in a predicament!
What can we do?
1. Boot into "Directory Service Restore Mode"
First we have to boot into what is called "Directory Service Restore Mode" (DSRM) on the server on which we performed the backup.

Tapping the F8 key should display a boot menu but it does not - not with a Windows Server 2012 guest in VMware. There might be a trick to this and I might succeed if I tried some more but there is another option.

At the command line, we enter the following (and then restart the computer):

bcdedit /set safeboot dsrepair


Note: to return to a normal boot, once the restore operation is complete, we enter this command:

bcdedit /deletevalue safeboot

Once the server restarts and we login, the screen should look like this:

Note the words "Safe Mode" in the corners of the desktop. I only show the upper left-hand corner above, but the indication is present in all four corners. That informs us that the boot into DSRM was successful.

2. Restore the System State

The next step is to restore the system state.

I would like to point out that in this practice scenario, there can be no confusion about the backup to restore since we only have one and created it only minutes ago. Likewise, we only backed up one server. In reality, the backup media could contain not only several backups but backups of several servers. Therefore, we have to identify the backup we want with the following command:

wbadmin get versions -backuptarget:E: -machine:DC5

Among other information, this command produces an entry for:

Version Identifier: 01/01/2014-2:36

This output is important because we must indicate the backup version (even if there is only one) in the command that restores the system state:

wbadmin start systemstaterecovery -version:01/01/2014-2:36 -backuptarget:E: -machine:DC5

At this point we are all set... or so it seems. Our three user accounts have been restored - as well as the rest of Active Directory and all the other elements of the "System State".
But there is a problem. The three user accounts have been marked as deleted. These deleted accounts, though "invisible" to the administrator, still have a certain form of existence in Active Directory (for a while) and are replicated as deleted accounts to the other domain controller(s). The replication of what is called a "tomb-stoned" object is necessary so the other domain controllers are aware of the deletion and can update their copy of the Active Directory database accordingly. Now, these deleted user accounts, even though they are deleted, have a higher version number than the user accounts that were backed up earlier. The correct term for this "version number" is "USN" or "update sequence number" and it helps govern replication:

Newer versions of an object, updated on a given domain controller,  replace older versions of an object that exist on other domain controllers.
So what will happen once the domain controller reboots and begins to replicate with the other domain controller? The "invisible" deleted user account, since it has a higher "version number", or USN, will replace the newly restored (but technically older) user account.

We need to mark the restored object(s) as "authoritative" which essentially increases their USN number so it is (much) higher than that of the deleted user account (the tomb-stoned object) that continues to represent it in Active Directory.

3. Mark the restored objects as authoritative (authoritative restore)

We manage the authoritative restore at the command line using the ntdsutil tool. We'll start by restoring the user Alan Reid, entering the commands as follows:

ntdsutil: activate instance ntds
Active Instance set to "NTDS".
ntdsutil: authoritative restore
authoritative restore: restore object "cn=Alan Reid,ou=ExchangeUsers,dc=mynet,dc=lan"

 When prompted for confirmation, I select "Yes":


I repeat the process for the other users.

The restore is successful. Once again, the users appear as they do in the screenshots above. What's more, the group membership is re-established as well. This was always a complex element in the restore process since membership in a group is not a property of the user, but rather of the group, and something known as the "back link" had to be restored, possibly in a second authoritative restore. Since group membership is restored here, at least in this rather simple scenario - single domain, single site, I'm led to believe that a Windows 2012 authoritative restore is able to process this element successfully.

The restore can be even more complex. If we had deleted the entire ExchangeUsers OU we could attempt to restore it with the "restore subtree" command in ntdsutil (instead of a single "object"):

authoritative restore: restore subtree "ou=ExchangeUsers,dc=mynet,dc=lan"


So the restore is successful but some might perceive it as cumbersome. In my next blog post, I'll examine the "Active Directory Recycle Bin" option, first introduced with Windows 2008 R2 and improved in Windows 2012 Server, notably by the addition of a graphical user interface.


Recovering Active Directory Domain Services

This article is about Windows 2008 R2 but the underlying principles still apply to Windows Server 2012. The article explains how group membership is re-established automatically since Windows 2003, at least in certain circumstances.

Thursday, January 9, 2014

WINS - special blog post

Having blogged most recently about Office 365, Windows 2012 and IPv6, I did not foresee the publication of a blog post about WINS.
Here's the situation.
In an environment where WINS has been retained for various reasons, it was discovered that the [1Ch] Domain Controller records (one on each WINS server) contain references to other domain controllers that were retired years ago.
This is not an original or never-before-seen problem. It has been related in various forums and the solution is apparently to delete the record and then recreate it. I was asked to verify that the methods that supposedly recreate the record actually function as advertised.
First, here are some references to the problem:

WINS 1C record problem (Experts Exchange)

Stale WINS 1C IP Address Entries (Microsoft Technet)

Invalid WINS records accross Four 2008R2 Domain Controllers (Microsoft Technet)

Second, after deletion of the record, here are the methods that would apparently recreate it:

1. Restart the netlogon service: "net stop netlogon" and then "net start netlogon"
2. Execute the "nbtstat -RR" command
3. Restart the WINS service

The first two are suggested in the articles cited above, the third is my idea.

Note: my domain controller (a virtual machine) is running Windows 2008 R2.

Once again, but now with illustrations, this is the problem.

In the "Active Registrations" folder of the WINS server, we have a [1Ch] record (domain controller) that contains references to other domain controllers long since retired. No, you do not see them in this screenshot:

In fact, we have to open the properties of the highlighted record to see where these references exist:

Even now, we only see one reference to a domain controller since this is our test environment and not the production environment where we are trying to clean the WINS database. In the production database, there are about 5 records that need to be purged. The screenshot may not show this, but the reader should understand that there are no means by which the record can be edited manually.
So the first step is to delete the [1Ch] domain controller record... or rather the second step, since it would be a good idea to backup the WINS database... just in case.
So... once the WINS database backup is finished, we can delete the record in question:

Since I only have one WINS server, I'll simply delete the record on the local server:

This screenshot proves the record has been deleted:

The question is: can we recreate the record?

I first attempted to recreate the record by stopping and then starting the netlogon service. This failed. Despite waiting a minute or two, refreshing the screen, opening and closing the WINS console, the [1Ch] Domain Controller record would not reappear. I did not take a separate screenshot since it would only be identical to the one above, in which the [1Ch] record is absent.
I then tried the nbtstat -RR command. The [1Ch] record re-appeared almost instantly. At most, I needed to refresh the screen.
I deleted the record once more and attempted to recreate it by stopping and starting the netlogon service. The results were consistent. This failed but the nbtstat -RR command recreated it successfully.

Restarting the WINS service also recreated the records.

In conclusion, it appears that, with at least some of the methods suggested, we can indeed delete and recreate the record with references to retired domain controllers. The results obtained are promising but since my test environment cannot simulate the production environment detail for detail (there are no outdated references in my [1Ch] record), it would be advisable to back up the WINS database first, just in case.
Moreover, my test environment contains only one WINS server. We should consider the effects of inter-WINS server replication on the results of the test - and the choices to make for the deletion of the record (see the screenshot above, related to this subject).

Tuesday, January 7, 2014

Windows Server 2012 - Active Directory - ADPREP

Or... adding a Windows 2012 domain controller to a Windows 2008 (R2) domain

Adding a Windows 2008 domain controller to a Windows 2003 domain - where all domain controllers are running Windows 2003 - or a Windows 2008 R2 controller to a domain where all the current controllers were at 2008, required the execution of the adprep command to prepare the forest and the domain for the latest domain controllers.
This has changed - to some extent - with Windows 2012. Previously, it was necessary to run the adprep commands (we'll see them in a second) manually, before promoting a server running the newer OS. When we promote a Windows 2012 server to domain controller status, the process includes running the adprep /forestprep and adprep /domainprep commands automatically, in the background.
However, we can still execute these commands manually and in either case, certain criteria still must be respected.

If we proceed manually, we need to execute 2 or 3 commands:

adprep /forestprep to prepare the forest

adprep /domainprep to prepare the domain

And optionally...

adprep /rodcprep if we plan to user "Read-Only" domain controllers.

We should run the first command on the schema master and the second on the infrastructure master.
If we are not sure which domain controller holds these roles, we can determine that with this command:

netdom query fsmo

Or alternately:

dsquery server -hasfsmo schema

dsquery server -hasfsmo infra

Of course, the schema master and the infrastructure master may be located on the same domain controller.
The user running the commands must be schema administrator (in the forest) and domain administrator in each of the domains to be prepared.
So, let's make a first attempt.
We need to have the Windows Server 2012 media available, either the DVD or the .iso file (which we would have to mount). Once we've mounted the .iso file or inserted the DVD, we browse to the following location on that media:

Note: in this case, the DVD has been inserted in the D: drive. The drive letter, of course, could be something else.

PS C:\Users\admin> cd\
PS C:\> D:
PS D:\> cd support
PS D:\support> cd adprep
PS D:\support\adprep>

Note: instead of "cd" we could use the Powershell equivalent "sl" to "set" the location.

Now, if we execute the command as we would at the traditional Windows command line, we will encounter an error:

PS D:\support\adprep> adprep /forestprep

The term 'adprep' is not recognized as the name of a cmdlet, function, script file, or operable program. Check the spelling of the name, or if a path was included, verify that the path is correct and try again [snip].

Suggestion [3,General]: The command adprep was not found, but does exist in the current location. Windows PowerShell doesn't load commands from the current location by default. If you trust this command, instead type ".\adprep". See "get-help about_Command_Precedence" for more details.

So, in Powershell we need to enter the full command like this:

PS D:\support\adprep> .\adprep /forestprep

But we encounter one more obstacle:

Adprep detected that the supplied or default user is not a member of the following group: Schema Admins Group.
Adprep has stopped without making changes.
[User Action]
Verify the user is a member of Enterprise Admins group and Schema Admins group.

In fact, this is an error I created by removing the administrator account used to execute the command from the schema administrators group. I wanted to illustrate what would happen if this requirement was not met. This is not an implausible scenario. Some experts recommend that the schema admins group remain empty until there is a need to upgrade the schema. This is to prevent accidental unplanned schema upgrades.

So, in summary...

1. We have to prefix the actual command with .\ when running the command in PowerShell.
2. The user running the command must be member of the schema admin group - and the domain administrators group of any domain being prepared for Windows 2012.

Once these requirements are met, we can make some progress:

PS D:\support\adprep> .\adprep /forestprep


Before running adprep, all Windows Active Directory Domain Controllers in the forest must run Windows Server 2003 or later. You are about to upgrade the schema for the Active Directory forest named 'mynet.lan', using the Active Directory domain controller (schema master) 'DC2.mynet.lan'.
This operation cannot be reversed after it completes.

[User Action]
If all domain controllers in the forest run Windows Server 2003 or later and you want to upgrade the schema, confirm by typing 'C' and then press ENTER to continue. Otherwise, type any other key and press ENTER to quit.


Current Schema Version is 47

Upgrading schema to version 56

Verifying file signature
Connecting to "DC2.mynet.lan"
Logging in as current user using SSPI
Importing directory from file "D:\support\adprep\sch48.ldf"

The command has completed successfully
Verifying file signature
Connecting to "DC2.mynet.lan"
Logging in as current user using SSPI
Importing directory from file "D:\support\adprep\sch56.ldf"
Loading entries....
188 entries modified successfully.

The command has completed successfully
Adprep successfully updated the forest-wide information.


We then can prepare the domain:


PS D:\support\adprep> .\adprep /domainprep

Adprep successfully updated the domain-wide information.


The output of the adprep /forestprep command shows a progression from schema version 47 to schema version 56. Schema version 47 represents Windows 2008 R2 and 56 Windows 2012.
Here is a chart of the schema version numbers and the corresponding operating system:

13 = Windows 2000 Server
30 = Windows Server 2003
31 = Windows Server 2003 R2
44 = Windows Server 2008
47 = Windows Server 2008 R2
56 = Windows Server 2012
69 = Windows Server 2012 R2

I happened to know beforehand that I was moving from Windows Server 2008 R2 to Windows Server 2012. But what if you do not know?

The current schema version can be displayed with this command:

PS C:\> dsquery * "cn=schema,cn=configuration,dc=mynet,dc=lan" -scope base -attr objectversion

It can also be viewed in both the ADSI Editor (screenshot 1) and in the registry (screenshot 2) at the locations indicated:



In case the path is not legible, I'll rewrite it here:


By viewing the schema version before and after the upgrade, we can verify the success of the operation.


How to determine the current Active Directory or Exchange Server schema version

Running Adprep.exe

Saturday, January 4, 2014

Windows Server 2012 - Active Directory - NTDSUTIL, part 2

In this second post about NTDSUTIL, I'm going to examine three other tasks we can perform with this tool:

1. Resetting the Directory Services Restore Mode (DSRM) password.
2. Finding duplicate SIDs.
3. Defragmenting the ntds.dit file (the Active Directory database).

 Resetting the DSRM password

When we promote a server to domain controller we are prompted to enter a password for the "Directory Services Restore Mode". We will need this password if we ever need to boot into "DSRM". True, with restartable directory services, we can perform many operations without having to boot into DSRM, offline defragmentation for example. But there is at least one case where we still have to boot into DSRM: restoring all or part of the Active Directory database. So what if we do not remember the DSRM password? What if we start to manage an Active Directory environment where documentation is limited or even non-existent? In this situation, we can reset the DSRM password in ntdsutil as follows (the words in bold are the commands that we must enter):

PS C:\> ntdsutil
C:\Windows\system32\ntdsutil.exe: set dsrm password
Reset DSRM Administrator Password: reset password on server DC5
Please type password for DS Restore Mode Administrator Account: **********
Please confirm new password: **********
Password has been set successfully.
Reset DSRM Administrator Password: quit
C:\Windows\system32\ntdsutil.exe: quit

Note: in this case, we do not have to "activate" an "instance" of ntds as we do for other ntdsutil commands.

Finding duplicate SIDs

Users (and other objects) in Active Directory have what is known as a security identifier or "SID". This is a property of the object that represents them in Active Directory and regulates access to resources in the network. When a user account is authenticated, it is granted a "token" that contains the SID not only for the user account itself but also the SIDs of the groups of which the user is a member. This token - and more precisely the SIDs that it contains - are compared to the Access Control Entries (ACE) of the Access Control Lists (ACL) to determine if the user should have access to the resource and if so, what level of access.

It is important, therefore, that Active Directory does not have duplicate SIDs, that is, objects with the same security identifier. If that were the case, it would be difficult to regulate access to resources if two users had the same SID. Windows security only examines the SID and is not programmed to consider other elements to distinguish between two objects with the same identifier.

In normal circumstances, duplicate SIDs should not exist. The RID master (one of the FSMO roles - or operations masters) distributes pools of "relative IDs" to the other domain controllers, each of which should thus have a distinct range of IDs to use when creating SIDs for Active Directory objects such as users, groups and computers. If one does not mismanage the RID Master, by restoring a failed domain controller after seizing the role on another, for example, there should not be duplicates.

We can check for duplicate SIDs all the same with the following set of commands:

PS C:\> ntdsutil
C:\Windows\system32\ntdsutil.exe: security account management
Security Account Maintenance: connect to server DC5
Security Account Maintenance: check duplicate sid
Duplicate SID check completed successfully. Check dupsid.log for any duplicates
Security Account Maintenance: quit
C:\Windows\system32\ntdsutil.exe: quit
PS C:\>
PS C:\> gci

    Directory: C:\

Mode          LastWriteTime     Length  Name
----                -------------           ------     ----
d----         7/26/2012   3:44 AM            PerfLogs
d-r--        12/30/2013  11:12 PM           Program Files
d----         7/26/2012   4:04 AM            Program Files (x86)
d-r--        12/31/2013   8:40 PM            Users
d----          1/1/2014   9:56 PM             Windows
-a---          1/3/2014   8:51 PM             0 dupsid.log

PS C:\>

In my case, I opened the dupsid.log (which is created at the root of the C: drive) and discovered no duplicate SIDs. But what if I had?

There is another command that will remove the duplicate SIDs:

cleanup duplicate sid

Which... as the Microsoft documentation explains "deletes all objects that have duplicate SIDs and logs these entries into the log file."

But what if these objects are users, groups or computers?

It looks like those objects would have to be recreated - unless the organization was willing to accept the existence of duplicate SIDs, which would be a fundamental security flaw.

Offline defragmentation of ntds.dit

The ntds.dit is defragmented online twice a day. Online defragmenation can create usable free space within the ntds.dit after deletions are made. New objects can be created in this free space without increasing the size of the ntds.dit file itself - until all the free space (sometimes called "white space") is used. At this point, the size of the ntds.dit file will increase again.
It is possible that the free space is so significant that it is wasting disk space on the volume where the ntds.dit file resides. In this case, we can opt to recover this free space with offline defragmentation.
But how can we tell how much free space is available? How can we tell if an offline defragmentation of the database would even be beneficial?
We can adjust a value in the registry that will cause Active Directory to log " Event ID 1646" when online defragmentation is complete. We set value 6 (Garbage Collection) to 1 at the following location in the registry:
The EventID 1646 entry will indicate, for example:

Free hard disk space (megabytes)
Total allocated hard disk space (megabytes):

If an offline defragmentation appears worthwhile, we can proceed as outlined in the following lines.

First, we want to determine the size of the existing ntds.dit database. By default, this file is located here:


We can observe the size of the file as shown in Windows Explorer or the command line output shown later.

Second, it is recommended to perform a backup of the ntds.dit database. With Windows Server 2012, either a Full Server Backup (-allcritical backup at the command line) or System State backup will achieve this.

Third, we must stop the NTDS service before the offline defragmentation can begin. I'll use the new Powershell cmdlets to do this:

PS C:\> stop-service ntds -force
Fourth, we need to make a folder where ntdsutil can place the defragmented database. In fact, a brand new database will be created. We will have to copy this new database to the location of the original ntds.dit database, moving, deleting or overwriting the older copy as preferred. Besides a Full Server Backup, I opted to copy the old database to another location before overwriting it with the defragmented copy (not shown here).
We perform the defragmentation itself with the following commands (in bold):


PS C:\> ntdsutil
C:\Windows\system32\ntdsutil.exe: activate instance ntds
Active instance set to "ntds".
C:\Windows\system32\ntdsutil.exe: files
file maintenance: info

Drive Information:
        C:\ NTFS (Fixed Drive  ) free(38.5 Gb) total(49.6 Gb)
DS Path Information:
        Database   : C:\Windows\NTDS\ntds.dit - 40.1 Mb
        Backup dir : C:\Windows\NTDS\dsadata.bak
        Working dir: C:\Windows\NTDS
        Log dir    : C:\Windows\NTDS - 40.0 Mb total
                        edbres00002.jrs - 10.0 Mb
                        edbres00001.jrs - 10.0 Mb
                        edb00006.log - 10.0 Mb
                        edb.log - 10.0 Mb
file maintenance:
file maintenance: compact to c:\windows\ntds\ntds-defrag

Initiating DEFRAGMENTATION mode...
     Source Database: C:\Windows\NTDS\ntds.dit
     Target Database: c:\windows\ntds\ntds-defrag\ntds.dit

                  Defragmentation  Status (% complete)
          0    10   20   30   40   50   60   70   80   90  100

It is recommended that you immediately perform a full backup
of this database. If you restore a backup made before the
defragmentation, the database will be rolled back to the state
it was in at the time of that backup.

Compaction is successful. You need to:
   copy "c:\windows\ntds\ntds-defrag\ntds.dit" "C:\Windows\NTDS\ntds.dit"
and delete the old log files:
   del C:\Windows\NTDS\*.log

file maintenance: info
Drive Information:
        C:\ NTFS (Fixed Drive  ) free(38.4 Gb) total(49.6 Gb)
DS Path Information:
        Database   : C:\Windows\NTDS\ntds.dit - 50.1 Mb
        Backup dir : C:\Windows\NTDS\dsadata.bak
        Working dir: C:\Windows\NTDS
        Log dir    : C:\Windows\NTDS - 40.0 Mb total
                        edbres00002.jrs - 10.0 Mb
                        edbres00001.jrs - 10.0 Mb
                        edb00006.log - 10.0 Mb
                        edb.log - 10.0 Mb
file maintenance: quit
C:\Windows\system32\ntdsutil.exe: quit
PS C:\>


At this point, as directed in the red print above, we copy the defragmented ntds.dit file to the original location and thus replace the old fragmented ntds.dit file.
The reader may have noticed that the size of the ntds.dit database has increased by 10 MB when we expected it to either decrease or remain the same (because of the very small number of objects in what is, essentially, a test database with some test users). This is also evident in a screenshot of the database as shown in Windows Explorer:
I'm not sure why the file size increased. If anyone knows, there is a comment section at the end of this post. Please feel free to contribute!
Otherwise, we should now backup the System State of this domain controller once again so if we need to restore the database in the near future, we will be able to restore the defragmented copy of the file.