We currently have an Exchange2007 CCR deployment that is in the same physical location. However, we need to move this cluster, with minimal downtime, to a new physical location. I've thought this through and think this will not be an issue, but figured I'd throw this out there anyway incase I've missed something.The plan is to move the Passive server to the new location first, along with one of the Transport servers, make sure it's synchronizing properly and failover to it. Then the Active can be brought over with the other Transport which hosts the FSW. Once everything was up and running it would be failed back to the Active. The storage would also be moved together with each device.Both the Public & Private IP addresses can be kept the same. Latency will be <100MS.From what I've read, the 'max' latency is 500MS, so I'm assuming we should be fine. Any input is greatly appreciated.

Is this server 2008 or 2003If 2008, adding a 2nd subnet isn't really hard but you have to understand that both CCR nodes need to be in the same AD site, so adding another HT/CA server over there wont help unless you add them all to the primary site. You can do this by using /32 subnets on your Exchange servers. You can "fix" this once you're all the way on the other side. in the mean time, if you're split across both sides and the primary side fails, you'll have to change the site/subnet definition before the 2nd will come online properly. Mike Crowley: MCT, MCSE, MCTS, MCITP: Enterprise Administrator / Messaging Administrator

Doh, thought I mentioned that. Server 2003 which is why we'll need to keep the nodes on the same subnet.

ok so you'll be extending the VLAN - thats fine. Just understand the AD site and AD access implications I mentioned above. I'm not sure I see a point in putting another HT over there either, since Exchange might pick that one, but it might also use the HT on the first location, since it will all be in the same AD site. This logic applies to CAS and DCs as well - its all about the sites. Now if you want, you can hard code the DC and HT on the new location, but the problem with that is you'll be coding them to the CMS (not the node), which in a normal event you wouldn't want them to use the 2nd locations resource. Mike Crowley: MCT, MCSE, MCTS, MCITP: Enterprise Administrator / Messaging Administrator

Thanks Mike. The reasoning behind moving one of the HT's is to ensure mail flow isn't impacted. We have two of them, so one will be shut down and moved to the new location along with the passive server. That way we can bring them up at the new location, failover to the passive and shut down the Active and remaining HT and bring those over.I'm still trying to decide whether it matters what happens with the FSW in this process. One of the HT's hosts the FSW. If we leave the FSW with the Active, and then failover to the passive and shut down both the Active & FSW servers, the Passive will temporarily be the only node. That should be fine as long as it's up and running, right?The alternative is we bring the FSW over with the Passive, leaving the Active as the only node and then failover once the Passive & FSW are both brought up at their new location.

I understand the notion to have a HT ready for when that site becomes active. just include in your plan to update AD Sites and Services at that time with the proper subnet relationships. Also note that your Client Access Server also requires a intrasite relationship with Exchange, so maybe make the server a CAS/HT combo?On the topic of the FSW: If your primary node AND FSW are offline your Majority Node Set (MNS) quorum will have 1 out of 3 votes - which is not the majority and will cause the cluster to fail. I suggest moving the FSW while both nodes are active so that a 2/3 vote will remain intact. you can "force quorum" for just the one surviving node, but I'm pretty sure this can only be done immediatly after the failure - not while its on. That menas you'll have downtime. Your final paragraph regarding FSW going with the Passive is a good idea, just be sure to move one at a time so that you'll always have 2/3 online at any given time.Mike Crowley: MCT, MCSE, MCTS, MCITP: Enterprise Administrator / Messaging Administrator

Thanks Mike, I appreciate your input. I'll update this post with the end result.

This went almost exactly as planned, except I decided to bring the FSW over first. Once it was up and the cluster recognized that the FSW was available again, I brought over one Mailbox Server, caught up the logs and failed over. After that it was just a matter of bringing the remaining server over. Piece of cake ;)

Sweet - thanks for the update! Mike Crowley: MCT, MCSE, MCTS, MCITP: Enterprise Administrator / Messaging Administrator