Active Directory Domain Services: Last Interactive Logon

Active Directory Domain Services (AD DS) in the Windows Server® 2008 operating system introduces a new feature: last interactive logon. Last interactive logon information is available in domains that operate at the Windows Server 2008 domain functional level. It is also available in domain-joined Windows Server 2008 server computers and Windows Vista® client computers.

What does last interactive logon do?

Last interactive logon helps you record four key components of user logon information:

• The total number of failed logon attempts at a domain-joined Windows Server 2008 server or a Windows Vista workstation
  
• The total number of failed logon attempts after a successful logon to a Windows Server 2008 server or a Windows Vista workstation
  
• The time of the last failed logon attempt at a Windows Server 2008 or a Windows Vista workstation
  
• The time of the last successful logon attempt at a Windows Server 2008 server or a Windows Vista workstation
  

Why use last interactive logon?

Last interactive logon is useful if you want to see if someone is trying to perform a brute-force attack on the directory by trying to access an account and guessing the password.
In addition, you can use last interactive logon for compliance and auditing purposes by determining who is trying to access a user account and when these access attempts occur.

Where last interactive logon information is stored

Last interactive logon information is stored in four attributes of the user objects that are added to the schema when a domain operates at a Windows Server 2008 functional level:

• msDS-FailedInteractiveLogonCount—The number of failed logon attempts at a Windows Server 2008 server or a Windows Vista workstation since the last interactive logon feature was enabled
  
• msDS-FailedInteractiveLogonCountAtLastSuccessfulLogon—The total number of failed interactive logons up until the last successful Ctrl-Alt-Del logon
  
• msDS-LastFailedInteractiveLogonTime—A time stamp of the last failed logon attempt
  
• msDS-LastSuccessfulInteractiveLogonTime—A time stamp of the last successful logon attempt at a Windows Server 2008 server or a Windows Vista workstation
  

Replication

Last interactive login information is updated on the domain controller that authenticates the user’s logon. The information is then replicated to every domain controller in the domain. In addition, as mentioned in the previous section, the information is stored in attributes that are assigned to user objects.
If a user account is authenticated by a read-only domain controller (RODC), the information is written to the user account that resides on the RODC. The information is also written to the nearest writeable domain controller. At the next scheduled replication, the information is then replicated from the writeable domain controller back to the RODC. This happens because the high-water mark and update sequence number are not updated on the RODC. Instead, they are updated on the writeable domain controller.

How last interactive logon information is reported

There are two ways to report last interactive logon information:

• Write the information to the directory in AD DS
  
  If last interactive logon information is enabled in a Group Policy object (GPO) with domain controllers in its scope of management, the last interactive logon information is written to the attributes that are listed in the previous Where last interactive logon information is stored section for all user accounts that are logging on to any domain controller in the domain.
  
• Write the information to the AD DS directory, and display last interactive logon information to the user
  
  If last interactive logon information is enabled in a GPO with domain controllers in its scope of management and in a GPO with server and client computers in its scope of management, last interactive logon information is written to the AD DS directory as previously described as well as displayed to the user after he or she logs on to the workstation.
  

Information that appears at the server and workstation

When a user logs on to a computer for the first time after the last interactive logon feature is turned on—in a GPO with domain controllers in its scope of management and with Windows Server 2008 servers or Windows Vista client computers in its scope of management—the following message appears after the user logs on:
“<User Account>”
“This is the first time you have interactively logged on to this account.”
On subsequent logons, the user receives the following message:
“<User Account>”
Successful Logon
“The last time you interactively logged on to this account was: <time>”
Unsuccessful Logon
“The last unsuccessful interactive logon attempt on this account was: <time>”
“The number of unsuccessful interactive logon attempts since your last interactive logon: <number>”

How to configure last interactive logon

