Tag Archive: Exchange 2010

As a Microsoft Certified Trainer (MCT) you would never expect me to post a blog review on a product that could somewhat compete with my company’s business. Now my company doesn’t produce any streamed or Computer Based Training (CBT) so this technically isn’t a conflict of interest.

I realize that people learn in different ways. People have very different lives. So some people would just rather have a relaxed video to talk them through a process or technology and can pick it up easily. Others require interaction with a Instructor Led Training (ILT) session. A lot of people can’t carve out the time away from work for a full blown ILT classroom environment. A lot of times your company can’t afford a full ILT class either. They have the desire to learn but can only afford a 30 minute span here or 2 hours a few times a week. If this is the case (and it is for a lot of people out there) then CBT learning is definitely for you.

Now it’s very rare that I endorse products on here. I try to shy away from such things as they could be taken the wrong way or can be misconstrued. So when I do, you know I do so because I really believe in the product or service.

Now that the *disclaimer* is out of the way let’s get to the goods. Maybe goods isn’t a correct word to describe the product were about to talk about, GREAT is a better word. I had the pleasure of reviewing a product from our friends over at Train Signal, (Follow them on Twitter – @TrainSignal). I have personally met some of the Train Signal team in person and they are a real pleasure to work with.

I have heard some pretty bad things about other CBT’s and was a bit hesitant at first. Within the first hour I was completely sold. The particular products I have been review is part of their Exchange 2010 series. In particular the Exchange 2010 MCITP and the soon to be released Exchange 2010 backup and recovery packages. I enjoyed the choice of formats. All of train signal’s products are available in a DVD or streaming option. I chose the DVD for one as I like to use my Windows Phone 7/zune device for podcasts in long car rides and the train commutes. The additional files and free transcenders for those of you which are certification hungry is a HUGE bonus. You are really getting a lot of content here for your buck.

Let’s talk about the instructor for both of these series for a bit. One of the biggest things that any online / remote instructor has to tackle is connecting with the audience. This is harder to convey things like body language and looks and glances are unavailable. Your style of delivery and tone / pitch of your voice really becomes truly make or break. Our instructor on these series is the soon to be famous J. Peter Bruzzese.  (Follow him on Twitter – @JPBruzzese) J.P is a Microsoft MVP for Exchange, Triple-MCSE, MCT, MCSA, MCITP: Messaging, CNA, CCNA, CIW Master, and CIW Certified Instructor! He is definitely well versed in IT! As a fellow instructor I tend to be a little more critical than the normal student. I also like to consider myself a Subject Matter Expert (SME) in Active Directory and Exchange. So when I started going through J.P.’s courses I was very refreshed in his great delivery, style and technical acumen. No one ever knows everything about technology, but he has to be close. I’ve been teaching Exchange for years and I was able to pick up a few things! He uses great real world analogies and doesn’t completely swim in the Microsoft Kool-aid. He regularly references technologies that aren’t always MS focused or delivered, to give you a sense it’s not a sales pitch.

Now the content itself covers almost every possible reach in the Exchange 2010 landscape. Everything from Backup, recovery, new SP1 features, message management, etc.. The content is in the right size chunks. You don’t have to commit 2-3 hrs for a lesson, nor does the content delivered feel overpowering. So between the right size, J.P.’s delivery I found it to be a perfect fit. The beautiful and best part is that it’s SO on point. If you’re an Exchange 2010 admin who’s been thrown into the mix, you will learn best practices and look for things to optimize in your existing environment. For you cert-mongers out there it’s almost a complete solution for exam readiness. If you are planning a deployment, these series will be able to fully understand all the mechanisms involved to properly plan your upcoming migration to Exchange 2010.

In summary I give Train Signals products in general and especially the Exchange 2010 series a 5 out of 5 stars!


So near the end of January I was lucky enough to escaped the void of the classroom and get back to hands-on work. I was able to act as a consultant for my training firm and go on-site to an old student of mine’s place of business. Our task seemed simple. Migrate a single exchange 2003 server to a mailbox redundant 2010 solution.

