In part #1, I spent a fair bit of time explaining how HMC was introduced into Exchange as part of the multi-tenant enablement process for service provider. I also spent some time discussing about how the Active Directory was partitioned and what the primary attributes that are essential to the Exchange 2007 SP1 multi-tenant enablement.
So far, there wasn't anything complicated about it. Now, I am going to move on to the 2nd part of the customizations, which is probably one of the more important ones, that is the Address List Segregation.
Let's look at what address lists we need to segregate and why. Address list is about contact information which is very important because it makes managing and finding your contacts (internal as well as external) easier and hence makes communication easier. There are a few places where you will use Outlook to locate the contact information,
From the above, I think it is pretty obvious that Contacts folder is a private folder, like the Inbox folder in a mailbox, is only accessible to the mailbox owner. PAB is really an offline file that store contact information. There is really nothing required to be done on these contact stores for a multi-tenant environment because those are 'not shared' and are private by default.
Server-side address lists however are slightly different. The address lists are shared and because of how we designed Exchange and Outlook, the address lists in Exchange, out of the box is accessible by everyone in the environment. That obviously is a problem for multi-tenancy because it means users in company A will be able to see the users in company B. So, let's take a closer look at what HMC will change in order to segregate the address lists so that every company will only see what they are supposed to see.
Before that, I think it is important to highlight that address list in Exchange is really nothing more than an Active Directory object containing query logic or filter that specify what mail enabled objects in Active Directory should be included in that list. It is not an actual list or a table or store that consists of all the contact information. It is a filter or I like to call it query logic. That's not all, what is more important to understand is that this query logic is only essential when creating the mailbox, but not so much for the actual Outlook query. As we walk through the blog, the statement above will become clearer to you and you will why HMC does what it does.
What is HMC trying to do?
So, let's look at what HMC intends to achieve here,
So, with the above objectives in mind, let's take a closer look.
Global Address List Segregation
Outlook needs GAL to work and as we know, Outlook can only see one GAL at a time. In order to provide each company their own Global Address List, we need to create different GAL objects for different companies, having specific query logic that scope to just users, distribution groups and resources in the company.
Once we have different GALs for different companies, we need to address the following,
(1) What's the limitation of Global Address List?
The default configuration of the global address list (GAL) class object allows only 1000 address lists. This presents a clear problem because we do expect most hosters to have at least more than that. To make sure that the environment can support more than 1000, you need to use the MakeGalLinked tool to extend this limit.
This is documented in the deployment walkthrough. I am not going to spend time to cover that as I am quite sure you can find other blogs cover this better.
(2) How to make sure that Outlook clients access the correct global address list if there is more than one global address list?
If you refer to the following article, http://support.microsoft.com/kb/312287, you will realize that Outlook displays the global address list that meets the following criteria:
The above Outlook logic means that the Default Global Address List will always be used because all the users created will always be a member of this GAL and it is obviously the largest GAL of all because it consists of everyone in the environment.
Because of the above Outlook logic, we need to either make sure the user is not a member of the Default GAL or we make sure that the user has no permission to it. HMC has selected the latter. We deny almost everyone except Exchange Servers and Domain Admins permission to Open Address List for Default GAL. You may notice that this isn't very different as compared to the steps documented in White Paper: Configuring Virtual Organizations and Address List Segregation in Exchange 2007.
With the default GAL not accessible to all the users, we need to now create different GAL for different companies so that Outlook will actually work.
What HMC did is this, when you create a company and the user with Outlook plan, it will automatically create a company GAL. HMC also ensures that only users (AllUsers@<company>) in that company/tenant will have the Open Address Lists permission their GAL. I am not going to list down all the permissions that we set in there but it shouldn't stop you from finding out yourself, right? If you want to know the exact permissions being granted, just run Get-ADPermission cmdlet, for example,
Get-ADPermission "AlpineSkiHouse GAL" | FL
(3) What query logic or filter should we use for the company GAL?
In White Paper: Configuring Virtual Organizations and Address List Segregation in Exchange 2007 , the article uses customattribute1 and they make sure that mailboxes or resources created must have that attribute, if not, it will not be included in that GAL.
This is where HMC 4.5 does things slightly differently. If you perform a Get-GlobalAddressList on one of the GALs created by HMC, you will find the query logic/filter, which is the RecipientFilter and LdapRecipientFilter attributes are empty.
These attributes are essential if you want to make sure a newly created mailbox will be included as a member of this GAL. Only if the user is a member of the GAL, it can access the GAL and that it can show up in the GAL. These attributes are being read during the creation of the mailboxes and if the mailbox falls under the query logic, the appropriate membership will be stamped.
So, why does HMC not have any value on those attributes then? The answers are,
You may ask, what about when I query this from Outlook? Does it use those query logic? The answer is no. When you query from Outlook, it retrieves the objects based on Address List Membership (showInAddressBook) attribute in each objects. In short, the query logic in the GAL itself is only used for stamping the membership during mailbox creation.
There you go, Global Address List segregation, not really a difficult concept but can be confusing sometimes.
Address List Segregation
Address List Segregation isn't very different as compared to the GAL Segregation. However, there are a few things worth mentioning here.
Firstly, out of the box, Exchange 2007 installation comes with a few default address lists, All Contacts, All Groups, All Rooms, All Users, and Public Folders. Those will be removed during HMC 4.5 deployment. So, a clean HMC deployment will have an empty All Address Lists container.
Next, like the GAL segregation, the permission of the All Address Lists container has been properly locked down. Now, in theory, we don't really need to be part of any Address Lists for Outlook to work. Being part of the GAL is more essential because if you are not, you can't even create an Outlook profile for that user.
However, some processes in Exchange, such as the Offline Address Book generation prefers using Address List than Global Address List when generating the OAB (I will cover the OAB generation process in my next part). For those reasons, we need to make sure each company will also have company Address List where every mail enabled objects in the company will be part of that address list (yes, there is no difference compared to GAL).
Like the GAL membership stamping process, the Address List membership stamping process is the same, it is done by HMC mechanism. Hence you will see the query logic/filter for all the Address Lists created by HMC are also empty.
Wait the minute, what about Outlook Web Access?
So far, we have been discussing about the Outlook experience of the Global Address List and Address Lists. I think it is important to highlight that things work a little bit differently in Outlook Web Access.
There is some permission that applies only to specific clients. For example, Outlook Web Access does not incorporate user permission sets when doing searches. The permissions set on OUs do not prevent search results from including other segregated group's recipients, due to how OWA works. This is where attribute msExchQueryBaseDN comes in.
In order for us to control or restrict the search results to include only the members of the appropriate address list in Outlook Web Access, we must set the attribute msExchQueryBaseDN on each user object to the distinguishedname (DN) of the OU or an address list containing the correct group of users. In the case of HMC, when a mailbox user is created, HMC will also populate this attribute with the OU of the company/tenant.
What about LDAP? I have clients needing this access.
If I have a group of users using other clients and needs LDAP access so that they can query the users of in their company/tenant, what happen then? Well, the way I look at it is this, as much as possible, don't.
However if you have to do it, make sure that the client has to at least go through some form of VPN or something because you really don't want to put your Active Directory server out and exposed them to the Internet just like that.
Also, if you are having HMC 4.0, you should look at this article, Hosted users can see other hosted users if they can access the HMC Active Directory by using LDAP tools in Microsoft Solution for Hosted Messaging and Collaboration version 4.0 (http://support.microsoft.com/kb/943864/en-us), to properly lock it down before allow your users to use it.
What are some of the usual problems that you may face with Address Lists?
(1) Incorrect Address List membership
The most common issue that I have seen with address lists issues are membership problem. Based on the above, you kind of understand how some of the things could have gone wrong. The fact that HMC does not use the RecipientFilter and LdapRecipientFilter means that you can't run Update-GlobalAddressList or Update-AddressList because, That two cmdlets will rebuild (there is no update process in Exchange 2007, only rebuild) the address list, which means when it finds that it is empty, it may reset those accounts that currently are supposed to be in the address list.
When an account lost the GAL or AL membership, you may notice that you may not be able to create an Outlook profile for that user, and the user may have other problems too.
To resolve that, you can either use ADSIEdit to manually slot those membership back or you can use the hosted Email 2007::ModifyMailbox to reset this attribute to its correct values without having to know the address list DNs. This procedure resets the showInAddressBook attribute on each call.
Here is a sample, assuming that you supply the original values for <emailAddresses> and <alias> the procedure will only reset the showInAddressBook value without modifying any other attributes.
<request> <data> <preferredDomainController>AD02.Fabrikam.Com</preferredDomainController> <user>LDAP://CN=User1,OU=AlpineSkiHouse,OU=ConsolidatedMessenger,OU=Hosting,DC=fabrikam,DC=com </user> <alias>User1</alias> <emailAddresses> <value>User1@alpineskihouse.com </value> </emailAddresses> </data> <procedure> <execute namespace="Hosted Email 2007" procedure="ModifyMailbox" impersonate="1" > <before source="data" destination="executeData" mode="merge" /> <after source="executeData" destination="data" mode="merge" /> </execute> </procedure></request>
This functionality was added to account for the fact that the Exchange Cmdlets like to reset showInAddressBook value during most mailbox operations.
PingBack from http://diggffxi.info/tags/101/200812/microsoft-exchange-server-outlook-default-mail-client-2.html
Introduction One of the frequently asked questions about Hosted Messaging & Collaboration (HMC) is this, "What do you do to Exchange to make HMC work?" So, here I will attempt to demystify this. HMC started long way back but the concept has not deviated
I have been seeing installation issues with Blackberry Enterprise server because of the way HMC changes the GAL. I'm unable how to figure a way around this. Can you provide some direction?
Just make sure your BB service account has access to the Default Global Address List and make sure the rest of the mailboxes is also part of that but has no access to it.
I have a strange issue with our HMC4.5 environment. When a tenant from organization emails a tenant at another organization, the sender email address shows the LegacyExchangeDN attribute value in recipients email FROM Field when you double click on it to view the contact or reply. It only happens in all versions of outlook (2003, 2007 and 2010). It does not happen in OWA. Exchange server is running SP2 and HMC update rollup 6. I am not sure if this is by design or if there is a workaround? Can you please advice on what could be wrong?
@ P Zain, I took a quick look at this. I am able to reproduce the issue. While this is not a conclusive answer, I believe the issue has to be that Outlook detects (either by some headers or message class) that the message is an internal delivery and hence attempts to resolve the address. I do not think this has to do with SP2 or HMC Update Rollup 6. I do not think there is a lot you can do to change this behaviour at the moment. I will a note to our internal team to investigate into this. Thanks for the feedback.
Thanks for the response. Please can you let us know how the investigation progresses and update this Blog?
@ P Zain, I will if I have the updates.
The issue may come from Outlook client cache.
just delete outlook autocomplete cache, that issue will be resolved,
@ YS. Thanks for your suggestion. I haven't done thorough testing but I do not believe it is nk2 Outlook name cache issue. It maybe the case if we are trying to resolve to a mailbox that has already been deleted but it isn't the case here.
Hi I have tried deleting the cache .NK2 file in outlook but it does not fix the problem. Like Kip says it looks like it is another issue.
Hi @kip.ng. Have you got any updates from the internal Team.? Thanks
It is being investigated. That's all I can say right now.
"To resolve that, you can either use ADSIEdit to manually slot those membership back or you can use the hosted Email 2007::ModifyMailbox to reset this attribute to its correct values without having to know the address list DNs. This procedure resets the showInAddressBook attribute on each call. "
Please help me, how do I correct the problem, in details.
Let say that i have a user named "Bill Board" with the alias "b.board.com" and a other user from a different company named "My Game" alias "m.game.com, how do i make sure that they are updated.
The exac problem that i have right now, is that I am running a HMC enviroment, and the OWA i working perfectly, but when the users try to setup the Outlook (2007) the run as Outlook AnyWhere, it returns the error, that "the user was not found in the addresslist" and so on. To me it look like it is at problem with the GAL.
Hi C. Jershauge,
You are probably right. OWA uses a msExchQueryBaseDN and Outlook looks at the company GAL, specifically. Now, assuming that this user has been subscribed to a user plan with MAPI enabled. Take a look at this post that I blogged a while ago and see if it helps,
Let me know if you need more help.