You configure last interactive logon through a GPO. You must configure the following setting for the GPO with domain controllers in its scope of management if you want to report last interactive logon information to the directory service:
Computer Configuration| Policies | Administrative Templates | Windows Components | Windows Logon Options | Display information about previous logons during user logon = Enabled
If you want to display last interactive logon information to the user, you must configure this setting for both the GPO with domain controllers in its scope of management as well as any GPO with Windows Server 2008 and Windows Vista client computers in its scope of management.

Configuration notes

Note the following considerations for configuration of last interactive logon:

• For last interactive logon to operate correctly, the domain functional level must be set to Windows Server 2008. If this is not the case, users will not be able to log on to their computers and they will receive the following message:
  
  “Security policies on this computer are set to display information about the last interactive logon. Windows could not retrieve this information. Please contact your network administrator for assistance.”
  
• If you enable last interactive logon on Windows Server 2008 and Windows Vista domain-joined computers and you do not enable this feature in a GPO with domain controllers in its scope, users will not able to log on to the system.
  
• Only Windows Server 2008 and Windows Vista computers display last interactive logon information to users. All other operating systems ignore this feature.
  
• Last interactive logon does not report from which computer the logon attempts occurred because last interactive logon information is stored in the user account properties. To determine from where the logon attempts occurred, you must check the security logs of the domain controllers.

Active Directory Domain Services: Last Interactive Logon

Active Directory Domain Services (AD DS) in the Windows Server® 2008 operating system introduces a new feature: last interactive logon. Last interactive logon information is available in domains that operate at the Windows Server 2008 domain functional level. It is also available in domain-joined Windows Server 2008 server computers and Windows Vista® client computers.

What does last interactive logon do?

Last interactive logon helps you record four key components of user logon information:

• The total number of failed logon attempts at a domain-joined Windows Server 2008 server or a Windows Vista workstation
  
• The total number of failed logon attempts after a successful logon to a Windows Server 2008 server or a Windows Vista workstation
  
• The time of the last failed logon attempt at a Windows Server 2008 or a Windows Vista workstation
  
• The time of the last successful logon attempt at a Windows Server 2008 server or a Windows Vista workstation
  

Why use last interactive logon?

Last interactive logon is useful if you want to see if someone is trying to perform a brute-force attack on the directory by trying to access an account and guessing the password.
In addition, you can use last interactive logon for compliance and auditing purposes by determining who is trying to access a user account and when these access attempts occur.

Where last interactive logon information is stored

Last interactive logon information is stored in four attributes of the user objects that are added to the schema when a domain operates at a Windows Server 2008 functional level:

• msDS-FailedInteractiveLogonCount—The number of failed logon attempts at a Windows Server 2008 server or a Windows Vista workstation since the last interactive logon feature was enabled
  
• msDS-FailedInteractiveLogonCountAtLastSuccessfulLogon—The total number of failed interactive logons up until the last successful Ctrl-Alt-Del logon
  
• msDS-LastFailedInteractiveLogonTime—A time stamp of the last failed logon attempt
  
• msDS-LastSuccessfulInteractiveLogonTime—A time stamp of the last successful logon attempt at a Windows Server 2008 server or a Windows Vista workstation
  

Replication

Last interactive login information is updated on the domain controller that authenticates the user’s logon. The information is then replicated to every domain controller in the domain. In addition, as mentioned in the previous section, the information is stored in attributes that are assigned to user objects.
If a user account is authenticated by a read-only domain controller (RODC), the information is written to the user account that resides on the RODC. The information is also written to the nearest writeable domain controller. At the next scheduled replication, the information is then replicated from the writeable domain controller back to the RODC. This happens because the high-water mark and update sequence number are not updated on the RODC. Instead, they are updated on the writeable domain controller.

How last interactive logon information is reported

There are two ways to report last interactive logon information:

• Write the information to the directory in AD DS
  
  If last interactive logon information is enabled in a Group Policy object (GPO) with domain controllers in its scope of management, the last interactive logon information is written to the attributes that are listed in the previous Where last interactive logon information is stored section for all user accounts that are logging on to any domain controller in the domain.
  
