Deploying windows updates with Microsoft SCCM 2007

Part 1



Part 2



Part 3

Exchange 2003 to Exchange 2010 Migration Guide

We will walk through six main steps:-

• Exchange 2003 to Exchange 2010 migration – Preparing the Active Directory

• Exchange 2003 to Exchange 2010 migration – Exchange 2010 virtualization

• Exchange 2003 to Exchange 2010 migration – Deploy Exchange 2010 Client Access role

• Coexistence of Exchange 2010 Client Access server role with legacy Exchange servers

• Deploying the Exchange 2010 Hub Transport Server Role

• Deploying Exchange 2010 Mailbox Server Role

Preparing the Active Directory

Some companies still run Exchange 2003 and are content with its performance. However, Exchange 2003 is slowly getting close to the end of its lifecycle. Besides the end of mainstream support, there are other good reasons to switch to a newer Exchange version. In particular, Exchange 2010 offers many features that are just too good to be ignored. In addition to high scalability, the most welcome feature is the Database Availability Groups (DAG). It has never been easier to offer High Availability services for your users. But what about the migration to Exchange 2010; is it as simple as building a DAG?

The migration certainly is easier than what most administrators will expect. Microsoft also offers some nice guides, such as the Exchange Server Deployment Assistant. Though I strictly followed the guide, I encountered more than one problem. As problem solving can take quite some time, I decided to share my experience. This is by no means a complete migration guide or an alternative to the documentation available on TechNet or elsewhere. It is merely a supplement to the Exchange Server Deployment Assistant.

Before you even consider starting the migration, you have to plan your Exchange deployment and consider such things as Exchange 2010 System Requirements and Storage Design. You also have to understand the different roles an Exchange Server can perform: Client Access Server, Hub Transport Server, Mailbox Server, and Edge Server. In the transition process I didn’t rely on a specific UI, as sometimes it’s easier to use the GUI and sometimes it’s faster to type the command in the shell. So if you have any aversions to shells, it is better to get rid of them soon because you have to use the shell to manage Exchange Server 2010.

The first thing you have to do after you finish the planning stage is upgrade the Active Directory. To prepare the Active Directory for Exchange Server 2010, I recommend using the command shell. The GUI setup is supposed to automatically do all the Active Directory upgrades in the background during install, but for some reason that didn’t work on my machine. Besides, you have more control over the process and you will learn more if you do one step after another in the shell and not just have the GUI do everything automatically.

So let us begin. Open a command shell, change to your installation media, and execute the following three commands:

setup /PrepareLegacyExchangePermissions

Exchange Server 2010 uses E-Mail Address Policies instead of Exchange Server’s 2003 Recipient Update Service. By running this command, you prepare the Active Directory for the coexistence of both.

setup /PrepareSchema

This command will create a connection to the schema master and update the schema with attributes specific to Exchange 2010.

setup /PrepareAD

This command prepares the local Active Directory for Exchange 2010, for example it creates a new OU called “Microsoft Exchange Security Groups”. In this container you’ll find a few default security groups that are quite handy for the administration of Exchange Server 2010.

After all three commands have finished successfully; you are ready to install the first Exchange Server 2010 in your domain. I will write about the deployment of the different Exchange roles in upcoming parts.

Exchange 2010 virtualization

Before I give a rough guide through the migration process I want to talk about the possibilities of virtualization for Exchange Server 2010. There are two reasons why I think it is necessary to bring this point up: First, there are still quite a few administrators that have a deep aversion to virtualization. Second, although virtualization is widely used today, there are a few things you have to consider before you should deploy Exchange 2010 on a virtualized machine. Exchange 2010 is ready for virtualization, so you can install every role on virtualized guests. Only the Unified Messaging Server Role needs to be installed directly on the hardware.

For those who are still skeptical about running a business-critical application like Exchange in a virtualized environment, I just have to say that it works; indeed, it works very well. Besides that, there is no difference between running Exchange Server 2010 on a hardware machine or a virtualized machine, as long as you follow some guidelines. It even has some advantages: If you want use the DAG feature of Exchange 2010 you need two Server and two Windows Server 2008 R2 Enterprise licenses. If you only have a midsized company, the chances are big that the resources of the two Servers are not close to being utilized properly. The Windows Enterprise license allows you to run up to four software instances at a time in a virtualized environment under one license. So you could have up to eight virtualized machines running Windows Server 2008 R2 Enterprise with the two licenses you need for a DAG. Isn’t that alone reason enough to virtualize Exchange 2010?

