Blog - Title

July, 2009

  • Getting Over Replmon

    Ned here again. The AD Replication Monitor utility (Replmon.exe) was introduced with the Windows Server 2000 Support Tools many years ago as a GUI mechanism for performing certain DC admin tasks. With the release of Window Server 2008 Replmon was not included and we stopped making add-on Support Tools. Every few weeks someone asks me ‘where do I download the Windows Server 2008 version of Replmon? Nowhere. It’s done. Buried. Gone. Kaput. If you want it, you must run the old Windows Server 2003 version. Today I will talk about moving on with its supported replacement, Repadmin.exe.


    Replmon grew out of the need for a more useful tool than the AD Sites and Services snap-in (dssites.msc). DS Sites offered only a basic view of the topology, and had very limited options for forcing replication or seeing errors in the topology.


    On the other hand, Replmon exposed more information and had a deeper view into the AD partitioning structure. It was designed not by the Windows Product Group but rather by an engineer in PSS. Like all Support Tools, it was not truly supported but instead provided ‘AS IS’.


    Replmon gave an administrator the ability to quickly force replication, get basic status reports, and see information about the environmental configuration.


    It was also written in a graphical format rather than a command-line interface. When Active Directory was first released 10 years ago, most tools were given more attention in their GUI rather than command-line versions. Customers were already overwhelmed with the radical changes of AD over NT and having a GUI was a highly desirable feature for a complex and not well-understood product like Active Directory.

    That was then.

    Now AD is as ubiquitous as Windows in most customer environments. Windows administrators are much more comfortable with the command-line, and that’s great – because repadmin.exe is now equal or superior to Replmon. Don’t believe me? Let’s compare.

    Moving On with Repadmin Syncall

    The most common operation with Replmon was to have it ”push” AD replication outbound from a given DC where someone had made a change and wanted it to propagate quickly to all partners. I put ”push” in quotes because AD replication is always pull-based; there is no such thing as push. What Replmon was actually doing was contacting the partner DCs and telling them to replicate inbound immediately. To do this you would:

    1. Start Replmon.

    2. Type in (or search for) the DC.

    3. Right click the DC or partition and choose Synchronize to force replication.

    4. Select if you wanted to pull or push, cross AD sites or not, and disable transitivity or not.



    Then you waited for it to finish. There were no immediate results to view, and you weren’t always going to see useful messages when something was shown at all. The only progress was a small status bar:


    And you might also see:


    If there was a problem you would get an error, but it could be misleading. For example, here is the error you get when forcing replication of the Domain partition and one of the DCs is offline for maintenance:



    Now contrast this with the Repadmin.exe steps for the same server, doing a push replication of all partitions:

    1. Run:

    Repadmin /syncall DC_name /APed

    2. There is no step 2, we’re done. :-)

    By running a repadmin /syncall with the /A(ll partitions) P(ush) e(nterprise, cross sites) d(istinguished names) parameters, you have duplicated exactly what Replmon is doing. Except that you did it in one step, not many. And with the benefit of seeing immediate results on how the operations are proceeding. If I am running it on the DC itself, I don’t even have to specify the server name.


    What about the situation I showed earlier where one of the DCs was offline for maintenance? In this case I am going to have Repadmin synchronize just the Domain partition, pushing across site boundaries:

    Repadmin /syncall /Pe dc_name naming_context

    With Repadmin we get a much more specific error:


    Those are legitimate errors that are documented and can be researched.

    Status Checking

    Replmon had the option to generate a status report text file. It could tell you which servers were configured to replicate with each other, if they had any errors, and so on. It was pretty useful actually, and one of the main reasons people liked the tool.

    Repadmin.exe offers similar functionality within a few of its command line options. For example, we can get a summary report:

    Repadmin /replsummary *


    Several DCs have been taken offline. Repadmin shows the correct error of 58 – that the other DCs are not available and cannot tell you their status.

    You can also use more verbose commands with Repadmin to see details about which DCs are or are not replicating:

    Repadmin /showrepl *


    If you want to generate a ‘repadmin status report’ that generates a bunch of useful status information, give this simple batch file a try:

    @echo off

    echo Gathering Report for DCLIST = %1
    Echo Report for DCLIST = %1 > replreport.txt

    echo. >> replreport.txt
    echo. >> replreport.txt

    echo Gathering Verbose Replication and Connections
    echo Verbose Replication and Connections >> replreport.txt echo. >> replreport.txt
    repadmin /showrepl %1 /all >> replreport.txt
    echo. >> replreport.txt

    echo Gathering Bridgeheads
    echo Bridgeheads >> replreport.txt
    echo. >> replreport.txt
    repadmin /bridgeheads %1 /verbose >> replreport.txt
    echo. >> replreport.txt

    echo Gathering ISTG
    echo ISTG >> replreport.txt
    echo. >> replreport.txt
    repadmin /istg %1 >> replreport.txt
    echo. >> replreport.txt

    echo Gathering DRS Calls
    echo Outbound DRS Calls >> replreport.txt
    echo. >> replreport.txt
    repadmin /showoutcalls %1 >> replreport.txt
    echo. >> replreport.txt

    echo Gathering Queue
    echo Queue >> replreport.txt
    echo. >> replreport.txt
    repadmin /queue %1 >> replreport.txt
    echo. >> replreport.txt

    echo Gathering KCC Failures
    echo KCC Failures >> replreport.txt
    echo. >> replreport.txt
    repadmin /failcache %1 >> replreport.txt
    echo. >> replreport.txt

    echo Gathering Trusts
    echo Trusts >> replreport.txt
    echo. >> replreport.txt
    repadmin /showtrust %1 >> replreport.txt
    echo. >> replreport.txt

    echo Gathering Replication Flags
    echo Replication Flags >> replreport.txt
    echo. >> replreport.txt
    repadmin /bind %1 >> replreport.txt
    echo. >> replreport.txt

    echo Done.

    Copy and paste into notepad, save as a CMD file and run it with a server name, a partial server name with wildcards, or an asterisk. It supports whatever Repadmin supports.

    So to get data from one server, like with Replmon:

    Replreport.cmd server1

    Or to get data from all DC’s (which Replmon cannot do):

    Replreport.cmd *

    Or to get data from all servers that have names starting with “SANFRAN“:

    Replreport.cmd sanfran*

    It will output to a text file called replreport.txt. Anything Repadmin can do, you can do in this batch file.

    More More More

    Repadmin can do even more for monitoring. Such as:

    Tell you the last time your DCs were backed up, by reading the DSASignature attribute from all servers:

    Repadmin /showbackup *


    Or output all replication summary information from all DCs to a CSV format that you can open in a spreadsheet or database. Here I’ve brought my DCs back online and replicated any pending changes. Then I get a replication report:

    Repadmin /showrepl * /csv


    Or you can see what your replication backlog is currently in the queue, like here:

    Repadmin /queue *


    Or you can see which changes have not yet replicated from a server, as well as what changes have replicated since the last time the command was run, with /showchanges:

    repadmin /showchanges destination_DC source_DSA_GUID domain_DN

    (69) add CN=Ned Pyle,CN=Users,DC=adatum,DC=com
    1> parentGUID: a90a9633-2682-4896-be86-21220cf24f0c
    1> objectGUID: e8f0e0a2-69aa-4e4e-9f74-3db79ad6f3b7
    4> objectClass: top; person; organizationalPerson; user
    1> sn: Pyle
    1> givenName: Ned
    1> instanceType: 0x4 = ( WRITE )
    1> whenCreated: 6/21/2009 9:05:32 AM Pacific Daylight Time
    1> displayName: Ned Pyle
    1> nTSecurityDescriptor: O:DAG:DAD:AI
    1> name: Ned Pyle
    1> userAccountControl: 0x10200 = ( NORMAL_ACCOUNT | DONT_EXPIRE_PASSWD )
    1> codePage: 0
    1> countryCode: 0
    1> pwdLastSet: 6/21/2009 9:05:32 AM Pacific Daylight Time
    1> primaryGroupID: 513 = ( GROUP_RID_USERS )
    1> objectSid: S-1-5-21-3776065869-1984782319-1196103478-1107
    1> accountExpires: (never)
    1> sAMAccountName: nedpyle
    1> sAMAccountType: 805306368 = ( NORMAL_USER_ACCOUNT )
    1> userPrincipalName:
    1> objectCategory: <GUID=4ed8da23575bed48b12cd36061257c14>;CN=Person,CN=Schema,CN=Configuration,DC=adatum,DC=com

    Neat right? That’s a user I created while the other DC was offline, in the list of pending changes. I snipped out another long list of changes that were also pending. Pretty useful to see if a DC that has not been replicating for a while is worth spending time trying to fix or is better off demoting.

    Other Repadmin capabilities

    Repadmin has plenty of other secrets you can use for monitoring, administering, and troubleshooting – most of which Replmon cannot do:

    • Replicate a single specific object
    • View and modify RODC password policies as well as trigger password caching
    • Create, modify, and delete replication topology
    • Remove lingering objects
    • Manipulate Global Catalog partitions
    • Set replication registry values
    • Export data to Excel-ready text
    • Way more cool stuff…

    Need to see all the help?

    Basic help - Repadmin /?

    Help on selecting DCs - Repadmin /listhelp

    Advanced command help - Repadmin /experthelp

    Help and examples for every parameter- Repadmin /?:Your specific parameter here

    Wrapping it up

    Repadmin may not be as pretty as Replmon or Dssites.msc, but it is far more powerful than both of those utilities combined. Being an AD administrator brings a lot of responsibility – you are accountable for identity management, authentication, authorization, and general network availability for your entire company. You owe it to yourself to learn and use AD’s most powerful tools, even if they don’t support a mouse.

    Update July 2 2009: One of our readers also points out that we have an excellent whitepaper on using Repadmin to troubleshoot problems.

    Grab it here:

    (Nice one, Mike!)

    - Ned ‘Cursor’ Pyle

  • Configuring DFSR to a Static Port - The rest of the story

    Ned-san here again. Customers frequently call us about configuring their servers to listen over specific network ports. This is usually to satisfy firewall rules – more on this later. A port in TCP/IP is simply an endpoint to communication between computers. Some are reserved, some are well-known, and the rest are simply available to any application to use. Today I will explain the network communication done through all facets of DFSR operation and administration. Even if you don’t care about firewalls and ports, this should shed some light on DFSR networking in general, and may save you skull sweat someday.

    DFSR and RPC

    Plenty of Windows components support hard-coding to exclusive ports, and at a glance, DFSR is no exception. By running the DFSRDIAG STATICRPC command against the DFSR servers you force them to listen on whatever port you like for file replication:


    Many Windows RPC applications use the Endpoint Mapper (EPM) component for these types of client-server operations. It’s not a requirement though; an RPC application is free to declare its own port and only listen on that one, with a client that is hard-coded to contact that port only. This range of ports is 1025-5000 in Windows Server 2003 and older, and 49152-65535 in Vista and later. DFSR uses EPM.

    Update 3/3/2011 (nice catch Walter)

    As you have probably found, we later noticed a bug in DFSR on Win2008 and Win2008 R2 DCs (only - not member servers) where the service would always send-receive on port 5722. This article was done before that and doesn't reflect it. Read more on this here:;EN-US;832017

    All of the below is accurate for non-DCs

    By setting the port, you are telling EPM to always respond with the same port instead of one within the dynamic range. So when DFSR contacted the other server, it would only need to use two ports:


    So with a Netmon 3.3 capture, it will look something like this when the DFSR service starts up:

    1. The local computer opens a dynamic client port and connects to EPM on the remote computer, asking for connectivity to DFSR.


    2. That remote computer responds with a port that the local computer can connect to for DFSR communication. Because I have statically assigned port 55555, the remote computer will always respond with this port.


    3. The local computer then opens a new client port and binds to that RPC port on the remote server, where the DFSR service is actually listening. At this point two DFSR servers can replicate files between each other.


    The Rest of the Story

    If it’s that easy, why the blog post? Because there’s much more DFSR than just the RPC replication port. To start, your DFSR servers need to be able to contact DC’s. To do that, they need name resolution. And they will need to use Kerberos. And the management tools will need DRS API connectivity to the DC’s. There will also need to be SMB connectivity to create replicated folders and communicate with the Service Control Manager to manipulate DFSR. And all of the above also need the dynamic client ports available outbound through the firewall to allow that communication. So now that’s:

    • EPM port 135 (inbound on remote DFSR servers and DC’s)
    • DFSR port X (inbound on remote DFSR servers)
    • SMB port 445 (inbound on remote DFSR servers)
    • DNS port 53 (inbound on remote DNS servers)
    • LDAP port 389 (inbound on remote DC’s)
    • Kerberos port 88 (inbound on remote DC’s)
    • Ports 1025-5000 or 49152-65535 (outbound, Win2003 and Win2008 respectively – and inbound on remote DC’s).

    Let’s see this in action. Here I gathered a Netmon 3.3 capture of configuring a new replication group:

    • Server-01 – IP – DC/DNS
    • Server-02 – IP – DFSR
    • Server-03 – IP – DFSR
    • Server-04 – IP – Computer running the DFSMGMT.MSC snap-in

    1. First the snap-in gets name resolution for the DC from my management computer (local port 51562 to remote port 53):


    2. Then it contacts the DC – the EPM is bound (local port 49199 to remote port 135) and a dynamic port is negotiated so that the client knows which port on which to talk to the DC (port 49156).


    3. Having connected to the DC through RPC to DRS (a management API), it then returns information about the domain and other things needed by the snap-in.


    4. The snap-in then performs an LDAP query to the DC to locate the DFSR-GlobalSettings container in that domain o that it can read in any new Replication Groups (local port 49201 to remote port 389).


    5. The snap-performs LDAP and DNS queries to get the names of the computers being selected for replication:


    6. The DFSR service must be verified (is it installed? Is it running?) This requires a Kerberos CIFS (SMB) request to the DC as well as an SMB connection to the DFSR servers – this is actually a ‘named pipe’ operation over remote port 445, where RPC uses SMB as a transport:




    7. The Replicated Folders are created (or verified to exist) on the DFSR servers – I called mine ‘testrf’. This uses SMB again from the snap-in computer to the DFSR server, over remote port 445:


    8. The snap-in will write all the configuration data through LDAP over remote port 389 against the DC. This creates all the AD objects and attributes, creates the topology, writes to each DFSR computer object, etc. There are quite a few frames here so I will just highlight a bit of it:


    9. If you wait for AD replication to complete and the DFSR servers to poll for changes, you will see the DFSR servers request configuration info through LDAP, and then start working normally on their static RPC port 55555 – just like I showed at the beginning of this post above.

    DCOM and WMI

    All of the things I’ve discussed are guaranteed needs in order to use DFSR. For the most part you don’t have to have too many remote ports open on the DFSR server itself. However, if you want to use tools like DFSRDIAG.EXE and WMIC.EXE remotely against a DFSR server, or have a remote DFSR server generate ‘Diagnostic Health Reports’, there is more to do.

    DFSR utilizes Windows Management Instrumentation as its ‘quasi-API’. When tools like DFS Management are run to generate health reports, or DFSRDIAG POLLAD is targeted against a remote server, you are actually using DCOM and WMI to tell the targeted server to perform actions on your behalf.

    There is no mechanism to control which RPC DCOM/WMI will listen on as there is for DFSR and other services. At service startup DCOM/WMI will pick the next available dynamic RPC port. This means in theory that you would have to have open the entire range of dynamic ports for the target OS, 1025-5000 (Win2003) or 49152-65535 (Win2008)

    For example, here I am running DFSRDIAG POLLAD /MEM:2008-02 to force that server to poll its DC for configuration changes. Note the listening port that I am talking to on the DFSR server (hint – it’s not 55555):




    And in my final example, here I am running the DFS Management snap-in and requesting a diagnostic health report. Note again how we use DCOM/WMI/RPC and do not connect directly to the DFSR service; again this requires that we have all those inbound dynamic ports open on the DFSR server:


    Wrap Up

    So is it worth it to try and use a static replication port? Maybe. If you don’t plan on directly administering a DFSR server and just need it talking to its DC, its DNS server, and its replication partners, can definitely keep the number of ports used quite low. But if you ever want to communicate directly with it as an administrator, you will need quite a few holes punched through your firewall.

    That is, unless you are using IPSEC tunnels through your Firewalls like we recommend. :-)

    - Ned ‘Honto’ Pyle

  • Active Directory Recycle Bin in Windows Server 2008 R2

    Ned here again. Now that the moratorium has ended, I can start talking about new features in Windows 7 and Windows Server 2008 R2. To get things rolling today, I wanted to give you a very brief introduction to the AD Recycle Bin. It's brief because we expect a lot of folks will be using this and we already have a lot of good step-by-step documents released - so I am just going to point you to there and set you loose. Feel free to use the Release Candidate version of Win2008 R2 of this until we start throwing RTM ISO's out there; RC's pretty much feature complete, and Recycle Bin works.

    For those that haven't been keeping up, AD Recycle Bin allows admins to restore deleted objects like users, groups, computers, OU's, etc without the need for an authoritative restore or backup tapes. If you ever been on the wrong end of some mullet head accidentally zapping 10,000 user accounts with his 'provisioning script', this is the feature for you. It has these requirements:

    • Windows Server 2008 R2 DC(s)
    • Windows Server 2008 R2 Forest Functional Level

    For further introduction, check out:

    What's New in AD DS: Active Directory Recycle Bin (TechNet)

    For a complete step-by-step guide, check out:

    Active Directory Recycle Bin Step-by-Step Guide (TechNet)

    For two very useful sample scripts (did I mention that Recycle Bin administration is implemented in AD Powershell?):

    Appendix B: Restore Multiple, Deleted Active Directory Objects (Sample Script) (TechNet)
    Inspecting Deleted Objects before Restore (AD PowerShell Blog)

    I'll be happy to answer any questions you have on this here. Have a nice weekend testing :-).

     - Ned 'Go Green' Pyle

  • How to Migrate the AzMan Store

    David Everett here again. I’ve had a couple customers contact me wanting to migrate an Authorization Manager (Azman) store and I thought others wishing to do the same might find this useful. This need typically arises when someone has been testing AzMan in a test domain and they want to preserve all of the time and effort by moving the AzMan store to their production domain, or they may find they want to run AzMan using an XML file instead of Active Directory. For those who are not aware of what Authorization Manger is, it is a role-based access control (RBAC) framework which applications can use to perform Role Based authentication. Role-based authentication grants permissions to users who have been assigned to certain roles to perform job functions allowing them to perform related tasks within the application. Azman.msc is the MMC snap-in used to manage these roles which can be stored in an XML file or in Active Directory. Follow this link to learn more about AzMan.

    While there is no production tool meant to provide this, the developers for AzMan have created an un-supported sample application called azmigrate.exe which is in the Windows SDK. This tool can export the AzMan store allowing migrations from AD to XML or from XML to AD. The exported content retains all SIDs currently assigned to a role and can be imported to a new Active Directory domain or loaded right from the XML file that was generated from the export.

    To get azmigrate.exe you must download the Windows SDK and once it is installed you need to:

    1) Compile the AzMigrate project using Visual Studio:

    a. Select File > Open > Project/Solution.

    b. Change the Solutions Configurations drop-down in the toolbar from Debug to Release.


    c. Select AzMigrate.vcproj located under %programfiles%\Microsoft SDKs\Windows\v6.1\Samples\Security\Authorization\AzMan\AzMigrate.

    NOTE: If you are prompted to run the Conversion Wizard, do so

    2) In Visual Studio select Build > Build Solution, then click Build > Build AzMigrate and get the compiled binary from %Program Files%\Microsoft SDKs\Windows\v6.1\Samples\Security\Authorization\AzMan\AzMigrate\Win32\Release.

    NOTE: If you encounter issues while compiling please refer to Visual Studio Help documentation.

    Once you’ve compiled azmigrate.exe, here’s the syntax needed to export the AzMan store from Active Directory to an XML file in the C:\Temp folder:

    AzMigrate.exe "msxml://C:/ Temp/AzmanStore.xml" "msldap://,CN=Program Data,DC=contoso,DC=com" /o /l=C:\temp\export.log /v

    NOTE: you need to get the correct DN for your AzMan store and modify the string above. To do this open azman.msc and view the Properties of the AzMan store then copy the DN from the Name field.


    The exported XML file can now be loaded in azman.msc directly from the XML file or you can import the file to another Active Directory domain where the Domain Function Level has been raised to Windows Server 2003 by running using this command:

    AzMigrate.exe "msldap://,CN=Program Data,DC=child,DC=contoso,DC=com" "msxml://C:/ Temp/AzmanStore.xml" /o /l=C:\temp\import.log /v

    Note that the export and import LDAP paths cited above target a specific DC. If when importing you encounter an error containing “More data is available” in the error string you may be importing the file from a member computer that is not joined to the same domain as the DN listed in the msldap:// string specified on your import command. When this occurs the import is unsuccessfully attempted against a DC belonging to the domain of the computer you are logged onto instead of a DC in the domain specified in the DN. When this occurs the import command looked like this:

    AzMigrate.exe "msldap://CN=AzmanStore,CN=Program Data,DC=child,DC=contoso,DC=com" "msxml://C:/ Temp/AzmanStore.xml" /o /l=C:\temp\import.log /v

    This can be avoided by specifically targeting a DC in the domain you want to import to using the desired LDAP port as shown in the second example above.

    Finally, one other error you might encounter when importing is “FAILED.ERROR MSG:The specified server cannot perform the requested operation.” If you encounter this error make sure the Domain Function Level has been raised to Windows Server 2003.

    - David “You’re the Azman!” Everett

  • Hello Jose

    Ned here again. I've added a new blog to our Useful MS Blogs section:

    Jose Barreto's Blog

    We've posted some of Jose's stuff before but now we're making it official. :-) Jose is the PM of DFS Namespaces and writes quite a bit of interesting and useful stuff. For example, some recent ones that really kick booty:

    Five ways to check your DFS-Namespaces (DFS-N) configuration with the DFSDIAG.EXE tool

    File Server Capacity Tool (FSCT) Release Candidate available for download

    Using the Windows Server 2008 DFSUTIL.EXE command line to manage DFS-Namespaces

     It's not all DFS either, so definitely give it a shot.

    - Ned 'Shoutout' Pyle

  • Done

    Ned here. Windows 7 client, Windows Server 2008 R2, and Windows Server 2008 R2 Hyper-V Standalone are RTM.

    Read more here on when you can get what, and other high-fiving amongst ourselves:

    Ned 'Working on Windows 8' Pyle

  • Microsoft Assessment and Planning Toolkit is RTM

    Ned here. You probably already knew this, but better late than never. The Microsoft Assessment and Planning Toolkit 4.0 has been released. What is it good for and how does it work?

    • Assessment & Readiness - Windows 7 readiness, Windows Vista Hardware Assessment, 2007 Office Assessment, Windows Server 2008 R2 Readiness, Windows Server 2008 Readiness, Power Savings Assessment, Security Assessment, Application Virtualization Assessment
    • Discovery & Inventory - SQL Server, Windows Server Roles, Virtual Machine Inventory
    • Server Consolidation -  Inventory, Performance, Virtual Machine Analysis, ROI Calculator
    • Agentless - no software to install on your surveyed computers (Woohoo - nothing to install on targets!)
    • Computer discovery methods - Active Directory, NetBIOS browsing, computer names from a file, scan an IP address range, or manually enter computer names

    If you just want to check a few Win7 computers for readiness though, avoid the overkill above and just grab Windows 7 Upgrade Advisor.

    The price on both? Free, baby, free. Lots more info here. Go now, before we change our minds and charge you the millions it's worth.

    - Ned 'Giveaway' Pyle

  • New Directory Services KB Articles/Blogs 7/12-7/26

    KB Articles


    The private key description field always displays "CryptoAPI Private Key," and you cannot change the text on computers that are running Windows Server 2003 or Windows XP x64 Professional


    Certificates are unusable when you import a PEX file to a computer that is running Windows Vista or Windows Server 2008


    Applications that reply on the RPC service are blocked in Windows Vista SP1 or Windows Server 2008 when you block Windows Firewall incoming connections and enable remote management


    The Group Policy Management MMC snap-in stops responding on a computer that is running Windows Vista or Windows Server 2008 when you select a Group Policy object in a domain that has lots of organizational units


    The Terminal Server Licensing MMC snap-in or the TS Licensing Manager MMC snap-in uses NT LAN Manager instead of the Kerberos protocol to pass authentication, respectively, in Windows Server 2003 or in Windows Vista and Windows Server 2008


    Windows Explorer stops responding for approximately 30 seconds when you try to access the DFS resources in a Windows Server 2008 domain


    Network bindings are incorrect after you change a network adapter's configuration on a computer that is running Windows Vista or Windows Server 2008


    The upgrade from Windows Server 2008 to Windows Server 2008 R2 fails if you have applied some TCP-A and NetDMA settings before the upgrade


    A warning message is returned from the W32Time service when you run the dcdiag command on Windows Server 2008 against a Windows Server 2008 R2 domain controller