hi
My customer has allowed some users permission to modify their own
Distribution Lists, to delegate some of the workload away from the IT Support
Teams. This also provides ownership to the business, to manage the scope of
communication to their own teams - particularly in cases where regular
changes of personnel are prevalent.
Known Issue
This process fails if the Distribution List is in a different domain to the
Global Catalog Server the user happens to be talking to, at the time.
Refer:
http://support.microsoft.com/kb/262199
Workaround
When a client requires a Global Catalog, it first looks for one in its own
site. If one does not exist, it will seek the closest one it can find. This
search process is not optimized by design and is largely random. To fix, we
can preference the GC by modifying the Registry for the user's profile on
their workstation.
Refer:
http://support.microsoft.com/kb/319206
Here we can use a generic DNS Alias to point to an actual GC Server Name in
the CHILD DOMAIN B or an equivalent in CHILD DOMAIN A or CHILD DOMAIN C,
based on where the specific DL resides, that the user is trying to modify.
The Problem
1. If the user modifies DLs in both CHILD DOMAIN A and CHILD DOMAIN B, then
we can only satisfy half the request (Registry is fixed to one GC)
2. If the user receives a new workstation, re-imaged or has their Profile
reset, they lose this Registry setting
3. If the user moves to a new PC, the Registry change will not follow them
(Roaming Profile will fix that)
Solution Options
When they reach the stage of a single CHILD DOMAIN A domain housing all
resources and accounts, this problem will go away. In the meantime...
1. Accept the workaround above, but may need to consider how we manage
(track) what workstations we have made this ad-hoc Registry modification to?
2. Move all Distribution Lists to CHILD DOMAIN A and incorporate a Registry
change to point all user profiles to a GC in CHILD DOMAIN A via Group Policy
or SOE build?
3. Change business strategy to allow only IT Support staff to modify DLs,
until we are all migrated to CHILD DOMAIN A?
Option 2 seems to be the best option, as ultimately, the customer wants to
migrate all DLs to CHILD DOMAIN A anyway and allows them to meet the current
advantages of delegating DL management to the business. However, they don't
know how to move a Universal Distribution Group from one domain to another
without blowing it away and recreating it via a script, which they would
prefer to avoid.
Thanks for any advices and suggestion of applicable tools e.g. ADMT or tools
from Quest?
Hong