• Write the information to the AD DS directory, and display last interactive logon information to the user
  
  If last interactive logon information is enabled in a GPO with domain controllers in its scope of management and in a GPO with server and client computers in its scope of management, last interactive logon information is written to the AD DS directory as previously described as well as displayed to the user after he or she logs on to the workstation.
  

Information that appears at the server and workstation

When a user logs on to a computer for the first time after the last interactive logon feature is turned on—in a GPO with domain controllers in its scope of management and with Windows Server 2008 servers or Windows Vista client computers in its scope of management—the following message appears after the user logs on:
“<User Account>”
“This is the first time you have interactively logged on to this account.”
On subsequent logons, the user receives the following message:
“<User Account>”
Successful Logon
“The last time you interactively logged on to this account was: <time>”
Unsuccessful Logon
“The last unsuccessful interactive logon attempt on this account was: <time>”
“The number of unsuccessful interactive logon attempts since your last interactive logon: <number>”

How to configure last interactive logon

You configure last interactive logon through a GPO. You must configure the following setting for the GPO with domain controllers in its scope of management if you want to report last interactive logon information to the directory service:
Computer Configuration| Policies | Administrative Templates | Windows Components | Windows Logon Options | Display information about previous logons during user logon = Enabled
If you want to display last interactive logon information to the user, you must configure this setting for both the GPO with domain controllers in its scope of management as well as any GPO with Windows Server 2008 and Windows Vista client computers in its scope of management.

Configuration notes

Note the following considerations for configuration of last interactive logon:

• For last interactive logon to operate correctly, the domain functional level must be set to Windows Server 2008. If this is not the case, users will not be able to log on to their computers and they will receive the following message:
  
  “Security policies on this computer are set to display information about the last interactive logon. Windows could not retrieve this information. Please contact your network administrator for assistance.”
  
• If you enable last interactive logon on Windows Server 2008 and Windows Vista domain-joined computers and you do not enable this feature in a GPO with domain controllers in its scope, users will not able to log on to the system.
  
• Only Windows Server 2008 and Windows Vista computers display last interactive logon information to users. All other operating systems ignore this feature.
  
• Last interactive logon does not report from which computer the logon attempts occurred because last interactive logon information is stored in the user account properties. To determine from where the logon attempts occurred, you must check the security logs of the domain controllers.

How to start in Directory Service Restore Mode (DSRM) in Windows Server 2008 and Windows Server 2008 R2

Here are two methods to enter Directory Services Restore Mode (DSRM) in Windows Server 2008 or Windows Server 2008 R2:

1. From the Desktop use the graphical user interface (GUI) Msconfig tool. Click Start. In Start Search, type msconfig and then click OK. On the Boot tab, select Safe Boot, and then click Active Directory repair. (see attached figure)
2. From a command prompt, use bcdedit. The command: bcdedit /set safeboot dsrepair enables DSRM upon restart. When you want to restart in normal mode, run the following command: bcdedit /deletevalue safeboot

This posting is provided "AS IS" with no warranties, and confers no rights.

Introducing Active Directory Recycle Bin

