It’s not a typical task to configure Free / Busy availability between Exchange Organizations located in different Active Directory forests for every organization, but still, we can see this need very often in reality. This is needed between two different companies that are closely interacting with each other, or when one company merges with another one, but decides to keep current Exchange infrastructure in each company.

Free / Busy availability means, that user in one company can create a meeting in Outlook or OWA for user in another company as attendee of the meeting and see available time slots in his calendar to plan their meeting accordingly.

To make Free / Busy information available, you can configure Federation Trust or Availability Service for cross-forest communication. In this post we will discuss the second option, as recently I had a question regarding this one and this topic is not described quite holistically for latest Exchange versions (at least I wasn’t able to find some details I consider important).

Basics of Availability service for cross-forest topologies configuration

So, official article from Microsoft Configure the Availability service for cross-forest topologies in Exchange Server lists available options and pre-requisites.

Information returned by Availability Service depends on if we can configure an Active Directory trust between Organization’s forests. Per article:

• In trusted forests, you can configure the Availability service to retrieve free/busy information on a per-user basis. When the Availability service is configured to retrieve free/busy information on a per-user basis, the service can make cross-forest requests on behalf of a particular user. This allows a user in a remote forest to retrieve detailed free/busy information for someone who is not in the same forest.

• In untrusted forests, you can only configure the Availability service to retrieve free/busy information on an organization-wide basis. When the Availability service makes free/busy cross-forest requests at the organizational level, free/busy information is returned for each user in the organization. In untrusted forests, it isn’t possible to control the level of free/busy information that’s returned on a per-user basis.

In case you don’t want to depend on Cloud services or just don’t have opportunity to provide appropriate network access required for federation trust, than configuration of the Availability service for cross-forest topologies is the option you would probably like to use.

Configuration for trusted and untrusted forest from Exchange Server perspective is similar. But the opportunity to provide per-user free/busy information available in trusted forests have some requirements to global address list synchronization.

Common configuration steps

When the Availability service makes free/busy cross-forest requests at the organizational level or per-user basis, free/busy information is returned for each user in the organization.  Communication happens between Exchange Servers and returns back to the user. This is the official and supported way by Microsoft.

If we’re talking about rich coexistence between 2 companies – Free / Busy availability is commonly one of really important parts of it, but not the only one. There’s a great series of blog articles dedicated to Deep dive into rich coexistence between Exchange Forests, so if you’re interested to read about this in more detail, that’s good to start. 

Let’s assume, that we have 2 Organizations called Contoso and Fabrikam. Common configuration steps to configure cross-forest availability are:

1. Configure appropriate network permissions. You will need to configure required permissions for forest trust between domain controllers (for per user Availability), open https traffic between Exchange Servers and / or Load Balancer, depending on your network configuration, permissions for DNS resolution.
2. To make everything work Contoso and Fabrikam should resolve requited DNS records. So, it’s important to enable DNS name resolution between forests, for example, by configuring conditional forwarding. But it depends on specific topology and requirements.  
3. Configure forest trust  – 2 way as we need free /  busy in both organizations if per user availability is needed.
4. Configure Exchange servers to trust certificates used in another forest. As Exchange servers need to communicate between each other they should trust certificates. If you use third party certificates, there’s almost nothing to do – you just need to verify that those certificates’ revocation lists are available from Exchange and root certificate is trusted. If you use internal certificate authority, you will need to import all root certificated to trusted root authorities store manually or via group policy.
5. Verify that Autodiscover is properly configured. Depending on your configuration you may need to create Autodiscover.contoso.com and Autodiscover.fabrikam.com DNS records. Verify that those names are covered by your Exchange certificates.
6. Configure send and receive connectors in case you expect your users will exchange email and meetings. If you consider your organizations as trusted, I would recommend to create a dedicated receive connectors with  AuthMechanism set to ExternalAuthoritative. This will allow to consider messages sent between 2 Exchange organizations as trusted. Thus, the sender will be resolved in Address Book (GAL). In relation to this blog post, imagine that user from Contoso will create and send a meeting to user in Fabrikam. Recipient in Fabrikam will not be able to resolve Organizer in GAL, thus his availability information will be represented as unavailable to him while opening this meeting. You can also tune other parameters like number of connections, tarpit interval or even configure shadow redundancy in cross-forest coexistence.
7. Configure GAL synchronization or create mail recipients manually (will be discussed later)
8. Configure appropriate namespace and permissions for trusted and untrusted scenario according to official article.

For trusted scenario in contoso organization:

For untrusted scenario in contoso organization:

Create user, for example, FBFabrikamUser in Fabrikam domain.

Configure GAL synchronization or create mail recipients manually.

Gobal address list (GAL) contains mail recipients from a single forest only. That means, in a cross-forest environment we need to create appropriate mail recipients for users in another forest.

Recommended way is to implement Identity Lifecycle Management to ensure that the GAL in any given forest contains mail recipients from other forests. That’s important not to create required contacts ones, but keep them up-to-date. Users can leave the company, change their Family name, addresses and so on. These changes should be reflected in another forest.

