Exchange 2007 & Exchange 2010 UC/SAN Certificate

Exchange 2007 & Exchange 2010 UC/SAN Certificate

Ace Fekay, MCT, MVP, MCITP EA, Exchange 2010 Enterprise Administrator, MCTS Windows 2008, Exchange 2010 & Exchange 2007, MCSE 2003/2000, MCSA Messaging 2003
  Microsoft Certified Trainer
  Microsoft MVP: Directory Services
  Active Directory, Exchange and Windows Infrastructure Engineer

Original Creation Date: May, 2009, Posted Aug, 2009 – Edited on various dates, latest edit on 11/2/09.

9/6/2009   – For syntax, and added SBS2008 SSL information on 9/6/2009 (as noted below with timestamp).
9/19/2009  – Added additional SBS SSL certificate link (as noted below by timestamp).
9/24/2009  – Added additional link (as noted below by timestamp).
9/30/0209  – Added an Exchange certificate how-to step by step (as noted below by timestamp).
10/14/2009 – Added info about adding a UC/SAN cert in Windows, added info about Exchange 2010, changed title to reflect Exchange 2010



This topic goes into understanding the differences between certificate requirements in Exchange 2007 than what you’re used to with previous Exchange versions.

Getting a certificate for Exchange 2007 is a little different than Exchange 2003 or a simple website. Exchange 2007 requires a UC/SAN (Unified Communications – Subject Alternative Name). This type of cert supports multiple names, which Exchange 2007 requires, especially to include support for Outlook 2007 Autodiscover record.


Exchange 2010

If asking about Exchange 2010, it was changed so all of this is GUI based. You can actually use the steps outlined in this blog since the commands are the same, or just use the GUI. There’s more on Exchange 2010 at Digicert in their step by step with screenshots. They even created a video how-to:

How to generate a CSR for Microsoft Exchange 2010


Exchange 2007 Single Name certificate (not using a UC/SAN certificate)

For SBS 2003 and SBS 2008 installations that decide to use a single name cert (just to get this out of the way before I get to the good stuff below)

Yes, this can be done, but it will not work for the autodiscover feature. If the internal domain name is the same as the external, it will work find internally. That is kind of an exception to the rule. I just did this for one client, and everything’s working fine, OWA, Outlook and Windows Mobile devices. Just follow the rules to create the cert, but only put one name in it.

However it is possible to use a single named SSL certificate, as was used in Exchange 2003 and basic web sites, however I’ve found with the UC/SAN cert that it accommodates Outlook 2007’s Outlook Anywhere and auto-connect features. You can read about using a single named, standard SSL certificate with SBS 2008 in the following links. Just keep in mind with SBS, you must use the wizards to set this up. If you have SBS, read the following, if not, please move on to the info below). – Small Business Server and Other Technology: Installing a GoDaddy Standard SSL Certificate on SBS 2008:

(Edit: The following link was added 9/19/09 12:19AM EST)
Receiving Certificate Errors When Connecting to Clients/Servers with TS Gateway or Remote Web Workplace on SBS 2008

Edit: Added 9/30/09
Error messages when you try to synchronize a Windows Mobile 5.0-based mobile device to Exchange Server 2003 on a Windows SBS 2003-based computer

SBS 2008 – Introducing the Internet Address Management Wizard: Part 1 of 3

SBS 2008 – Introducing the Internet Address Management Wizard: Part 2 of 3

SBS 2008 – Introducing the Internet Address Management Wizard: Part 3 of 3 (has info about certs and autodiscover)


Windows Mobile Clients using ActiveSync

Before going further, if you are not sure if your Exchange 2007 installation is setup properly for outside clients, whether they would be Outlook 2003, Outlook 2007, or Mobile handhelds using ActiveSync, please visit the following Microsoft Exchange Connectivity Test site. It will provide a report on where things fail if there are any issuess:

Microsoft Exchange Server Remote Connectivity AnalyzerSelect the test you want to run.


ActiveSync & iPhones

Edit: Added 11/2/09

How To Set Up iPhone Exchange ActiveSync

If having difficulties, use the Exchange Server ActiveSync Web Administration Tool:
Microsoft Exchange Server ActiveSync Web Administration Tool

iPhone 3G won’t Sync with Exchange in Windows Small Business Server General:


The little known and dreaded UCC/SAN Certificate

The advantage and features of a UC/SAn cert is it allows you to create multiple names in the certificate. Note, this is not a wildcard certificate that will allow you to use any or an infinite number of names. Exchange 2007 does not work with such a certificate. It will, as mentioned, work with a single name certificate, if so desired to save money on the certificate prices, but I’ve found it beneficial to use a UC/SAN certificate for the multiple names that an Exchange server will use for clients.

The four main names I recommend adding to the cert when creating the request file are: (the external FQDN name used to access OWA) (used for Outlook 2007 Outlook Anywhere’s autoconnect feature) (what Outlook Anywhere and DSProxy uses over RPC/HTTPS used to connect to Exchange)
internalname (the NetBIOS name of the Exchange 2007 server)

The is what Outlook Anywhere and DSProxy uses over RPC/HTTPS that’s used to connect to Exchange 2007.

The is used by Outlook 2007’s Outlook Anywhere autoconfiguration feature.

If you go to the following site, they offer complete instructions on how the request works along with a web-based tool to configure and create a certificate request command to be used in the Exchange Management Shell in Exchange 2007. I’ve found this feature very convenient.

DigiCert’s Exchange 2007 CSR Tool

Once it creates the command for you, you can use it to create the request in your Exchange 2007 server, then submit the request file to the certificate authority. You canfind a full step-by-step at the following link to a blog created by Simon Butler, aka Sembee, a Microsoft Exchange MVP. I highly recommend reading his article, in the following link.

Exchange 2007 and SSL Certificates – Take 2, by Simon Butler, aka Sembee, a Microsoft Exchange MVP, This is a complete step-by-step. Sembee provides instructions on how to use Digicert’s wizard to create the request file with the names that you’ve chosen and pre-created in DNS, that you will need to generate the request command you will need in order to run in your Exchange Managment Shell, (by copying and pasting it from Digicert’s wizard into the Exchange Management Shell). When you receive the response back from Digicert (the cert itself), save it to as a text file, then use the Import-ExchangeCertificate command to import it into Exchange. Complete step-by-step:

You can also use a third party GUI for PowerShell if you are not familiar or comfortable with PowerShell.

Welcome to – a free community for PowerGUI, a graphical user interface and script editor for Microsoft Windows PowerShell!

Note – I’ve been using DigiCert to purchase this type of certificate for my customers. However, keep in mind, I am not trying to push this company’s certificate on anyone. I’ve just found it easy to use, especially with the wizard and the step-by-steps at their site, as well as less expensive than other CAs (certificate authorities), which may have other stipulations and requirements when requesting a UC/SAN certificate. It also works very well with Windows Mobile 5 and 6 without problems. Please check the other companies, such as Verisign, Thwate, InstanSSL, etc, to compare.


How to add additional names to a SAN certificate in Windows

Creating “Wildcard” Certificate Requests for IIS using the Windows Vista/Server 2008 Certificates MMC plugin

UCC Certificates, IIS and


Things to consider choosing an internal AD DNS domain name if using Exchange 2007

Please keep in mind, your name, company name, etc, whatever name you put on the cert (based on the domain name), a WHOIS on your domain name must have this exact information at the domain registrar when you registered your public domain name. If the names of your company and Administrative Contact are not the same, or any Contact information, they will not issue the certificate. This is a strict requirement by the certificate authorities. You can call them if more specific info about this.

Be careful that the internal name, is a publicly registered name that may be regsitered to someone else. This means whatever name you;ve chosen for your internal AD DNS name, be aware of the TLD you’ve chosen. You do not want to choose one that is already in use by another entity. Reason is it will cause due confusion, and will create problems if you were to get an Exchange 2007 UC/SAN certificate and adding a name for the internal namespace on the certificate.

If you choose a TLD for the internal AD domain name, make sure it just doesn’t happen to belong to someone else. This of course, may have been unintentional. A good example is if you’ve chosen your internal AD DNS name to be, (because the three letters are abbreviations for your companyname), and when you attempted to use that name with a UC/SAN request, the CA responds that they can’t match your name to You come to find that is an actualy public name that was registered by someone in Korea. So now you can’t use that name for the internal AD domain name and can’t use the names, such as your Therefore you are faced wtih an internal AD domain name rename task.

The point is, make sure your internal AD name is name is not registered by an actual entity other than you, or the CA will not approve it. In one sentence, please make sure never to use a internal domain with a suffix same as existing TLD (Top-level domain name such as com, net, edu, etc), unless you will register it as your own. One good example is if your external name is, register as well, and use that for the internal AD domain name. Whatever TLD you choose, make sure it does not exist as a current public name.

Technically speaking, you can also use the same name for the internal domain and the external domain. However, this method is not recommended. You may encounter following possible issues that you may have to perform a domain rename in the future. Not something that one desires to do.


Internal Domain Name naming guidelines summarized

1. If you name the internal domain the same as your Internet public domain name, in some time domain internal client will get the domain external IP (resolved from external domain name). In the scenarios that you also have published Exchange Server to receive external mails, the issue will be much more complicated. A sample issue:

Same Internal and External Domain Name

2. Worse, if your internal AD DNS domain name is registered by others, the certificate request will never get approved by the CA.


Guidelines for the Autodiscover record

External DNS:
In your public zone, create an ‘autodiscover’ record under the public domain name.

Internal DNS:
To alleviate errors with Outlook Anywhere, you can create a DNS Service Location (SRV) records to locate the Exchange Autodiscover service. If not, errors will generally happen when the SRV record for the domain for autodiscover is missing. In this issue that internal Outlook users receive the error, you may check whether the _autodiscover SRV record exists in the domain zone.

The record looks like:



TLDs (Top Level Domain Names) – Be careful what you choose for your internal AD DNS domain name

Generic top-level domains that you should be aware of when choosing an internal name. Just to be clear, if you choose any one of these as a TLD, I suggest to purchase the name at the registrar to avoid certificate issues.

biz .com .info .name  .net  .org  .pro  .aero  .asia  .cat  .coop .edu 
gov .int  .jobs  .mil .mobi  .museum   .tel  .travel

Country-Code Top-Level Domains that you want to be careful choosing, especially if someone else owns it on the internet. You’ll never get the cert approved if it is owned by someone else, despite the argument that “it’s my internal domain name…”

ac  .ad  .ae  .af  .ag  .ai  .al  .am  .an  .ao  .aq  .ar  .as  .at  .au 
aw  .ax  .az  .ba  .bb  .bd  .be  .bf  .bg  .bh  .bi  .bj  .bm  .bn  .bo 
br  .bs  .bt  .bw  .by  .bz  .ca  .cc  .cd  .cf  .cg  .ch  .ci  .ck  .cl 
cm  .cn  .co  .cr  .cu  .cv  .cx  .cy  .cz  .de  .dj  .dk  .dm  .do  .dz 
ec  .ee  .eg  .er  .es  .et  .eu  .fi  .fj  .fk  .fm  .fo  .fr  .ga  .gd 
ge  .gf  .gg  .gh  .gi  .gl  .gm  .gn  .gp  .gq  .gr  .gs  .gt  .gu  .gw 
gy  .hk  .hm  .hn  .hr  .ht  .hu  .id  .ie  .il  .im  .in  .io  .iq  .ir 
is  .it  .je  .jm  .jo  .jp  .ke  .kg  .kh  .ki  .km  .kn  .kp  .kr  .kw 
ky  .kz  .la  .lb  .lc  .li  .lk  .lr  .ls  .lt  .lu  .lv  .ly  .ma  .mc 
me  .md  .mg  .mh  .mk  .ml  .mm  .mn  .mo  .mp  .mq  .mr  .ms  .mt  .mu 
mv  .mw  .mx  .my  .mz  .na  .nc  .ne  .nf  .ng  .ni  .nl  .no  .np  .nr 
nu  .nz  .om  .pa  .pe  .pf  .pg  .ph  .pk  .pl  .pn  .pr  .ps  .pt  .pw 
py  .qa  .re  .ro  .rs  .ru  .rw  .sa  .sb  .sc  .sd  .se  .sg  .sh  .si 
sk  .sl  .sm  .sn  .sr  .st  .sv  .sy  .sz  .tc  .td  .tf  .tg  .th  .tj 
tk  .tl  .tm  .tn  .to  .tr  .tt  .tv  .tw  .tz  .ua  .ug  .uk  .us  .uy 
uz  .va  .vc  .ve  .vg  .vi  .vn  .vu  .wf  .ws  .ye  .za  .zm  .zw


Related Links and how-to articles

A new feature is available that enables Outlook 2007 to use DNS Service Location (SRV) records to locate the Exchange Autodiscover service

Unified Communications Certificate Partners for Exchange 2007 and for Communications Server 2007

Certificates for Exchange (This is a CA site that I haven’t used, but thought to provide it)