Accidental deletion of Active Directory objects is a common occurrence for users of Active Directory Domain Services (AD DS) and Active Directory Lightweight Directory Services (AD LDS).
In Windows Server 2008 Active Directory domains, you could recover accidentally deleted objects from backups of AD DS that were taken by Windows Server Backup. Or you could recover deleted Active Directory objects through tombstone reanimation. The drawback to the authoritative restore solution was that it had to be performed in Directory Services Restore Mode (DSRM) during which the domain controller being restored had to remain offline. And the problem with tombstone reanimation was that reanimated objects' link-valued attributes (for example, group memberships of user accounts) were physically removed and non-link-valued attributes were cleared and not recovered.
Windows Server 2008 R2 Active Directory Recycle Bin enhances your ability to preserve and recover accidentally deleted Active Directory objects by preserving all link-valued and non-link-valued attributes of the deleted Active Directory objects. With the Active Directory Recycle Bin enabled, the objects are restored in their entirety to the same consistent logical state that they were in immediately before deletion.
There are a couple of special considerations:
1. By default, Active Directory Recycle Bin is disabled. To enable it, you must first raise the forest functional level of your AD DS or AD LDS environment to Windows Server 2008 R2. This in turn requires that all domain controllers in the forest or all servers that host instances of AD LDS configuration sets be running Windows Server 2008 R2.
2. In Windows Server 2008 R2, the process of enabling Active Directory Recycle Bin is irreversible. After you enable Active Directory Recycle Bin in your environment, you cannot disable it.
For further information, such as the Active Directory Recycle Bin scenario overview and the detailed steps on how to recover a single or multiple deleted objects (using ldp.exe or the Active Directory PowerShell snap-in), see What's New in AD DS: Active Directory Recycle Bin (http://go.microsoft.com/fwlink/?LinkId=141392) and Active Directory Recycle Bin Step-by-Step Guide (http://go.microsoft.com/fwlink/?LinkId=133971).  
This posting is provided "AS IS" with no warranties, and confers no rights. 

Local and Domain User Password Policy

We know that we can set domain password policies through a group policy tied to the domain NC head.  We know that up until 2008, this policy becomes the singular effective password policy for all domain user accounts.  This means that even if we create a group policy and tie it to an OU lower down in the structure, say an Admins OU, this will not affect domain user policy - even for thos admin accounts in that OU.  So, natively, we can’t set one policy for our users and another, more restrictive policy for our admins.  However, what is often unknown or overlooked is that password policy set down at the lower OU may actually have an impact.
If the policy in the lower OU applies only to users, then the password policy settings will be useless (remember, password policy settings are applied in the computer portion of policy) – even if we enable Loopback Processing.  But, if the password policy applies to computers (workstations or servers), then the policy does have an impact.
Group policy settings become part of the effective local policy.  The password policy settings for local policy affect any local accounts; and every Windows machine has a local accounts database.  The password policy settings in the group policy will overwrite any locally configured settings and the accounts in the local SAM will be subjected to these domain-based password policy settings.
I occasionally have customers request that their local accounts have a different password policy than the domain (say, a longer password requirement).  To apply that to some contained set of workstations, simply create a policy linked to the OU or a parent OU of these workstations and configure the password policy settings there.  It will have no impact on the domain password policy but it will affect local accounts on the workstations.

DNS Command Line and GUI Scenarios Clarified

I suggested that they do the following:

1. Set it so DNS enables scavenging on all zones by default, so that it's enabled when the zone is created.
2. Set all of the zones that weren't set to scavenge, to do so.
3. Set it so DNS zones are automatically set to secure only. ;)
4. Set all of the zones that weren't set to be secure only, to do so.

Below is what I told them to do to accomplish those simple goals, however since some of the wizards don't explain exactly what they do, and since you can get inconsistent or unexpected results, if you don't know what to expect, I thought I'd clarify a bit.
In order to meet the first goal, to set all newly created zones to scavenge upon creation, I told them to run the following command, obviously changing <server> to their server names.
Dnscmd <server> /config /defaultagingstate 1
Note: By default it's set to 0.  Also, unlike some other commands you can't just type the command without a parameter to see the status.
Also, it's important to note that the /defaultagingstate switch is server specific, so if a zone is created on another DC/DNS server where it's not set to 1, it won't automatically be set to scavenge, unless that command is run for that server as well, or it's enabled via the GUI.
Essentially, that command is the command line equivalent to right clicking the server, selecting "Set Aging/Scavenging for all Zones", checking the "Scavenge Stale Resource Records" box, and then clicking OK.

