Search WWW Search

Thursday, December 23, 2010

420 4.2.0 RESOLVER.ADR.Ambiguous; ambiguous address

Error is caused by duplicate SMTP proxy addresses. In this instance Galsync created a contact during a sync to the target forest even though the user was already migrated to the target forest. Since the contact and user had the same SMTP address, messages to this user was queued.

James Chong (MVP)
Security+, Project+, ITIL

Wednesday, December 22, 2010

Preserve Cross Forest Free Busy When Migrating to New Forest Feasible?

FreeBusy requires that both old and new Forest needs two unique SMTP domains and The issue is that since both orgs are also sharing with being the primary SMTP domain for both orgs we run into problems with Galsync.

Scenario: For newdomain.dom users to see user’s FreeBusy

1. Add as another SMTP email address to userA in ipcfcdom forest
2. Galsync will create a contact in corp.dom for userA with being the primary email and being secondary
3. User in tries to look up FreeBusy for userA and fails. Although is in userA’s contact, userA’s primary email is still
4. To resolve; Galsync must change what’s known as the targetaddress (foreign email address) to on the contact. By default Galsync makes the targetaddress the same as the primary email address This is the problem. According to MS you will need to do custom coding on the source code for the GALsync to change this default behavior.

What I implemented:

ForestA has as authoratative accepted domain and Email address policy.
ForestB has @ADdomainB.dom as authoratative accepted domain and Email address policy.

Create respective SMTP send connectors to forward these SMTP domains to each respective HT servers shared SMTP mail flow.

Now internal mail flow between both forests will be based on these internal SMTP domains. FreeBusy will also be based on these internal domains.

Then follow doc
How to Configure the Availability Service for Cross-Forest Topologies

You will need to export the SCP of each respective domain and configure the availability address space.

If you do still are not able to see the FreeBusy after you have configured everything, make sure that the Firewall is not blocking HTTPS between the CAS server in 2007 and CAS servers in 2010. HTTPS needs to be open for the respective CAS servers to query each others serviceBindingInformation.

Then my GALsync contacts in ForestB (new forest) I will need to change the targetaddress to GALsync created contacts for MB users from FroestA to ForestB but sets the targetaddress on the contacts as the shared primary SMTP of

What I did was use good old Admodify, and limit the scope to the OU where the GALsync contacts got created and do a cusom LDAP query for (targetaddress=* The reason is I don't want to inadvertently modify the targetaddress for external contacts that may have actual external addresses say This query will search for all contacts that have the targetaddress of Then I go into the custom tab and set the targetaddress to %'mailNickName'

Now when you migrate a user's mailbox from ForestA to ForestB, the MB user gets converted to a mail enabled user. You need to ensure that the targetaddress is set to You can append this in the new-moverequest parameter.

New-MoveRequest -Identity "Distinguished name of User in Target Forest" -RemoteLegacy -TargetDatabase "E2K10 Mailbox Database Name" -RemoteGlobalCatalog "FQDN of Source DC" -RemoteCredential $Remote -TargetDeliveryDomain ""

Note when you run GALsync again, it will overwrite the targetaddress of the contacts back to the shared SMTP namespace This will break FreeBusy again. So your options are, don't run Galsync again or you will need to fix again using Admodify to update the targetaddress again.

Also GALsync will create a mail contact even if a matching mailbox enabled user exists on the target forest. Therefore after you migrate a mailbox user, you need to have GALsync exlude those accounts from being synced up. Two methods move the migrated users to a separate OU in the source domain and have Galsync ignore those OUs when it syncs. Or what I did was set up GALsync to ignore all accounts that have attributeextension15 with the work "migrated". You would set this on the attribute flow rule.

As far as autodiscover for externally connected, non domain joined clients for users who get migrated, you have no option. FreeBusy, OOF will not work. You will need to tell your migrated users to use OWA in during the coexistence. This is because externally connected clients will have to use DNS to find the autodiscover. Unless you are willing to publish and use two unique public SMTP namespace you have no other option.

James Chong
Security+, Project+, ITIL

Monday, December 06, 2010

Exchange 2010 moving mailboxes back to source forest

The following examples show moving a mailbox from a 2007 Exchange Forest to a new 2010 Exchange Forest then moving back to the 2007 Exchange Forest. When moving mailboxes cross forest, the source mailbox is deleted. For contingency planning you can export the mailboxes to a pst prior to moving or move the mailboxes back to the source Forest.

Moving the mailbox from the Exchange 2007 Forest to new Exchange 2010 Forest.

1. .\Prepare-MoveRequest.Ps1 -Identity "CN=migusr5,OU=Office,DC=ipcfcdom,DC=inphonic,DC=com" -RemoteForestDomainController "" -RemoteForestCredential $Remote -LocalForestDomainController "eqdcp01.corp.dom" -LocalForestCredential $Local -TargetMailUserOU "OU=FromILM,OU=GALSync,DC=corp,DC=dom" -UseLocalObject

2. New-MoveRequest -Identity "CN=migusr5,OU=FromILM,OU=GALSync,DC=corp,DC=dom" -RemoteLegacy -TargetDatabase "mdb01 tier1" -RemoteGlobalCatalog "" -RemoteCredential $Remote -TargetDeliveryDomain ""

Moving the mailbox back from Exchange 2010 Forest to Exchange 2007 Forest.

1. New-MoveRequest -Identity "" -remotelegacy -RemoteTargetDatabase "DCEX01\Third Storage Group\Third Storage Group Mailbox Database 250MB Limit" -Remoteglobalcatalog "" -RemoteCredential $Remote -TargetDeliveryDomain ""

Make sure to clear the move request log in EMC prior to moving the mailbox back.

Known issues:
It may take 2 hours for the mail to start working in the source domain. This is because the source Exchange server's information store caches the homemdb value. You either have to restart the IS service or wait. During this time the recipient will not receive any emails and will bounce back to the sender. As a temporary workaround, you can create a transport rule to redirect all emails sent to this moved user to another mailbox to save all emails and prevent bounces.

James Chong (MVP)
Security+, Project+, ITIL

ILM 2007: Microsoft Identity Server has detected a Microsoft Exchange Version different from the one you have selected.

When creating the GALsync MAs you receive the error:

Microsoft Identity Server has detected a Microsoft Exchange Version different from the one you have selected. Do you want to continue? If you believe this is an error, please re-enter forest credentials to run detection again.

This is an innocuous error and can be ignored according to MS tech. I have not seen any issues with functionality.

James Chong (MVP)
Security+, Project+, ITIL

ILM 2007: It appears this forest is not exchange enabled

When configuring ILM 2007 for GALsync you receive the following errors when configuring the Galsyn MA for the target forest.

"It appears this forest is not exchange enabled"

To resolve enter the credentials for the target MA in upn format.

pass: password

If you delete the MA and recreate you do not have to use the UPN. Appears to be a bug.

James Chong (MVP)
Security+, Project+, ITIL
xml:lang="en" lang="en"> MS Exchange Tips: December 2010