Link to home
Start Free TrialLog in
Avatar of Italia_NYC
Italia_NYCFlag for United States of America

asked on

Assigning Users to a default Address List (Exchange 2010)

In lieu of creating multiple segregated GAL's which isn't supported in 2010 yet... I have created a few individual Address Lists and paired them with the OU/Container that contain the relevant users. I also created individual OAB's and included the appropriate new Address List with it. All this works as intended.

My question is, can I make one of these new Address Lists, the DEFAULT address list, for certain users? That's part 1. Part 2 of my question would be, can you also hide the other address lists so users cannot see Address Lists they are not a member of?

Thanks in advance!
ASKER CERTIFIED SOLUTION
Avatar of Alan Hardisty
Alan Hardisty
Flag of United Kingdom of Great Britain and Northern Ireland image

Link to home
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
Start Free Trial
Avatar of Italia_NYC

ASKER

It did? I thought that article was forbidden to use in a 2010 environment and would cause far more harm than good?

Either way... in terms of just assigning users to a default address list; can this be done?
Forbidden by whom?  Microsoft?
You would have to create multiple address lists, select members based on a particular criteria / custom attribute etc and then deny permissions to the other address lists.
Simplest way is to follow the article.  It works very nicely.  Microsoft don't support it - yet, but that's not to say it can't / shoudn't be done.
Per this article... http://blogs.msdn.com/dgoldman/archive/2010/01/06/exchange-2010-address-list-segregation-as-of-now-is-100-unsupported.aspx ; It is recommended by Microsoft to avoid that whitepaper for 2007. That was enough for me not to attempt to implement it in our 2010 environment at the moment.

So I'm kind of searching for work-arounds until they release a whitepaper for 2010.
I'll aware you the points, but I can clearly see why that article and this procedure as a whole is not supported or recommended. I tried this, and it somewhat works, though very sporadically and it requires a very sharp IT staff, will increase the time it take to create new users 10 fold and troubleshooting problems once this is introduced is near impossible. Try at your own risk.
It works perfectly on my own 2010 server.  It may be an 'unsupported' configuration and MS will write (are in the process of writing), their 'supported' white paper, but having followed that document, it works 100% for me and adding users / domains etc takes very little time with a few powershell scripting files.