Partager via

Exchange 2003 / 2007 Address List Segregation Document - Updates!!

  • Article

Since the document has been out a few questions have come up and I wanted to try to answer them.

Top Question: What if I am in a mixed mode and I have modified my permissions on the 2003 side because I was self-hosting?

Answer:  This is not going to work. You need to revert your *entire* organization back to the default install. You can follow this blog here for resetting *all* of your permissionshttps://blogs.msdn.com/dgoldman/archive/2007/05/16/missing-permissions-on-the-address-lists-container-breaks-the-oab-generation-process.aspx. If you do not reset the permissions back you will not get the white paper to work nor will you be able to install any other exchange servers.

Question: Why is Exchange 2007 Service Pack 1 a requirement.

Answer:  It is a requirement do to certain fixes that were added to SP1. We also wanted to make sure that customers are on the same platform that this was tested on. Since this was tested on SP1 it will be supported if you are *running* SP1. Applying this document to a system that doesn't have Service Pack 1 can yield different results and therefore might be a problem for you.

Question: What happens when you stand up a 2007 SP1 server in a existing 2003 organization?

Answer: Nothing. Applying this document in your environment will cause no problems if you are in a mixed environment. Once thing that you *will* have to consider is where you are going to host your Address Lists and OAB's (on Exchange 2003 or Exchange 2007). If your users are on Exchange 2003 you will not be able to host your Address Lists and OAB's on the Exchange 2007 server. The reason for this is that at the time of the generation we will read the search filter from the Exchange 2003 side and LDAP is not compatible with OPATH for Exchange 2007. With this regard you will have to move all of your Exchange 2003 mailboxes for that company over to Exchange 2007, then create your companies Address Lists and OAB's.

Question: Why can my Outlook users no longer see all of the Address Lists from within Outlook after I applied this document?

Answer: This is by default. By adding the 'All Users Security Group' and applying a 'Deny for Read and Open Address List' you are blocking the NSPI calls that Outlook makes to the All Address Lists Container. This was done to prevent users from one address list so they can not see users in another.

Question: Where is the Exchange 2003 version of this document?

Answer: This is not supported. We put out the Exchange 2007 document first as there was a greater need for this. The Exchange Product Group has decided to no longer support this.

Question: What is Supported? A "full segregated" environment. So there is ONLY ONE gal per company and a security group grants permissions? How can I implement, that company1 is using GAL1 and AL1, company2 is using GAL2 and AL2?

Answer: - This is what this document walks you through. Being fully segregated each company only has *1* gal. This is the purpose of segregation.

Question: But what if you still want to have a "default gal" containing everything ?. Why ? Sample:

  • Global Company with many sub-companies
  • Subcompany1 users should use their segregated GAL/AL
  • Subcompany2 users should use their segregated GAL/AL
  • CEO and marketing of Main-Company should have a full GAL. (same with Blackberry Servers, Single Item Backups etc)

So by following this document there really is no way to configure one company with two or three GAL's and restrict only the "standard Users" to one GAL ?

Answer:  No. Either you follow this or you stay with standard exchange. What is not supported is trying to have the gal and trying to segregate that Default GAL. What you can do is make another OAB and then add all of the address lists to it and make sure that CEO is not part of any deny groups so he can see them in outlook.

Question: What if you read "319213 How To Use Address Lists to Organize Recipients in Exchange 2003", you can see an other permission model (deny on Address Lists).

Answer: This KB Article will soon be pulled and is no longer supported. Please do not follow it.

Question: What if I am in mixed mode, can I still use this document?

Answer: Yes, however to be supported all objects and exchange components as well as all segregation *MUST* be on the Exchange 2007 side. There is no support for having any segregation on Exchange 2003. In order to do this there are a few steps involved.

  1. MIXED MODE MIGRATIONS ONLY!!!! - Do not remove the permissions for the Default Global Address List until your migration is complete. You will not want to run the add-adpermissions powershell cmdlet until all users are on Exchange 2007.
  2. You will be required to apply a security group to the Default Global Address List to stop users that have already been moved over to Exchange 2007 so they can not read the Global Address List. The security group will block read access as it does to the CN=All Address Lists Container.
  3. Once your migration is complete you can remove the access with the powershell commands.

I will update this from time to time when I can.

Dave

Comments

  • Anonymous
    February 19, 2008
    PingBack from http://blogs.msexchange.org/patricio/2008/02/19/exchange-2007-address-list-segregation-document-qa-updates/

  • Anonymous
    February 20, 2008
    Over the last few months a great number of people have asked if we would be putting out a white paper

  • Anonymous
    February 20, 2008
    This white paper provides the information that you need in order to configure Microsoft Exchange Server 2007 with multiple address lists so different groups of users can have their own address list and secure those address lists so that groups...

  • Anonymous
    February 22, 2008
    Exchange 2007 CALs – Why everyone needs Standard CALs Microsoft turns Server 2008 RTM into Server 2008

  • Anonymous
    February 27, 2008
    I have a question about the PRoduct Teaming pulling support for something.  Where does it leave clients who have already implemented the feature. Not supporting something from the outset is one thing, pulling support after customer have already deployed depending on it is something else especially if upgrading the E2K7 isn't immediately achievable.

  • Anonymous
    February 27, 2008
    The comment has been removed

  • Anonymous
    March 05, 2008
    Excellent doc just what a lot of people have been waiting for. The scripts will be invaluable for small hostering companies who dont want to enter the HMC arena just yet. Well done!

  • Anonymous
    March 28, 2008
    dgoldman, Thank you for taking the time to create such a great and informative document. You refer to two options of GAL Segregation. You're doc and the HMC. Where do I find the HMC's method of GAL Segregation? -Brian

  • Anonymous
    March 28, 2008
    Hi Brian, you can look here for more information on HMC. http://www.microsoft.com/serviceproviders/solutions/hostedmessaging.mspx Dave

  • Anonymous
    April 14, 2008
    Hello Dave, We have the described environment running on Exchange 2003 and now plan to move on Exchange 2007. We do not publish all attributes of a recipient during the object's creation, but allow delegated administrators to publish additional properties afterwards. We want to use these properties are then with  address list and email address policy filters. With the address list-stamping process bound to the mailbox creation, how would the update of a recipient's showInAddressBook-property work for us? Thanks,

  • Mikeltxu

  • Anonymous
    April 14, 2008
    Having a mixed org is fine. If you can help me to understand what you mean by "additional attributes"? With regards to the showInAddressBook, you do not want to modify this. This will be taken care of for you when you provision the user and you only want the user to be part of two address lists, theirs and the default which will fail when you remove permissions. This will force the outlook query to roll back to the org that they have been added too.

  • Anonymous
    April 14, 2008
    Hello Dave, Thank you for your help and advise. Given a native Exchange 2007 environment with an address list, let's say, filtering {(CustomAttribute15 –like ‘CONTACT')}. When a recipient is created, and  CustomAttribute15 has no value, this recipient does not get into this address list. When an admin fills CustomAttribute15 later, the right way to get this recipient into this address list is via get-addresslist | update-addresslist, correct? Thanks, -Mikeltxu

  • Anonymous
    April 15, 2008
    See you will follow the white paper and this will do everything for you. After that if you start doing things that are not in the doc you will be in an unsupported state. My suggestion is that you use the sample scripts to do all of the provisioning and you leave it at that.

  • Anonymous
    June 01, 2008
    Just want to point you to a few blog articles I have read recently just in case your search doesn't reveal