When you click OK, it'll take you to another screen and then you'd click OK again, leaving the "apply these settings to the existing Active Directory-integrated zones" check box unchecked.
You can also define default no-refresh and refresh intervals (that will be modified on the same screen) by using the /defaultnorefreshinterval and /defaultrefreshinterval switches. Those are also server-level settings and the value is a hex value. Obviously, if you have a small number of DNS servers then the GUI method is easier for changing all of the defaults, but if you have a lot of DNS servers, then you'll want to use the command line or using that via a batch file or script.
The one thing that I'm not a big fan of is that the wizard doesn't explain very well what it is exactly that you're enabling. When selecting "Set Aging/Scavenging for all Zones", to me that sounds like a one time deal where you just run through the wizard.
Also of note, if you define those settings, and then want to run through the wizard to age all of the zones with the same settings, the confirmation screen will be blank, as depicted below and changes will not be propagated to all zones as you might expect:

For example, lets say that 20 new zones were created on another server, but that server doesn't have default aging settings, and later you realize that aging isn't enabled. Well lets say that you go back to the DC that does have default aging settings and you try to use the "Set Aging/Scavenging for all Zones" wizard to set all of the zones to age with your defined settings...you come to realize that it doesn't work.. You see the blank confirmation window above saying that no changes will be made (though it doesn't jump out and say that).
Now, if on that same DC, where you your default settings defined, if you change intervals away from 3 in this example, to 5, then the confirmation will reflect that change for the no-refresh and refresh intervals...but that only changes those intervals (if you check the "apply these settings to the existing Active Directory-integrated zones")...it will not check the "Scavenge Stale Resource Records" box for the newly created zone that was created from the other DC. That's implicitly evident on the confirmation screen though, but you'd need to know what was missing in that screen to know that the "Scavenge Stale Resource Records" check box wouldn't be checked.

If you want to make changes to the no-refresh and refresh intervals, as well as enabled "Scavenge Stale Resource Records" for all zones, as the Wizard implies, after already having these settings defined, you can do that by changing the no-refresh and refresh values, as well as unchecking the "Scavenge Stale Resource Records" box and click ok. In this case, you would not want to check "apply these settings to the existing Active Directory-integrated zones". After you save the changes, you would go back into the wizard, define the settings that you do want applied to all zones, and then click OK.

Notice that this time, we see in the confirmation box, that it will also check the "Scavenge Stale Resource Records" box for the zone, where before that implicitly left out. If we check "apply these settings to the existing Active Directory-integrated zones", now this will apply to all zones as depicted on the confirmation screen, satisfying the second goal. Alternatively, you could make changes from another DNS server that has no defaults defined and that will also do it, among other ways.
To satisfy the third goal of setting the zones to be secured by default...you do absolutely nothing...its set that way by default.
They could have had it set to be unsecured for any number of reasons. In my mind, either they went out of their way to check the "allow both non-secure and secure dynamic updates" button for some requirement that they had (but as far as I know there is no requirement for that in their environment), or those were secondary zones that were created to "migrate" DNS from an old domain that's now collapsed, where they "promoted" those secondary zones to Primary/AD-integrated zones to preserve records, and the zone security settings were also preserved. In this case the old zones were un-secure. Regardless of the reason, they wanted to set them all to be secure.
So to satisfy the last requirement of setting all of the zones to being secure without having to manually do it, we just ran the following command, again changing <server> to their server name:
dnscmd <Server> /config ..AllZones /AllowUpdate 2
When we ran the command however, it threw an error: DNS_ERROR_INVALID_ZONE_TYPE Regardless of the error, the command still worked. But now I had to know why it threw the error...
I only found one internal article that discussed the error when running the same exact command, but they said the cause was due to the customers' server having secondary zones on it. In testing it in my lab, it also threw the same error. I don't have any secondary zones however, nor does my customer, so that was out. The only thing that I noticed when testing in my lab was that when I did a dnscmd /enumzones after running the "dnscmd <Server> /config ..AllZones /AllowUpdate 2" command to set the zones to secure, the only zone that didn't update was the built in TrustAnchors zone (for DNSSEC)...and being that it was my lab and I didn't care, I deleted it. It immediately went away when killing it in ADSI, but it didn't go away when re-enumerating the zones, it just said "Aging Down". Eventually it went away when re-enumerating (though I may have cycled the DNS service) and after that the command ran without error.