Historically, many customers used Microsoft Identity Manager for GAL sync. MIM creates contacts that represent recipients from other forests, thereby allowing users to view them in the GAL and send email. For example, users in Forest A appear as a contacts in Forest B and vice versa. Users in the target forest can then select the contact object that represents a recipient in another forest to send mail.

Also, there are third party management agents that import mail-enabled users, contacts, and groups from designated Active Directory services into a centralized metadirectory.

Delegation and per-user Availability

After you’ve configured all required steps, user from one organization should see availability of user from other organization. Below you can see, that only information about the fact of availability can be seen, no information about subject, organizer and etc.

This is because we’re fallen under default permission level:

Of course, this level can be changed, but it will affect availability for all users. For per-user in trusted forests configuration we can delegate permissions per-user level and provide more visibility. In this scenario, maximum level of visibility are Free/Busy time, subject and location, even if more extended permissions are set:

You can also open other’s user calendar, but you won’t be able to get information about attendees, open meeting, update, delete, or create a new one. Even if corresponding permissions are granted.

Difference between regular contacts and contacts created by MIM

You can notice that you cannot grant permissions to any contact. In this example you can see a contact created by MIM and contact created manually in standard way:

So what’s the difference between them? If you try to look MIM’ contact properties via powershell  there will be already one hint.

If we compare their properties, we can see some significant differences (compare objects returned by Get-ADObject -Properties *):

Reference for Exchange types attributes values can be found in this blog: Reference to msExchRecipientDisplayType, msExchRecipientTypeDetails and msExchRemoteRecipientType values

Knowing this, you can easily create corresponding contact manually for test purposes or if you don’t have GAL sync solution. You can create a contact using Exchange powershell and correct corresponding properties as needed.

In test environment I used New-ADObject, however, be careful with that in production environment as it’s easy to miss required attributes:

What about calendar delegation?

So, what if you want to get information about attendees, open meeting, update, delete, or create a new one with corresponding permissions? You can notice, that although you can add such a contact as delegate in Outlook:

If you open Calendar from another forest and try to open a meeting, most commonly Outlook will be unresponsive or provide a warning, that corresponding permissions are not set (depends on Outlook version and updates).

If you’ look at Fiddler trace, you can see that Outlook actually is trying access to mailbox in another forest directly. First, trying to get connectivity settings via Autodiscover, that doesn’t work with Internal Server error:

If we’ll look at Autodiscover http proxy logs we will see something like this:

You can reproduce this behavior if you try to open Autodiscover url for cross-forest organization and provide credentials of user’s who’s trying to access calendar:

So, let’s try to create a mail user, not a contact for another user, cont2, with the same required changes that we discussed before. Simple example:

msExchRecipientTypeDetails=”128″ corresponding to MailUser. This is the main change regarding Exchange related attributes.

Now we can see, that we have mail contact for cont1 and mail user for cont2.

Try to open Autodiscover url again for cross-forest organization and provide credentials of user’s for whom we created mail user (cont2). Result as expected.

Don’t forget to update the corresponding address lists and offline address books before test something in Outlook.

Now you can see additional information in pop-up information message:

Options to manage calendar are available:

You can open meeting and update it:

Meeting update will be sent on behalf of user cont2:

What else about calendar delegation and management in cross-forest?

With mail user object Outlook doesn’t use availability service to manage and view calendar with extended permissions but connects directly to Exchange in other forest. First, for Autodiscover, second, to connect mailbox directly.

That means, Outlook client should have network access to Exchange in another forest and also trust certificates used by servers. Another thing could be Kerberos authentication.

Kerberos authentication should be configured manually in load-balanced environments. But if it’s configured and used in this example, Outlook client should also have network access to domain controllers in SOLS organization.

Calendar delegation described above works for Outlook only.

Summary

As this was a long discussion, let’s summarize the conclusions we should get in the end.

1. You can configure availability service for cross-forest environment to exchange Free / Busy availability information between Exchange Organizations (works for Outlook and OWA clients)
2. This a good option for organizations who don’t want to depend on Cloud services or just don’t have opportunity to provide appropriate network access required for federation trust
3. This can be done for trusted and un-trusted forests. The first option provides opportunity to delegate permissions per-user, second option provides general availability.
4. There are some requirements for mail-enabled objects created by GAL sync or manually in another organization to provide permissions on MAPI level. There’s no official guidance from Microsoft, about according to how this is configured in MIM  – it creates cross-forest contacts with specific properties values
5. Calendar delegation (opportunity to get extended information about attendees, open meetings, update, delete, or create a new one with corresponding permissions) is not described anywhere officially, thus, most likely is not supported by vendor.
6. We already mentioned some concerns related to calendar delegation and this cannot be not a full list, as I never saw this in production environment and it’s not described by Microsoft as available opportunity.
7. Apart from a lot of concerns regarding supportability making modifications to attributes related to account type outside of Exchange powershell or EAC usually are not supported.

For more information on federated sharing:

Cross Forest Free / Busy in Exchange Server Environment via Federation Trust

End.