HAHAHAHAHA.
Carte Blanche baby! :oP
It is an Exchange problem. Even Outlook clients that don't
know how to talk to AD have the issue when pushing the requests through
DSPROXY.
And....
They are fixing it....
Sort of...
It seems several VERY large customers all complained in a
short time frame on how bad this functionality was (some of us really really
really loudly with notes to MS executives though I was told that had no bearing
on it) and the problem will be "addressed" either in K3 SP1 or E2K3 SP2. I
think they are still arguing where it needs to be fixed.
The issue is that outlook uses NSPI either against the
Exchange Server (older versions of outlook) or against DCs (newer versions of
outlook) and if the GC being used by the machine doing the update (Exchange
Server or client) does not have a writeable copy of the group then no
attempt at referral is attempted.
If all groups were UGs this problem wouldn't exist because
UGs live on GCs and UGs solve ALL problems... Heh. Just kidding. Long live the
Universal Domain Local Group that I am petitioning to be created! Can't be used
for a global DL but is great for security which is what AD is really for
anyway... <wink>
One possible way of the future "addressing" of the issue is
to have DSACCESS give out GCs that make a little more sense... I.E. A client in
Domain 1 should get a Domain 1 GC. An Exchange Server in Domain 1 should use a
Domain 1 GC. The other possible way of the future "addressing" of the issue is
to have the NSPI piece of GCs refer the requests to the proper domain.
The first one will fix a lot of things, but if a client in
Domain 1 wants to update a group in Domain 2 there is still an issue... However
they can with certainty update groups in Domain 1. Also the public delegate and
cert issues go away. The second one "should" fix all issues but the Exchange
group would have to get the AD group to buy in to the change (hey guys, if I
forget when we are Redmond, remind me to or ask yourself of the AD Dev guys if
they are even looking at this...). I personally dislike intensely that the
GCs have special Exchange only functionality on them at all, but if it is going
to have it, it should probably do it well.
Of course this is a great argument for deploying Exchange
in a separate single domain Forest...
Also MS is working on a tool called AutoGroup (maybe beta
by the end of this year.. maybe - I'm first in line for that beta). This is an
update to the AutoDL tool you get with Exchange or in a res kit or something;
they use AutoGroup internally right now and it is pretty darn slick from what I
have seen. That tool can be used for managing groups. Actually if you have lots
of DLs, it may be worth your time to look at AutoDL right now.
But Guido is kind of right too, it is sort of an Outlook
issue as well. But look at it this way, say you have 100 Exchange Servers, 400
Domain Controllers, and 200,000 outlook clients... Where is the most likely
place to get the issue corrected quickly and easily for large companies that are
truly feeling the pain from this BUG or design shortcoming?
However I argue that if you are pretending and advertising
you are making a transparent change for clients, you should probably do so for
all functionality, not just the easy ones.
joe
-------------
call it what you want - other programs handle group changes
better, and you have one of them on every client: the people search function,
where you query AD as the Address book. You can use this to change groups
and it will do true LDAP referrals to check for a writeable DC of the applicable
domain when changing the group... I'm sure this will be fixed in Outlook
sometime in the near future as well (1-10 years).
But whatever you call it, have to be fair to say it's not
an Exchange problem - it's an Outlook client issue.
Hi
All,
I
know that some of you think the Exchange/AD is the best thing since "sliced
bread" <wink> based on past exchanges/rants on this mailing list, and
I wonder about the following:
In multi-domain environments, the
global catalog server that you select may not be in the same domain as Active
Directory group objects. Therefore, users cannot update group membership because
the local global catalog server has a read-only copy of the
group.
from: How to
configure a specific GC: http://support.microsoft.com/default.aspx?scid=kb;EN-US;319206
Since an Outlook client can
choose any of the available GCs in the enterprise, when a user tries to update a
group membership, obviously it's going to fail if connected to a GC that has a
read-only copy. So the fixup, according to the KB article, is to
specify a particular GC. But by specifying a particular GC, all of a
sudden I have lost the redundancy that AD gives me! Catch-22! Is
this an Exchange design flaw? How are others handling this
problem? TIA!
Mike
Thommes