AD RMS Infrastructure Concepts

AD RMS infrastructure

AD RMS, like any IT service, relies on some infrastructure to work. In the case of AD RMS there are several components that work together in order for the solution to deliver a useful service. The most relevant ones are:
· AD RMS servers and clusters
· The AD RMS SQL Server database
· Active Directory
· The Rights Management Services client and RMS-enabled applications in the client
· AD RMS-integrated server applications



While there are other components that work along with AD RMS to make the whole thing work, those should cover the most important ones needed to understand other topics in this blog.

AD RMS Servers and Clusters

AD RMS provides its services to other elements as a web-service, and it is thus hosted inside Internet Information Services in a Windows Server. It normally runs over HTTPs (though running it over HTTP is also possible) providing a few web service operations that can be consumed by clients and services to perform information protection and consumption tasks.
AD RMS actually not only uses IIS in the hosting server, but it also uses Message Queuing to interact with the AD RMS database which we will be discussing later. That ensures that operations in the AD RMS services that need to send data to the database can be performed asynchronously and that in turn increases performance and resiliency of the database services.
Multiple AD RMS servers are typically joined together forming AD RMS clusters, which are basically collections of identically-configured AD RMS servers connected to the same AD RMS database and working together to resolve requests from other clients and servers. In an AD RMS cluster it doesn’t matter which server resolves a request, so the requests are typically load balanced through a mechanisms such as Network Load Balancing in Windows or an external load balancer.

AD RMS Database

As stated, a group of identical AD RMS servers form an AD RMS cluster. Servers in a cluster don’t host persistent service-related data in their own disks. All configurations, logs, persistent status and operation data and caches are actually hosted externally to the AD RMS servers in a SQL Server database called the AD RMS Database. That way, all servers share a common configuration and if a server fails users can continue to work through other servers in the cluster.
There’s actually not a single AD RMS database but three. Those three databases are typically hosted in the same server and are:
· The AD RMS Configuration Database, which hosts all the configurations defining the behavior of the cluster such as its URLs and caching behavior, as well as copies of some certificates and other items needed to keep the service running. It typically also holds the core certificates and keys for the AD RMS servers themselves.
· The AD RMS Caching database, which is used to cache frequently used data about the users and groups defined in Active Directory, in order to avoid impacting the performance of AD every time the service needs anything from the directory.
· The AD RMS Logging Database, in which AD RMS puts information about transactions that have been performed by the service. This information is not used by AD RMS for anything other than for reporting.

Active Directory

AD RMS uses Active Directory to authenticate users of the system within the forest where it is installed. It also uses AD to obtain information about the email address of the users, which is used as the users’ identifier thorough the system, and to obtain information about group membership when the rights assigned to a document refer to a group instead of an individual user.
As stated above, AD RMS caches data from AD in the AD RMS AD Caching database in order to avoid hitting the domain controllers too hard.

Client-side components

AD RMS typically works together with client-side components to perform the encryption, decryption and policy enforcement tasks.
The main client-side components in an AD RMS system are the Rights Management Services client and AD RMS-enabled applications.
The Rights Management Services client, which comes installed as part of Windows Vista SP1 and later and in Windows 7, and that can be installed in earlier versions of Windows, deals with all the key management, communicates with the AD RMS services in requesting licenses and providing certificates and communicates with the client applications to perform the encryption and decryption of content. It also provides a secure environment for all these tasks to occur, helping prevent tampering and potential key disclosures.

AD RMS enabled server-side applications

While most AD RMS-related operations are performed between the clients and the AD RMS servers, having some level of integration between certain server-side services and AD RMS can provide for a better user experience and more efficient IT services. For example, Exchange Server 2010 can acquire licenses for content on behalf of the users so users don’t have to wait for a license to be acquired when they open email they have in their inbox. It also provides the ability to create and consume protected content in the browser when using OWA, along with other capabilities.