Unified Messaging Requires the Server Name in the SSL Certificate

Exchange 2007 with a Single Name SSL Certificate

More on SSL Certificates with Exchange 2007 – (supported uses)

Warning message when you start Outlook 2007 and then connect to a mailbox that is hosted on an Exchange 2007-based server: “The name of the security certificate is invalid or does not match the name of the site”

Outlook 2007 and Exchange 2007 Certificate issue

Exchange 2007 Autodiscover and Certificates:

Error messages when you try to synchronize a Windows Mobile 5.0-based mobile device to Exchange Server 2003 on a Windows SBS 2003-based computer

How to Configure SSL Certificates to Use Multiple Client Access Server Host Names

More on Exchange 2007 and certificates – with real world scenario

Certificate error with Outlook 2007 clients to Exchange 2007 server

Exchange: Test-OutlookWebServices


Default Self-Signed certificate use and generation

Exchange 2007 certificate request and issue steps

Exchange 2007 Autodiscover and certificates

Exchange 2007 certificate generation command: New-ExchangeCertificate


Exchange 2007 Certificates How-To and Example

This little tutorial is based on using DigiCert’s wizard to  help you request a cert. Not all CAs have such a wizard, but you can actually use their wizard to generate a request file that will be valid to use at any other CA.

First, go to DigiCert’s site to generate a request file and command. Digicert’s wizard will help at the following link:

DigiCert Exchange 2007 Certificate Request Wizard and

The following is an example that DigiCert’s wizard will create for you:

New-ExchangeCertificate -GenerateRequest -Path c:\mail_yourDomaname_com.csr -KeySize 2048 -SubjectName “c=US, s=DE, l=City, o=Company Name Inc, ou=Information Technology,” -DomainName,, mail-mx-01.yourDomaname.local, mail-mx-01 -PrivateKeyExportable $True

Then once the command is run, it creates the certificate request c:\mail_yourDomaname_com.csr. Open this file with Notepad.

Copy and paste everything in the file, and paste it in the correct location following DigiCert’s instructions when filling out the forms.

Once submitted, along with credit card info, etc, DigiCert will validate the company name that is requesting the certificate is actually the company name that the public domain name is registered to. They use a WHOIS search to check.

You can use any one of the registrars’ WHOIS search feature to run it yourself. Run a WHOIS on your public name to insure that the name returned in the results matches the name of your company, including contact information.

If your domain info is completely hidden, you may have to unhide it for them to validate it. If most of it is hidden, including all email address contacts, except the company name, they will at least use the company name as part of the validation. However to complete the validation, they will send an email to one of the following:,, or When you receive the email, simply agree to the terms, sign your name that you used in the request form, click submit. In about 10 minutes you will receive the actual certificate by email in a zip file.

Once you’ve received the cert, open the zip file, and copy the CSR file to the C: drive. Then run the import command:

Import-exchangecertificate –path c:\mail_trainwithksi_com.csr

[PS] C:\Windows\System32>Import-exchangecertificate -path c:\mail_yourDomainName_com.cer

Thumbprint                                Services   Subject
———-                                ——–   ——-
EF9CC2BD6546716ADA4AC744F8C30B65EC9C2D98  …..…

Now you can enable the cert for other uses, such as IMAP, POP, UM, IIS, and SMTP. To enable it for OWA, using the IIS option will take care of that.

To run the command to enabled it for other services, you need the certificate thumbprint. To retrive the thumbprint:

You can combine the services into one command, once you have the correct thumbprint, with the following command:

[PS] C:\Windows\System32>Enable-exchangecertificate -services IIS, SMTP, IMAP, POP -thumbprint EF9CC2BD6546716ADA4AC744F8C30B6D4C9C2D98

Overwrite existing default SMTP certificate,
‘580C47D434EB3AEC0C6330037D1E77701313F654’ (expires 3/15/2010 1:17:43 AM), with
 certificate ‘EF9CC2BD6546716ADA4AC744F8C30B6D4C9C2D98’ (expires 10/4/2010
7:59:59 PM)?
[Y] Yes  [A] Yes to All  [N] No  [L] No to All  [S] Suspend  [?] Help
(default is “Y”):
[PS] C:\Windows\System32>

Once that is run, you can confirm that the certificate is being used for the services you requested by the following command:

[PS] C:\Windows\System32>Get-Exchangecertificate

Thumbprint                                Services   Subject
———-                                ——–   ——-
EF9CC2BD6546716ADA4AC744F8C30B6D4C9C2D98  IP.WS      CN=mail.yoruDomain.c…
580C47D434EB3AEC0C6330037D1E77701313F654  ….S      CN=mail-mx-01
0459E4ADFFB68289325650740C009DB772D4E5FE  ….S      CN=mail-mx-01
B91E0E815163FF9E677E771225005CC2273FF886  …..      CN=WMSvc-mail-mx-01

Or you can simply connect to OWA externally using the FQDN. If it doesn’t prompt to trust the certificate, it worked.

Ace Fekay

DHCP, Dynamic DNS Updates , Scavenging, static entries & time stamps, the DnsUpdateProxy Group, and DHCP Name Protection

DHCP, Dynamic DNS Updates , Scavenging, static entries & timestamps, the DnsUpdateProxy Group, and DHCP Name Protection

Ace Fekay, MCT, MVP, MCITP EA, Exchange 2010 Enterprise Administrator, MCTS Windows 2008, Exchange 2010 & Exchange 2007, MCSE 2003/2000, MCSA Messaging 2003
  Microsoft Certified Trainer
  Microsoft MVP: Directory Services
  Active Directory, Exchange and Windows Infrastructure Engineer