But the focus of this post is not to convince you of going virtual, but to give you some help in deploying the virtual environment properly. Because you already have a Windows Server 2008 R2 Enterprise license, and because Hyper-V is a great hypervisor, I recommend using Hyper-V R2 as the host system. But you are not limited to Hyper-V. If you favor other virtualization solutions, like VMware ESX, Exchange 2010 should run on them flawlessly, as long as the product is part of the Server Virtualization Validation Program.

The most important point you have to consider when going virtual is performance, because an improperly deployed virtualized Exchange system can result in sluggishness and instability. There are just a few points you have to consider when going virtual:

• The virtual hard disk has to be either fixed sized or a passthrough hard disk. Passthrough disks are the faster option, and should be used for storing the mailbox. If you plan to use a SAN, Microsoft recommends using a separate LUN for the host server, the guest server and the virtual hard disk on which the Mailbox is stored.

• Hyper-V offers the option to take snapshots from guests. This is great feature for testing purposes, but you should never use this feature when performance is important, because after you have taken a snapshot, performance will drop a lot. Furthermore, reverting to a snapshot is not supported by Microsoft.

• Allocate sufficient memory for the host system. 1 GB of RAM may be enough, but I would reserve at least 2 GB of RAM for the host system.

• You can have a maximum of two virtual processors for every physical core. One physical core is reserved for the host system. So if you have one quad core processor you can assign up to six virtual processors to your guest systems. The amount of virtual processors per guest is limited to four, though.

• For managing your host, you should reserve one NIC. Also, if you run a failover cluster, you should have a dedicated NIC for this purpose. Depending on the network bandwidth the guests need, it might be necessary to use more than one NIC for the guests.

• The virtualization host should be dedicated to serve the virtualization environment, so no other services should run on it.

If you follow these recommendations, you have the basement for a stable and fast virtualized Exchange 2010 environment. Nonetheless, you have to plan the amount of servers and their resources correctly to not run into any problems.

Deploy Exchange 2010 Client Access role

The first role you have to deploy is the Client Access role. Before you can run the Exchange server’s setup routine, you must install the following software: .NET Framework 3.5 SP1, PowerShell 2.0, WinRM 2.0, and IIS 7.0.

You also have to install a few server roles and features. You can do this via the Server Manager interface, or you can use this PowerShell command:

Add-WindowsFeature NET-Framework,RSAT-ADDS,Web-Server,Web-Basic-Auth,Web-Windows-Auth,Web-Metabase,Web-Net-Ext,Web-Lgcy-Mgmt-Console,WAS-Process-Model,RSAT-Web-Server,Web-ISAPI-Ext,Web-Digest-Auth,Web-Dyn-Compression,NET-HTTP-Activation,RPC-Over-HTTP-Proxy -Restart

You must also set the .NET TCP Port Sharing Service to automatic. Just copy and paste this command to the PowerShell command line:

Set-Service NetTcpPortSharing -StartupType Automatic

Now that the prerequisites are installed, you are ready to run the Exchange 2010 setup. It is easier to use the GUI for this installation step. When you insert the installation media, the setup wizard should launch automatically; if not, manually launch setup.exe on the installation media.

When the wizard starts, you’ll see five steps listed under the heading Install. The first and second ones are grayed out because, assuming you followed this guide, you have already completed these steps. To complete Step 3, you have to choose the languages you want to install. If you don’t have any exotic language requirements it is sufficient to use only the languages delivered with the DVD.

The installation routine starts when you click on the next step. After the introduction screen, you have to accept the License Agreement. If desired, you can also disable the sending of error reports to Microsoft. On the next page you have the option to make a typical or custom Exchange installation; choose “custom” here.

Now it gets interesting because you can select which Server Roles you want to install. At first you only need the Client Access Role, so check the appropriate box. You’ll see that the Management Tools are selected automatically. The Edge Server Role is grayed out because this role can’t coexist with any other Server Role.

When you click the Next button, you will be asked if the Client Access server is Internet facing. If you want to use Outlook Web Access, Outlook Anywhere, or ActiveSync outside of your company’s network, you will have to make the Client Access server Internet facing. You will also have to provide a namespace (for example, mail.contoso.com) under which your users can access Exchange 2010 from the Internet. If the namespace you plan to use for Exchange 2010 is already taken by your previous Exchange server, you will have to change the namespace of the legacy Exchange server later. Entering your productive namespace will also make some Exchange services, such as ActiveSync, unavailable for your users until you fix some things. I will talk about that in another post, so if you want to use your existing namespace it is a good idea to read the post before you continue.

After you enter the domain name, click Next. The installation routine automatically starts the Readiness Checks. As long as you followed this post you should not run into any problems. However, if any errors occur, the setup wizard gives a helpful description of the problem and its solution. After every check completes successfully, proceed to the next page. The setup wizard begins copying the files to the hard disk and configuring the Exchange 2010 environment. After a few minutes, the installation of the Client Access Role is completed.