Windows 2008 Clustering

Where is the cluster log in Windows 2008 ?
This short answer is its no longer there. On our Windows 2008 cluster node if we navigate to %systemroot%\system32\LogFiles\Cluster your wont find the cluster.log file anymore.
Why ? Its been replaced by a much more sophisticated event based tracing system.
The Vista\Windows Server 2008 Event Model is the next generation of Windows Event Logging and replaces the current version of the Event Log shipped in Microsoft® Windows® 2003 Server, Microsoft® Windows® XP, Windows 2000, and previous versions of Microsoft® Windows NT®.
The new model is a major update to the NT Event Log service. It maintains 100% backwards compatibility with the existing APIs and functionality and fully leverages the existing NT Event Log instrumentation in the applications and services. At the same time, it eliminates some of the limitations of the NT Event Log and provides additional features to better support monitoring and diagnostics of Windows applications, services, components, and drivers.
In a future post I will go through the new Logging and tracing features for clusters in Windows 2008 but for now lets look at how to get access to the old familiar cluster.log file.
Here's how to go about it.
1.   Go to a command prompt
2.  Type "Cluster /Cluster:yourclustername log /gen /copy "C:\temp". You should get output as follows




3. Navigate to the c:\temp directory and there you will find the .log files for each node of your cluster.
The cluster log can now be opened in Notepad.
Please note that you need to run this command after each change as its not dynamically updated like the old .log file.

Roll Back / Lower Active Directory Functional Levels in Windows Server 2008 R2

In Windows Server 2008 R2, you can now roll back (lower) the domain functional level (DFL) and forest functional level (FFL). There are a couple of conditions and limitations to this new functionality, which I discuss below.

Background Information

