In a previous article I described how to share free/busy information in an untrusted cross-forest environment. The procedures are published not very often and you sometimes get some "nice errors". I use the follwoing steps to troubleshoot these issues.
1. Basic Tests
- Does dcdiag on your DCs or does exbpa on your Exchange server indicate any errors, which could be related to your issue?
- Are the clients in both forests able to get free/busy information of other clients in the same domain?
- Are clients able to send/receive mails (between the 2 forests) by sending mail using the SMTP address of the recipient
- Are clients able to send/receive/accept/decline meeting invitations (between the 2 forests) by sending mail using the SMTP address of the recipient
- Are the mailboxes from source created as contacts in the target by using GALsync?
- Are clients able to send/receive mails (between the 2 forests) by sending mail using the GAL to address the recipient
- Are clients able to send/receive/accept/decline meeting invitations (between the 2 forests) by sending mail using the GAL to address the recipient
4. Proxy Account
- Are the proxy accounts on both sides present? (if you want only a uni-directional f/b query the proxy account must be present in the target domain which will be queried).
- Is the certificate of the source domains CAS servers present in the target domains CAS servers certificate store?
- Is the certificate of the target domains CAS servers present in the source domains CAS servers certificate store?
- Is the certificate of the CAS server assigned to IIS?
- Are the correct alternate names configured in the certificates?
6. Virtual Directories
- Are you able to connect to the target mailbox by using OWA Client (i.e. without getting certificate errors)?
Are the internal and external URLs for autodiscover configured?
Get-autodiscoverVirtualDirectory| fl name,server,InternalURL,ExternalURL
Get-AutodiscoverVirtualDirectory | Set-AutodiscoverVirtualDirectory –InternalURL https://adc.foresta.com/autodiscover/autodiscover.xml –ExternalURL https://adc.foresta.com/autodiscover/autodiscover.xml
Please wait 15 MS-Minutes after configuring the value
- connection test
- Exchange 2010: test-outlookwebservice -targetaddress user@forestB.com | fl
Exchange 2013: $cred=get-credentials
test-outlookwebservice -id:juser@forestC.com -mailboxcredential $cred| fl
- Get-WebServicesVirtualDirectory | fl name,server,InternalURL,ExternalURL
- Get-WebServicesVirtualDirectory | Set-WebServicesVirtualDirectory –ExternalURL https://mobile.forestC.com/EWS/Exchange.asmx
- Are the CAS Servers ot the source able to perform nslookup/ping to autodiscover.targetdomain.xx?
Can you query the autodiscover URL with Internet Explorer and check if you get an certificate issue?
If you get an authentication request then insert a valid user name and password. Getting error 600 then this is the expected result and means: everything ok.
7. Availability Address Space
Did you configure the AddressSpace in the source domain correctly?
Add-AvailabilityAddressSpace –Forestname "ForestB.com" -AccessMethod OrgWideFB –Credential (get-Credential)
please use the credentiasl of the proxyaccount, which was configured in the target forest
Did you configure –OrgWideAccount <proxyaccount> in the target forest?
Set-AvailabilityConfig –OrgWideAccount freebusy
Increase the eventlog level:
Get-EventLogLevel | Set-EventLogLevel -Level expert
If you do not want to get a lot of results you should reduce the services to the following:
Set-EventLogLevel "MSExchange Autodiscover\Core" -Level expert
Set-EventLogLevel "MSExchange Autodiscover\Web" -Level expert
Set-EventLogLevel "MSExchange Autodiscover\Provider" -Level expert
Set-EventLogLevel "MSExchange Availability\Availability Service" -Level expert
Set-EventLogLevel "MSExchange Availability\Availability Service General" -Level expert
Set-EventLogLevel "MSExchange Availability\Availability Service Authentication" -Level expert
Set-EventLogLevel "MSExchange Availability\Availability Service Authorization" -Level expert
Open Outlook in protocol mode
- Note: Outlook 2013 seems not to use the fblog*.log as in earlier versions like in Outlook 2010, so troubleshooting with OLK13 is much more difficult. Use 2010!
- Run your Outlook clients in online mode, not in cached mode to keep your testing results "clean".
- Re-assign the password of the proxy account.
- Run Get-AvailabilityAddressSpace | remove-AvailabilityAddressSpace in the source forest and re-create the addresspace. Please keep an eye on the correct password.
- Re-create the virtual services for EWS and autodiscover. You can perform this in the EMC (Exchange 2007/2010) – please wait 15 minutes after that.
If you want to set internalurl or externalurl parameters inside Set-AutodiscoverVirtualDirectory, this will not work. Even if TECHNET says that it would work. i.e. Set-AutodiscoverVirtualDirectory -identity "CASserver\Autodiscover (Default Web Site)" –InternalUrl will produce an error saying that the arguments do not exist.
Solution: Use adsiedit in configuration partition. Look for msExchInternalHostName and msExchExternalHostName in:
CN=Autodiscover (Default Web Site),CN=HTTP,CN=Protocols,CN=B,CN=Servers,CN=Exchange Administrative Group (FYDIBOHF23SPDLT),CN=Administrative Groups,CN=First Organization,CN=Microsoft Exchange,CN=Services,CN=Configuration,DC=<domain>,DC=com