Networks

Ask something
Question Locked

Company name change/e-mail switchover

0 helpful
13 replies

by williamoshea

Closed to new repliesThis discussion is closed. It stays readable, but it takes no new replies.

Hello Folks,
we have a domain name and host our e-mails on an exchange server 2003. But our company is changing it's name to something else whic will mean a change in domain name and consequently e-mail address. We could not possibly inform all our customers of the new e-mail address and even if we could, some customers will still send messages to the old e-mail addresses. How do I manage this switch over? Do I have two exchange servers running sisde by side and gradually withdrawing the old domain? Do I create another domain and set up forwarding? How do I make sure all our future e-mails after the name change only carry the new domain name though the messgas could have been recieved using the old name.
I know there must be a way but I just can't figure out how to do it.
Thank you

13 replies

by churdoo

I'm assuming this is standalone Exchange and not Small Biz Server. In your Exchange Server, look at your recipient policies (ESM/Recipients/Recipient Policies), this is where you'll make the change.

Depending on how your policy is set up, you'll either have just the Default Policy, or you'll have the Default and 1 or more custom policies. Find the policy that has your existing domain in it and ADD the new domain to the same policy. When you add the new domain, check the box that says "This Exchange Organization is responsible ..."

Once you have the new email domain added (and don't make it the default email domain until you test it), you can rebuild RUS (ESM/Recipients/Recipient Update service). Give RUS some time to complete, minutes to hours depending on the size of your organization, you can go back to the recipient policy and 'Apply this Policy now ...' and shortly, everyone's email addresses will be updated with the new domain automatically. This means that mail sent to user@oldcompanyemail.com and user@newcompanyemail.com will end up in the SAME MAILBOX.

Once the new domain is tested and you want to make the new email domain name official, go back into the Recipient Policy and make the new email domain the default, Rebuild RUS, and re-apply the policy. Users will still receive email addressed to both domains, but their email address being advertised in their OUTBOUND email will be the new email domain.

Exchange doesn't care, You can leave it set with the multiple email domains indefinitely, or you can remove the old domain at some point in the future, by removing the old domain from the Policy, rebuild RUS, re-apply the Policy.

This one's gotta deserve the Thumbs Up button :-)

by gator98

What if I wanted to notify my customers sending the email to the old domain of the change ? Is there a way to do either capture the emails sent to XYZ domain to a specific mailbox or create a policy to reply with please update your address book ....?

by churdoo

Thanks sgt ... coming from someone with all your thumbs means a lot, or were you just busting my b@ll$ for my verbose response? lol

Nonetheless, to the problem at hand... I can't really think of a way, well actually I can, just that there isn't a simple "click this" Exchange way of doing what you're asking, and I'm not sure the workaround is worth the trouble.

First of all, since
a) you can leave both email domains in exchange indefinitely, and
b) for as long as the company pays the $8-$25 per year to keep the old domain registered, and
c) once you set the default email addy to the new domain all outbound email addy's will be advertising the new domain for reply-to's etc.
then peeps will ultimately update their address books simply by attrition, and you will still receive the straggling once in awhile email to the old domain.

Having said this, If however, you really wanted to do what you're asking, ...

I would suggest enabling your Message Tracking Logs if not already, then I would create a parsing process for the raw log files which are located in your exchange log directory/share. The parsing process would keep any line containing the old domain name (grep @oldemaildomain.com), then would grab the sender address from each resulting line (sed plus a bunch of switches), and send your "update your addy book" email to the resultant list of addy's, or feed those addy's to an inexpensive bulk mailer software or bulk email provider.

There are third-party utilities that allow you to query and otherwise report on your message tracking logs, that may or may not allow you to pull these sender lists, but I've not used them in years and am not current with their features.

Hope this helps.
--C

by sgt_shultz

if you don't get a thumb for that one i just give up!! thank you so much churdoo. i printed that fantastic answer and kept it in my notebook in case i ever get to administer exchange again. sigh. sob. sorry.

by williamoshea

And how do I update OWA to refelect the new domain name. Or will this happen automatically. And when users point their browsers at the existing exchange site, will it how e-mails sent to the new address?