Functional levels control the Active Directory Domain Services (AD DS) features that are enabled in a domain or forest and restrict the operating systems that can run on domain controllers. For more details on functional levels, see Understanding AD DS Functional Levels (http://technet.microsoft.com/en-us/library/cc754918.aspx).
In previous versions of Windows Server, changes to functional levels could not be rolled back. In other words, when you raise the DFL from Windows Server 2003 to Windows Server 2008, you cannot lower the DFL back to Windows Server 2003.
In Windows Server 2008 R2, you can roll back functional levels provided you meet the below mentioned conditions.

Domain Functional Level

In my test environment, I took a DC that has Windows Server 2008 R2 RC installed, and raised the DFL to Windows Server 2008 R2.
You will notice in the image below that the warning for changing the DFL has changed in WS08R2 to state that the change might not be reversible:

To roll back / lower the DFL, you need to meet certain conditions:

1. The current DFL must be set to Windows Server 2008 R2.
2. The forest functional level (FFL) must support domains of the DFL you are rolling back to. For example, if the DFL and FFL are set to Windows Server 2008 R2, you cannot roll back / lower the DFL to Windows Server 2008 because the Windows Server 2008 R2 FFL can only have domains with a DFL of Windows Server 2008 R2.

In addition, there is a limitation to rolling back / lowering the DFL. Specifically, you can only roll back to Windows Server 2008, no earlier. In other words, you cannot roll back from a DFL of Windows Server 2008 R2 to a DFL of Windows Server 2003, even if you had previously raised the DFL from Windows Server 2003 to Windows Server 2008 R2.

Roll Back / Lower the Domain Functional Level

In build 7100 (RC) of Windows Server 2008 R2, there is no way to roll back / lower the DFL by using the GUI. Instead, you must use the Set-ADDomainMode cmdlet, which is included with the Active Directory Module for Windows PowerShell in Windows Server 2008 R2. The process is as follows:

1. Open the Active Directory Module for Windows PowerShell (Start, Administrative Tools, Active Directory Module for Windows PowerShell)
2. At the PowerShell prompt, type the following command and then hit Enter:
   Set-ADDomainMode -Identity WS08R2RCDomain.local -DomainMode Windows2008Domain
   NOTE: Replace WS08R2RCDomain.local with the FQDN of the domain you want to roll back / lower the DFL on.
3. On the confirmation, shown in the image below, type Y, and then hit Enter to proceed.

At this point, you will not see any confirmation that the change was successful in PowerShell (let’s hope this is added to the RTM). You will simply be back at the PowerShell prompt if it was successful.
However, you can look for an event logged in the Directory Service log, with an event ID of 2039, that will tell you the DFL has been changed to 3, as shown below.

NOTE: A DFL shown as “3” represents Windows Server 2008. A DFL shown as “4” represents Windows Server 2008 R2.
You can also use the Get-ADDomain cmdlet, which is included with the Active Directory Module for Windows PowerShell in Windows Server 2008 R2. The image below shows the output of this cmdlet.

Forest Functional Level

When raising the FFL through Active Directory Domains and Trusts console, you will see a warning that the change might not be reversible.
To roll back / lower the FFL, you need to meet certain conditions:

1. The current FFL must be set to Windows Server 2008 R2.
2. Advanced Features (such as Recycling Bin) cannot be enabled. If you previously enabled the Recycling Bin feature, you are SOL because this feature cannot be disabled once it has been enabled. The fact that you cannot roll back / lower the FFL if Advanced Features are enabled is something you seriously need to consider and plan ahead for. If you have enabled other Advanced Features, but not the Recycling Bin, you can use the Disable-ADOptionalFeatures cmdlet, which is included with the Active Directory Module for Windows PowerShell in Windows Server 2008 R2.

There is a the same limitation to rolling back / lowering the FFL as there is with the DFL. You can only roll back to Windows Server 2008, no earlier. In other words, you cannot roll back from a FFL of Windows Server 2008 R2 to a FFL of Windows Server 2003, even if you had previously raised the FFL from Windows Server 2003 to Windows Server 2008 R2.

Roll Back / Lower the Forest Functional Level

In build 7100 (RC) of Windows Server 2008 R2, there is no way to roll back / lower the FFL by using the GUI. Instead, you must use the Set-ADForestMode cmdlet, which is included with the Active Directory Module for Windows PowerShell in Windows Server 2008 R2. The process is as follows:

1. Open the Active Directory Module for Windows PowerShell.
2. At the PowerShell prompt, type the following command and then hit Enter:
   Set-ADForestMode -Identity WS08R2RCDomain.local -ForestMode Windows2008Forest
   NOTE: Replace WS08R2RCDomain.local with the FQDN of the domain you want to roll back / lower the FFL on.
3. On the confirmation, shown in the image below, type Y, and then hit Enter to proceed.

Once again, you will not see any confirmation that the change was successful in PowerShell (let’s hope this is added to the RTM). You will simply be back at the PowerShell prompt if it was successful
However, you can look for an event logged in the Directory Service log, with an event ID of 2040, that will tell you the FFL has been changed to 3, as shown below.

You can also use the Get-ADForest cmdlet, which is included with the Active Directory Module for Windows PowerShell in Windows Server 2008 R2. The image below shows the output of this cmdlet.

Conclusion

The ability to roll back / lower functional levels is a valuable new feature in Windows Server 2008 R2. I don’t think this is something that will be used on a frequent basis. However, having this as an option is definitely an added benefit.
It would be great if Microsoft fixes some of the issues with the steps to roll back / lower functional levels. Specifically:

• Add a way to roll back / lower functional levels through the GUI.
• Fix the Set-ADDomainMode cmdlet so that it reports the success of changing the DFL.
• Fix the Set-ADForestMode cmdlet so that it reports the success of changing the FFL.

Lastly, the fact that the FFL cannot be rolled back / lowered if the Recycling Bin is enabled, coupled with the fact that the Recycling Bin cannot be disabled after it has been enabled, are potential pain points.
All in all, I’m glad to see this new functionality in Windows Server 2008 R2, and I can live with using PowerShell cmdlets to leverage this feature.