Coexistence of Exchange 2010 Client Access server role with legacy Exchange servers

By following my guide, you set the external namespace for the Exchange 2010 environment. For your users’ convenience, you might have chosen the same namespace you used for your legacy server. But assigning the same namespace for two different services usually causes a lot of trouble, so you might ask yourself how both Exchange versions can coexist under the same namespace.

Coexistence under the same namespace is not possible. When you provided the same namespace during the Client Access Server Role installation that you are using for your legacy Exchange installation, the setup routine automatically changes the namespace for the legacy server. If your users try to access Exchange using the URL they are used to, they connect to Exchange 2010. But that is what you want your users to do because Exchange 2010 Client Access can interoperate with legacy Client Access servers. If the Exchange 2010 Client Access server gets an access request it can’t handle, it simply redirects the query to the legacy server.

To make these redirections and the coexistence of both Exchange versions work, you have to assign a different external namespace (for example, legacy.contoso.com) to your legacy servers. The configuration of the legacy server is different for Exchange 2003 and Exchange 2007.

Coexistence with Exchange 2003

First, create a DNS entry for the legacy namespace and point it to your Exchange 2003 front-end servers. If this new namespace is not included in the certificates of your legacy front-end servers, you have to create new certificates. After the entry is created, you have to configure every Exchange 2010 server to redirect to this address. You can do this with the following command:

Set-OwaVirtualDirectory “Contoso/owa (default Web Site)” –Exchange2003Url https://legacy.contose.com/exchange

If you use ActiveSync on your legacy Exchange servers, make sure that the Integrated Windows authentication is turned on. Last, but not least, if you use RPC over http, make Exchange 2010 the connection point and disable RPC over http on the Exchange 2003 server.

Coexistence with Exchange 2007

First, create a DNS entry for the legacy namespace that points to the Exchange 2007 Client Access server. Update the external namespace on your Exchange 2007 Client Access server and install appropriate certificates. Next, change the Autodiscover path to point to your Exchange 2010 servers. The last step is to turn off Outlook Anywhere on the Exchange 2007 servers and enable it on the Exchange 2010 server.

Finalizing the configuration

The configuration of the Exchange side for the coexistence phase is now finished. But you must also adapt your firewall rules to the new environment. If you offer the same services on Exchange 2010 as on the legacy Exchange server, you just have to add the Exchange 2010 server to the rules and you are done. Otherwise you have to create a few new rules.

When you are finished with these steps, not everything is working yet. However, you have an environment where at least the basic services work (Outlook Web Access, Outlook Anywhere, and ActiveSync), and the coexistence of Exchange 2010 with your legacy Exchange server will give you some time to finalize the configuration of Exchange 2010. One of the next steps would be to configure the Offline Address Book. For that purpose you need a mailbox server running at least Exchange 2007. I will cover that topic in a following post, but first I am going to write about deploying the Exchange 2010 Hub Transport and Mailbox Server Role.

Deploying the Exchange 2010 Hub Transport Server Role

By now you should have a working Exchange 2010 Client Access server. However, an Exchange 2010 environment needs at least two more server roles installed: the Hub Transport Server Role and the Mailbox Server Role. It doesn’t matter if you are going to deploy these roles on the same server as the Client Access Server Role or if you choose a different server; the procedure is nearly the same. Because installing the three roles on the same server might lead to performance issues, however, Microsoft recommends to not combining the Mailbox Server Role with any other role on the same server. In small environments, performance shouldn’t drop when you run all of them on the same server, even if the server is virtualized.

Let’s start with the Hub Transport Server Role. The installation process will differ slightly if you install this role together with the Client Access Server Role or on a standalone system. If you do the latter, you should install the prerequisites before you launch the setup wizard. The fastest way to achieve this is by typing these PowerShell commands:

Import-Module ServerManager

Add-WindowsFeature NET-Framework,RSAT-ADDS,Web-Server,Web-Basic-Auth,Web-Windows-Auth,Web-Metabase,Web-Net-Ext,Web-Lgcy-Mgmt-Console,WAS-Process-Model,RSAT-Web-Server –Restart

Now you can launch the setup wizard. First, you have to choose the language; choose the same option you chose when installing the Client Access Server Role. Proceed to the next step and install the Exchange server. If you started the installation routine on an Exchange server where other roles are installed, the routine will tell you that Exchange is going into maintenance mode. On a bare system, you have to click through a few dialogs until you reach the Server Role Selection page. Here, choose the Hub Transport and click Next. The next steps are the same as when you installed the Client Access server, except that the Client Access-specific dialogs do not show up and one Hub Transport-specific dialog is displayed. This dialog, called Mail Flow Settings, is where you will choose the legacy server to which the Exchange 2010 server will connect.

