Thursday, March 29, 2007

Exchange Clustering Day 5.6.7.8.9 something

In the last few days we have been moving mailboxes and trying to iron out some issues that have come up.

One issue that came up was RUS (Recipient Update Service)service was pointing to an old domain controller that was decommissioned a LONG time ago. Any way we reconfigured that. The issues that came up were when a mailbox was moved it took forever in a day for the outlook client to reconnect back. And it should reconnect back in seconds. FIXED!

Another issue we were having is when moving the mailbox that had blackberry's associated with them the BB would not be able to send emails. I think this was b/c RUS was all eF'ed up too. FIXED!

We were also having Symantec Enterprise Vault issues when we had to reset up the services to archive the public folders. The application had to associate the service to the system mailbox and it could not see ANY mailboxes. So we rebooted the EV server and we where able to see all the mailboxes and chose the system mailbox for the EV service. FIXED!

Repathing SMTP. All of our incoming and outgoing emails go to MessageLabs. You can pretty much say they have an MX record for us. They only send emails to SMTP.domain.com and only recieve emails from A.B.C.D IP's we give them. If my current single exchange server is already working can't I just swap IP's. Well yes I can't and no it will not work 100% of the time. Here is why. My firewall objects points to my exchange server, switching the internal IP on the object will work for incoming emails. SMTP.domain.com points to a public IP that is NAT'ed to an internal IP. BUT... in a cluster what we have come to find is that even though the virtual exchange server that now SMTP.domain.com will get all emails going out is totally different. Which ever node in the cluster is the active one that's the IP that will be attached to the email header. So Messagelabs is seeing this new IP from the active node trying to send emails and is rejecting it even though the emails are coming from the virtual cluster with is registered with the correct external IP. It's the active node's IP that the emails hang on to. So I had to call Messagelabs and get them to add both external IPs of the active node that I created. Well it takes 4-6 hours to propagate. We send emails to a Messagelabs cluster so the changes I've added have to hit all server in thier cluster. I was able to get emails to go out b/c some towers in the cluster had the changes and some didn't. I'll just wait until they all have the changes to switch IP's later on tonight. So now all my emails are still flowing through the single (non-clustered) exchange server. Something to watch out for if you are exchange clustering. FIXED!(in a few hours)

No comments: