Recovering from USN Rollback

A bit later as promised, but here it is: part 2 on the USN Rollback.
Enjoy!

There are 3 methods to recover from a USN Rollback.

1. Reinstall AD.
   Use Dcpromo to remove AD from the faulty DC and demote the machine to a standalone server. Clean up all references to the DC, if this DC was hosting FSMO roles, make sure to transfer them to another (healthy) DC.
   
2. Restore the system state.
   If a valid system state backup was made before the rolled-back DC was restored from image, restore the system state from the most recent backup.
   
3. Fool your image-restored DC (requires Windows Server 2003 SP1!).
   - Restore your image.
   - Start the DC in Directory Services Restore Mode. Do NOT start normally or it’s all too late!!!
   - Open Registry Editor and look for the value ‘DSA Previous Restore Count’ (HKEY_LM\System\CurrentControlSet\Services\NTDS\Parameters). Make a note of this value. If the entry is not there, assume a value of 0. Do not add the entry.
   - Add the registry entry ‘Database restored from backup’ in HKEY_LM\System\CurrentControlSet\Services\NTDS\Parameters
   Data type: REG_DWORD
   Value: 1
   - Restart the DC normally.
   - Check the registry to be sure that the value of ‘DSA Previous Restore Count’ is equal to its previous value plus 1.
   - In the Directory Service event log, check to see that Event ID 1109 or 1587 appears.
   - This event confirms that AD has been restored and that the Invocation ID has changed.

USN Rollback

Lately, the only thing I've talked about is Vista. And although there is a lot more, today I would like to discuss something else: USN Rollback.

When talking about backup and restore of Active Directory, a question that I get regularly is: can we restore a Domain Controller from an image?
At first sight you might say: why not?
Restoring a system state backup to get Active Directory back to a previous state, or restoring a disk image you took a few days ago: the end result will be the same.

And that would be true in an environment with only 1 domain controller.
But in most situations there will be multiple DCs and then you will encounter a serious, yet very difficult to troubleshoot, problem: USN Rollback.

When you restore a DC by performing a system state restore, AD will change the database Invocation ID. The Invocation ID identifies the version of the database. After a correct system state restore this ID is reset before AD starts. (Event ID 1587 of source Replication will be logged in the Directory Services event log.)
For the other DCs this indicates that the database version has changed and in response they reset their high-water marks and update the restored DC with changes that occurred after the backup.

If you restore a DC from an image on the other hand, the Invocation ID will not be reset and noone will be aware of the fact that one of the DCs actually rolled back to a previous state. This will lead to inconsistencies in the database, since the restored DC will not get any updates that were taken since the backup and never will.
Why is this?

AD replication is triggered by comparing USNs (Update Sequence Numbers). Every DC has a USN table for every attribute. In that table it keeps track of the highest USN it received for this attribute from a given replication partner. If the current USN on the replication partner is higher than the one in his list, the DC knows that a change has been made and that it still has to copy these changes.

Imagine the following scenario: You have a domain containing 3 domain controllers DC1, DC2 and DC3.

1. You create 10 new users on DC1 corresponding to USN 1 through 10. These user accounts replicate to DC2 and DC3.
2. At this moment an image is created on DC1.
3. You make more changes to AD: you reset the passwords on the 10 user accounts (USNs 11 to 20), you create 10 computer accounts (USNs 21 to 30), you create 10 security groups (USNs 31 to 40). All these changes replicate to DC2 and DC3.
4. Then DC1 encounters a hardware or software failure. The image that was created is used to restore DC1. DC1 now uses a database that has a record of USNs 1 to 10 when AD starts.
5. DC1 maintains its original invocation ID and DC2 and DC3 maintain their original up-to-dateness vector of USN 40 for DC1.

As a result DC1 will never receive the changes for USNs 11 to 40 and its database will be inconsistent (resulting in logon failures and other problems).
A second problem arises when new objects are now created on DC1.
If you create a new user, that account will be given the next unused USN on DC1: USN 11.
Since DC2 and DC3 think that they already have every update from DC1 up until USN 40 they will not do anything and the new changes are not replicated.
All changes created on DC1 with USNs 11 to 40 will never be available on DC2 and DC3.

In case of a proper system state restore these problems do not arise, since the reset of the Invocation ID informs the replication partners of the restore and causes them to reset their up-to-dateness vector for the restored DC.

A USN rollback can be very difficult to detect, since no errors are logged in the Event Viewer (unless you are running W2003 SP1 or hotfix 875495, then Event ID 2095 is logged).

