• Status: Solved
  • Priority: Medium
  • Security: Public
  • Views: 212
  • Last Modified:

Looking for Closure in a Relationship with two DCs

I’m having difficulty retiring a failing GC / DC / Exchange Server (server1).
It’s running Windows Server 2003 with Exchange 2007 SP3.  The hardware is failing and the server needs to be replaced.  It’s a small business with 5 clients machines and a single server.

The replacement server (server2) is running Windows Server 2008 R2 with Exchange Server 2010 SP2.

I installed the replacement server; promoted it using DCPromo, set it up as a GC, transferred all FSMO roles, and enabled it as a DHCP and DNS server (and a WINS server for good measure since the clients are on XP).  Ran adprep /forestprep from the Windows Server 2008 R2 CD on server1.  There were no problems.  The login scripts automatically were synced on both servers.  I moved all the file shares and updated the login scripts to point to server2.  Users logged into and their drive mappings all point to server2 now.

Then installed Exchange 2010 SP2 on server2.  Moved the send and receive connectors from server1 to server2.  Changed the router to send 80, 25 and 443 to server2.  Moved all mailboxes.  So far so good.  Enabled Exchange to use server2 as the GC.  Tested OWA and ActiveSync.  Good to go at this point.

When I attempted to shut down server1, Exchange would not allow connections.  Users could not log into the network unless they had a hard coded IP.  Right away that pointed me towards DHCP as an issue, but the scope of server2 does not overlap with server1’s DHCP scope.  DNS is also working fine.  NSLOOKUP resolves to server2.

I have not actually done a DCPROMO on server1 to demote it to a member server in fear losing the domain, nor have I uninstalled Exchange 2007 on server1 to officially retire it.  I have done this in the past and yet somehow I feel I missed something.  Right now server1 is on life support.  Server2 cannot function unless server1 is on.

Can someone help me figure out what I  missed?

Thanks!

-Ted
0
tedwill
Asked:
tedwill
1 Solution
 
jpgobertCommented:
You have to actually uninstall Exchange from the server you're taking out of the network so that the domain & Exchange forest is properly updated.  If there are any left over items or hidden gremlins hanging out in your original Exchange box you'll find out during the uninstall... hopefully you won't have any remaining items to clean up and the uninstall will flow easily... if not, don't worry... just action each item that comes up so that Exchange will uninstall properly and you'll be good... you'll be able to decommission the domain controller at that point and have a clean exit.
0
 
SandyCommented:
sieze the FSMO's
0
 
Exchange_GeekCommented:
Are you facing an issue with Exchange or Network logins?

If its network login - troubleshooting goes to a different path, if its Exchange - again to a different path.

Clarify.

Regards,
Exchange_Geek
0
Concerto Cloud for Software Providers & ISVs

Can Concerto Cloud Services help you focus on evolving your application offerings, while delivering the best cloud experience to your customers? From DevOps to revenue models and customer support, the answer is yes!

Learn how Concerto can help you.

 
jpgobertCommented:
@Exchange_Geek... I think he was pretty clear... his new DC is online and holds the FSMO roles... he brought up an Exchange 2010 SP2 install in co-existence with his original 2007 server.  Once he got everything "working" he just shut down the 2007 machine which isn't going to work... the 2007 server has to be uninstalled from the domain properly so that the 2010 server isn't still referencing it...

...it's all pretty clearly written...
0
 
tedwillAuthor Commented:
I know that uninstalling the Exchange server will resolve the issues with Exchange, but will demoting the original resolve the issues?  I did an NTDSUTIL and saw that all five FSMO roles were on the new server.  Is there a delegation step I might have missed with DNS?
0
 
jpgobertCommented:
From what you've written it sounds like you've properly brought the new domain controller up, moved the FSMO roles, verified the FSMO roles are indeed on the new server, and you have the Exchange 2010 box working.  You've also setup the support services (DNS, WINS, DHCP) on the new controller and you've verified that those are working, correct?  Have you reviewed the event logs on the new server for any warnings or errors?  

What's the network configuration setup like?  Any special considerations in play?  Any VLANS or other advanced config details?

Have you reviewed AD Sites and Services to make sure that everything looks correct and that the new server is showing up in the site within the correct subnet?

I don't know how much you're able or willing to share but maybe posting portions of the event logs or something could give us something to review and help you track down the issue... I'd offer to join you in a Webex or Goto Assist session if you wanted to so we could check through everything... a second pair of eyes is usually the trick on things like this...

One question... have you verified for certain that DHCP & DNS are properly configured and working on the new server?  Can you create a static DHCP lease on the new server and verify that the lease works and the server responds to the client DHCP request with the right configuration?
0
 
tedwillAuthor Commented:
Thanks for the tip.  It got me started looking at DHCP.  Turns out there were issues on the old server's registry.   The new server was never properly authorized.  A "ghost" server which was decommissioned years ago was showing up as an authorized server.  I had to go into the registry to get rid of it.  Now DNS and DHCP are disabled on the old server.  The new server is serving up addresses just fine. <br /><br />Now for the nightmare of moving public folders off the old server.  Thanks for your help!
0

Featured Post

Get your Conversational Ransomware Defense e‑book

This e-book gives you an insight into the ransomware threat and reviews the fundamentals of top-notch ransomware preparedness and recovery. To help you protect yourself and your organization. The initial infection may be inevitable, so the best protection is to be fully prepared.

Tackle projects and never again get stuck behind a technical roadblock.
Join Now