Just drop down a few new 2010 boxes and call it a day right? Not so much. Any migration can have hiccups and issues along the way. We had originally chipped out four days to complete the process. Due to some SAN issues we lost our first day and then had to get everything ready in just 3. One box and about 350 mailboxes it should be easy right? We planned for extra time thank goodness. If we originally planned on 3 and now only got 2 we’d be very hard pressed to have that done. We did in fact get the major steps done in 3 days. let’s review all that happened.

For security purposes let’s not give out our clients domain name and such, let’s focus on what we know and what was learned over the 3 days. Here is where we started.

Single domain forest. All DC’s and GC’s were at the Exchange 2010 minimum of 2003 SP1 or higher. Domain functional level was 2003 as was the forest functional level. Permissions on the accounts to be used for installation were in place, so let’s get started. All inbound mail via his MX record was going into his SonicWall and then being placed into his Cisco IronPort device for scrubbing before being delivered to the 2003 Exchange server.

We began with bringing up the OS of the first Exchange 2010 box in a VMWare virtual environment. The OS was to be 2008 R2 Enterprise edition. Why enterprise? Well we planned on using a DAG (Database Availability Group). This HA (High Availability) feature requires the failover clustering component within Server 2008. That was still in standard edition back in the 2003 Server days, but has been removed in 2008 RTM and higher. So now that R2 server is ready and fully patched / updated, let’s get the Exchange pre-req’s on there for the Exchange bits install. To speed things up we used a pre-made script that automates all the installation of required items as they pertain to Exchange role requirements. You too can download it HERE. It was created by Exchange MVP Dejan Foro. You can hit his whole site here – www.exchangemaster.net.

Think your ready for Exchange install time? Not so fast son. There are four KB document fixes that will need to get put on 2008 R2 before anything else is started.

Before you start contemplating putting that Exchange 2010 media in or mounting that ISO. Check your DNS and active directory to ensure it’s solid and stable before continuing. Also make sure that you have your 2003 / AD settings all up to snuff.

  • Ensure your 2003 address policies are not split between authoritative and non-authoritative. This may require you to modify or even rebuild them.
  • Check your Recipient update services in that they are pointing to a valid DC that still exists Smile
  • Ensure any external or manually created trusts are working and verifiable.
  • Is your domain a SLD? (Single label domain – “Consoso”, not “contoso.com” when you have ADUC open).
  • Ensure IPv6 and the windows firewall is enabled. Either of these could kill your install of Exchange.

OK, NOW you can begin your installation of Exchange. I recommend copying the source files locally to a new folder called “C:\source” or something like that. Now download the latest rollup (RU) for the version of Exchange (RTM vs. SP1) and placing it in the \updates folder. This will slipstream the updates during the installation and save you steps later!

Step 1.) Preparation of AD

This went very easy as we had a single domain and all the rights necessary. Wasn’t a fast process but experienced no errors when we ran setup.com with the following switches..

/preparelegacypermissions – this is ONLY needed if you have 2003 exchange. Skip if you have 2007

/PrepareAD – do you know your organization name? you can find it in the ESM.

Step 2.) Install Exchange on your first server. Have a plan here. Don’t just rip off a “typical” install (core 3 roles – CAS/HUB/MBox) if  you’re unsure, use the Exchange Deployment assistant.

