AA-in-CA
asked on
"Dormant" Exchange 2013 instance in an Exchange 2007 environment
Here's my scenario: my customer has about 20 PCs, all managed by an SBS 2008 box, running Exchange 2007 SP3. We're gradually migrating them away from that. This weekend, I'd like to patch 2007 to the latest rollup, and install Exchange 2013, but I don't want to move mailboxes, interrupt mailflow, or disturb the users in any way.
If I just install 2013, and don't make any changes (eg, to the Exchange virtual directories, DNS, doing mailbox moves, etc.), is this supported? In other words, I just want to have 2013 installed and dormant, just "sitting there" not doing anything at all until we finally get around to migrating everyone at some later date. I can't imagine that would be a problem, but perhaps I'm wrong?
If I just install 2013, and don't make any changes (eg, to the Exchange virtual directories, DNS, doing mailbox moves, etc.), is this supported? In other words, I just want to have 2013 installed and dormant, just "sitting there" not doing anything at all until we finally get around to migrating everyone at some later date. I can't imagine that would be a problem, but perhaps I'm wrong?
ASKER CERTIFIED SOLUTION
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
ASKER
Simon,
We're already simulated this migration using backups of the production environment, running on their own hypervisor. So we know the migration process will be fine--my question is largely about timing. This is a 20 PC organization with no Edge Transport servers or other proxies.
The reasoning behind installing Exchange 2013 now, and migrating later, is so that we don't have to perform the install itself at the last minute. In other words, if I can install Exchange 2013, but leave it unconfigured post-install, with no impact to users, why not do that?
The proxying/coexistence scenario TechNet's Exchange Deployment Assistant walks you through doesn't make sense for this client, which only has 20 PCs. Why set up coexistence, and have 2013 proxy requests to 2007, when we can just arrange for a day of downtime, change DNS and virtual directories to point to the new server, and move mailboxes from the old to the new? However, if I can get 2013 installed but left unconfigured until that planned day of downtime, I've saved myself an hour.
You said that the new server will automatically be used for routing new mail--if we don't use Edge Transport servers at this client, how is this possible? Same thing with Autodiscover--if we don't update virtual directories and the SCP config until the day of planned downtime, why would the introduction of the new Exchange 2013 server be 'noticed' by Outlook on the PCs?
Maybe I'm missing something, but I don't see what's so inherently disruptive about this idea. Our topology is really simple:
Old: SBS 2008 VM running Exchange 2007
New: new DC VM, (planned) Exchange 2013 running on separate VM
all running on a LAN with 20 PCs running Outlook 2007 and later. Mailflow to and from the Internet passes through a single Sonicwall firewall/router/security appliance device.
We're already simulated this migration using backups of the production environment, running on their own hypervisor. So we know the migration process will be fine--my question is largely about timing. This is a 20 PC organization with no Edge Transport servers or other proxies.
The reasoning behind installing Exchange 2013 now, and migrating later, is so that we don't have to perform the install itself at the last minute. In other words, if I can install Exchange 2013, but leave it unconfigured post-install, with no impact to users, why not do that?
The proxying/coexistence scenario TechNet's Exchange Deployment Assistant walks you through doesn't make sense for this client, which only has 20 PCs. Why set up coexistence, and have 2013 proxy requests to 2007, when we can just arrange for a day of downtime, change DNS and virtual directories to point to the new server, and move mailboxes from the old to the new? However, if I can get 2013 installed but left unconfigured until that planned day of downtime, I've saved myself an hour.
You said that the new server will automatically be used for routing new mail--if we don't use Edge Transport servers at this client, how is this possible? Same thing with Autodiscover--if we don't update virtual directories and the SCP config until the day of planned downtime, why would the introduction of the new Exchange 2013 server be 'noticed' by Outlook on the PCs?
Maybe I'm missing something, but I don't see what's so inherently disruptive about this idea. Our topology is really simple:
Old: SBS 2008 VM running Exchange 2007
New: new DC VM, (planned) Exchange 2013 running on separate VM
all running on a LAN with 20 PCs running Outlook 2007 and later. Mailflow to and from the Internet passes through a single Sonicwall firewall/router/security appliance device.
Doesn't matter if you have one machine or one hundred, the same applies.
Exchange publishes information to the domain, that will include the Autodiscover information. All Exchange servers will publish their information to the domain, so when you have multiple servers you will usually have the same information across all servers.
As for routing - Edge has nothing to do with this. Again Exchange is designed to use all Exchange servers in the org. There is no such thing as a dormant Exchange servers.
Therefore it will send email via that other server, because that is what it is designed to do.
Either configure the server completely or install it closer to the migration date.
In your scenario I would be installing Exchange probably on the same day as the planned migration, no earlier. The host OS would probably be built before then, but I see no point in having an Exchange servers sitting around for days or weeks without being in production - it will simply cause confusion.
Simon.
Exchange publishes information to the domain, that will include the Autodiscover information. All Exchange servers will publish their information to the domain, so when you have multiple servers you will usually have the same information across all servers.
As for routing - Edge has nothing to do with this. Again Exchange is designed to use all Exchange servers in the org. There is no such thing as a dormant Exchange servers.
Therefore it will send email via that other server, because that is what it is designed to do.
Either configure the server completely or install it closer to the migration date.
In your scenario I would be installing Exchange probably on the same day as the planned migration, no earlier. The host OS would probably be built before then, but I see no point in having an Exchange servers sitting around for days or weeks without being in production - it will simply cause confusion.
Simon.
As soon as you install Exchange, it will become part of the live environment.
Exchange will use it for routing email, and it will also be used for Autodiscover functionality. Exchange is not a standalone application. It is heavily integrated within AD and all Exchange servers in an org will be used.
There is little you can do with regards to email routing, other than stopping the Exchange services.
You can avoid the Autodiscover issues by configuring the new server to use the old:
set-clientaccessserver newservername -AutodiscoverServiceIntern
where host.example.com is the name on your SSL certificate on the old server which also resolves internally to the server.
However, if you are not going to use the Exchange server for a while, why bother installing it at all? I would encourage you to not install Exchange, but instead plan exactly how you are going to do the migration, cope with the coexistence etc.
If you want to play around with Exchange 2013 then build a test environment to do it. Due to the integration mentioned above, you cannot really test Exchange in your live domain.
Simon.