When working in an Exchange Server environment, there are some key features that tend to come in handy quite often. One of these features is the ability to see the free/busy information for particular users. This information comes in handy for a multitude of reasons but when this information isn’t available, you get to see just how important it really is. Every business should always have this information available, as it is a key element to daily planning.
For this example we’re going to be working in a hybrid environment with our Exchange Server running the 2010 version with service pack 2 installed, as well as running Office 365. While running this setup we can view the free/busy information per user. In some cases when we attempt to view this information we are returned some unusual characters which are not correct. For example, the free/busy information may return with a “#” character or it may return “error 5037”. You may also be able to spot an error when viewing the Outlook error log which would return something like this:
- The caller does not have access to free/busy.
To put this in perspective some “on premise” users can’t view the free/busy information, but some are able to view the free/busy information for that particular “on premise” user.
The main reason for this information not working correctly is because the Simple Mail Transport Protocol (SMTP) address of the user who can’t view the free/busy information is not added to the domain names in the organization relationship. To test this functionality you can type the following in the cmdlet:
If you receive a warning then this would be because the SMTP domain wasn’t added to the system manually. But this result can also occur if you have created the Office 365 account before you upgraded the Exchange Server 2010 SP2. You may also experience the same result if you used the hybrid configuration wizard to set up the account in Exchange Server 2010.
For some perspective on this issue, let’s say the user’s domain name is example.com. When the request is sent out for information on the user it will call example.com instead of example.mail.onmicrosoft.com which is the one proxy account used to grab information. This request would ultimately be rejected because the organization relationship does not have example.com added to the environment.
In order to solve this problem we can take two different approaches that will both result in a fix for the error. The first approach uses the Exchange Management Console. Use the following steps to make this correction.
- Navigate to Organization Configuration.
- Open the properties for the organization relationships tab.
- Navigate to External Organization and add in the domains you want to be accepted by the system.
- When finished click OK.
This should add the particular domain you want to use to the system, thus rendering our problem fixed. If you want to use the Management Shell to do this, simply follow these steps:
- Run $OrgRel = Get-OrganizationRelationship example
This will set up the relationship for the domain.
- To add a domain to the list run $OrgRel.DomainNames += “example.com”
Your problems should now no longer exist, as you’ve added the domain you’re using for your SMTP address. Run the test command again to see if your results vary. If they don’t, then ensure that there is no context errors in your commands. Also check to see that your domain used is in fact the correct one. If all else fails contact Microsoft support for a solution.
If you can’t access your Exchange Server to perform some of these commands you can also try to connect to Office 365 by connecting to Exchange online using the PowerShell. To do so follow the steps below:
- Type in the following in your PowerShell window: $UserCredential = Get-Credential
- Input the information it asks for (username/password).
- Type the following: $Session = New-PSSession -ConfigurationName Microsoft.Exchange -ConnectionUri https://ps.outlook.com/powershell/ -Credential $UserCredential -Authentication Basic –AllowRedirection
- And finally run this last command: Import-PSSession $Session
Now you should be connected to your Exchange online system where you can perform additional troubleshooting. This is ultimately an alternative for gaining access to your system. Once you have access you can simply start the steps in this article to diagnose your issues.