Compiled 4/2006, recompiled 7/2009, & 1/4/2010
11/30/2011 – added DHCP credentials and DHCP/DNS tab properties screenshots.
3/10/2012 – Added enabling DNS scavenging screenshots.
8/22/2012 – Verified with a Microsoft enginner, we need to use the DnsUpdateProxy group and configure credentials to work, not one or the other. My blog has been corrected to reflect this. Also fixed missing screenshots
8/3/2012 – Additional info about DHCP Name Protection and that it requires Credentials, DnsUpdateProxy, but more so to secure the DnsUpdateProxy group


 Topics Covered:

  1. Preface: Keep in Mind, the entiity that registers the record into DNS, owns the record
  2. Scavenging Defined
  3. DNS Timestamp and Scavenging (and info on the dnsTombstoned Attribute)
  4. Scavenging Refresh and No Refresh Settings Must be less than the DHCP Lease Period
  5. DHCP Conflict Detection
  6. DHCP Lease has a “pen” or “pencil” Icon
  7. Records & timestamps, and the lack of timestamps
  8. Related Links



    Dynamic DNS Update Basics:

    1. By default, a Windows 2000 and newer statically configured machines will register their A record (hostname) and PTR (reverse entry) into DNS.
    2. If set to DHCP, a Windows 2000 or newer machine will request DHCP to allow the machine itself to register its own A record, but DHCP will register its PTR (reverse entry) record.
    3. The entity that registers the record in DNS, owns the record.



    How to configure DNS dynamic updates in Windows Server 2003.

    Using DNS servers with DHCP (Contains information on the DnsUpdateProxy group and its usage) (WS.10).aspx


    Caveat with the DHCP service out-of-the-box configuration

    The goal is to keep DNS clean without duplicate records.

    When a client shuts down, and later returns past the lease time, it may get a different IP address. With the default settings, a duplicate A record gets registered by DHCP with the client’s new IP. This is because the client will not update itself due to the current record in DNS is beyond the lease period. This happens even though DHCP registered the record. This is because DHCP doesn’t own the record, the client does, even though DHCP registered it.

    DHCP Option 081:

    The way to get around this is you can configure DHCP’s Option 081 to update the record for all client, no matter if the client asks or not. To configure DHCP Option 081, you must look at the DHCP server properties, under the DNS Tab in DHCP properties. Despite it being a DHCP Option, it’s not found in a DHCP server, scope or class option.


    Overview to make this work:

    • DHCP must own the record, not the client. This is done by configuring DHCP to register all DHCP clients, whether the client supports Dynamic Updates or not.
      • As long as DHCP owns the record, can keep the records in the FLZ and RLZ up to date when the client renews its lease, same IP or different IP.
      • Otherwise you’ll see duplicate A and PTR records in DNS, whether scavenging is enabled or not.
    • Configure DHCP credentials by creating a plain-Jane, Domain User account. It doesn’t have to be an administrator account.
    • Add the DHCP Server object in Active Directory to the DnsUpdateProxy group.
    • In addition, I suggest to enable DNS scavenging to remove stale records, which will keep the zone clean.


    How do we configure DHCP for this to work??

    Summary to Configure Credentials and add the DHCP server to the DnsUpdateProxy group.

    Windows 2008 R2 or newer:

    You have a new feature to prevent Name Squatting: DHCP Name Protection, you still need to configure Credentials and add the server to the DnsUpdateProxy group.

  10. Add the DHCP server to the Active Directory, Built-In DnsUpdateProxy security group.
  11. Configure DHCP Credentials.
  12. Configure Name Protection.
  13. If DHCP is co-located on a Windows 2008 R2 DC, you must secure the DnsUpdateProxy group by running the following:
    dnscmd /config /OpenAclOnProxyUpdates 0 

    Note: Configuring DHCP credentials AND using the DnsUpdateProxy group, and forcing DHCP to update all records, will also allow DHCP to register Win9x machines, as well as non-Windows machines, such as Linux, OSx (BIND based), and other Unix flavors, and update the records when they get renewed with a different IP.

  14. Scroll down to the Name Protection section for more specifics and references,

    For Windows 2008 and older:

    To force DHCP to own and control all records it updates into the DNS zone, there are two parts of the procedure:

    1. Add the DHCP server to the Active Directory, Built-In DnsUpdateProxy security group.
    2. Configure DHCP Credentials. 


    Step by Step procedure:

    Step 1: To add the DHCP server’s computer account to the DnsUpdateProxy Group  

      • In ADUC, add the DHCP server’s computer properties to the DnsUpdateProxy security group.

        • In ADUC, click on the Built-In container.
        • Scroll down to the DnsUpdateProxy group.
        • Right-click DnsUpdateProxy group, choose properties
        • Click ADD –  make sure that the search criteria is set to look for computer objects,
        • Either type in the DHCP server’s name and click Check Name or click on Advanced, then click on FIND, and scroll down to the DHCP server name.
        • Once you see the DHCP server’s computer object, highlight it
        • Click OK.

    Step 2: Force DHCP to register all records, Forward and PTR, whether a client machine can do it or not:

    See screenshots below to configure the Option 081 settings under DHCP properties, DNS tab

    Step 3: Configure other DHCP Options as needed

    Suggested basic DHCP options:

    • Set the Connection Specific Suffix DHCP Option 015 to the AD domain name (such as
    • Set Option 006 to only the internal DNS servers.
    • Option 003 to your router

    Step 4: Configure the zone for Secure Updates Only: 

    Credentials and the DnsUpdateProxy group will be used to register them.

    Step 5: Configure DHCP Credentials. Note – you can do this on 2008 R2 and newer, if you chose not to use .     

        • In AD, create and configure a dedicated Domain User account to use as credentials in DHCP.
        • The user account does not need any elevated rights, a normal user account is fine.
        • Choose a very strong password.
        • Set the password so it does not expire.

    Then configure DHCP with the credentials you created:

    For Windows 2003:

    • Open the DHCP Console:
    • Right-click the DHCP servername
    • Choose Properties.
    • Click the Credentials button
    • Provide the account’s credentials

    In Windows 2008 and 2008 R2:  

    • Select IP Scope
    • Choose Properties
    • Select the Advanced tab
    • Click the Credentials button
    • Provide the account’s credentials.

    For Windows 2000: 

    • It must be done with the Netsh command. Windows 2003 and newer can also be done with the Netsh command, if you desire.



    Note and warning: about using the DnsProxyUpdate group on a DC

    • We normally shy away from adding a DC to the DnsProxyUpdate group, as it weakens security including the DC records if DHCP is on a DC. However, in many cases, there’s not much of a choice.
    • Windows 2008 R2 and newer gives you the option to use the DHCP Name Protection Feature, but as stated above, you still need to configure credentials and add the server to the DnsUpdateProxy group.
    • When DHCP is running on a Windows 2008 R2 domain controller, you must secure the DnsUpdateProxy group by running the following:
      dnscmd /config /OpenAclOnProxyUpdates 0


    Note on older, pre-existing records in DNS:

    After configuring the above provedure, the credentials and DnsUpdateProxy group configuratuion will not update current or delete duplicate records. You must delete them manually to allow DHCP to take care of all new records moving forward.

    Also, it will allevaite another issue – If DHCP is on a DC, it will not overwrite the original host record for a machine getting a new lease with an IP previoulsy belonging to another host. 

    If there is a problem with PTRs getting updated even after configuring credentials, please see this article:

    DHCP server processes expired PTR resource records in Windows Server 2003




    Step by step screenshots:

    Windows 2003:




    Windows 2008 & Windows 2008 R2:



    DHCP Name Protection

    If you have Windows 2008 R2, in addition to configuring the DNS tab to force registration, you still must configure credentials and add the server to the DnsUpdateProxy group. If DHCP is on a Windows 2008 R2 DC, to protect the DC when using the DnsUpdateProxy group, you must secure the group by running:

    dnscmd /config /OpenAclOnProxyUpdates 0

    Using  “DHCP Name Protection.” will register A and PTR record on behalf of a client, and will prevent a workstation (non-Windows) Name Squatting, meaning using a name that another machine (non-Windows or Windows) client that DHCP already registered , from registering it’s name. DHCP will give that duplicate named client an IP, but it will not register it into DNS. 

    Quoted from the following link:

    “Name squatting occurs when a non-Windows-based computer registers in Domain Name System (DNS) with a name that is already registered to a computer running a Windows® operating system. The use of Name Protection in the Windows Server® 2008 R2 operating system prevents name squatting by non-Windows-based computers. Name squatting does not present a problem on a homogeneous Windows network where Active Directory® Domain Services (AD DS) can be used to reserve a name for a single user or computer.”

     DHCP Step-by-Step Guide: Demonstrate DHCP Name Protection
    “Name squatting occurs when a non-Windows-based computer registers in Domain Name System (DNS) with a name that is already registered to a computer running a Windows® operating system. The use of Name Protection in the Windows Server® 2008 R2 operating system prevents name squatting by non-Windows-based computers. “

    Configuring DHCP Name Protection 

    DHCP: The DNSupdateproxy group must be secured if Name Protection is enabled on any IPv4 scope

    DHCP: Credentials for DNS update should be configured if secure dynamic DNS update is enabled and the domain controller is on the same host as the DHCP server


    To configure Name Protection:

    • Right-click IPv4, choose Properties
    • Click on the DNS tab
    • Click “Configure”
    • Check the box, “Enable Name Protection”

    You can optionally select it on IPv6, too. No harm done, whether you have IPv6 scopes or not.


    You will notice that once you enable it:

    • Except the “Enable DNS Dynamic Updates according to the settings below,” checkbox, everything else under the DNS tab will be grayed out.
      • This is because the Name Protection feature takes over these functions, and will force register everything, so these settings are no longer used.
    • If you have multiple IPv4 scopes, once set at the IPv4 level, it will apply to all IPv4 scopes.
      • If you don’t want it to apply to all scopes, you can selectively disable the setting under each scope, or don’t enable it at the IPv4 level, and selectively enable it on a per scope basis.


    Here’s a screenshot of where to enable it:


    Screenshot of DNS Tab (which is actually Option 081), which grays out. This is because Name Protection took over these functions:


    If you have multiple IPv4 scopes, once set at the IPv4 level, it will apply to all IPv4 scopes.



    Back to top of page>




    Scavenging Defined


    Misconceptions about Scavenging

    There are some misconceptions prompting fears that Scavenging will remove everything in your zone, includind servers. Please understand, the main thing that scavenging works on is the timestamp. If there is no timestamp, such as a manually created, static record, it will not get scavenged. Also, if all servers, including DCs, are automatically updating their own record, then there is no fear of losing their records, because for one, their records (timestamps) are current, therefore scavenging won’t touch them, and two, Windows Servers by default will update their records every 24 hours, with the exception of domain controllers at every 60 minutes. Therefore, even if they were to scavenge these records, assuming the time stamp has ever been reached, the machines will refresh themselves anyway!


    DNS UPdate Interval is based on Operating System and WIndows Server Role:

    By default, statically configured clients and remote access clients that do not rely on the DHCP server for DNS registration, will re-register their A & PTR records dynamically and periodically every 24 hours. This applies to Windows 2000 Professional and all newer operating systems.
    For domain controllers, due to the importance of keeping up to date and accurate SRV and other records, the Netlogon service will attempt to update these records every 60 minutes.
    By default, on a computer that is running Windows XP/2003 or newer, the DefaultRegistrationRefreshInterval key value controls this (except Windows 2000, whichdoes not have this key but can be added), and is set by default to 1 day. This is true regardless of whether the computer is a client or a server, except domain controllers, which are every 60 minutes.
    You can use the following registry subkey to modify the update interval:

     Data type: REG_DWORD
    Range: 0x0 – 0xFFFFFFFF seconds
    Default value: 0x15180 (86,400 seconds = 24 hours) for Windows 2000 Professional
    Default value: 0xE10 (3,600 seconds = 1 hour) for Windows 2000 Server and Windows Advanced Server
     Scope: Affects all adaptors
    This specifies the time interval between DNS update registration updates.
    The default Time To Live (TTL) value used for dynamic registrations is 20 minutes. You can use the following registry subkey to modify the TTL value:


    In Summary:

    • Scavenging is a feature that will remove expired records based on their Timestamps.
    • Scavenging is not enabled by default.
    • Scavenging will NOT remove statically configured records, the ones you manually create unless you run dnscmd /AgeAllRecords, which will stamp them making them eligible for scavenging (more below on this). Without running this command, DNS will scavenge dynamically updated records that have reached their time stamp. To look at the time stamps of a record using Windows 2003 DNS, put the DNS console “view” in the menu to Advanced View, then look at the individual record properties, and you will see the time stamp. If using Windows 2008 or or newer, it will show up in the console as a separate column.


    Scavenge Refresh and No Refresh vs DHCP Lease period

    Scavenging Refresh and No Refresh settings must be equal to or less than the lease period. For example, using  the default DHCP lease period of 8 days with a 7day scavenge setting, is perfect. If you lower the lease, you need to lower the scavenge settings. If you are using a 4 hour lease, well, that’s a tough one, because the lowest you can go with scavenging is 1 day, and may provide inconsistent results.

    And please bear in mind, as already stated, scavenging will not remove statically configured records, (the ones you’ve manually created). It will scavenge updated records that have reached their time stamp. However, if you run dnscmd /AgeAllRecords, it will timestamp all records, making them eligible for scavenging.More on this in the next section, Static records.

    To set aging and scavenging properties for a DNS server using the DNS Console:

    1. In the DNS console, right-click the DNS server name, and choose “Set Aging/Scavenging for All Zones.
    2. Select the Scavenge stale resource records check box.
    3. You can now either choose to set Scavenging for all zones, or choose No, and manually set each zone individually. I suggest setting it for all zones.
    4. It’s recommended to go with the defaults of 7 days. If you choose to change it, it should reflect and stay in line with DHCP’s lease times. Now I’ve never found anything specific stating this, but keeping the scavenge setting to the lease minus one day, ensures that records will be deleted one day before lease renewal so it will be deleted if that record were actually not in use by a client, and has expired. If still in use, it will go through the scavenging refresh period and scavenge lifetime until the next expiration time.
    5. Once you’ve set scavenging, all records that have a time stamp will be aged,  will get scavenged. This does not include static records, because static records do not have a time stamp.


    Excample of a dynamically created record:


    Static Records:

    Static records will not get scavenged, since they have a 0 time stamp. When viewing a static record, it will show as the following:

    However, regarding static records, if you use force age all records using the dnscmd /AgeAllRecords. If the “Delete the record when it becomes stale” box was checked at time of the record creating, it will set a TimeStamp on it, which will make it eligible for scavenging. Therefore, if you have an static records, host, cnames, etc, they will get scavenged, and I advise to take inventory of your static entries if you run this command. I would suggest not to, and just allow scavenging to take it’s time to do its thing. Be PATIENT!!!!




    Rough formula to go by: NoRefresh + Refresh * 2 + the point in time during the 3 day scavenge period.

    Here’s a chart showing when events occur with a 3-day NoRefresh, 3 day Refresh, and 3 day Scavenging. (Graphics from Don’t Be Afraid of Scavening. You must be patient):

    If you look at the chart, based on scavenging settings of a 3 day NoRefresh and 3 day Refresh, then it becomes eligible for scavenging the day after these two pass, so it will be the 7th day. Then it waits for the next scavenge cycle (I kind of call it the garbage collection point), which is somewhere withing the next 72 hours (based on the NoRefresh). So based on this chart, starting at 1/1/2008, the record becomes eligible on 1/7/2008, then it’s deleted (scavenged) on, in this case, on 1/10/2008, at 6am during the next 72 hour scavenge cycle. The 72 hour scavenge cycle in this case, is based on the 3day scavenge setting..

    That was a total of about 10-11 days, but it could have happened, as you can see in the chart, anytime between the 10th day and the 14th day.




    If you choose the default 7 day setting may take up to 4 weeks + 1 day (29 days) for scavenging to take place.



    AD Integrated zones – Where do you set it? – Enable it only on one server, and the timestamp will replicate with AD replication

    In summary, with using AD integrated zones, you just enable scavenging on one server, then the time stamp will replicate to other servers with the normal AD replication process. When AD integrated zones are involved, DNS uses an additional mechanism to control replicating the records’s time stamp behavior through the dnsTombstoned attribute.

    In addition, regarding enabling it on one server, Josh Jones [MSFT] quotes (in his blog, “Don’t be afraid of DNS Scavenging” ):

    “Although you can set every server hosting the zone to scavenge I recommend just having one. The logic for this is simple: If the one server fails to scavenge the world won’t end. You’ll have one place to look for the culprit and one set of logs to check. If on the other hand you have many servers set to scavenge you have many logs to check if scavenging fails. Worse yet, if things start disappearing unexpectedly you don’t want to go hopping from server to server looking for 2501 events.”

    For more specifics, and to not duplicate Josh Jones’ efforts, please read his blog for specific info – “Don’t be afraid of DNS Scavenging

    Don’t be afraid of DNS Scavenging, Josh Jones [MSFT], 19 Mar 2008 6:49 PM


    AD Integrated Zones and Scavenging – How does it do it? It uses the AD attribute called, “dnsTombstoned”

    Good article by Guy Teverovsky [MSFT], explaining how AD handles scavenging with records in an AD integrated zone, as well as what happens if say a machine who’s record is marked as dnsTombstoned, but the machine is reinstalled, which now has a new SID, and how it can’t update the original record –  the original host record is not removed immediately:

    DNS Scavenging internals (or what is the dnsTombstoned attribute) for AD Integrated zones, by Guy Teverovsky [MSFT], 23 Sep 2010


    Other articles on Scavenging:

    Optimizing your network to keep your DNS squeaky clean


    Enable Scavenging Screenshots

    Screenshots showing enabling scavenging with the default 7 Day NoRefresh, and 7 Day Refresh. Note that scavenging will not kick in until 1 day after these two periods combined, meaning 15 days later. And if you also notice, that after I enabled them, and ran dnscmd /AgeAllRecords, the static records still didn’t show as stamped. Eventually they will. That’s the “being patient” part.















    Note of Caution: T\the only problem with running this command, is it will timestamp all static records making them eligible for scavenging. Therefore, you may NOT want to do this.





    Note on the screenshot below (quoted from Don’t Be Afraid of Scavening. You must be patient)::
    “The Scavenging Period is how often this particular server will attempt to scavenge. When a server scavenges it will log a DNS event 2501 to indicate how many records were scavenged. An event 2502 will be logged if no records were scavenged. Only one server is required to scavenge since the zone data is replicated to all servers hosting the zone.

    Tip: You can tell exactly when a server will attempt to scavenge by taking the timestamp on the most recent EventID 2501 & Event ID 2502 events and adding the Scavenging period to it.

    Image from:


    Moral of the story: Be Patient!!



    Back to top of page>

    DNS Time stamp and Scavenging

    If the record was manually created, it won’t show a time stamp, however, if the record was dynamically registered, it will show a time stamp. If you manually create a record, the checkbox will not be checked to scavenge, however if it was dynamically registered, it will be checked.
    As for the server entries (such as from a DC), if you allow auto registration, which is done by default, and it gets scavenged, it gets re-registered anyway by the DC’s Netlogon service (for the SRV, LdapIpAddress and GcIpAddress records) and the operating system (for the A and PTR records). Unless you are seeing something going on that is affecting your environment, the default settings work fine, at least they do for me for all of my customers and installations I’ve worked in that I’ve set scavenging and forced DHCP to own the records so it can update the records it had registered at lease refresh time.

    Regarding the Active Directory dnsTombstoned Attribute

    DNS Scavenging internals (or what is the dnsTombstoned attribute) for AD Integrated zones
    Discuss the internal processing of DNS Scavenging.

    dnsTombstoned Records clean-up:
    Everyday at 2AM (non-configurable) the DNS server scans all DNS integrated zones in AD and determines whether the tombstoned record is ready to be deleted. The default retention time of the tombstoned records is 7 days. This value can be changed by the DsTombStoneinterval value (dnscmd w2k8r2dc01 /config /DsTombstoneInterval value) or by editing the registry under HKLM\CCS\Services\DNS\Parameters Value Name:DsTombstoneInterval

    Value Type: DWORD). The value is in seconds.

    At that point the DNS deletes the record.

    Back to top of page>


    Scavenging Refresh and No Refresh Settings Must be less than the DHCP Lease Period

    The scavenging period must be set less than the lease time. The way you have it currently set, you have two different settings but both are beyond the lease time. Due to both of these settings being different and beyond the lease time, is why you are getting inconsistencies, as I previously mentioned.

    For example: The 7 and 7 day intervals work hand in hand with a default DHCP lease time of 8 days. DHCP renewals are half the lease interval right, whcih is 4 days. If it doesn’t get renewed, then it waits until 87.5% of the lease time to renew, which is at the 7th day. If it doesn’t get renewed, then the lease is lost, and the DHCP client will attempt to get a new lease. Once the lease is lost at the 7th day, then if you left scavenging set to default, it will clean out that old lease entry from DNS in all zones it existed in.

    Therfore, if you have an 8 hour lease, you’ll need to set scavenging for 1 day, but that is not a recommended setting. It’s simply too low. Also an 8 hour lease tries to renew at 50% of the lease time, and if unsuccessful, at 87.5% of the lease time, which is at the 7th hour. Scavening needs to be set below that, but scavenging settings are in days, which is at 24 hours intervals, so there’s no possible way to set it below the lease time.

    Also, a lease time of 8 hours, or even 4 hours, as I’ve heard some admins have set it to, is really an aggressively short lease and can cause other problems elsewhere, such as with WINS and replication partners. I’ve seen errors in WINS in a partnership scenario where the data is constantly changing and WINS simply couldn’t keep up with the changes between partners.

    My suggestion is at least that if you want to keep an aggressively short lease, to at least make the lease period 2 days and scavenging 1 day.

    However, I’ve been in environments with the default 8 day lease and 7 day scavenging settings, along setting either using credentials so DHCP owns all records it updates, or using the DnsProxyUpdate group, and it works fine. If a laptop gets a record at 8am on a Monday, but unplugs and goes home and comes back on Thursday, the laptops will attempt to get the same lease. If the laptop doesn’t come back until Tuesday the following week, it will get a new lease and new IP, since DHCP owns the record, it simply updates it in DNS for the forward and reverse zones.

    To properly make it work using the DnsProxyUpdate group or using credentials, you must force DHCP to update ALL RECORDS, whether the client knows how to update or not or requests it or not (the bottom setting). This will force DHCP to own ALL records. If you do not set these settings, and the scavenging period is more than the lease, unexpected results will occur.

    Scenario: Choosing a Short DHCP Lease Time of 8 hours

    If you reduce the DHCP lease to 8 hours, a number of things can occur, such as increased AD Tombstoning of DNS entries, which will increase the AD NTDS.dit file size, as well as possibly an inconsistency with the records in DNS, as well as issues with WINS trying to keep up with the changes, which will be evident with WINS Event log error entries.

    Also keep in mind, with any DHCP client no matter what operating system, uses the DORA method, that is Discovery, Offer, Request, and Acknowledgement. The point in time a client will ask for a lease refresh is at the 50% mark, where it uses RA, or Request (for the current lease config it has), and Acknowledgment. If it can’t get it at the 50% mark after 3 attempts, it will wait until 7/8 of the lease time to broadcast out a refresh request until the end of the lease period. If it doesn’t get a renewal at the end of lease, the client machine removes the current config from its interface and has no IP.

    Therefore with an 8 hour lease, the refresh time is at 4 hours. That needs to be taken into account with additional traffic, and how DNS updates, as well as how WINS handles it with the contstant requests coming through.

    Regarding the WINS issue, I’ve seen this once at a customer site years ago. It’s always stuck to the back of my mind to keep this in mind when such a short lease is desired. I found  a default lease works fine, as long as scavenging is enabled (using default settings as well), including if the DHCP server is on a DC, adding the DHCP server to the DnsUpdateProxy group, or to alleviate the security issues with such as move, to rather supplying credentials for DHCP, so it owns all records it registers into DNS, in order so it can update the records as they change. Otherwise, expect issues to occur.

    (The following, which goes into much more detail of what is actually occuring, was compiled and posted by Chris Dent in the Microsoft DNS newsgroup.)

    Why would one choose 8 hours? Possibly to handle many laptops coming in and out of the network. So you would think a shorter lease time would work. However, keep in mind with any lease time, the point at which a client will ask for a lease refresh is at 50% of the lease time. Therefore, the client machine will asking for a refresh every four hours.

    This will result in a high rate of change in DNS, which may lead to a large number of tombstoned DNS entries. It would seem reasonable to reconsider the DHCP Lease duration, 8 hours is, after all, extremely short.

    Essentially you have:

    • The amount of AD Tombstoned Data is increasing because of Stale DNS records
    • The number of Stale DNS Records is high because of the (potential) rate of change of records in both Forward and Reverse Lookup
    • The rate of change must be somewhat proportional to changing leases in DHCP

    The DNS Record lifecycle:

    1. An A record is created (as a dnsNode in AD).
    2. When the Timestamp is no longer updated, and the Aging Intervals passes it’s aged setting, the A Record becomes Stale.
    3. Stale Records are removed from the active DNS system, and the AD dnsTombstoned attribute is set to TRUE.
    4. Tombstoned record exists for value of the DsTombstoneInterval attribute, which is 7 days by default.
    5. The DnsNode object is moved to the Deleted Objects for the length of time of the tombstoneLifetime attribute value.

    Note : The Active Directory Tombstone Lifetime is listed in the schema.ini and will be set during the promotion of the very first DC in the forest based on the Windows version used to install the first DC. This value does not change after upgrading all domain controllers to newer Windows versions or by changing the Domain or Forest Functional Levels. The entry in the schema.ini “tombstoneLifetime=<number of days>”  and can be changed. Therefore, this will tell you what the value is depending on what Windows operating system was used to install the very first domain controller in your infrastructure:

    • If the very first DC was installed using a Windows 2003 with integrated SP1 CD or newer, the Tombstone Lifetime Value is 120 days.
    • If the very first DC installed in the forest is Windows 2000 (any Service Pack), or Windows 2003 (pre-Windows 2003 SP1), the Tombstone LIfetime is 60 days.

    The values can be changed. Please read the following for information on how to change it:

    Active Directory Lingering Objects, Journal Wraps, Tombstone Lifetime, and Event IDs 13568, 13508, 1388, 1988, 2042, 2023
    (Scroll down to “Active Directory Tombstone Lifetime”) 

    Therefore, you either need to reduce the rate of change by increasing the lease duration, or deal with the inaccuracy in DNS, by limiting the Aging and Scavenging settings, or deal with an increasing directory size to store all this additional data. The directory size should level out eventually, when you reach the point where the number of tombstoned records being flushed is equal to the number being created.



    Back to top of page>

    DHCP Conflict Detection

    When DHCP provides a lease to a client, it tries to determine if there are no conflicts with another machine using the IP, which may have been inadvertently configured with a static IP configuration not realizing the IP is withing the Lease Scope.

    DHCP uses pings for conflict detection.

    Enable address conflict detection

    DHCP Best Practices
    Look for: “Use server-side conflict detection on DHCP servers only when it is needed”

    DHCP Server Conflict Detection

    I’ve been asked a few times in the past if DHCP Conflict detection pings are the same as the pings when one uses a command prompt to ping a host. The answer to that is yes.

    To expand, the term “ping” is short for “Packet Internet Groper.” Pings are based on ICMP packets, just as you would ping an IP address, the DHCP server does the same to detect conflicts. It’s sumamrized in the following link by searching the sentence, “When conflict detection attempts are set, the DHCP server uses the Packet Internet Groper (ping) process …”

    DHCP Server Conflict Detection

    Specific info on the Ping command:

    Ping – General Summary

    Internet Control Message Protocol – Technical Summary

    Back to top of page>

    DHCP Lease has a “pen” or “pencil” Icon

    If a record shows up in the DHCP Lease list with a pen icon, it means that a write is pending. If it doesn’t disappear, it may mean it is trying to register into a zone that does not exist on the DNS servers. This happens in cases where the client machine is not joined to the domain and has a missing or different Primary DNS Suffix than the zone in DNS.

    Registration can only occur into a zone that exists on DNS and that zone updates have been configured to allow updates.

    If this is the case, go into the client machine’s IP properties, and perform the following:

    • On the DNS tab in TCP/IP Advanced properties, clear the “Register this connection’s addresses in DNS”
    • Clear the  “Use this connection’s DNS suffix in DNS registration” check boxes,
    • The DHCP Server will fill these in for you and register using the domain name in Option 015.


    DHCP console icons reference

    Back to top of page>


    Records & timestamps, and the lack of timestamps

    If the record was manually created, it won’t show a time stamp, however, if the record was dynamically registered, it will show a time stamp. My guess is the records you are referring to were manually created. If you manually create a record, the checkbox will not be checked to scavenge, however if it was dynamically registered, it will be checked.

    I just tested this with Windows 2003 DNS. When I had built a few servers for a customer and let them auto register, they had a timestamp and the scavenge checkbox was checked. For the records I manually created, such as internal www records, and others, they did not have a time stamp and were not checked to scavenge.

    Even if you allow auto registration, which I do by default, and it gets scavenged, it gets re-registered anyway by the OS. Unless you are seeing something going on that is affecting your environment, the default settings work fine, at least they do for me for all of my customers and installations I’ve worked in that I’ve set scavenging and forced DHCP to own the records so it can update the records it had registered at lease refresh time.

    Back to top of page>


    Related Links

    How to configure DNS dynamic updates in Windows Server 2003.

    Using DNS servers with DHCP (Contains information on the DnsUpdateProxy group and its usage) (WS.10).aspx

    Using DNS Aging and Scavenging
    Aging and scavenging of stale resource records are features of Domain Name System (DNS) that are available when you deploy your server with primary zones.

    Microsoft Enterprise Networking Team : Don’t be afraid of DNS, Mar 19, 2008
    DNS Scavenging is a great answer to a problem that has been nagging everyone since RFC 2136 came out way back in 1997. patient.aspx

    How DHCP Technology Works

    From Ulf B. Simon Weidner:
    DHCP, DNS and the DNSUpdateProxy-Group
    I had a discussion in the Newsgroups lately about DHCP and the DNSUpdateProxy-Group which is used to write unsecured DNS-Entries to a DNS-Zone which only …

    And from Kevin Goodnecht:
    Setting up DHCP for DNS registrations

    317590 – HOW TO Configure DNS Dynamic Update in Windows 2000 and DNSUpdateProxy Group:

    816592 – How to configure DNS dynamic updates in Windows Server 2003:

    Follow up discussion on the DNSUpdateProxy-Group:

    Back to top of page>



    Comments, Corrections and Suggestions are Welcomed

    Ace Fekay


    TCP Chimney and RSS Features May Cause Slow File Transfers or Cause Connectivity Problems


    Discusses possible cause of slow file transfer and connectivity with Windows 2003 SP2, and all newer operating systems due to TCP Chimney Offloading.

    Original – 5/2009
    Edit: 8/19/2009 – Reworded for syntax, as well as included a disclaimer about DC multihoming, and restructured paragraphs to be more concise.
    10/26/2014 – Updated.


    You notice that network shares (UNC and mapped drives) disconnect from the server, after a server has been running for a period of time such as a couple of weeks, and in some cases with heavy usage, a few hours. A server restart temporarily fixes the issue only to return.

    This may be due to the new RSS TCP Chimney Offload feature enabled on 2003 SP2 and newer servers.

    You may or may not be seeing the following errors when this occurs:
    System Error 64
    System Error 53


    Disclaimer based on your infrastructure configuration

    I just want to point out a common configuration error before making any changes and assuming this issue is to blame on the RSS TCP Chimney feature. Any one of the following configurations can contribute or be the sole cause of this issue. Therefore, please make sure none of the following exist:

    1. None of the machines (DCs, member servers and/or desktops and laptops), have been configured with an external DNS server, the router as a DNS server, or the ISP’s DNS server. This can surely cause this type of issue.

    2. The AD DNS domain name is not a single label name, such as “domain” and not the minimally required format of “domain.something.”

    3. The DCs are not multihomed. A multihomed DC means it may have more than one unteamed NIC on separate subnets or unteamed and on the same subnet, or a single NIC with more than one IP address.

    4. RRAS is not installed on any of the DCs. RRAS introduces extra interfaces that get registered into DNS, which causes issues just as a multihomed DC.

    For more information on DC multihoming and RRAS on a DC, and DNS implications such a configuration *will* cause, please read the following blog:

    Multihomed DCs with DNS, RRAS, and/or PPPoE adapters

    TCP Chimney Offload overview

    TCP Chimney Offload is a networking technology that helps transfer the workload from the CPU to a network adapter during network data transfer. In Windows Server 2008, TCP Chimney Offload enables the Windows networking subsystem to offload the processing of a TCP/IP connection to a network adapter that includes special support for TCP/IP offload processing.

    TCP Chimney Offload is available in all versions of Windows Server 2008 and Windows Vista. Both TCP/IPv4 connections and TCP/IPv6 connections can be offloaded if the network adapter supports this feature.

    You must check with your network adapter vendor’s documentation or support department, to find out if the adapter supports this feature or not. If not, I would suggest to disable the TCP Chimney/RSS feature in Windows.

    Two ways to handle this issue

    Option 1. Disable RSS using the netsh command (preferred)
    Option 2. Disable RSS in the registry

    Option 1

    Disable RSS using the netsh command:

    netsh interface tcp set global rss=disabled
    netsh interface tcp set global autotuninglevel=disabled
    Reboot the server

    More information on RSS and TCP Chimney Offloading on a Windows 2008 server can be found at:

    Information about the TCP Chimney Offload, Receive Side Scaling, and Network Direct Memory Access features in Windows Server 2008


    Option 2

    Disable RSS in the Registry

    Add a DWORD registry key value for
    and setting it to 0.  A reboot is required to make the value go in to effect.
    Set DisableTaskOffload in the Registry

    Use the steps in KB904946 (link posted below) to create a DWORD value for
    and set it to 1.

    A reboot is required to make this value go in to effect.

    More information on the registry changes can be found at:

    You cannot host TCP connections when Receive Side Scaling is enabled in Windows Server 2003 with Service Pack 2


    More info and Related Links

    Information about the TCP Chimney Offload, Receive Side Scaling, and Network Direct Memory Access features in Windows Server 2008

    You cannot host TCP connections when Receive Side Scaling is enabled in Windows Server 2003 with Service Pack 2

    Vista slow after SP2 installed on Windows 2003 Server (SBS or non-SBS) or using Windows 2008

    Windows 2003 service pack 2 known issues on Small Business Server 2003

    Susan Bradley: Vista slow after SP2 installed

    You experience intermittent communication failure between computers that are running Windows XP or Windows Server 2003

    Common Networking Issues After Applying Windows Server 2003 SP2 on SBS



    I hope this helped you to easily configure your time service and what to do if it didn’t work.

    Ace Fekay
    MVP, MCT, MCSE 2012, MCITP EA & MCTS Windows 2008/R2, Exchange 2013, 2010 EA & 2007, MCSE & MCSA 2003/2000, MCSA Messaging 2003
    Microsoft Certified Trainer
    Microsoft MVP – Directory Services

    clip_image002[6][2] clip_image004[6][2] clip_image006[6][2] clip_image008[6][2] clip_image010[6][2] clip_image012[6][2] clip_image014[6][2]

    Complete List of Technical Blogs:

    This posting is provided AS-IS with no warranties or guarantees and confers no rights.

    Domain Rename With or Without Exchange

    Domain Rename With or Without Exchange

    Ace Fekay, MCT, MVP, MCITP EA, Exchange 2010 Enterprise Administrator, MCTS Windows 2008, Exchange 2010 & Exchange 2007, MCSE 2003/2000, MCSA Messaging 2003
    Microsoft Certified Trainer
    Microsoft MVP: Directory Services
    Active Directory, Exchange and Windows Infrastructure Engineer

    Originally Published 4/2009
    3/3/2010   – General Syntax revision
    10/11/2010 – Added additional information regarding DNS names and underscores, and Exchange 2010



    I thought to offer my notes on domain renames, since it appears to be a necessary evil in some cases that can confuse even the experienced admin. There are a number of reasons to rename a domain, such as:

    1. Single Label Name – The DNS Domain Name is a a single label, such as “DOMAIN” rather than the necessary minimal of “,” “,” “domain.local,” etc.

    2. Underscore in the DNS domain name – An underscore is an illegal DNS character, and AD relies on DNS.

    The internal domain name conflicts with a public domain name that belongs to someone else – This can hinder the abiilty to purchase a UC/SAN certificate for Exchange 2007 or 2010. See the following blog for more information on this issue:
    Exchange 2007 UC/SAN Certificate

    3. Company Name Change

    4. Acquisition

    5. The admin is not happy with the DNS domain name – Ok, this is a lot of work just because you’re not happy. But so as it may be, some will do it because of this reason.


    I hope my notes are helpful with anyone facing this task. But as I said, I would rather perform, and recommend a migration to a fresh installation instead of a rename.


    Before we start

    Examples of applications that are incompatible with domain rename include but are not limited to the following products:

    • Microsoft Exchange 2000
    • Microsoft Exchange 2007
    • Microsoft Exchange 2010
    • Microsoft Internet Security and Acceleration (ISA) Server 2004
    • Microsoft Live Communications Server 2005
    • Microsoft Operations Manager 2005
    • Microsoft SharePoint Portal Server 2003
    • Microsoft Systems Management Server (SMS) 2003
    • Microsoft Office Communications Server 2007


    Are you sure you want to rename your domain?

    Ok, so are you sure you want to rename the domain? PLEASE Read up on it first in this link 

    How Domain Rename Works, Updated: June 3, 2010 :


    Domain Rename Procedure Notes


    1. The Domain and Forest functional levels must be set to minimal 2003. This means no Windows 2000 domain controllers can exist in the Forest.

    2. If Exchange 2000 or Exchange 2007 is installed, it is not supported. Exchange 2000 can be upgraded to Exchange 2003, however Exchange 2007 will need to be removed prior to the procedure. More info below on Exchange 2007.

    Once you’re met the prerequisites, you can now procede with the rename. I did not outline a step by step here, since there are numerous documents that exist outining the steps, but I wanted to consolidate specific links I thought will be helpful, including the Microsoft Technet Webcast, and Microsoft’s Step By Step Guide to implementing a domain rename.

    Support WebCast Microsoft Windows Server 2003 Implementing an Active Directory Domain Rename Operation:

    TechNet Support WebCast: Renaming domains when Microsoft Exchange Server 2003 is in the Active Directory

    Step-by-Step Guide to Implementing Domain Rename:

    TechRepublic Tutorial: RenDom helps you to rename a Windows .NET domain
    Workstations MUST be rebooted twice after a rename so they reflect the new NetBIOS name.

    Domain Rename Part 1 – Setup

    Domain Rename Part 2 – Renaming

    Domain Rename Part 3 – Exchange 2003

    [DOC] Download Details – Microsoft – Step-by-Step Guide to Implementing Domain Rename:

    How Domain Rename Works

    Step-by-Step Guide to Implementing Domain Rename
    Understanding How Domain Rename Works
    Download: Windows Server 2003 Domain Rename Tools


    If a NetBIOS Name Change Was Chosen

    For Workstations and member servers to reflect the new name in the drop-down domain list selection box, they must be rebooted twice. The following paragraph was quoted from the Step By Step Guide at:

    Step-by-Step Guide to Implementing Domain Rename:

    “Reboot member computers. Reboot twice all member workstations, member servers,  and standalone servers (excluding domain controllers) that are running Windows 2000, Windows XP, and Windows Server 2003 Server family in the renamed domains in your forest. Rebooting twice ensures that each member computer learns of the domain name changes (LSA policy changes) and propagates them to all applications and services running on the member computer. Note that each computer must be restarted by logging into the computer and using the Shutdown/Restart administrative option. Computers must not be restarted by turning off the machine power and then turning it back on.”


    If a PKI infrastructure exist…

    The PKI infrastructure will need to be removed first prior to a domain rename:

    How to Manually Remove an Enterprise Windows Certificate Authority from Windows 2000/2003 Domain

    How to decommission a Windows enterprise certification authority and how to remove all related objects from Windows Server 2003 and from Windows Server 2000

    HOWTO: Move a certificate authority to a new server running on a 2003 or 2008 CA, Standard or Enterprise

    HOWTO: Move a certificate authority to a new server running on a domain controller (2003).


    Is Exchange In The Picture?

    Exchange 2000

    Exchange 2000 does not support a rename. Your main option is to upgrade Exchange 2000 to 2003. If you do not have the option to upgrade to Exchange 2003, SP1 (preferred SP2), you can Exmerge all of your mailboxes to PSTs, uninstall Exchange 2000, run the domain rename operation, then reinstall Exchange 2000, and use Exmerge to pump the mailboxes back in the user’s newly created mailbox accounts.

    Exchange 2003

    Exchange 2003 supports a rename. In order to support it, it must be minimally at SP1.

    Rename a Windows 2003 Forest with Exchange 2003 installed (if you don’t have Exchange, you can ignore the Exchange part in the tutorial)

    Here’s what you need as well for Exchange 2003 renames:

    Supplemental steps for using the Exchange Server Domain Rename Fixup tool together with the Windows Server 2003 domain rename tools:

    Exchange 2007 or Exchange 2010

    As of this writing, unfortunately, Exchange 2007 nor Exchagne 2010 support a domain rename. The choices are:

    1. Export your mailboxes and Public Folders to PST files, uninstall Exchange 2007, then rename the domain, then reinstall Exchange 2007. I know it is easier said then done, but that seems to be the only option at this time.
    2. Migrate to a fresh, pristine forest with the proper name.

    Your best bet is Option #2 – Simply create a new domain in a new forest with the correct name, install Exchange 2007, use ADMT to migrate the user accounts, then perform a move mailbox to move the mailboxes and Public Folders from the old to the new forest.


    Exchange 2007 and Exchange 2010 domain rename related Links

    Introduction to Administering Active Directory Domain Rename, Jul 9, 2010
    The domain rename operation is not supported in Microsoft Exchange Server 2007 or Exchange Server 2010. DNS domain rename is supported in Exchange 2003. However, renaming of the NetBIOS domain name is not supported in any version of Exchange Server.

    If Exchange 2007 is in use, a domain rename is not supported:
    The Microsoft Exchange System Attendant service does not start on a computer that is running Exchange Server 2007 after you rename a Windows Server 2003 domain:

    Exchange 2007 and Domain Rename – You can’t perform a domain rename with Exchange 2007 is installed.

    This article will show you how to use a temp domain with Exchange 2007 installed to move all of your mailboxes and PFs to this temp organization, then uninstall Exchange 2007, rename the domain, re-install Exchange 2007, then move the mailboxes and PFs back to the original organization:


    Related Links

    How to raise domain and forest functional levels in Widows Server
    […] The attribute is msDS-Behavior-Version on the CN=Partitions, CN=Configuration, DC=ForestRootDom, DC=tld object. Value of 0 or not set=mixed level forest […]

    Error messages encountered on renaming domain

    The following was quoted from:
    “Keep in mind after a rename procedure, the DC’s Primary DNS Suffix is not automatically changed to match the new domain name. You are required to change the Primary DNS Suffix to match the new name. In other words, unlike the names of member computers, the DNS names of domain controllers in a renamed domain will remain unchanged.  The domain controllers can be renamed in a separate step, using a special domain controller rename procedure, after the domain rename operation is complete. You must double-check ALL domain members to insure that their Primary DNS Suffix matches the new domain name.”

    The DNS suffix of the computer name of a new domain controller may not match the name of the domain after you upgrade a Windows NT 4.0 primary domain controller (PDC) to Windows 2000;EN-US;257623

    Windows Server 2003 Active Directory Domain Rename Tools:




    Comments, suggestions and corrections are welcomed!

    Ace Fekay

    Multihomed DCs with DNS, RRAS, and/or PPPoE adapters

    Multihomed DCs with DNS, RRAS, and/or PPPoE adapters

    Ace Fekay, MCT, MVP, MCITP EA, Exchange 2010 Enterprise Administrator, MCTS Windows 2008, Exchange 2010 & Exchange 2007, MCSE 2003/2000, MCSA Messaging 2003
    Microsoft Certified Trainer
    Microsoft MVP: Directory Services
    Active Directory, Exchange and Windows Infrastructure Engineer

    Published 4/2009
    First compiled January, 2003
    Updated July, 2006
    Updated 5/2010 with a new Step #10
    Updated 10/14/2010 adding a new section about AD communications across a NAT
    Updated 1/22/2011 – Added about NIC teaming NOT supported by Microsoft. Better to disable the additional NIC then use teaming.


    What is a Multihomed DC?

    A Multihomed DC is a domain controller with more than one NIC and/or IP address, and/or RRAS installed on it (for VPN, routing, dialup, etc), or with a PPPoE adapter from your ISP’s ADSL line.

    Multihomed DCs wiill cause numerous issues. The only exception to the rule are SBS servers, but that is a completely different topic which I will not address in this blog, but I can add that even the SBS gurus recommend to single-home it.

    It’s highly recommended to single-home all DCs and use a non-DC for multihoming purposes. If it’s the internet gateway, such as using the DC as a NAT device, not only will the multihomed DC cause AD problems, but you’re also exposing the DC directly on the internet. To overcome both of these issues, I recommend disabling the outer NIC and purchasing an inexpensive cable/DSL firewall/router or other type of firewall/NAT device for this purpose. My preference is a Cisco ASA device. There are also less expensive options, such as a Linksys wireless N router for less than USD $150, and there are less expensive models under it. If the hardware device is compromised by an internet attacker remotely, it can’t further compromise the rest of the internal network, nor your DC.

    If you have a PPPoE adapter installed (such as the WinPoet software from Verizon for ADSL lines), it will cause the same problems, for after all, they are additional interfaces.


    Internet Connection Services (ICS) on a DC

    If attempting to use Internet Connection Serivices (ICS) on a DC, this further complicates matters with DC functionality, because ICS has it’s own built-in DNS and DHCP service that is non-configurable, and cannot be fixed with the following steps outlined in this article. I suggest disabling it.


    AD’s reliance on DNS

    To explain why multhoming a DC causes problems will require a little background on AD and DNS.

    You can’t use your ISP’s DNS in your DC and workstation NIC properties

    Let’s put this into layman’s terms: Let’s say the NFL SUperbowl is tomorrow, and I invited a few friends over. I went out and bought two cases of beer for the game. I put them into the refridgerator. So I know those cases are in the rerfidgerator before I went to bed. I wake up to find half the case is gone. No one else was in the house last night. I walk out front and see my neighbor washing his car. I yell over to him, “Hey, do you know where my beer went that I had in my refridgerator?” He responds that he has no idea. Nor that I would expect him to know. THis is the same as if I used Comcast’s or some other ISP’s DNS address in my DC or my workstations. When the workstation or DC needs AD communications and functionality, it will be asking the Comast DNS servers, “Hey, what is the IP address of my domain controller?” Will it have that answer? No, it won’t.

    To understand the specifics behind AD’s reliance on DNS, please read the following article:

    Active Directory’s Reliance on DNS, and using an ISP’s DNS address:

    Also, you can’t mix an external DNS address with your internal address. THis is due to the way the client side resolver service works. You need to only use your own internal DNS address. For efficient internet name resolution, you can configure a Forwarder to your ISP’s DNS server. That’s done in DNS properties, Forwarders tab. To understand this process, please read the following article:

    DNS, WINS NetBIOS & the Client Side Resolver, Browser Service, Disabling NetBIOS, Direct Hosted SMB (DirectSMB), If One DC is Down Does a Client logon to Another DC, and DNS Forwarders Algorithm if you have multiple forwarders.

    Bascially, AD required DNS

    Basically, AD requires DNS. DNS stores AD’s resource and service locations in the form of SRV records, hence how everything that is part of the domain will find resources in the domain. If the ISP’s DNS is configured in the any of the internal AD member machines’ IP properties, (including all client machines and DCs), the machines will be asking the ISP’s DNS ‘where is the domain controller for my domain?”, whenever it needs to perform a function, (such as a logon request, replication request, querying and applying GPOs, etc). Unfortunately, the ISP’s DNS does not have that info and they reply with an “I dunno know”, and things just fail. Unfortunately, the ISP’s (or your router as a DNS server) DNS doesn’t have information or records about your internal private AD domain, and they shouldn’t have that sort of information.

    Also, AD registers certain records in DNS in the form of SRV records that signify AD’s resource and service locations. When there are multiple NICs, each NIC registers. IF a client, or another DC queries DNS for this DC, it may get the wrong record. One factor controlling this is Round Robin. If a DC or client on another subnet that the DC is not configured on queries for it, Round Robin will kick in offering one or the other. If the wrong one gets offered, it may not have a route to it. On the other hand, Subnetmask Priortization will ensure a querying client will get an IP that corresponds to the subnet it’s on, which will work.

    AD’s reliance on DNS MUST BE FULLY understood to understand why multihoming causes problems. Once again, to understand the specifics behind AD’s reliance on DNS, please read the following article:

    Active Directory’s Reliance on DNS, and using an ISP’s DNS address:

    After reading the above article. you should now understand and realize that if you are using your ISP’s DNS addresses, some other external DNS address that doesn’t host the internal AD zone, or using your router as a DNS address in your IP configuration (DCs or workstations), they must be removed. If these external DNS addresses are used, it’s guaranteed to cause additional problems. If not sure what I mean that you can’t use a DNS server other than your internal DNS servers, please re-read the above article.


     Errors caused by using a DNS address that does not host the AD zone

    I usually see errors (GPOs not working, can’t find the domain, RPC issues, replication taking a nose dive, dcdiag and replmon errors, etc), when the ISP’s or some other non-internal DNS servers are listed on a client, DCs and/or member servers, or with multihomed DCs. If you have an ISP’s (or some other outside DNS server or even using your router as a DNS server) DNS addresses in your IP configuration (all DCs, member servers and clients), they need to be REMOVED and ONLY use the internal DNS server(s). Otherwise, expect problems. Surprisingly I’ve heard of some customers say, “I’ve been using it for years this way and have never had problems.” Consider yourself lucky.


    If you have multiple IPs on one NIC, you can control which gets registered into DNS

    You can control the default DNS registration process of registering multiple IPs that have been configured on a single NIC. If this is the scenario, then you won’t need to follow the procedure later in this blog. However, if you have multiple NICs, this does not work.

    “All IP addresses are registered on the DNS servers when the IP addresses are assigned to one network adapter on a computer that is running Windows Server 2008 SP2 or Windows Vista SP2”


    To insure everything works, stick with one NIC

    Since this DC is multi-homed, it requires additional configuration to prevent the public interface addresses from being registered in DNS. This creates a problem for internal clients locating AD to authenticate and find other services and resources such as the Global Catalog, file sharing  and the SYSVOL DFS share and can cause GPO errors with Userenv 1000 events to be logged, authenticating to shares and printers, logging on takes forever, among numerous other issues.

    But if you like, there are some registry changes to eliminate the registration of the external NIC or simply use the internal networking routing to allow access.

    Another problem is the DC now becomes part of two Sites. This is another issue that can be problematic.

    But believe me, it’s much easier to just get a separate NAT device or multihome a non-DC then having to alter the DC. If the both NICs are internal, I would suggest to pick a subnet, team the NICs and allow your internal routers handle the traffic between subnets – Good luck!


    NIC Teaming on a Domain Controller – Not recommended nor Supported by Microsoft!

    Although teaming sounds like a good idea to eliminate a multihomed scenario for such cases where both NICs are on the same segment and you have the NIC vendor software installed that offers teaming, but I must point out that teaming NICs on DCs, or any other servers, is not recommended, nor is it supported by Microsoft:

    Teamed network cards for domain controllers? (Thread Answered by a great write-up by Jared Crandall, former Microsoft Support Engineer)

    Using teaming adapters with network load balancing may cause network problems

    however did you know Nic teaming NICs on a DC, or any other Windows box is not a good idea,



    The following are the manual steps to configure a Multihomed DC

    1. Insure that all the NICS only point to your internal DNS server(s) only and none others, such as your ISP’s DNS servers’ IP addresses.

    2. In Network & Dialup properties, Advanced Menu item, Advanced Settings, move the internal NIC (the network that AD is on) to the top of the binding order (top of the list).

    3. Disable the ability for the outer NIC to register. The procedure, as mentioned, involves identifying the outer NIC’s GUID number. The following link will show you how:

    246804 – How to Enable-Disable Windows 2000 Dynamic DNS Registrations (per NIC too):

    4. Disable NetBIOS on the outside NIC. That is performed by choosing to disable NetBIOS in IP Properties, Advanced, and you will find that under the “WINS” tab.
    You may want to look at step #3 in the following article to show you how to disable NetBIOS on the RRAS interfaces if this is a RRAS server.

    Chapter 11 – NetBIOS over TCP/IP

    Or enable/disable NetBIOS on an interface in the registry:

    To do it in the registry  but you will need to identify the GUID of that interface – (this may not apply to PPP interfaces)
    HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\NetBT\Parameters\Interfaces, find the GUID(s) with NetbiosOptions set to 0 and set them to 2.

    Using WMIC:

    First, get the list of interfaces:
    wmic nicconfig get caption,index,TcpipNetbiosOptions

    Then use the “index number” in the next command:
    wmic nicconfig where index=1 call SetTcpipNetbios 2

    SetTcpopNetbios options are:

    0 – Use NetBIOS setting from the DHCP server
    1 – Enable NetBIOS over TCP/IP
    2 – Disable NetBIOS over TCP/IP

    More info on the wmic commands and the registry entries can be found in this forum thread link:

    Thread – Configuring NetBIOS over TCP/IP

    Configure TCP/IP to use WINS  

    A standard Windows service, called the “Browser service”, provides the list of machines, workgroup and domain names that you see in “My Network Places” (or the legacy term “Network Neighborhood”). The Browser service relies on the NetBIOS service. One major requirement of NetBIOS service is a machine can only have one name to one IP address. It’s sort of a fingerprint. You can’t have two brothers named Darrell. A multihomed machine will cause duplicate name errors on itself because Windows sees itself with the same name in the Browse List (My Network Places), but with different IPs. You can only have one, hence the error generated.

    5. Disable the “File and Print Service” and disable the “MS Client Service” on the outer NIC. That is done in NIC properties by unchecking the respective service under the general properties page. If you need these services on the outside NIC (which is unlikely), which allow other machines to connect to your machine for accessing resource on your machine (shared folders, printers, etc.), then you will probably need to keep them enabled.

    6. Uncheck “Register this connection” under IP properties, Advanced settings, “DNS” tab. 

    7. Delete the outer NIC IP address, disable Netlogon registration, and manually create the required records

          a. In DNS under the zone name, (your DNS domain name), delete the outer NIC’s IP references for the “LdapIpAddress”. 

          b. If this is a GC, you will need to delete the GC IP record as well (the “GcIpAddress”). To do that, in the DNS console, under the zone name, you will see the _msdcs folder. Under the _msdcs folder, you will see the _gc folder. To the right, you will see the IP address referencing the GC address. That is called the GcIpAddress. Delete the IP addresses referencing the outer NIC.

                1. To stop these two records from registering that information, use the steps provided in the links below:

                    Private Network Interfaces on a Domain Controller Are Registered in DNS

                 2.. The one section of the article that disables these records is done with this registry entry:

                       (Create this Multi-String Value under it):
                        Registry value: DnsAvoidRegisterRecords
                        Data type: REG_MULTI_SZ
                        Values: LdapIpAddress

                         The following link provides more information on the LdapIpAddress and GcIpAddress, as well as other Netlogon Service records:

                          Restrict the DNS SRV resource records updated by the Netlogon service[includingGC]:

                    3. Then you will need to manually create GcIpAddress and IpAddress records in DNS with the IP addresses that you need for the DC. To create the LdapIpAddress, manually create a new host under the domain, but leave the “hostname” field blank, and provide the internal IP of the DC, which results in a record that  looks like:
    (same as parent) A              ( is used for this example)

                     4. You need to also manually create the GcIpAddress as well, if this is a GC. That would be under the _msdcs._gc SRV record under the zone. It is created in the same fashion as the LdapIpAddress mentioned above.

    8. In the DNS console, right click the server name, choose properties, then under the “Interfaces” tab, force it only to listen to the internal NIC’s IP address, and not the IP address of the outer NIC.

    9. Since this is also a DNS server, the IPs from all NICs will register, even if you tell it not to in the NIC properties. See this to show you how to stop that behavior (this procedure is for Windows 2000, but will also work for Windows 2003):

    275554 – The Host’s A Record Is Registered in DNS After You Choose Not to Register the Connection’s Address:  

    10. Disable the round robin functionality on the DNS server. To do so: (This step added 5/2010)
                        1. Click Start, click Settings, click Administrative Tools, and then click DNS.
                        2. Open the properties for the DNS server’s name.

    11. If you haven’t done so, configure a forwarder. You can use and, if not sure which DNS to forward to until you’ve got the DNS address of your ISP. How to set a forwarder? Good question. Depending on your operating system, choose one of the following articles, depending on your operating system.

    300202 – HOW TO: Configure DNS for Internet Access in Windows 2000 
    323380 – HOW TO: Configure DNS for Internet Access in Windows Server 2003 (How to configure a forwarder): 

    Configure a DNS Server to Use Forwarders – Windows 2008 and 2008 R2

    Active Directory and NAT

    I thought to touch base on this overlooked fact about AD communication through a NAT.

    If a planned resources is to be provided in the AD infrastructure that uses AD authentication (Kerberos) that must traverse a NAT, it basically won’t work. This is due to secure RPC communications and NAT not being able to translate the traffic due to the encryption. If you really need to make it work, there are solutions to work around it, such as a Direct VPN between the services across the NAT devices, or additional NICs directly connecting them. More on it in this link, and Microsoft’s take and solution on it:

    Description of support boundaries for Active Directory over NAT;en-us;978772&sd=rss&spid=12925

    Active Directory communication fails on multihomed domain controllers 


    Source IP address selection on a Multi-Homed Windows Computer

    There is often confusion about how a computer chooses which adapter to use when sending traffic. This blog describes the process by which a network adapter is chosen for an outbound connection on a multiple-homed computer, and how a local source IP address is chosen for that connection.

    Source IP address selection on a Multi-Homed Windows Computer


    For multihomed non-DCs that have DNS installed: 

    In instances where you are running a separate DNS server internally to host public records and the server is configured with a private IP and different internal name than your hostname server records, you will need to disable registration due to the NS and SOA records that get created and manually create the records under the Nameserver tab, and change the SOA record under the General tab. To disable registration:

    To disable registration on Windows 2003 SP2 and 2008 and newer:

    The following registry entries are located under HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Tcpip\Parameters.

    RegistrationEnabled    (This DWORD registry entry is a global setting that affects all interfaces on a machine.)
    Value = 0   (Disabled = 0, Enabled =1)

    More info on these registry settings can be found here:

     Windows 2003 & 2008 DNS Registry Settings:


    Related Links

    More links to read up and understand what is going on with multihoming and the implications it causes.

    Multihoming a Windows Server, by Gunner

    292822 – Name Resolution and Connectivity Issues on Windows 2000 Domain Controller with Routing and Remote Access and DNS Insta {DNS and RRAS and unwanted IPs registering]: 

    Active Directory communication fails on multihomed domain controllers 

    246804 – How to enable or disable DNS updates in Windows 2000 and in Windows Server 2003  

    295328 – Private Network Interfaces on a Domain Controller Are Registered in DNS [also shows DnsAvoidRegisterRecords LdapIpAddress to avoid reg sameasparent private IP]:  

    306602 – How to Optimize the Location of a DC or GC That Resides Outside of a Client’s Site [Includes info LdapIpAddress and GcIpAddress information and the SRV mnemonic values]: 

    825036 – Best practices for DNS client settings in Windows 2000 Server and in Windows Server 2003 (including how-to configure a forwarder): 

    291382 – Frequently asked questions about Windows 2000 DNS and Windows Server 2003 DNS 

    296379 – How to Disable NetBIOS on an Incoming Remote Access Interface [Registry Entry]: 

    Rid Pool Errors and other multihomed DC errors, and how to configure a multihomed DC, Ace Fekay, 24 Feb 2006  

    257623 257623 Domain Controller’s Domain Name System Suffix Does Not Match Domain Name

    Additonal Links added 5/21/2010:

    157025 – Default Gateway Configuration for Multihomed Computers;en-us;157025&Product=win2000

    Default gateways

    Default Gateway Behavior for Windows TCP/IP

    159168 – Multiple Default Gateways Can Cause Connectivity Problems

    Name resolution and connectivity issues on a Routing and Remote Access
    Server that also runs DNS or WINS

    272294 – Active Directory Communication Fails on Multihomed Domain

    191611 – Symptoms of Multihomed Browsers;EN-US;191611

    Microsoft Windows XP – Multihoming Considerations

    Active Directory’s Reliance on DNS, and using an ISP’s DNS address

    Active Directory’s Reliance on DNS, and using an ISP’s DNS address

    Ace Fekay, MCT, MVP, MCITP EA, Exchange 2010 Enterprise Administrator, MCTS Windows 2008, Exchange 2010 & Exchange 2007, MCSE 2003/2000, MCSA Messaging 2003
      Microsoft Certified Trainer
      Microsoft MVP: Directory Services
      Active Directory, Exchange and Windows Infrastructure Engineer

    Compiled 5/2007, Edited 9/18/09 to add info regarding desktops, Updated 6/14/2010


    You wake up and get ready for work. You sit down and have a bowl of cereal. You crack open a full gallon of milk. Now there’s a little less in the gallon, but you know you have plenty of milk for the next couple of days. You walk out of your house and drive off to work. Upon returning, you find the milk is missing. You know you had some milk left over when you left for work in morning. You walk out front and see your neighbor just happens to be outside. You walk over to him and ask him, “Do you know what happen to my milk?” He just stares at you not knowing what you’re talking about.

    Can your neighbor, an outside entitiy to your internal household, respond to that? The same thing is occuring when you use an outside DNS server in your NIC properties (whether on the DC, member servers and/or client machines). If  the machines are set to use an outside DNS address, then your machines are literally asking an outside entity, “What’s the IP address of my domain controller?” The outside DNS servers do NOT have that answer. 

    Using an ISP’s DNS

    What will happen if you use an ISP’s DNS addess, or a router as a DNS address on a DC or client machine, is the machine (whether a DC or client), will ask the ISP’s DNS, “What is my DC’s IP address? I need to know because I would like to send a logon request.” The ISP’s DNS doesn’t have that answer. Their DNS servers do not host the your internal AD zone name therefore, they have no information about your internal AD network. It’s like me asking that guy down the street that I’ve never met, “Hey you, where did all the beer or milk go in my refridgerator?” He won’t have that answer either. 🙂

    I’ve read and responded to numerous newsgroup and forums posts requesting assistance, as well as new customers I’ve been called upon to fix issues, with such complaints as taking a long time to login, can’t access printers or mapped drives, Outlook fails to find the Exchange servers, among other issues.

    I’ve also seen other errors such as GPOs not working, can’t find the domain, RPC issues, Exchange profusely failing and its services not wanting to start, users complaining they can’t get their emails, etc, when the ISP’s DNS servers are listed on a client, DCs and/or member servers, or with  DCs.

    After a short investigation, I’ve come to find that the domain controllers network properties have included either an ISP’s DNS address, the ISP’s router’s IP address, or some other external DNS server as an IP address in the NIC’s properties. I’ve also observerd that using a non-internal DNS addrsses were also found on internal company desktops and laptops, whether the IP conifiguration was set by a static entry, or from DHCP (DHCP Option 006).

    This type of conifiguration can and will lead to numerous issues with a Active Directory, from authentication issues, replication issues, to much more.

    I hope this explanation provides a greater understanding on how it all works and exemplifies to not ONLY use the internal DNS server for all internal machines, but as well as in the VPN’s DHCP service for VPN clients. Keep in mind, a client machine plugged in at home, using an aircard, or say sitting at Starbucks, will probably be configured with an ISP’s anyway if outside the network. That is fine. If using a VPN connected to the office, the VPN client will use that DNS to find the VPN server for your network. But once the VPN authenticates and connects, the VPN will be configured with your company’s internal DNS servers on its interface, and because the VPN interface by default is the first in the binding order, therfore the first interface it will use, will be able to logon to the domain and authenticate to the domain in order to access internal resources, which is what you want it to do.


    The Usual Suspects That Can Cause Issues with AD Communications, long logon times, etc

    Here is a summarized list of possible causes, but NOT limited to:

    1. Single label name Active Directory DNS domain name (extremely problematic).
    2. SRV records missing. This can be due to DNS or network interface card (NIC) mis-configuration.
    3. Disjointed namespace.- AD domain name doesn’t match the Primary DNS Suffix and/or the zone name.
    4. Using an ISP’s or some other DNS server that is not hosting the AD zone or that doesn’t have a reference to it, in IP properties of the DCs and clients.
    5. DHCP Client service disabled on the DCs (a required service even if statically configured)
    6. DCs are possibly multihomed. A multihomed DC has more than one unteamed NIC, more than one IP and/or RRAS installed such as for VPN purposes, which makes it problematic if not configured properly (more info on this below).
    7. A third party firewall or security application is installed blocking traffic.
    8. Antivirus software blocking functionality
    9. Antispyware blocking functionality


    AD & DNS Configuration

    When I’ve visited a customer site to fix issues and noticing the DNS entries are incorrect on the DC(s), upon interviewing the parties involved that had configured the machines, simply stated they were not aware of this requirement.

    Usually it simply comes down to a simple misunderstanding of AD and how DNS works, as well as the Client Side Resolver Service.  Some ISPs will tell their customers that they need to use the router as a DNS address, or that they need to use their DNS servers out on the internet, or they warn them that they will not resolve internet names. The ISP customer service reps are not well versed with how AD and DNS works, and frankly provide misguided advise.

    Keep in mind, if a DC goes down for whatever reason, or simply not be available because the clients can’t “find” the DC,, so will your Exchange server, AD domain functions, mapped drive access, printer access, etc. If the DC actually went down, such as hardware failure, this is a worst case scenario and wouldn’t matter to config your machines with the ISP’s DNS. If you need, you can configure your own workstation to the ISP’s during such a crisis in case you need outside communication to research the problem, but you must change it back to your internal DNS once you’re done researching the issue and/or you’ve fixed the problem.



    FYI about AD, DNS, authentication, finding the domain, GPOs, RPC issues,ISP’s DNS servers, etc

    Active Directory stores it’s resources and service locations in DNS in the form of SRV records (those folder names with the underscores in them). These records are used for a multitude of things, such as finding the domain when a client logons, domain replication from one DC to another, authentication, and more. 

    If the ISP’s DNS is configured in the any of the internal AD member machines’ IP properties, (including all client machines and DCs), the machines will be asking the ISP’s DNS ‘where is the domain controller for my domain?”, whenever it needs to perform a function, (such as a logon request, replication request, querying and applying GPOs, etc). Unfortunately, the ISP’s DNS does not have that info and they reply with an “I dunno know”, and things just fail. Unfortunately, the ISP’s DNS doesn’t have information or records about your internal private AD domain, and they shouldn’t have that sort of information.

    Therefore, with an AD infrastructure, all domain members (DCs, clients and servers), must only use the internal DNS server(s).

    If for instance a user wanted to log on, part of the logon process involves the machine to find where the DCs are. The machine will ask DNS, “Where is my domain controller?” If the machine is properly set to use only the internal DNS servers, it will be able to respond with an answer, thus the user can logon.

    If the machine asks the DNS server, “Where is my domain controller?”, will it have that answer? No, unfortunately not.

    Also, it is highly recommended to not use your firewall or router as a DNS or DHCP server. If you are using your NT4 as a DNS server in your AD domain, change it over to Win2003 DNS. Same with DHCP. NT4 DNS cannot support AD’s SRV requirements and dynamic updates. Windows DHCP service supports additional features for DNS Dynamic updates, as well as other features, that a router or firewall’s DHCP server does not support.


    Do not configure the DNS client settings on the domain controllers to point to your Internet Service Provider’s (ISP’s) DNS servers or any other DNS other than the DNS hosting the AD zone, otherwise…

    Common Mistakes When Upgrading a Windows 2000 Domain To a Windows 2003 Domain (whether it was upgraded or not, this is full of useful information relating to AD and DNS, among other info):


    The DNS Client Side Resolver Service

    Another question that has come up is, “Why can’t I use the ISP’s address as the second entry?” This will cause problems as well, due to the way the client side resolver works, which is the resolver service that runs on all machines – DC or workstation – that queries DNS and what to do with the answer. Yes, the domain controller, too, after all the domain controlleris also a DNS client, because it will query DNS to “find” itself.

    The Client Side Resolver will query the first DNS server listed in the NIC’s properties. If that server doesn’t respond, it will remove it from the ‘eligible resolver list” for 15 “minutes and go on to the next one in the list. So say if the client happens to try to authenticate to AD in order to access a printer, and it’s stuck on the ISP’s, it will fail to connect until the 15 minute time out period expires and the list resets.

    To summarize, if there are multiple DNS entries on a machine (whether a DC, member server or client), it will ask the first entry first. If it doesn’t have the answer, it will go to the second entry after a time out period, or TTL, which can last 15 seconds or more as it keeps trying the first one, at which then it REMOVES the first entry from the eligible resolvers list, and won’t go back to it for another 15 minutes at which time the list is reset back to the original order. This can cause issues within AD when accessing a resource such as a printer, folder, getting GPOs to function, etc. Now if the ISP’s is the first one, obviously it will be knocked out when a client is trying to login. This can be noticed by a really really logon time period the client will experience before it goes to the second one, your internal DNS. Therefore, the first one is knocked out for 15 minutes. Then let’s say the client decides to go to an internet site. It will be querying the internal DNS at this point. As long as the internal DNS is configured with forwarders to an outside DNS, or using it’s Root Hints, it will resolve both internal and external internet addresses.

    In summary, based on the way the client side resolver service algorithm works, you simply can’t mix an ISP or some other DNS server that doesn’t host the AD zone name or have some sort of reference to it, whether using a conditional forwarder, stub, secondary or general forwarder, or expect problems. Read the following for more detail and understanding of the client side resolver service algorithm.

    DNS Client side resolver service

    The DNS Client Service Does Not Revert to Using the First Server in the List in Windows XP

    Then if I don’t use the ISP’s DNS address in my machines, how will it resolve internet names?

    For Internet resolution, the Root Hints will be used by default, unless a root zone exists. The root zone actually looks like a period that you normally type at the end of a sentence, such as a  dot “.” zone. If a root zone exists, delete it, and restart the DNS server service.

    Therefore, the recommended “best practice” to insure full AD and client functionality is to point all machines ONLY to the internal server(s), and configure a forwarder to your ISP’s DNS server properties (rt-click DNS servername, properties, Forwarders tab). This way all machines query your DNS and if it doesn’t have the answer, it asks outside. If the forwarding option is grayed out, delete the Root zone (that dot zone). If not sure how to perform these two tasks, please follow one of the articles listed below, depending on your operating system, for step by step.

    300202 – HOW TO Configure DNS for Internet Access in Windows Server 2000 (Configure Forwarding) :

    323380 – HOW TO Configure DNS for Internet Access in Windows Server 2003 (Configure Forwarding) :

    How to Configure Conditional Forwarders in Windows Server 2008

    Configure a DNS Server to Use Forwarders – Windows 2008 and 2008 R2

    DNS Conditional Forwarding in Windows Server 2003

    825036 – Best practices for DNS client settings in Windows 2000 Server and in Windows Server 2003


    Multihomed Domain Controllers

    Another issue I’ve encountered is when a non-SBS domain controller has been configured with mutiple NICs, IP addresses, and/or RRAS. This is another problematic configuration that is dubbed as a “multihomed domain controller.” Multihomed DCs are extremely problematic if not configured correctly, however to configure one correctly involves a multitude of steps including registry changes to alter DNS registration. However, this blog is not intended to discuss multihomed DCs, rather to discuss using an ISP’s DNS address in your network. For more information on multihomed DCs, please read the following link to my blog on it, and how to configure it.

    Multihomed DCs with DNS, RRAS, and/or PPPoE adapters:



    If you have your ISP’s DNS addresses in your IP configuration (all DCs, member servers and clients), they need to be REMOVED and ONLY use the internal DNS server(s). This will cause numerous problems with AD.


    Related Links

    291382 – Frequently asked questions about Windows 2000 DNS and Windows Server 2003 DNS

    Common Mistakes When Upgrading a Windows 2000 Domain To a Windows 2003 Domain (whether it was upgraded or not, this is full of useful information relating to AD and DNS, among other info):

    Domain Controller’s Domain Name System Suffix Does Not Match Domain Name:

    Clients cannot dynamically register DNS records in a single-label forward lookup zone:

    300684 – Information About Configuring Windows 2000 for Domains with Single-Label DNS Names

    828263 – DNS query responses do not travel through a firewall in Windows Server 2003:



    Exchange on a Domain Controller – How to Move Exchange off a DC

    Exchange on a Domain Controller – Ramifications and How to Move Exchange off a DC  
    Formerly Titled: Exchange on a DC: Moving from Exchange 2000 currently on a Windows 2000 domain controller to a new Exchange 2003 server on a Windows 2003 member server

    Ace Fekay, MCT, MVP, MCITP EA, Exchange 2010 Enterprise Administrator, MCTS Windows 2008, Exchange 2010 & Exchange 2007, MCSE 2003/2000, MCSA Messaging 2003
      Microsoft Certified Trainer
      Microsoft MVP: Directory Services
      Active Directory, Exchange and Windows Infrastructure Engineer

    Edits and updates:
    9/16/2009, 8:30 PM EST. Added Errata and blurb on Exchange not recommended to be installed on a DC, with additional links to articles explaining this issue.
    10/4/2010, 1:54 AM EST. Retitled Blog and added new links for Exchange 2007
    10/9/2010 – Added blurb about write-caching being disabled on a DC by default, how it conflicts with Exchange, and how you can’t change it.
    10/28/2011 – Updated syntax and wording.
    1/15/2012 – Added additional info in the section about demoting a DC with Exchange on it,



    Other than Small Business Server (SBS), which is designed to run Exchange on a DC, installing Exchange on a DC, is not recommended. There are a number of implications:

    • When a machine is promoted to a DC, it disabled the write cache function on the drive controller. This is to protect the AD database (ntds.dit) and its method of transactional logging. However, Exchange needs this function to be enabled for its transactional logging method. Thisresults in a substantial performance loss.
    • Difficult and complex to recover.
    • Internet exposure of a DC when accessing OWA. IIS on a DC is not best security practice.
    • Exchange on a DC will “lock” itself to the local DC for a GC and won’t look elsewhere. Make sure at least it’s a GC.
    • You can’t demote a DC with Exchange. You must uninstall Exchange first.
    • Exchange is not supported in a clustered configuration where the cluster nodes are domain controllers

    Complete list can be found here:
    Exchange resident on domain controller that is not a global catalog server

    “You can run Exchange Server 2003 on either a member server or on a domain controller. After you install Exchange Server 2003 on a server, do not change the role of the server. For example, if you install Exchange Server 2003 on a member server, do not use the Dcpromo tool to promote the server to a domain controller. Or, if you install Exchange Server 2003 on a domain controller, do not use the Dcpromo tool to demote the server to a member server. Changing the role of a server after you install Exchange Server 2003 may result in loss of some Exchange functionality and is not supported.”

    That was quoted from the following, and applies to all versions of Exchange:
    Overview of operating system and Active Directory requirements for Exchange Server 2003


    Write-Cache is Disabled on a DC

    When a server is promoted to a DC, write cache is disabled by default. You can try to enable it, but it will revert back to disabled. This is default and can’t be changed. It’s done to protect the AD database as well as improve AD DC performance. However as mentioned above, this conflicts with Exchange, which requires write-cache to be enabled for performance and the way Exchange’s transactional logging works. More info in the following links on DC write caching being disabled.

    Event ID 1539 — Database integrity – Domain controllers attempt to protect this data from accidental loss or by disabling write-caching…

    Slow Network Performance After You Promote a Windows 2000-Based …If you use the Dcpromo tool to promote a Windows 2000-based server to a domain controller, the write caching functionality (write-back cache is a firmware …

    Things to consider when you host Active Directory domain …Discusses the issues that affect a domain controller that runs as a guest …

    Event 13512 Logged on a Domain ControllerThe File Replication Service has detected an enabled disk write cache on the …


    DSAcess – Global Catalog Ramifications

    The other implication is the fact Exchange “locks” on to the DC it’s installed on for its GC DSAccess. If it is not a GC, it may cause issues. If AD services on the DC fail, and you have other DCs, Exchange will not failvoer to another DC for DSAccess. This is by design based on to use the closest DC for DSAccess, and since it is installed on a DC, it will not look elsewhere.

    Also, if you manage to demote the DC without removing Exchange first, Exchange will not look elsewhere for a DC/GC because it “locks” on to the GC it was installed on. Read more on this in the following articles.

    This Exchange server is also a domain controller, which is not a recommended configuration

    Exchange resident on domain controller that is not a global catalog server

    Running Exchange on a Domain Controller

    Problems with Exchange 2003 Installed on Domain Controllers


    Recovering a DC/Exchange Server

    For the most part, if a DC is lost for any reason, such as a failed drive, etc, you can simply manually remove the orphaned DC out of the AD database, in addition to a few other steps, reinstall a new operating system with the same name and promote it. It’s much faster and simpler than trying to recover the DC. However, with Exchange installed on it, it adds a complexity because you must recover the DC first, then Exchange.

    Also, you can’t backup a DC’s System State and an Information Store backup on the same backup job, otherwise the INformation Store backup is useless when trying to restore any Exchange data. They need to be run separately. Albeit, some third party backup processes can overcome this limitation.

    More info on recovering a failed DC:

    Complete Step by Step to Remove an Orphaned Domain controller
    Published by acefekay on Oct 5, 2010 at 12:14 AM


    SBS is the Exception!

    Of course, the ONLY exception to this rule regarding Exchange on a DC, is SBS. SBS was specifically designed to run Exchange, SQL and other services together on a DC.


    Removing Exchange from a DC

    Keep in mind the following fact:

    If the computer is running Exchange 2000 Server, you can demote the server to a member server using DCPromo at the first opportunity.

    If the computer is running Exchange Server 2003, Exchange Server 2007, or Exchange Server 2010, you can’t demote it. YOu must uninstall Exchange first, before you can demote it. That will involve installing another Exchange server and move the mailboxes, public folders, system & hidden folders, rehoming public folders, reconfigure connectors, etc, and then uninstall Exchange, then demote it.

    Read more on this:

    Exchange resident on domain controller that is not a global catalog server


    Documentation where I had to demote a DC that was an Exchange 2003 Server

    (This applies to any version of Exchange and Windows)

    I previously preformed this procedure for a customer in Feb, 2009, without a hitch. Here are the steps I followed. Keep in mind, as pointed out at the top, if you want to demote a DC to a member server that has Exchange installed, it cannot be done. Exchange must be removed first, then the DC can be demoted.

    Therefore, you must install Exchange on another server, whether or not you want to move up to a newer version of Exchange. Of course, with Exchange 2007 or 2010, this would depend on if the company’s budget allows for acquiring the new version taking into account the new licensing rules and beefy 64 bit server requirements. In this case, the customer already had an SA that included Exchange Enterprise 2003, so they wanted to stick with 2003.

    You can follow the steps I performed to install a new Windows 2003 DC, then install Exchange 2003 on a member server, moved everything to the new Exchange 2003 server, then remove the original Exchange installation off the DC, then demoted it.

    8 Steps…

    1. Run the command in the following article to fix the mangled attributes in your current domain. This is because Exchange 2000 creates two incompatible attributes that Windows 2003 cannot use since it was updated in 2003 AD. Follow the steps under “Scenario 2: Exchange 2000 Schema Changes Are Installed Before You Run the Windows Server 2003 adprep /forestprep Command”

    Windows Server 2003 adprep /forestprep Command Causes Mangled Attributes in Windows 2000 Forests That Contain Exchange 2000 Servers:

    2. Then promote the Windows 2003 as a replica DC in the existing domain.

    3. Move the FSMO roles and the GC to the new server. Run repadmin /syncall and wait about 30 minutes allowing replication to take place and insure that the new DC has taken on the FSMO roles and it became a GC. Check DNS to insure that it’s now registerd as a GC.

    4. Install Exchange as an additional Exchange server in the existing organization. Moving forward, it’s recommended to install it on a member server.

    5. In ADUC, highlight all of your mailbox enabled accounts, right-click, choose Exchange Tasks, choose to move all mailboxes to the new Exchange server.

    6. Move ALL Public and System (hidden) folders to the new Exchange server. Follow the following articles for specific steps. Look for the section about “Migration of mailboxes and public folders”. This is extremely important because the system folders are only created when a new Exchange organization is created. If you remove the first server without moving the hidden system folder, it’s possible to recreate them, but it’s extremely difficult and quite involved.

    822450 – How to Remove the Last Exchange Server 5.5 Computer from an Exchange Server 2003 Administrative Group (Look at “Migration of mailboxes and public folders”):

    822450 – How to Remove the Last Exchange Server 5.5 Computer from an Exchange Server 2003 Administrative Group (Look at Step 4 about how to view the System folders and how to replicate them and remove the original instances):

    Step-by-Step Migrating Exchange 2000 to Exchange 2003 Using New Hardware:

    7. Once you’ve verified the folders are all moved, mailboxes are working, then run the Exchange setup and remove (uninstall) Exchange off of the original DC.

    8. Double check in ADSI Edit, configuration container, Services, Exchange, drill down to the server list, and insure that the original Exchange server reference is gone on the original DC, and all Exchange components are on the new DC.


    Clustered Exchange on Domain Controllers?

    Nope. It’s not recommended, or supported

    Exchange is not supported in a clustered configuration where the cluster nodes are domain controllers

    Domain Controllers as Cluster Nodes – Bad Idea (Microsoft recommends against it)


    Complete List of Related links including the Aforementioned Links

    Exchange Server 2003 and Domain Controllers – A Summary:

    This Exchange server is also a domain controller, which is not a recommended configuration

    Exchange resident on domain controller that is not a global catalog server

    Exchange Server 2007 and Domain Controllers – A Summary 

    Exchange Server 2003 and Domain Controllers – A Summary:

    Running Exchange on a Domain Controller

    Problems with Exchange 2003 Installed on Domain Controllers

    How to remove Exchange Server 2003 from your computer. This how-to article describes the steps to automatically or manually remove Microsoft Exchange Server 2003 from your computer.

    How to completely remove a Exchange server or the entire Exchange …Oct 19, 2004 … Remove the Exchange 2003 server object from the Exchange 5.5 Admin … How to Remove the First Exchange 2003 Server Computer from the Site …

    Removing The Last Exchange 2003 Server From Exchange 2007 (Part 1)Jun 5, 2008 … The steps required in order to remove the last Exchange 2003 server from an organization that has been migrated to Exchange 2007.

    How to remove the first Exchange Server 2003 computer from the …This article describes the steps to remove the first Microsoft Exchange Server 2003 computer from an administrative group. The first Exchange Server 2003 …

    CANNOT REMOVE EXCHANGE 2003 SERVER FROM ACTIVE DIRECTORY: Note: this site requires a membership. If you don’t have a membership, no problem. The thread makes mention that after following KB833396, to delete or confirm deletion of the old server object out of the Administrative Group using ADSIEdit, that is if you plan to never install that server by name, which is assuming you are moving it off the DC anyway.


    All comments, suggestions or corrections welcomed!

    Ace Fekay