One way to detect a USN rollback is running the following command on a DC and its replication partners: repadmin /showutdvec.
If the USN for the DC on the replication partners is higher than the one the DC has for itself and no replication errors are reported, you are probably dealing with USN rollback!

Tomorrow: Recovering from USN rollback!

Multiple Local Policies in Windows Vista

Group Policy is for sure one of the best inventions in Windows. Configuring multiple client computers has never been easier. And with Vista and Longhorn numerous extra settings will be available.

Group Policy really has only one limitation: it requires Active Directory.

And sometimes you can't (or you don't want to) use Active Directory, but you would like to create policies to control the things people can change or have access to on your pc.
For example, a kiosk computer, PCs in a cybercafé, your home machine (especially when the children are using it more and more).

In XP it is possible to use the Local Computer Policy to make changes to a single computer that is not part of a domain. And while you can implement the exact same settings as with group policy, there is one serious drawback.
You cannot make exceptions to policy settings for individual users. Once the policy is applied, it will enforce restrictions for everyone, including the Administrator.

But now there is Vista!
And one of the great new things in Vista is that you can create multiple local policies! Different policies per user. Or you could create 1 policy for the Administrators and another one for the Non-administrators.
It is very easy to limit everyone accessing your computer, except for yourself!

This is the way to go:

1. Open a Management Console.
2. Add the Group Policy Object Editor snap-in.
3. In the "Local Computer" policy window, click Browse.
4. Click on the Users tab.
5. Select the user that you want to create a policy for.
6. Configure the settings that you want to apply for this individual user.

Note: the only users you see are local users. Besides the users you will also find the local Administrators group and the non-administrators group.

If multiple policies apply, the end result wil be a combination of these policies and the user policy will win in case of conflicts.
For example: User 1 is a normal user (no administrator). You create an individual Local policy for user 1 that prohibits access to the Control Panel and explicitly allows him to access Search from the Start Menu.
You also create a policy for the Non-Administrators, that removes the Search from the Start Menu.

When user 1 logs on, both policies will be applied, but user 1's policy will override the conflicting Search setting in the Non-Administrators policy.
End result: user 1 has no access to Control Panel, but he will be able to use the Search from the Start Menu.

Disk management in Windows Vista

In earlier versions of Windows it was not possible to extend your system and boot partition. You can extend data partititons in Windows Server 2003, even on a basic disk (using diskpart), but system/boot is not an option unless you turn to some third-party tool.
And shrinking partitions was completely impossible.

Up until now!

In Vista, you can do it all:

• You can shrink any partition.
• You can extend any partition.
• Including system and boot partition.
• Both on dynamic and on basic disks.
• Using Disk Management (GUI) or Diskpart (cmd).

There is only 1 limitation: when you try to extend a partition, you'll see that it is still only possible to extend with contiguous free space.
Thus, let's say you have the following situation:

• C: drive (50 Gb)
• D: drive (50 Gb)
• Free space (100 Gb)

Then you will be able to extend drive D: but you will not be able to extend drive C: since the last one does not have any white space directly following the partition.
If you're in this situation, you still need a third-party tool.

Another thing that seems to have changed, has to do with the types of partitions.
When you try to create a new partition in Vista, you'll see that the only thing you can create is a "volume".
What happened to primary and extended partitions?

Let's take a look at Windows Server 2003.
There are 2 types of disks there: basic disks and dynamic disks.
On a basic disk, you create partitions (primary or extended). On a dynamic disk, you create volumes.

How does this work in Vista?
The only thing you can create here on a basic disk is a volume. But in fact you are creating a primary partition. Vista does not give you the choice anymore, it decides for you.
The first 3 volumes that you create, are actually primary partitions. When you create a fourth volume, Vista will automatically create 1 extended partition using the remainder of the free space on the disk. Within that partition a logical drive will be created with the size you specified in the new volume wizard.

So, basically nothing has really changed there, you just don't get to choose the type of partition to create anymore.

Log on as builtin administrator in Vista

The builtin administrator is disabled by default in Windows Vista.

If you want to use this account, the first thing you'll have to do is enable the administrator using Computer Management.

But then it still does not show up on the Welcome Screen.
Like in XP, you have to add a registry key to accomplish this.

1. Start the registry editor.
2. Browse to HKEY_LocalMachine\Software\Microsoft\WindowsNT\CurrentVersion\Winlogon\
3. Create a new key: SpecialAccounts
4. In the SpecialAccounts key, create another new key: UserList
5. In this key, create a new DWORD value: Administrator
6. Set this value to 1

Then you should be able to logon with the builtin administrator.