Monthly Archives: May 2010

Cross-Forest Migration in Lab

How to do a migration from one organization to another?
In this case it’s about Exchange 2003 organization (legacy) to Exchange 2010

They are totally separated by individual domains, network connection has been established between the domains and two-way trusts have been setup.

Company A à Company B

I’ve created up an account in the target domain called; admt.
The account is added to domain administrator for target.local and the built-in administrators group in the source domain.

To get the passwoed migration to work I needed to:
First on the DC in target domain I installed ADMT ver 3.0 and then run the following command from cmd
“admt key /opt:create /sd:source /kf:c:\key”

In the source domain I needed to create a local group named sourcedomain$$$

A little registry change needs to be done:
“HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Lsa” Create a new DWORD value called TcpipClientSupport and configure it with a value of 1
Install the ADMT password migration DLL on the server from I386\ADMT\Pwdmig folder on the Windows Server 2003 CD-ROM or from C:\Windows\ADMT\PES
Then in the installation point on the pes file created previously on the target/destination DC

Reboot when the settings and installation are done.
When password migration is done, remove the DWORD and reboot the source DC.

On the target side I needed to do some things:
Enable auditing for success and failures for account management in your default domain controllers policy in the target domain

Also verify that the account that’s going to be used in the migration has the appropriate permissions and that the Password Export Server Service is started.

We’re ready to start the user migration from the source domain to the target domain using ADMT.

In my case I had a little problem migrating the accounts because they didn’t have any password so I had to set password for them
Here’s an example I used to set password for all users in a OU

“dsquery user “ou=source,dc=source,dc=local” -limit 0 | dsmod user -pwd P@ssw0rd >password.log”

Now it’s time for the mailbox to move from one organization to another, this could be a little problematic.

I’ve done the following steps to move the mailbox from Exchange 2003 to 2010.
Then move will be an offline move, this means that the client will be disconnected when the move starts.
There are a lot of suffixes for how to move the mailbox if need exists.
These suffixes of commands can be found here:

First step is: Typing in the password for the local forest/domain by starting EMS and typing in
$Local = Get-Credential

Second step is to type in the password for the source forest/domain
$Remote = Get-Credential

It’s time to prepare the move by identifying the user/mailbox
./Prepare-MoveRequest.Ps1 -Identity admin@source.local -RemoteForestDomainController server01.source.local -RemoteForestCredential $Remote -LocalForestDomainController -LocalForestCredential $Local
This is done by using the official prepare-moverequest script, it can be found here:

When the prepare is set, the move request can be set
New-MoveRequest -Identity admin@target.local -RemoteLegacy -TargetDatabase “DB” -RemoteGlobalCatalog server01.source.local -RemoteCredential $Remote -TargetDeliveryDomain “target.local”

The move have started, to check the progress run:
Get-MoveRequestStatistics -id username

When the move is done, the move-request needs to be removed by typing in:
Remove-MoveRequest –id username

The problems I have discovered were that for some reason the attribute “msExchMailboxGuid” didn’t migrate to the new account in the target domain.
This can be solved by either: copy and paste the information manual or by using IIFP.
In my case I did a manual copy and paste because this is a lab environment.

The last problem, I wasn’t able to create the MoveRequest because it couldn’t find the mailbox/user for some reason and this seems to be a bug and can be solved by on the target mailbox server adding the dns suffix of both the target and the source domain.

Hope this helps someone that will make this procedure!
Don’t hesitate to leave comments and feedback


What about Legacy / Coexistence for OWA?



After reading and answering in MS forum I can tell you all that this is a very common question that need to be clarified.

Before Exchange 2010 was released there was a built-in function that handled the co-existence for OWA.
A little background check, Exchange 2003 and 2007 could co-existence by pointing to the Exchange 2007 CAS server(s) and use /exchange.

In Exchange 2010 this function is removed and replaced by “Legacy”.

What to think about when you are planning for a co-existence?

  1. You need to add the name to the certificate that will be used on the CAS server(s).
  2. Change the external URL on Exchange 2007 (OWA) by using EMC or EMS.

    Set-OwaVirtualDirectory -ExternalUrl ‘’ -Identity ‘CASSERVER\owa (Default Web Site)’

    If Exchange 2003 is used with co-existence you have to do this from Exchange 2010 EMC or EMS from Server Configuration -> CAS -> Outlook Web App. Select Exchange 2003 and type in as the external name.
    Or using cmdlet;
    Set-OWAVirtualDirectory -Exchange2003URL ‘’ -Identity ‘CASSERVER\OWA*’

  3. Make sure that Windows Integrated is used on the OWA sites (NTLM) so it will be single sign on.
  4. Add a DNS record for to point to Exchange 2003/2007 server.
  5. Final step will be to change the firewall rules so it instead of pointing to the old server, point it to the Exchange 2010 CAS server(s).


I hope this will help someone!

If using this example in your organization, make sure to test it before using it.
No warranties, use at your own risk.

Also, here’s a helpful link from TechNet:

How to update legacy email address policys


This is an easy step-by-step guide how to upgrade the legacy policies when
transition from Exchange 2000 or 2003 to 2007 or 2010 there’s a need for upgrading the email address policies.

Also remember, this is example without any guarantee!

Don’t forget! Before running these commands make sure that you remove mailbox management policy, or else you will get problems.

Get-EmailAddressPolicy | where { $_.RecipientFilterType -eq “Legacy” } | Set-EmailAddressPolicy –IncludedRecipients AllRecipients
Set-AddressList “All Contacts” -IncludedRecipients MailContacts
Set-AddressList “All Groups” -IncludedRecipients MailGroups
Set-AddressList “All Users” -IncludedRecipients MailboxUsers
Set-AddressList “Public Folders” -RecipientFilter { RecipientType -eq ‘PublicFolder’ }
Set-GlobalAddressList “Default Global Address List” -RecipientFilter {(Alias -ne $null -and (ObjectClass -eq ‘user’ -or ObjectClass -eq ‘contact’ -or ObjectClass -eq ‘msExchSystemMailbox’ -or ObjectClass -eq ‘msExchDynamicDistributionList’ -or ObjectClass -eq ‘group’ -or ObjectClass -eq ‘publicFolder’))}

They work like a charm J

Relay Connector

Many times the question comes up in forums how to create a relay connector that works just like it did in Exchange 2003.
At that time it was like…. If the IP address was in the list, that IP was able to relay no matter what.

In Exchange 2007/2010 it’s not working that way..
Now we need to create a receive connector, give it a proper name (like Relay Connector) and also set an extra security setting on it.

Here are the commands that I usually use to create the relay connector

New-ReceiveConnector -Name ‘Relay Connector’ -Usage ‘Custom’ -Bindings ‘*’ -RemoteIPRanges ‘type in the address that should be able to relay’ -Server ‘*Servername’

Get-ReceiveConnector -Identity ‘Relay Connector’ | Add-ADPermission -User “NT AUTHORITY\ANONYMOUS LOGON” -ExtendedRights “ms-Exch-SMTP-Accept-Any-Recipient”

* – If you’re going to use NLB for this relay connector, type in the NLB (VIP) IP address in here, with it will receive mail on all available ip addresses
* Servername – Type in the Exchange HUB server name in here
With this connector the sender doesn’t need to authenticate so it means that no matter what it is that’s going to send mail with the connector, it will work.
Sometimes a server/device can’t authenticate like a SAN etc, then this will be nice to use.