Welcome to MSDN Blogs Sign in | Join | Help

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

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

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 ?

AnswerNo. 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 segregation will need to be done on the Exchange 2007 side. 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

Published Sunday, February 17, 2008 6:56 PM by dgoldman

Comments

# Anderson Patricio Blog » Blog Archive » Exchange 2007 Address List Segregation Document - Q&A Updates

Wednesday, February 20, 2008 1:06 PM by Dgoldman's WebLog

# Exchange 2003 Address List Segregation Document

Over the last few months a great number of people have asked if we would be putting out a white paper

Thursday, February 21, 2008 1:45 AM by Man On The Way

# White Paper: Configuring Virtual Organizations and Address List Segregation in Exchange 2007

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...

Friday, February 22, 2008 3:03 PM by subject: exchange

# Weekend reading

Exchange 2007 CALs – Why everyone needs Standard CALs Microsoft turns Server 2008 RTM into Server 2008

Wednesday, February 27, 2008 9:38 PM by Andrew

# re: Exchange 2003 / 2007 Address List Segregation Document - Updates!!

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.

Thursday, February 28, 2008 7:58 AM by dgoldman

# re: Exchange 2003 / 2007 Address List Segregation Document - Updates!!

Andrew, there never was an offical support stance for 2003 address list segregation. All that was out was a few kb articles. The hosting team at one time put at a hosting doc and that was pulled. When something is pulled it is no longer supported and then we came out with the HMC product. If you guys followed the KB articles all I can say is have everything documented. I worked closely with the development team to make sure there was a supported stance and there are two offical stances as of today

1. HMC

2. The Exchange 2007 address list doc that I wrote.

With all of the changes to service packs, hot fixes etc the older kb articles are no longer vaild.

Thursday, March 06, 2008 2:00 AM by Richard

# re: Exchange 2003 / 2007 Address List Segregation Document - Updates!!

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!

Friday, March 28, 2008 5:20 PM by Brian

# HMC Support?

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

Friday, March 28, 2008 5:59 PM by dgoldman

# re: Exchange 2003 / 2007 Address List Segregation Document - Updates!!

Hi Brian, you can look here for more information on HMC.

http://www.microsoft.com/serviceproviders/solutions/hostedmessaging.mspx

Dave

Monday, April 14, 2008 10:30 AM by Mikeltxu

# Address list update after recipient object creation

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

Monday, April 14, 2008 3:39 PM by dgoldman

# re: Exchange 2003 / 2007 Address List Segregation Document - Updates!!

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.

Tuesday, April 15, 2008 5:11 AM by Mikeltxu

# re: Exchange 2003 / 2007 Address List Segregation Document - Updates!!

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

Tuesday, April 15, 2008 10:45 AM by dgoldman

# re: Exchange 2003 / 2007 Address List Segregation Document - Updates!!

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.

Monday, June 02, 2008 4:23 AM by Dougs Blog >> Exchange Server in the field

# They say it better than I can...

Just want to point you to a few blog articles I have read recently just in case your search doesn't reveal

New Comments to this post are disabled
 
Page view tracker