by churdoo

Do you mean, how do you get OWA to respond to, for example, http://myowa.newcompanyname.com/exchange instead of the existing url? If so, the answer is simply adding an A-record (or CNAME) in the DNS zonefile of the new company domain (you'll request this of the ISP or registrar that hosting the NAMESERVERS for the new domain), plus adding the new domain name to the virtual hosts list of the default website in IIS (depending on how IIS is set up, this step may not be required).

If you're talking about emails reaching the company recipients, and/or outbound emails displaying the sender name from the new company email domain, then the work with Recipient Policies will take care of that for OWA as well as for Outlook.

by ramond222

Excellent information thank-you. You mention SBS in the begining - are you able to configure it in the same way to accomodate a name change?

by churdoo

If SBS 2003, the short answer is yes you can configure it the same way as described in this thread,

But of course the whole reason I tried to distinguish SBS was because of course there is a BUT! ... At some point with SBS 2003 you would want to re-run the CEICW (Configure Email and Internet Connection Wizard) and specify the new company domain name for the web Certificate and the email domain. This point IMO is the point at which you want the remote users to start using https://hq.newcompanydomain.com/remote and/or https://hq.newcompanydomain.com/exchange to access the resources remotely. after which point you'll want to revisit the Recipient Update Services and make sure the OLD domain is still listed in RUS, adding the old domain back if necessary and rebuilding RUS.

by williamoshea

What I mean is: at the moment my users type in http://exchange.olddomainname.com to access their e-mails. If I just update the recipient policy to start using the new domain name, what will happen when my users try to use OWA by typing in the old address into the browser? Will it present them with e-mails sent to both old and new addresses or will it only presnt them with e-mails sent only to old domain address? In which case, I would like to know, do i need to create domain name in IIS for this new domain (which would lead to duplicity). Basically how do i get my users to type in one address into the browser window but get access to all e-mails irrespective of the address it was sent to (old email address or new)?
Thanks.

by churdoo

The work in the Recipient Policies from the first response will take care of this; you will not have to do any extra steps for OWA users to get their email from both email domains.

OWA is merely a browser-based window to the users' exchange mailboxes; how they get there, i.e. the url that they use in their browser has no bearing on the content of said mailboxes; the content is still governed by your work to the Recipient Policies.

For the sake of being consistent with the new company name, at some point you will want to put an A-record in the NEW domain DNS zone pointing to the exchange server, for peeps to browse to http://exchange.newdomainname.com for their OWA. Again, this will just be a change for the sake of consistency with the new domain name and will have no affect on the contents of the users' mailboxes once they're in OWA.

by williamoshea

Just confirm this and I'll let you rest:
That means once I've updated the recipient policies, when users launch outlook, messages from all configured SMTP domains will be delivered into their INBOX. Likewise when they visit the OWA address in their browser they will be looking at the same INBOX too.
You mentioned the new domain DNS zone. If I am just updating the e-mail domain in exchange manager using recipient policies, I guess I do not need to create a new zone for this new domain yet. The new zone will be necessary if I rename my AD domain in future. At the moment I am just sorting the e-mail addresses while all my hosts continue to have the netbios name of hosts.olddomainname.com, and the login domain remains olddomainname. Is this likely to cause me problems?
Thanks

by churdoo

except I do have to go make some money soon so I'll be tearing myself away soon.

your paragraph 1 = absolutely correct.

re: DNS Zone -- Sorry, I confused you. I was speaking of the PUBLIC DNS zone for the newdomain.com, the same place where you had to add MX records in order for the world to know to deliver email for newdomain.com to your Exchange server IP. I was merely saying that adding an A record to that DNS (or a CNAME since you already have your IP assigned to some host), for exchange.newdomain.com may be the only change you need to make for your OWA users to use http://exchange.newdomain.com instead of http://exchange.olddomain.com; either way, the OWA users will be looking at the same server, and the same INBOX, and will see the same email.

We've spoken nothing about your internal AD naming or netbios resolution, and we don't need to (until you want to). None of the changes we've talked about care about your internal AD naming, nor vice-versa.

This discussion is closed to new replies.