0

I am in the process of completely upgrading a Exchange 2007 system running on server 2008 R2 Hyper-V VMs hosted on a Exchange 2008 R2 domain controller. It had all the FSMO roles on it, and it was the PDC Emulator.

I have successfully upgraded my Exchange 2007 environment (Mailbox/Hub Server and Edge Server) to Exchange 2013 Mailbox server and Edge Server, and both incoming and outgoing internet mail are functioning properly. (both Exchange 2013 servers are running in Win Server 2012R2 VMs on a Win Server 2012R2 Hyper-V host machine). Outlook on client machines can successfully connect to the new mailbox server and they all function properly. OWA also is working, both internally, and from outside the firewall on the public internet.

I have uninstalled Exchanged 2007 from the old Exchange 2007 Mailbox/Hub Server and from the old Exchange 2007 Edge Server, and removed these servers from the Exchange Organization. Both of these servers were on VMs running in Hyper-V on a Win Server 2008 R2 PDC in my domain. These VMs have been shut down, and the new Exchange 2013 servers, and all client services, are still functioning properly. My next step is to retire and shut down the old Server 2008 R2 DC that was hosting the old Exchange 2k7 VMs. So, I have built up a new Win server 2012 R2 DC to be my new Primary DC, and transferred all the FSMO roles, and the Operations Master role, from the old 2008 box to it.

At this point, before demoting the old 2008 DC to be an ordinary server and shutting it down permanently, I wanted to make sure that the new Exchange 2013 system would work properly without it, so I shut it down to test everything.

Unfortunately, nothing worked. Outlook running on any of client machine could no longer connect to the mailbox server, and OWA could not authenticate users on login. In addition, I could not even use Remote Desktop to log in to any of the servers in my domain, not the new DC, not the new Hyper-V host, nor either of the Exchange 2013 Servers in the VMs. Although when the old DC is running, RDP connects quickly and without complaining, with the DC offline, after a substantial delay, I eventually get a "Untrusted Certificate Error" window, with includes a message to the effect that if I want to use this cert I need to install the cert into the "Trusted Root Certification Authorities" folder... If I click yes to ignore the untrustworthiness of the Cert, it does connect... But even if I install the cert into the folder as suggested, the next time around I get the same error.

Also, when I open Active Directory Domains and Trusts, and right click on the root node and select "Change Active Directory Domain Controller" it lists the old win 2008 R2 DC as the "Current Directory Server". If I change it to the new one I just built, it "Sticks" as long as I have the cmdlet open, but if I close the mmc and reopen it, it goes back to the old wrong one.

I am afraid to demote the old DC until I am sure that the exchange system will function properly without it. Clearly, something in the system has a dependency on this box, and I need t oremove that dependency.

How do I do that?

More info: Running DCDiag on either of the twpo new DCs shows that Advertising test fails "Warning: DsGetDcName returns information for \[Old DC FQDN], when we were trying to reach [NewName]. SERVER IS NOT RESPONDING OR IS NOT CONSIDERED SUITABLE." ...................... [NEWNAME failed test Advertising

also, on both new DCs, it fails test NetLogons:

 Starting test: NetLogons     
 Unable to connect to the NETLOGON share! (\\ASGARD\netlogon)   
 [ASGARD] An net use or LsaPolicy operation failed with error 67,    
 The network name cannot be found..
Charles Bretana
  • 235
  • 5
  • 17

1 Answers1

0

I think that sounds like a problem with DNS.

Did you install the DNS role on the new DC during the promotion, and is it working properly with replicas of your AD zones? Are all the other servers pointed to just the old DC's IP for their DNS resolution?

Shane Madden
  • 114,520
  • 13
  • 181
  • 251
  • Yes... It is installed on both of the new DCs. and the DNS IP address on the network adapters have all been changed to point to the two new internal DNS IP addresses. – Charles Bretana Apr 16 '14 at 01:55
  • @CharlesBretana And the other servers' DNS configuration? – Shane Madden Apr 16 '14 at 01:56
  • What do you mean DNS configureation ? do you mean whether they have reverse look up zones or not ? – Charles Bretana Apr 16 '14 at 01:57
  • @CharlesBretana I mean, in their network adapter configuration, what DNS server addresses are configured? – Shane Madden Apr 16 '14 at 01:58
  • Yes in the adapters on all three servers, the HyperV host, and the two VMs, there are now two DNS server IP addresses, pointing to the two new Win 2012 R2 DCs in my domain. The IP address of the old DC w/DNS (the one I am trying to retire) is not on any of the adapters. – Charles Bretana Apr 16 '14 at 01:59
  • @CharlesBretana Well then, so much for that idea. Make sure the A record for the root of the domain's zone, as well as the SRV records in the `_msdcs` zone, have the new domain controllers? – Shane Madden Apr 16 '14 at 02:03
  • Also, when I try to RDP sometimes I get "The Remote computer that you are trying to connect to requires Network Level Authentication (NLA), but your Windows Domain controller cannot be contacted to perform NLA. If you are an admin, you can disable NLA by using options on the Remote tab of the Systems Properties dialog box. – Charles Bretana Apr 16 '14 at 02:07
  • the SRV record in _msdcs (under pdc\_tcp) does point to the new dns, but I notice that under domains\{long guid}\_tcp, there are three servers listed, and the old dc (the one I am trying to retire), is listed first. – Charles Bretana Apr 16 '14 at 02:12
  • @CharlesBretana That should be fine. Are there any interesting system logs from back when it was broken? Otherwise, can you re-break it on off hours for some troubleshooting? – Shane Madden Apr 16 '14 at 02:59
  • I can break it any time... more info... DCDiag on both new DCs shows that the Advertising test fails... it says that "...dsGetDcName returned information for [\\FQDN of old DC], when we were trying to reach [this DC] ". But dcDiag for the old dc passes advertising test. – Charles Bretana Apr 16 '14 at 03:03
  • @CharlesBretana Check if the proper content is there in the sysvol shares on the new DCs? See http://blogs.technet.com/b/ziggy/archive/2013/08/21/sysvol-on-newly-promoted-dc-is-not-synchronising-but-replication-looks-ok.aspx – Shane Madden Apr 16 '14 at 03:07
  • What does repadmin /showrepl report? – FACTORY909 Feb 17 '17 at 03:31