This is notes from a recent troubleshooting case. The client received the error: 420 4.2.0 RESOLVER.ADR.Ambiguous; ambiguous address and a lot of messages ended up in the Submission queue with this error.
The error came after running GALsync. We have two Exchange 2010 forests and was running GALsync between the two. Forest A (contoso) was using one address space (contoso.dk) and Forest B (nwtraders) was using several address spaces (nwtraders.dk, litware.dk etc).
Everything working fine between contoso.dk and nwtraders.dk, the two main address spaces, but the problem with 420 4.2.0 RESOLVER.ADR.Ambiguous; ambiguous address, came when trying to send to address space litware.dk from Forest A.
The error was caused by duplicate SMTP proxy addresses.
I have seen it before where GALsync created a contact during a sync to the target forest even though the user was already migrated to the target forest. Then we have the both a mail contact and mail user had the same SMTP address and messages to this user will be queued.
In this case the issue was quite similar, although the client had created the extra mail user themselves and when GALSync created the mail contact, the problem came.
The solution was to clean up in the proxy addresses of the two objects (mail user and mail contact) and good way of checking this is using ADSI Edit to see and confirm the proxy addresses of the objects.
Last week I had the honor of presenting at Microsoft Campus Days 2011 in Copenhagen.
The session topic was about Exchange 2010 and integration with Forefront Online Protection for Exchange (FOPE) and Forefront Protection for Exchange (FPE).
The session was recorded (In Danish) and will be available from Microsoft soon. I will post a link to the recording when it is available.
For now I have made the slides (PowerPoint) for you…
Session P14: Exchange 2010 and Forefront Online
Download slides here from my Skydrive.
Here are some field notes from a Lync 2010 environment using the telephony and integration to Exchange Unified Messaging for the Voice mail feature.
There was a problem changing the UM Dial Plan settings from Unsecured to SIP secured or Secured.
The following error may appear on the completion page of the wizard, when you change from unsecured to secured or SIP secured from within your Dial Plan is:
The following warning(s) occurred while saving changes:
Set-UMDialPlan
Completed
Warning:
The VoIPSecurity type of dial plan ‘UMDialPlan1′ doesn’t match the UMStartupMode of the following Unified Messaging servers: ‘EXCH-UM’. Make sure that if the UMStartupMode of the Unified Messaging server is set to TCP, the VoIPSecurity type for the dial plan is set to Unsecured. If the UMStartupMode of the Unified Messaging server is TLS, the VoIPSecurity type for the dial plan should be set to either SIPSecured or Secured.
You will have to make sure that the UM Settings has the Startup mode set to TLS or Dual.
To resolve this issue, open the Exchange Management Console – go to Unified Messaging under the Server Configuration. Right-click the unified messaging server you are using with your Dial plan and select Properties. In the UM Settings tab change Startup mode to either TLS or Dual.
After changing the setting, restart the Microsoft Exchange Unified Messaging service.
You can now change the VOPIP Security settings of your Dial Plan.
In Exchange Management Console navigate back to the UM Dial Plans tab under Organization Configuration > Unified Messaging. Open your Dial Plan and you can now change the VOPIP Security setting from unsecured to Secured.
Here is some notes from a recent issue error that I encountered at a client with SSL certificates for an Exchange 2010 server.
This error may be seen on Exchange Server 2010. It may occur even though the certificate is a public certificate, from a trusted provider e.g. GlobalSign, Verisign or anyone else. Although it is most often seen when using certificates from a private PKI infrastructure. This blog post will focus on the usage of a public certificate, in this case from GlobalSign.
The error: The certificate is invalid for exchange server usage
It is shown in the Exchange Management Console (EMC) as:
The reason for the error is because the certificate cannot be verified to a trusted Certificate Authority.
The certificate chain is broken, because of a missing or wrong Intermediate or Root CA in the Certificate store of the Exchange 2010 server.
Make sure you have the correct Intermediate and Root CA from the provider (validate with your provider, that you have the correct ones) and make sure they are imported into the Certificate store. They should be imported into the correct destination of the Certificate Store of the Computer (Exchange Server), such as Trusted Root Certification Authorities (holds the Root CA) and Intermediate Certification Authorities (holds the Intermediate CA), as shown below:
When you have imported or validated the correct versions, the next time you start the Exchange Management Console, the certificate will now be listed as valid, as shown below:
The Exchange Team has announced SP2 for Exchange 2010, it is scheduled for release in the second half of 2011.
The SP2 includes the following major new features:
- Outlook Web App (OWA) Mini: A browse-only version of OWA designed for low bandwidth and resolution devices. Based on the existing Exchange 2010 SP1 OWA infrastructure, this feature provides a simple text based interface to navigate the user’s mailbox and access to the global address list from a plurality of mobile devices.
- Cross-Site Silent Redirection for Outlook Web App: With Service Pack 2, you will have the ability to enable silent redirection when CAS must redirect an OWA request to CAS infrastructure located in another Active Directory site.
- Hybrid Configuration Wizard: Organizations can choose to deploy a hybrid scenario where some mailboxes are on-premises and some are in Exchange Online with Microsoft Office 365.
- Address Book Policies: Allows organizations to segment their address books into smaller scoped subsets of users providing a more refined user experience than the previous manual configuration approach. They blogged about this feature earlier: GAL Segmentation, Exchange Server 2010 and Address Book Policies.
- Customer Requested Fixes: All fixes contained within update rollups released prior to Service Pack 2 will also be contained within SP2.
Read more at the Exchange Team blog.
Great news from the Exchange team today. They have announced enhancements to the virtualization support of Microsoft Exchange Server 2010 running with SP1.
With Exchange SP1 the following scenarios are now supported running under hardware virtualization:
The Unified Messaging server role is supported in a virtualized environment.
Combining Exchange 2010 high availability solutions (database availability groups (DAGs)) with hypervisor-based clustering, high availability, or migration solutions that will move or automatically failover mailbox servers that are members of a DAG between clustered root servers, is now supported.
A new Best Practices for Virtualizing Exchange Server 2010 with Windows Server 2008 R2 Hyper-V whitepaper has also been released.
Read more about these enhancements on the Exchange Team blog.
The Office team has posted a nice overview of the needed licenses for using Exchange 2010 Personal Archive and Retention Policies.
To use Personal Archive or retention policies requires a Microsoft Exchange Server 2010 account with Microsoft Exchange Server Enterprise Client Access License (CAL) and one of the following Microsoft Outlook licenses.
Read their post here.
I recently installed the Exchange 2010 SP1 Unified Messaging (UM) role at a client and in that process I was installing the pre-requirements:
- Unified Communications Managed API 2.0, Core Runtime
- Microsoft Speech Platform – Server Runtime
I found that there are multiple versions of the Speech Platform Runtime, available as download:
Since this was a new installation, I was about to download and install version 10.2. Be aware that this version is not supported with Exchange 2010 SP1 and you might experience that the Exchange 2010 SP1 Readiness Check will not recognize the Speech Platform Runtime installed as a pre-requirement.
The solution is to install version 10.1 of the Speech Platform Runtime.
Why it does not recognize the version 10.2 I do not know, maybe it is a version mismatch in Exchange 2010 SP1.
Follow Me