I have an environment with 2003 AD on 2 forests. One forest is housing user
accounts and another is housing Exchange mailboxes with trusts between user
and email domains.
The structure is for multiple virtual companies so I need to hide all but
the required GAL based on a group. As each mail enabled user has an account
in both domains one for the user account and one as a mailbox resource, which
user object needs to not have read access to a GAL to prevent viewing. The
user on the exchange forest which owns the mailbox being used, or the user on
the user forest that will actually be logging in to outlook.

With multiple GAL's Im also unsure of the resultant list for a user that has
read permission to multiple GAL's. Do they just see the first GAL or do they
get a combined list of all they have read permissions to.

Thanks anyone for help.

Frogot to mention I have tried technet article 822940 have had some success.
I managed to get a test account to pick up a specific GAL list by denying the
user to read the other GAL's, but when I change it again it is stuck on the
last GAL it had rights to read despite the user now having deny read on that
group.

Have a look at this article: How to Manage Address Lists When You Host
Virtual Organizations
http://support.microsoft.com/default...b;en-us;822940. Just
released you have already seen this.

There used to be a whitepaper called "Exchange 2000 Server Hosting for ASPs
Deployment Guide" but I can't seem to find it any more. The Active Directory
Application Services Kit is supposed to include the whitepaper but again I
can't see it there.

Have a look at this WinNT Mag article "Exchange 2000 Hosting: The ASP Model,
Part 1"
http://www.winnetmag.com/MicrosoftEx...404/22404.html
and Part 2
http://www.win2000mag.com/MicrosoftE...895/22895.html


So on to some additional info:

I would expect that the user account would be the one that would set the
permissions, but test it to see. It wouldn't surprise me if it was the other
way around.

The users will receive the largest GAL they have permissions to.

I would try to stay away from using deny rights if possible. Take the
default permissions away (you may need to stop inheritance and copy the
permissions to the object) and build up the specific groups that you want to
see the GAL or address list. This way it is less confusing and less chance
of running into inherited deny vs explicit allow or inherited allow and
which one wins.

Remember to create and edit the address lists as well (as per the article
you found). But when you do this you will find that users will still be able
to see the address list of the other company but will not be able to open
it. Very annoying if you want it to look pretty and clean for users.
Try these steps if it is an issue:
1. Use ADSI edit and change the attribute dsHeuristics to "001" on
cn=directory,cn=windows,cn=services,cn=configurati on,dc=DOMAIN.
Here is an article that talks a bit more about this attribute, although it
states that only "0" and "2" are valid values.
http://support.microsoft.com/default.aspx?scid=326690
We have successfully implemented a value of "1" in our org.

2. Still in ADSI edit go to the configuration container and navigate down to
the Address lists container. Properties on the container, security tab,
remove authenticated users permissions. Apply change. Then on the advanced
tab of the security page add authenticated users and scope to "This Object
Only" set allow List object and List Contents. Apply change.

3. In Exchange System Manager, All Address Lists container Properties,
Security tab, advanced, add the authenticated users group, scope to This
Object Only and give List Object. This step confused me a little as the
permissions set in ADSI edit seemed to have already done this.

4. Create an address list and set permissions so that the group that you
want to see it can.
Permissions required: Scope "This object, sub containers, and children
objects". Set Allow list contents, open address list, list contents.

Obviously document all settings before making changes and test in a
non-production environment first.


Hope this helps

Glen




"Marcus Bentley" <MarcusBentley> wrote in message
news:ca7b
[..]

Thanks it does seem to be working now, we are considering the other mail
groups at the moment so that other stuff is helpful. I also would never have
guessed the GAL used would be selected based on the largest GAL you have
rights to.

In case anyone else has a similar situation the security required on the
groups is as below

on the security tab on the GAL you are giving to a group you need to give
permission to the user account or user group from the user domain, rather
than the user or group from exchange domain.

When creating the ldap query for the GAL the group distinguished name you
use has to be the group from the Exchange domain (more obvious as you can't
send a message to a user that doesn't own a mailbox)

Glad to have helped and thanks for the update on what worked for you.

Glen



"Marcus Bentley" <MarcusBentley> wrote in message
news:b09c
[..]