We knew we were only going to have 2 servers with all three roles on them. We chose to do the “typical” install. We also set the “External” address for his CAS role to the same thing as his existing 2003 OWA URL (I.E. – “Http://mail.contoso.com”)

Now we have a fully functional Exchange 2010 server with nothing coming into it, and not hosting any mailboxes.


This is a great starting post and will continue to cover hiccups we hit in a future post. (ran out of time Smile )

Windows phone 7. Is it a game changer? new paradigm? No. I own one. I’ve just moved from an iPhone 3G. Is it better than it? too early to say honestly. iPhone’s have had the luxury to evolve their platform over time. This is still RTM of WP7. I think the interface is fantastic and the “flow” of it refreshing. I do hate how few apps there are still. I expect this to improve over time as it has for the Droids. For that reason alone I still keep my old iPhone handy for certain things Sad smile 

The WP7 devices are consumer focused. I expect they’ll be ready for prime time in the enterprise soon as it evolves as has the iPhone. One of the things that shocked me was the serious limitations on the EAS policy features for WP7. Another being the NO local sync for non-cloud mail based users. My wife was personally affected by this. One of the reasons she stayed with the iPhone 4

Uber blogger extraordinaire Paul Thurrott (twitter @thurrott) expounds on what has been removed and what is really left when it comes to EAS support on WP7. The article “Windows Phone 7 and Exchange Activesync” can also be found on his WP7 primary page of http://windowsphonesecrets.com/ or his other site http://www.winsupersite.com/

Below is a tidbit of what Paul reports..

What is left?

Its important to note that Windows Phone 7 devices only support a subset of the Exchange ActiveSync (EAS) policies available with Exchange 2003, Exchange 2007, and Exchange 2010. Currently, Windows Phone 7 supports the following EAS policies:

  • Password Required
  • Minimum Password Length
  • Idle Timeout Frequency Value
  • Device Wipe Threshold
  • Allow Simple Password
  • Password Expiration
  • Password History
  • Disable Removable Storage
  • Disable IrDA
  • Disable Desktop Sync
  • Block Remote Desktop
  • Block Internet Sharing

If I have a NLB or hardware load balancer – why do I need a CAS array?

This is an excellent question and it’s all about client connectivity, transparency of the connection to the user and automagic cutover in the event of a CAS array member failing. this becoems even more important now that ALL client connections including RPC MAPI connections are now going through the CAS role. Heck if you look at the MAPI account config for an exchange mailbox user it now shows the CAS server name, not the Mailbox role server name. To avoid client reconfiguration or disconnection and forcing a re-query for available CAS boxes, we have CAS arrays to assist in this.

The following information was found in this TechNet page Understanding RPC Client Access. NOTE – this is for RPC high availability, if you still want OWA / EAS  / ECP high availability MS recommends a solution like Forefront Threat Management Gateway.

When a Client Access server array is defined in an Active Directory site, it serves as a single contact point for all client connections within that Active Directory site. A Client Access server array can include one or many Client Access servers.

Each Active Directory site can have a single Client Access server array. A Client Access server array doesn’t provide load balancing. A separate load balancing solution is still needed. For more information about load balancing, see Understanding Load Balancing in Exchange 2010.

Microsoft recommends that you create a Client Access server array even if you only have a single Client Access server within your organization. When a Client Access server array is created, clients connect through the virtual name of the Client Access server array rather than directly to the fully-qualified domain name (FQDN) of your single Client Access server. If a single Client Access server needs to be replaced within an Active Directory site or a second Client Access server is added, no profile updates are necessary on the clients.

After a Client Access server array is defined within an Active Directory site, all Client Access servers within that Active Directory site are automatically part of the Client Access server array.

The high level steps are here..

  1. Create a Client Access array
  2. Configure load balancing
  3. Configure IP ports
  4. Configure RPC encryption settings
  5. Configure your Mailbox databases
  6. Ensure low latency and sufficient network speed

     Create a Client Access Array

You can create a Client Access array within your Active Directory site by using the following command.

New-ClientAccessArray -Name name -Site site_name -FQDN internal_only_CAS_Array_FQDN


After the Client Access array has been created, you’ll also need to create the address in DNS and associate it with the virtual IP address used for the Client Access array.

It’s important that the (FQDN) specified in the command be only resolvable internally. If the name is also resolvable externally, these external clients will attempt to connect to the array via a TCP connection instead of HTTPS.

  Configure Load Balancing

Load balancing is recommended for high availability, failover, and for spreading the traffic load over multiple servers to help performance. When you choose a load balancing solution, consider the following:

  • Windows Network Load Balancing isn’t supported on Windows failover cluster servers.
  • You can’t use a Client Access array across multiple Active Directory sites. Instead, create two Client Access arrays and load balance separately within the sites.
  • Hardware load balancers typically monitor return traffic, port availability, or service availability to ensure that servers that can’t answer client requests aren’t given network connections.
  • Some load balancing solutions, such as ISA 2006 or TMG 2010, can’t do RPC load balancing or monitor RPC services. These solutions aren’t recommended unless all clients are connecting via Outlook Anywhere and all traffic is encapsulated inside HTTP.

For more information about load balancing, see Understanding Load Balancing in Exchange 2010.

Configure IP Ports

An IP port is an opening through which information can pass from the originating computer to the destination computer. By default, the dynamic port range for outgoing connections on Windows Server 2008 R2 is 49152 to 65535. Exchange 2010 Client Access changes this range to 6005 through 59530. The range was expanded to provide sufficient scaling for large deployments. This is a large range of ports to balance through your firewall between the client and the Client Access servers or Client Access array.

By fixing the MAPI and directory endpoints, you can greatly reduce the number of ports that need to be load balanced. The MAPI endpoint can be statically configured in the registry and the directory endpoint can be fixed in a configuration file.

To fix the MAPI endpoint, use the following setting in the registry.

HKLM\SYSTEM\CurrentControlSet\ Services\MSExchangeRPC\ParametersSystemTCP/IP Port [DWORD] is the value for the IP port to use

To fix the directory services endpoint, edit the RpcTcpPort value in the configuration file Microsoft.Exchange.AddressBook.Service.Exe.config.


Microsoft doesn’t recommend that you change the default value of the Outlook Anywhere ports.


  Configure RPC Encryption Settings

In Exchange 2010, the RPC endpoint is encrypted by default. However, Outlook 2003 doesn’t enforce encrypted MAPI connections. When you upgrade your organization to Exchange 2010, your clients running Outlook 2007 or later versions will automatically be compatible with the change to RPC Client Access, since they support RPC encryption by default. Outlook 2003 doesn’t use RPC encryption, however, and RPC Client Access requires it by default. If you haven’t turned off RPC encryption, which we don’t recommend, your users will need to configure Outlook 2003 for RPC encryption or you’ll need to use a Group Policy to force Outlook 2003 to use RPC encryption.

Symptoms of this problem include the following error messages:

  • Cannot start Microsoft Office Outlook. Unable to open the Office window. The set of folders could not be opened.
  • Unable to open your default e-mail folders. The information store could not be opened.

If your users are using Cached Exchange Mode, Office won’t display an error, but will start in disconnected mode.

For more information about this issue, including workarounds, see Outlook Connection Issues with Exchange 2010 Mailboxes.


  Configure Outlook 2003 to Use RPC Encryption

To configure Outlook 2003 to use RPC encryption, use the following steps.

  1. Click Tools > E-Mail Accounts > View or Change an Existing Account.
  2. Select the account and click More Settings.
  3. Select the Security tab.
  4. Select Encrypt data between Microsoft Office Outlook and Microsoft Exchange Server.
  5. Click OK

In addition to the RPC encryption requirement, UDP notification support was removed from Exchange 2010. As a result, Outlook 2003 can only use polling notifications in online mode. This will result in a slight delay in updates to item status (30 seconds on average with up to a one-minute delay) when changes are made to items in a mailbox accessed by Outlook 2003. There are two workarounds for this issue:

  • Use Outlook 2003 in Cached Exchange Mode.
  • Adjust the polling interval on the Client Access server. This will impact the performance of the Client Access server.

For more information about this issue, see E-mail messages take a long time to send and receive.

  Configure Your Mailbox Database

Each Mailbox database contains an RPCClientAccessServer value. This value is established when the database is created and it determines the Client Access server or Client Access array that the clients with mailboxes on that Mailbox server will use. This value also determines the location of the RPC end point. For Outlook 2007 and Outlook 2010 clients, this value is obtained from the Autodiscover service.

The default value of the RPCClientAccessServer is determined by the following rules:

  • If you have configured a Client Access Server array within your Active Directory site, the address of that array will be used.
  • If an array does not exist within the Active Directory site and if you have both the Client Access server role and the Mailbox server role on the same physical server, the value of RPCClientAccessServer property for a particular Mailbox server will be the same as the Mailbox server.
  • Otherwise, the value of the RPCClientAccessServer property for a particular Mailbox server will be set to a random Client Access server within the Active Directory site.


    We don’t recommend that you install all the server roles on a single computer that’s also a domain controller. Although this configuration is supported, it’s not recommended.

  • If you created a Mailbox database before the creation of a Client Access array or the installed a Client Access server within the Active Directory site, you’ll need to reconfigure the value of the RPCClientAccessServer property. If no Client Access server exists in the Active Directory site when the Mailbox database is created, the value of the RPCClientAccessServer property will be set to the FQDN of the Mailbox server. To configure the value of the RPCClientAccessServer property, use the following command.
    Set-MailboxDatabase <name> -RPCClientAccessServer <internal_only_CAS_Array_FQDN>

  Latency and Bandwidth Requirements

For users running Outlook without Cached Exchange Mode, high latency times between the client and the server directly affect how frequently Outlook is unresponsive. In general, a latency of greater than 200 milliseconds (ms) to the home Mailbox server will result in poor client performance.

Because latency between the Client Access server and the mailbox should be less than 10 ms, we recommend that the value of the RPCClientAccessServer property always be configured to a Client Access array in the active Mailbox database site.


Changing the value of the RPCClientAccessServer property will force all clients to reconnect.

  Configuring the Address Book Service

The Address Book service is configured through the Microsoft.Exchange.AddressBook.Service.config file. This file allows you to configure the following:

  • The number of concurrent connections per user (the default limit is 50).
  • Disable or enable logging.
  • The location, size, and retention period for the log files.

To set the value of the maximum number of sessions per user, use the following value: <add key=“MaxSessionsPerUser” value=“50” />

To enable logging, use the following value: <add key="ProtocolLoggingEnabled" value="true" />

Great querstion from this week’s 10233 design of Exchange 2010 class. Our student asks

“in the past a mailbox move didn’t also move dumpster data. You had to recover it prior to the move. Has this changed in 2010?”

After some digging I was able to confirm that it IS now gathered along with everything else. Confirmed HERE found on the MSexchange.org site. Great article Neil!


The move request puts a special system message into the system mailbox on the mailbox database. The Microsoft Exchange Mailbox Replication service checks the contents of the system mailbox on each mailbox database to see if any move requests are waiting and then processes them accordingly. There are many benefits to having the mailbox moves carried out by this service. Here are three main areas that I typically encounter on migration projects that are addressed with move requests:

  • Mailboxes can now be moved online whilst the users are logged into them. Admittedly this is only available if the source mailbox is running Exchange 2007 SP2 or later, or Exchange 2010. However, this is a welcome addition to the overall mailbox moving process as it will help negate the need to move mailboxes out of core business hours.
  • Items in the dumpster are now moved as part of the process. In previous versions of Exchange, moving a mailbox did not move the items in the dumpster and it was therefore required that the user had to recover any deleted items prior to the mailbox move. It was all too easy to forget to inform the users of this fact and in some cases users who had been moved then proceeded to recover items from their dumpster only to find it completely empty.
  • The mailbox contents are no longer processed by the computer running the move process. It was often the case in Exchange 2007 that the Move-Mailbox cmdlet, or associated script, was run on an administrative machine rather than directly on the target Exchange 2007 server. However, in this scenario, the mailbox contents are moved from the source database to the administrative machine and then into the target database. This scenario was mitigated by running the cmdlet or script directly on the target database server. In Exchange 2010 this situation will not be encountered since the mailbox moves are performed by the Microsoft Exchange Mailbox Replication service running on the Client Access Server.

Now the following post has some parts from our friends at Exchangeserverpro.com. Please follow them on Twitter – @Exchservpro. Instead of re-inventing the wheel here I’d post some of their great content from the following two links..

Exchange 2010 CAS backup and recovery


Exchange 2010 Hub Transport backup and recovery


Now understand these steps listed below are if you are NOT going to be doing bare-metal or full server backups. Those obviously would be the easiest route.

Planning the Client Access Server Backup

As you plan the Client Access server backup strategy there are different techniques that you can consider depending on your requirements.

Backing up Everything

A full system backup of the Exchange 2010 Client Access server, along with a working Active Directory, will have all of the required information to recover the Client Access server.  Naturally this backup takes the longest to run, and will use up the most backup storage.

Backup up the Minimum

To reduce backup storage and keep the backup time frame shorter the minimum data on the Client Access server can be backed up.  This involves backing up the system state of the server, and configuration files stored in the \ClientAccess path of the Exchange Server 2010 installation folder (C:\Program Files\Microsoft\Exchange Server\V14 by default).

Backing up Nothing

It may be practical to not back up the Client Access server at all if:

  • There are multiple, redundant Client Access servers deployed (ie Client Access Server Array)
  • The SSL certificates are exported or retrievable from elsewhere
  • Customizations to the Client Access server virtual directories can be quickly reapplied using an existing script

If all of those conditions are true then the Client Access server may not need to be backed up at all.

Backing Up and Restoring Client Access Servers

In this demonstration a Client Access server has been configured as a single-node NLB cluster and Exchange 2010 CAS array.

Exchange 2010 Client Access server configured with NLB

Exchange 2010 Client Access server configured with NLB

The external URL has also been configured.

[PS] C:\>Get-OwaVirtualDirectory | fl name, *URL*

Name            : owa (Default Web Site)
Url             : {}
Exchange2003Url :
FailbackUrl     :
InternalUrl     : https://ex3.exchangeserverpro.local/owa
ExternalUrl     : https://mail.exchangeserverpro.local/owa
Recovering an Exchange 2010 Client Access Server

Because most of the Client Access server configurtion is stored in Active Directory when a Client Access server has failed you can recover the server using the following procedure.

  1. Install a new server to host the Client Access server role
  2. Configure the server to have the same name, IP address, and domain membership as the server that failed
  3. Install the Exchange Server 2010 pre-requisites
  4. Perform a recovery mode install of Exchange Server 2010

To run Exchange Server 2010 setup in Recovery Mode use the following command from an elevated command prompt.

setup /m:recoverserver

Setup performs a server recovery using the configuration information stored in Active Directory.

Welcome to Microsoft Exchange Server 2010 Unattended Setup

By continuing the installation process, you agree to the license terms of
Microsoft Exchange Server 2010. If you don't accept these license terms,
please cancel the installation. To review these license terms, please go to


No key presses were detected.  Setup will continue.
Preparing Exchange Setup

    Copying Setup Files              ......................... COMPLETED

The following server roles will be recovered
    Client Access Role
    Management Tools

Performing Microsoft Exchange Server Prerequisite Check

    Client Access Role Checks         ......................... COMPLETED

Configuring Microsoft Exchange Server

    Preparing Setup                  ......................... COMPLETED
    Stopping Services                ......................... COMPLETED
    Copying Exchange Files           ......................... COMPLETED
    Restoring Services               ......................... COMPLETED
    Client Access Server Role         ......................... COMPLETED
    Exchange Management Tools        ......................... COMPLETED
    Finalizing Setup.                ......................... COMPLETED

The Microsoft Exchange Server setup operation completed successfully.
Setup has made changes to operating system settings that require a reboot to tak
e effect. Please reboot this server prior to placing it into production.

After the reboot you can verify that some configurations have been recovered, such as the OWA virtual directory URLs. However any other customized configurations that were stored in the system state or the file system are not recovered by this process. Those settings will need to be reapplied from the minimal backups, or reapplied manually or by using a script.




Planning the Hub Transport Server Backup

When you are planning the Hub Transport server backup strategy there are different approaches you can take depending on your requirements.

Backing up Everything

A full system backup of the server, along with a working Active Directory, encompasses all of the required information for a recovery.  However this backup takes the longest and will consume the most backup storage.

If a server failed and needed to be recovered from a full backup any undelivered messages still in the transport queue would be lost.  But it is impractical to backup the entire server multiple times a day just to protect the transport queue databases from data loss.

Depending on the Exchange environment and the backup infrastructure in place a full server recovery may take longer than simply rebuilding the server from scratch.

Backing up the Minimum

To save on backup storage and minimize the backup time frame the minimum data on the Hub Transport server can be backed up.  For most environments this would mean only backing up the transport queue databases and the log files on the file system.

Because these would be relatively fast to back up this type of backup could be performed multiple times per day to minimize the risk of losing undelivered messages.  This concern would mostly apply to high volume email environments where the transport queues are regularly backlogged.  Of course in those cases some attention should be paid to whatever performance bottleneck is causing the backlog, if it is something within the control of that organization to fix.

Backing up Nothing

A perfectly feasible backup strategy for the Hub Transport server is to back up nothing at all.  This would be practical if:

  • there are multiple, redundant Hub Transport servers deployed
  • the transport queues are not frequently backlogged
  • the organization does not wish to retain any log files from the Hub Transport servers

If all those conditions are true then it may not be necessary to back up the Hub Transport servers at all.

Backing Up and Restoring Hub Transport Servers

For the purposes of this demonstration I’ve configured a Hub Transport server with an additional Receive Connector.


Message tracking logs are also enabled.


Recovering a Hub Transport Server

As mentioned earlier most of the critical Hub Transport server configuration is stored in Active Directory.  When a Hub Transport server has failed you can recover the server using the following process.

  1. Install a new server to host the Hub Transport server role
  2. Configure the server with the same name and IP address as the failed server, and join it to the domain
  3. Install the Exchange Server 2010 pre-requisites
  4. Perform an installation of Exchange Server 2010 using Recovery Mode

To run setup in Recovery Mode use the following command to launch Exchange Server 2010 set from an elevated command prompt.

C:\Admin\Exchange 2010>setup /m:recoverserver

Setup performs a server recovery instead of a normal installation.

Welcome to Microsoft Exchange Server 2010 Unattended Setup

By continuing the installation process, you agree to the license terms of
Microsoft Exchange Server 2010. If you don't accept these license terms,
please cancel the installation. To review these license terms, please go to


No key presses were detected.  Setup will continue.
Preparing Exchange Setup

    Copying Setup Files              ......................... COMPLETED

The following server roles will be recovered
    Hub Transport Role
    Management Tools

Performing Microsoft Exchange Server Prerequisite Check

    Hub Transport Role Checks        ......................... COMPLETED
 This computer requires the 2007 Office System Converter: Microsoft Filter Pack.
 Please install the software from http://go.microsoft.com/fwlink/?LinkId=123380.

Configuring Microsoft Exchange Server

    Preparing Setup                  ......................... COMPLETED
    Stopping Services                ......................... COMPLETED
    Copying Exchange Files           ......................... COMPLETED
    Restoring Services               ......................... COMPLETED
    Hub Transport Server Role        ......................... COMPLETED
    Exchange Management Tools        ......................... COMPLETED
    Finalizing Setup.                ......................... COMPLETED

The Microsoft Exchange Server setup operation completed successfully.
Setup has made changes to operating system settings that require a reboot to tak
e effect. Please reboot this server prior to placing it into production.

Restart the server as prompted.  When the server has finished restarting you can verify that configurations such as the additional Receive Connector and the message tracking log configuration have been recovered with the server.



However the log files themselves are not restored during a Recovery Mode install of Exchange Server 2010.


Neither are additional applications or agents that were previously installed ont he server.  For the Hub Transport server one notable item would the Microsoft Office Filter Pack.

Therefore the server is not fully recovered until all of those items, along with any further customizations to the server, have been manually applied.

Exchange 2010 allows us a new replication topology when it comes to our mailbox databases, DAG (Database availability groups). You may have noted I didn’t use the general term databases. Public folder databases cannot be used in a DAG. Now to avoid corruption passing to Db copies throughout your organization we now have a capability to use a Lagged copy of the database. which still has all of the transaction logs but just have not applied them.

Walter from this week’s 10135 class was looking for some more information on the entire process of activating a lagged copy and more specifically

“what do I do with the transaction logs if I know where the corruption occurred?”

here ya go buddy – taken from this page – Activate a Lagged Mailbox Database Copy

A lagged mailbox database copy is a mailbox database copy configured with a replay lag time value greater than 0. Activating and recovering a lagged mailbox database copy is a simple process if you want the database to replay all log files and make the database copy current. If you want to replay log files up to a specific point in time, it’s a more difficult operation because you have to manually manipulate log files and run Eseutil.


You can’t use the Exchange Management Console (EMC) to activate a lagged mailbox database copy to a specific point in time.

  1. Suspend replication for the lagged copy being activated by using the Suspend-MailboxDatabaseCopy cmdlet, as shown in this example.
  2. Suspend-MailboxDatabaseCopy DB1\EX3 -SuspendComment "Activate lagged copy of DB1 on Server EX3" -Confirm:$false
  3. Optionally (to preserve a lagged copy), take a file system-based (non-Exchange aware) Volume Shadow Copy Service (VSS) snapshot of the volumes containing the database copy and its log files. You can use the vssadmin.exe tool that’s included in Windows to take a VSS snapshot, as shown in this example.
    vssadmin create shadow /For=C:\mountpoints\db01
    vssadmin create shadow /For=C:\mountpoints\db01_logs


    At this point, you have shadow copies outstanding for the database and log volumes. Continuing to perform this procedure on the existing volume would incur a copy on write performance penalty. If this isn’t desirable, you can copy the database and log files to another volume to perform the recovery.

  4. Determine which log files are required to replay into the database to meet your point-in-time requirement for this recovery (based on log file date and time, as shown in Windows Explorer). All logs created after this point should be moved to a different directory, until the recovery process is completed, and the logs are no longer needed.
  5. Delete the checkpoint (.chk) file for the database.
  6. Use Eseutil to perform the recovery operation, as shown in this example.
    Eseutil.exe /r eXX /a


    In the preceding example, eXX is the log generation prefix for the database (for example, E00, E01, E02, and so on).


    This step may take a considerable amount of time, depending on several factors, such as the length of the replay lag time, the number of log files generated during that period, and the speed at which your hardware can replay those logs into the database being recovered.

  7. After log replay is finished, the database is in a clean shutdown state and can be copied and used for recovery purposes.
  8. After the recovery process is complete, resume replication for the database that was used as part of the recovery process, as shown in this example.
    Resume-MailboxDatabaseCopy DB1\EX3

Our friends over at Exchange server pro (http://exchangeserverpro.com/) had an AWESOME write up on using Exchange’s new Database Availibility Groups on top of VMWare virtualization. Worth a read for sure! Heck – just look at this part alond..

Microsoft clearly states that hypervisor HA features should be disabled for DAG members, while VMware considers it to be an effective solution.

Microsoft vs VMware on Exchange Virtualization and HA Best Practices

Also if you’re a twitter head like myself make sure you follow them!


One of my students from this week’s 10135 class asked a great question…

Where can I see which services are used for each of the roles?

Great question! I stumbled upon a technet article that maps out just that!

Overview of Services Installed by Exchange Setup


Now for clarity sake I’ve taken the content from TechNet’s page above and dropped it into an .XLSX file for your convenience here..

Exchange 2010 Service List

“so I have 3,000 mailboxes in a single, multi domain forest. When I go to recipient configuration I only see a subset of them all? What gives Chad?”

Great question!

By design the exchange management console only shows recipients from the currently connected to domain. To change this you need to change the scope of the filter. This allows you to change and see the entire forest contents or just another domain.

Don’t forget though there is a default limit to the number of items displayed for that filter set. Out of the box this is 1,000 objects. This too is customizable but it may affect performance.