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.