After the installation finishes, open the Exchange Management Console and navigate to Server Configuration -> Hub Transport. Under Receive Connectors, you will find a default receive rule that is automatically generated during the installation to ensure that e-mails can be exchanged between the legacy server and the Exchange 2010 Hub Transport server. Although everything should already be configured, you should manually check these settings.

By default, no send connector exists. To create one, navigate to Organization Configuration -> Hub Transport, right-click in the result pane to open the context menu, and choose New Send Connector. This opens the New Send Connector wizard, where you should choose a meaningful name for the connector and select Internet as the intended use for this connector. You’ll define the address space in the next window. Usually you want to route your external mail traffic to one relay, so you should type a * here. Don’t change the Type and Cost settings. The next step, called Network Settings, is where you will choose the server to which outgoing messages are sent. The default setting (using DNS to route outgoing mail traffic) is the right one unless your company has a mail relay that works as a smart host. In the last dialog, you can add other Hub Transport servers to this send connector, but you shouldn’t have one at the moment. Finalize the wizard by clicking the Next and New buttons. Now your Exchange 2010 environment is ready to deliver mail to your legacy Exchange server and to every other mail server on the Internet.

Before you start installing the Mailbox Server Role, you should delete the Exchange 2003 SMTP connector. I recommend verifying that the message flow of the Exchange 2010 server works as intended before you delete the SMTP connector. In my next post, I will talk about the deployment of the Mailbox Server Role, which is the only required role that is still needed for a working Exchange 2010 environment.

Deploying Exchange 2010 Mailbox Server Role

The Mailbox Server Role is the last role you need to install to have a working Exchange 2010 environment. The two Server Roles that I haven’t talked about yet—namely, the Edge Server Role and the Unified Messaging Server Role—are specialized roles that either improve security or centralize communication in one inbox. Exchange 2010 will run well without them, so I won’t cover these topics in my Exchange 2010 deployment series.

The deployment of the Mailbox Server Role is straightforward. The Mailbox Server Role is quite resource intensive, so unless you have a very small amount of users and data you should deploy it on its own server. The mailbox server is also the place where all your data resides, so it needs plenty of hard disk space. A video is available at TechNet that supports you in deciding how to size the mailbox server. There is also a tool to calculate Exchange 2010 Mailbox Server Role Requirements.

If you want to install the Mailbox Server Role on a bare server, on which no other Exchange Server Roles reside, you have to install the prerequisites first. This is easily accomplished by executing the following commands in PowerShell:

Import-Module ServerManager

Add-WindowsFeature NET-Framework,RSAT-ADDS,Web-Server,Web-Basic-Auth,Web-Windows-Auth,Web-Metabase,Web-Net-Ext,Web-Lgcy-Mgmt-Console,WAS-Process-Model,RSAT-Web-Server –Restart

You are now ready to launch the installation wizard from the installation media. You should be familiar with the process by now: Choose which language pack to install, and then start the installation wizard. As this is the third time you will be using the wizards, I won’t bore you by explaining the details again.

If the installation has completed successfully, you are done with the installation part of the Exchange 2010 deployment for now. It is time to configure the different Server Roles. But if you want to add more security, high availability, or a unified inbox to your Exchange environment later, you will need to run the installation wizard again.

The newly created mailbox server already has a default database. I recommend changing the paths of the mailbox database file and the transaction log folder. If you want maximum performance, you should put each of them on a different drive. You can change the paths easily by launching the Exchange Management Console and navigating to Organization Configuration -> Mailbox. Before you do so, you have to dismount the database; you can find that option by right-clicking the database’s name. After dismounting it you can choose the “Move Database Path” option from the context menu. A small wizard will be launched where you can set the database name, database path, and location of the transaction logs.

If public folders are used in your environment, a default public folder database should be created during the installation. You should also change the path settings for this database. You may want to change some settings for Message Tracking and Records Management, too. This can’t be done with the Exchange Management Console, though. You need to use the Exchange Management Shell. To alter the Message Tracking settings you have to use this command:

Set-MailboxServer <MailboxServerName> –ManagedFolderAssistantSchedule <AssistantSchedule>

For the Records Management settings use this command:

Set-MailboxServer <MailboxServerName> -MessageTrackingLogPath <LogPath> -MessageTrackingLogMaxAge <MaxAge> -MessageTrackingLogMaxDirectorySize <LogDirSize> -MessageTrackingLogMaxFileSize <LogFileSize> -MessageTrackingLogSubjectLoggingEnabled <SubjectLogEnabled>

Now the final step is moving your mailboxes to the Exchange 2010 mailbox server using move mail boxes wizard.