I often get questions from people who are concerned about the impact of installing the first Exchange 2010 server into their existing organization.
The true impact is going to depending a lot on the size, complexity, and integration points of an Exchange organization. But here is a quick run down of a few of the more common scenarios that I’ve encountered..
Exchange Server 2010 has its own schema update required. Like any schema update this is not something that can easily be rolled back if you change your mind.
Although I’ve never encountered an Exchange schema update that went badly due to errors, I have unfortunately heard from a few people who installed Exchange 2010 and made a mistake but who had no Active Directory backups at all.
So before you proceed make sure your existing AD is healthy, and you have your AD backups working and are familiar with the process for doing a schema roll back.
Inbound/Outbound Email Routing
Installing Exchange 2010 Transport servers into an organization has no impact on in/out email routing between your organization and external networks, until you make changes to move the new servers into the email route.
For example, until you update your MX records, or change your SMTP firewall rules or smart host configuration, to point incoming email at the Exchange 2010 server, it will not be responsible for incoming email.
Similarly, until you add your Exchange 2010 Hub Transport server as a source server for the Send Connector that sends email out of your organization, it will not be involved in that mail flow either.
Internal Email Routing
An Exchange 2010 Hub Transport server may participate in inter-site email flow within the organization. A possible area of concern here is message size limits. If you have modified yours to be larger than the defaults, the new server may reject some email (although I would expect Exchange to work out another route anyway).
For that and other reasons you may consider using the /DoNotStartTransport parameter during setup to prevent the server from coming online until you’ve configured it the way you want it.
Outlook 2007/2010 clients may see SSL warnings when an Exchange 2010 Client Access server has been installed due to Autodiscover and the default self-signed certificate that is installed with the new server.
This is explained in more detail here: Autodiscover and SSL Warnings during Exchange 2010 Migration
Outlook Web App and Other Client Access Services
A common concern is that the introduction of an Exchange 2010 CAS will in some way change how clients connect to services such as OWA and ActiveSync.
This concern tends to emerge due to the option during setup to specify an external name for the Client Access server.
This option during graphical setup is the same as the /ExternalCASServerDomain parameter for unattended setup. As explained on TechNet:
Use this parameter to specify the external domain for the Client Access server to configure the external URL for the OWA/ActiveSync/Web Services/OAB virtual directory.
In other words, it just pre-configures the External URLs for those virtual directories for you, saving you some time later on. You still have complete control over where you clients connect for those services, because that depends on where the DNS records are pointing.
When you install a Mailbox server it includes a mailbox database by default. Or in other cases, you may install a Mailbox server, configure multiple mailbox databases, and then leave it for a period of time before you add mailboxes to it.
There is a risk in some organizations that another administrator may mistakenly add or move mailboxes to one of your new mailbox databases before you configured backups for them.
My recommendation is to use this PowerShell script to monitor your database backup time stamps and alert you to those that have not been backed up recently. My personal view is that if a database exists, even pre-production, it should be backed up. If you aren’t planning to put it in production for a lengthy period of time, the database shouldn’t exist at all.
Sorry if this was asked before, but I cannot seem to find the answer to a problem that seems to me simple to solve.
We get a lot of SPAM from senders that use our internal names, escpecially admin and info, but also other existing internal domain names.
I would like to be able to specify an edge/server rule that says: Only accept mail from senders known in my domain if this sender is authenticated.
Thanks for any advise.
We are in the same situation as Gregski. We are currently running Exchange 2003 servers in a FE/BE config. We use MS TMG in our DMZ to load balance OWA requests to FE OWA servers.
We are moving to 2010 but taking 1 step at a time. I have the 2, 2010 CAS VMs built and ready to install the CAS and HUB roles. However, I am waiting for storage in order to install the 2 Mailbox servers. Those servers will also be in a DAG. So, I am wanting just to install the 2 node CAS array first to co-exist with my 2003 Exchange servers and install the MBs when the storage arrives.
Reading above, it does not seem like I should worry about the installation of the new 2 node 2010 CAS array that has the CAS and HUB roles, with respect to how internal mail flows from users Outlook 2007 clients to their 2003 mailboxes or worry about how external users access 2003 OWA through the TMG server in the DMZ, correct?
We have a complex enterprise 2003 setup (multiple front ends and multiple cluster back ends). We like to take baby steps. This article puts our mind at ease a bit. However can we just install the 2010 CAS servers (sure we will use a CAS array) but can we install them and no new 2010 HUB servers and just chill for a week or two without any problems. I would expect the CAS servers only playing a role in client access, ie working as traffic cops to direct our Outlook 2010 MAPI clients to the old 2003 front ends which would then point the users at their old 2003 mailbox servers. OWA would still go directly to the old 2003 front ends. We do not have any Public FOlders. Is that so or am I missing something?
No they won’t act as traffic cops. Exchange 2003 mailbox users continue connecting to Exchange 2003 servers, regardless of their Outlook version.
I also think it’s worth mentioning to go ahead and create a CAS Array. It’s a one line PowerShell script that would have saved me HOURS of legwork when I added a 2nd server to our Organization. Since I had no CAS array, when I moved mailboxes the Outlook clients were “hard mapped” to our server name. Because I moved mailboxes to the new server before creating the CAS array that servername mapping was in there.
If i had created a CAS array before moving mailboxes all that trouble would have been saved.
This should just be automatically created during Exchange setup in my opinion.
You aren’t alone in that situation, and yes I agree it should have been clearer at the outset. The best practice took quite a while to emerge, and the creation of CAS Arrays is buried in the shell too where most people won’t discover it on their own the way they do things that are surfaced in the GUI tools.