Cross-forest Mailbox Moves using the Exchange Management Console

Another great feature in the Exchange 2010 Management Console is that you now can do cross-forest mailbox moves using the new “New Move Request” wizard. To launch this wizard right-click a User Mailbox in the EMC, then select New Move Request in the context menu as shown in the figure below.



This brings up the wizard shown next. Here you can specify to which Exchange organization you want to move a mailbox.



Note
Before you can perform a cross-forest move, you must add the Exchange org in the target forest to the EMC. In addition, you must have the AD account of the source user mailbox migrated/replicated to the target forest using ILM or a similar tool. Yes doesn’t work like the Move-Mailbox cmdlet did in Exchange 2007, where the AD object would be created if it didn’t already exist.

Online Mailbox Moves with the Exchange Management Shell

A cool improvement revolving around mailbox moves in Exchange 2010 is that they by default are done in so called online mode. That is the Outlook client won’t be disconnected while a user’s mailbox is being moved. Only end-user impact is that with Outlook 2003/2007, the user is asked to restart Outlook after the mailbox moved has been completed.

There’s still support for the Move-Mailbox cmdlet, but in Exchange 2010 you’re supposed to use the New-MoveRequest and Complete-MoveRequest cmdlets when performing mailbox moves.

To move one mailbox enter: New-MoveRequest –Local –TargetDatabase

Note
It’s not required to specify a target database, if you don’t one will be picked randomly.



While mailboxes are moved, you can type Get-MoveRequest | fl to see the status for the mailbox move.



When the mailbox data has been moved to another mailbox database, you can finish the move using Complete-MoveRequest . Note this is the command that will trigger the warning in the end-user’s Outlook client in regards to the requested restart.

Exchange 2010 Database Availability Groups

Because I deal a lot with HA/site resilience in my job as a Technology Architect, one of my favorite features in Exchange 2010 is naturally the new Database Availability Group (DAG) HA/site resilience feature, which replaces CCR/SCR/LCR. Also note that SCC has been deprecated/cut with Exchange 2010.

DAG built on the functionality we know from CCR and SCR, that is it still uses asynchronous log shipping and replay etc.

An interesting thing about DAGs is that you’re no longer required to form a cluster before you install the MBX server role. The limited cluster features that are used by DAGs (primarily cluster heartbeat and quorum) are configured automatically when adding the first MBX server to the DAG and thereby more or less invisible to the administrator.

With DAG you can have up to 16 copies of a Mailbox database. In addition, you can also have other Exchange 2010 server roles such as HT and CAS installed on the MBX server which is member of a DAG. Also, you can have DAG members located on different subnets and in separate AD sites.







There’s a lot to say about DAG, but I’ll stop here and instead let you know I currently am writing a multi-part articles series on this very subject. Look forward to seeing it published here on MSExchange.org in a near future.

Connecting to a remote Exchange 2010 Organization using Remote PowerShell

In this blog post I wanted to show you how you can connect to an Exchange 2010 server in a remote organization using Remote PowerShell (Windows PowerShell 2.0) running on a Windows client/server. In this specific example, I’ve installed Windows PowerShell V2 CTP3 and WSMan on a Windows 2008 server).

First step is to launch Windows PowerShell. Then we will create a variable storing the credentials for the administrator in the remote Exchange 2010 organization. We do so using the below command:

$UserCredential = Get-Credential



Now enter the credentials of the administrator account from the remote Exchange 2010 organization.



We will now connect to the remote Exchange 2010 organization by specifying the name of an Exchange 2010 server in that specific organization. In this particular example we use the following command:

$Session = New-PSSession –ConfigurationName Microsoft.Exchange –ConnectionUri https://E2K10EX01/PowerShell/ –Credential $UserCredential



Note
In order to connect to the remote Exchange 2010 organization, your local machine must either trust the certificate on the specific Exchange 2010 server you connect to or you must use the -SessionOption $SkipCertificate parameter in the above command.

We now need to import the server-side PowerShell session which is done with the following command:

Import-PSSession $Session



The cmdlets etc. will now be imported to the client-side session. You will probably get a few warning because some of the cmdlet’s already are available in the client-side session. as can be seen below.



Now let’s try to issue a command against the remote Exchange organization. In the below figure, I retrieve details for an Exchange 2010 server in the remote Exchange organization.



Let’s try to create an Exchange object and then manipulate it afterwards. Below I create a new distribution group and then add a user mailbox to it.



We’ll now switch to an Exchange 2010 Management Console in the remote org and verify the distribution group were created properly and that the user mailbox were added to it.



When finished administering the remote Exchange 2010 organization, you can disconnect the the client-side session using:

Remove-PSSession $Session

Yes Windows PowerShell in Exchange 2007 was pretty cool, but it simply rocks in Exchange 2010

Installing E2K7 and E2K10 Management tools on the same machine

When the time comes where you need to transition from Exchange 2007 to Exchange 2010, depending on the size of your organization, it can take weeks, months or in some cases even years to complete the transition. During the co-existence period, you would need to manage both Exchange 2007 and Exchange 2010 users, groups, servers and so on. Since some Exchange 2007 objects must be managed using the Exchange 2007 Management Console or Shell and most Exchange 2010 objects must be managed using the Exchange 2010 Management console or Shell, it would be nice if you could just install both management tool version on the same machine right? Guess what? Yes this is in fact possible.

Just install the prerequisites for the Exchange 2010 Management tools. Then install the Exchange 2010 Management tools followed by the Exchange 2007 Management tools.

You can now open the management tools for both versions from the start menu as shown below.



You can even have the management tools for each version run side by side.



And since both Exchange 2007 and 2010 management tools are based on MMC 3.0, you could as well add the respective snap-in for each version to the same MMC console.



You can of course also run each version of the Exchange Management Shell by side.



Pretty cool huh?