Take the 2-minute tour ×
Server Fault is a question and answer site for professional system and network administrators. It's 100% free, no registration required.

I have two Windows Server 2008 R2 machines. Server1 is running AD & Terminal Services, and Server2 is running Exchange 2010 SP1. They are both Domain Controllers.

A disk on Server2 suffered a disk error - and the RAID1 configuration was set up incorrectly - thus leaving me to reimage a new disk (hooray for inherited job roles). Note: The disk error will progressively get worse. The server can still function from it, but we cannot perform backups from it due to disk errors.

So I have performed a Bare Metal Recovery from the last backup we have to a new disk. My problem is now that Server2 will no longer connect to Server1 - however - when I log on to Server2 (from an older image) I can log in with the Administrator account's new password - which leads me to believe the servers can indeed talk to each other.

So when I open the Exchange Management Console it tells me there is an error:

The attempt to connect to http://Server2.local/PowerShell using "Kerberos" authentication failed: Connecting to the remote server failed with the following error message: The client cannot connect to the destination specified in the request. Verify that the service on the destination is running and is accepting requests. Consult the logs and documentation for the WS-Management service running on the destination to analyze and configure the WinRM service: "winrm quickconfig". For more information, see the about_Remote_Troubleshooting Help topic.

So I performed winrm quickconfig and it returns:

WinRM already is set up to receive requests on this machine.
WinRM already is set up for remote management on this machine.

I was also under the impression that performing a bare metal recovery would simply restore the entire system to how it was in the image. Have I misunderstood this method of backup? I have performed a Google search and that has yielded many different problems, but none that seem specific to my scenario (and a lot of them seem to be outdated).

So what should I do to enable my Exchange Server to get online again? Am I missing something blindingly obvious?

Edit: System times are the same (kind of - they are within about a third of a second of eachother)

Update - I now have a new issue:

The following error occurred while attempting to connect to the specified Exchange server 'Server2.local':

The attempt to connect to http://server2.local/PowerShell using "Kerberos" authentication failed: Connecting to remote server failed with the following error message: Access is denied. For more information, see the about_Remote_Troubleshooting Help topic.

I am stumped here. Thoughts?

share|improve this question
1  
Do both servers have the same system time, or are they within 5 minutes of each other? –  Jeremy Lyons May 4 '13 at 14:44
    
@JeremyLyons - The system times are the same. –  positiv May 5 '13 at 4:11

2 Answers 2

I have just picked up on the "both are domain controllers" comment. That makes my original steps useless to you, sorry.

How recent was the backup? If it was older than the tombstone interval then domain controller replication may be the issue. On both server1 and server2, in an administrative cmd prompt, execute repadmin /showreps and look for errors. Execute repadmin /syncall and again look for errors. Also dcdiag.

Is there a Global Catalog server on the network? On both machines, run Start | Administrative Tools | Active Directory Sites and Services. Under Sites, YourSiteName, Servers, click each server and right-click NTDS Settings on the right hand side. At least one of them should have Global Catalog ticked.

And, of course, check the Application Event log.


If server2 were a domain member:

It sounds like the new server2 hadn't fully joined the domain. My next step would be to reset the account and join it again.

  1. Move the new server2 from the domain into a workgroup with some temp name (like "WORKGROUP" - resist the temptation to name it something obscene - I did that once in a late-night bad temper and it didn't end well).
  2. On the Domain Controller, in Active Directory Users and Computers, right-click server2's machine account object and choose "Reset Account"†.
  3. Move the new server2 back into the domain. The machine will attach itself to the existing machine account object.

† Warning: do not click "Delete"!

share|improve this answer
    
Hi @GreenstoneWalker, thanks for your answer. For step one, I would right click Computer > Properties > Change Settings under the domain and click the Change button in the System properties tab? It tells me that "Domain controllers cannot be moved from one domain to another, they must first be demoted. Renaming this domain controller may cause it to become temporarily unavailable to users and computers. ...<snip>...". When I click Okay, it won't let me leave the domain and join a workgroup. Is this normal? Or is there some other method I should try to leave the domain and join a workgroup? –  positiv May 6 '13 at 3:52
    
Oops, I missed the comment above about both computers being a Domain Controller. In that case, do not follow my steps - they won't work. –  Greenstone Walker May 6 '13 at 4:34
    
I checked the GC settings on the servers as you described in your edited answer; they both have Global Catalog ticked. Should this be like that? –  positiv May 6 '13 at 5:01
up vote 0 down vote accepted

So I couldn't really let it be in that state for too long. I ended up calling Microsoft and had them walk me through the process.

At some point during the recovery process, the secure channel between the two DCs was broken.

We reset the password using netdom resetpwd /server:server1 /userd:DOMAIN\administrator /passwordd:mypassword

This allowed replication to continue so I am back on line now!

share|improve this answer

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.