Hey I wanted to chime in on this one quickly. Note I am not
ignoring other posts or the emails I am getting, just trying to dig myself out.
In fact I had so many emails about a certain problem with people's understanding
of things I made some code changes in CPAU so I can cut down my email volume by
a couple of hundred emails every couple of days (I hope).
:o)
Anyway, I don't think this is a Whidbey issue though I
guess Whidbey should know how to leverage the fixes that need to be
made.
There are two things I think MS needs to do that I see
right off.
1. Add more DNS entries that are Domain Specific for GCs.
I.E. Currently say I have a forest with the following names and dcs with all
being gcs as well
root.com
(dc1)
child1.root.com
(dc2) child2.root.com
(dc3)You will see records like the following for the domains
(note I know there are more, trying to keep this simple)
_ldap._tcp.sitename._sites.root.com
(dc1)
_ldap._tcp.sitename._sites.child1.root.com (dc2)
_ldap._tcp.sitename._sites.child2.root.com (dc3)
If you
look at GC records you would only see
_gc._tcp.sitename._sites.root.com
(dc1)
_gc._tcp.sitename._sites.root.com
(dc2)
_gc._tcp.sitename._sites.root.com
(dc3) We
need the child1.root.com and child2.root.com assuming the GC is a member of one
of those domains as well. I.E. In addition to those records above you should
also see (amongst others)
_gc._tcp.sitename._sites.child1.root.com (dc2)
_gc._tcp.sitename._sites.child2.root.com (dc3) 2.
Fix DsGetDCName API call specifically the DS_GC_SERVER_REQUIRED flag so
that you don't have to specify the forest name, you can specify a domain
name.
Most
likely those two fixes would flow into Whidbey as they are the key changes
needed and fix the underpinning. I doubt, and I think it would be a bad idea if,
Whidbey had its own method of locating DCs. Exchange sort of so so did this in a
so so way and look what you have. People confused as to its DC/GC choices. They
sort of get it from the normal ways and then go off and figure other things out
too on their own but just maybe they wouldn't have had to if the AD guys had the
Domain Specific GC records in place...
Every
AD Dev guy I came into contact with while at AD HQ I said, we need these
additional DNS Entries and here is why (with Exchange always as the first
mentioned item to hopefully give it some extra weight). Stuart seemed to
be knowledgeable of the issue I was describing so I hope that means he has
someone working on the solution. I can't see that this would be overly difficult
to pull off for the additional DNS entries, the API call change may be involved,
I haven't looked at its guts yet. But if the DNS entries are there I can't
believe it would exceedingly difficult.
Absolutely not all GCs are created equal. I will
disagree with Roger in that the hooks aren't there to find the right GC though.
They actually are, they are just not "EASY" to get a hold of. The AD guys
should make it more easy to get that info. The blame I put on Exchange is not
knowing they had this limitation until after they put the product out the door
and then trying to slough it off like it was a local Exchange
Implementation/Design issue versus a core failing in their product. When I first
ran into this as a DL issue Premier told us the problem was due to saying we
didn't use DLs so the design (they were involved in) wasn't made to account
for it.... 4-5 months later we hit the publicDelegates issue and they had no
other excuses. I now know that no matter what design you use, you can't flexibly
handle DLs within Exchange/Outlook.
Note
that even if the AD team were to fix this issue above (PLEASE PLEASE PLEASE
PLEASE) it will not entirely fix Exchange. Right now this causes pain to
Exchange in a couple of areas
1. You
could get a GC that is a DC of a domain that isn't the home domain of the userid
you are using. This means that you will be frelled when trying to manipulate
publicDelegates, certs, or anything else on your userid that outlook wants
to modify. Outlook may or may not report an error back to you. In the case of
publicDelegates it can be extremely messy and a security issue.
2. The
other issue is if you like to use UNIVERSAL GROUPS (heh) for DLs and you
have a user in outlook who wants to manipulate a DL. If you get a GC that isn't
a DC of the domain where the UNI is hosted, you can't modify it from
outlook.
#1 can be fixed strictly in DSACCESS and I think
what the Exchange team is doing. They will make DSACCESS a little smarter in
what GCs it gives out to users. I.E. It will give a user a GC that is a DC of
the domain that the user object lives in. This way all of the issues in #1 are
gone... Hopefully again, AD team makes getting this specific info easier by
publishing more DNS records and fixing the API, but Exchange can work around
this without the change and probably will unless the AD team is already moving
on it as the Exchange fix is supposed to be out for E2K3 this year
still.
However #2 can not be fixed by this workaround. Why?
What if the DL is in domain Child2 and you are in domain Child1, due to the fix
above, the GC you will be getting will be the Child1 GC. That GC can not modify
the Child2 DL. Uh oh, what do you do? The issue here is that the modify ops
appear to be NSPI calls, if you go back to an older client, these are proxied
through DSPROXY on an Exchange Server which could be fixed to do the right
thing. On newer clients they go straight to the GC the outlook client knows
about which will take the request but will not foreward it and NSPI doesn't do
referrals and even if it did, I doubt outlook would handle it. The answer MS
will probably now start pushing for this one is to use AutoGroup/AutoDL instead.
I do wonder if the next version of Outlook will have DL membership modification
capability stripped out of it since it has high potential to not work
consistently in a multi-domain environment. Alternatively I guess they could do
what they should have done with O2K3 and said, hey wait, we are hitting an AD
Server, lets use LDAP instead of this crappy NSPI.
Note
that fixing the two above things helps out others with apps that need to find
specific GCs. I have internally, examples of UNIX apps and even some Windows
Apps that use little tricks to find full forest group memberships for users (DLG
or otherwise).
As a
bonus point, while they are in there working on that section of the code, maybe
they can work on DsGetDCSiteCoverage or add a DsGetGCSiteCoverage so you can ask
a DC/GC what sites it covers for global catalog functionality. I asked around
once before how to do this and no one seemed to have an answer for me. Currently
the only way I can think of to get what sites a certain GC covers
authoritatively is to tear apart the netlogon.dns file.
-------------
http://www.joeware.net (download joeware)
http://www.cafeshops.com/joewarenet (wear joeware)
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of [EMAIL PROTECTED] Sent: Monday, April 12, 2004 1:05 PM To: [EMAIL PROTECTED] Subject: RE: [ActiveDir] using dsacls.exe I agree that I don’t
think they totally understood the problem. Let’s type something up on this
and send it to them or post it in the MVP newsgroup. I think the
time is now if there is to be any chance of getting this dealt with for
Whidbey. I think if they understood the problem, they might do
something. Joe
Kaplan From:
[EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]
On Behalf Of Roger
Seielstad The GC per DC question
came up in one of the sessions I attended (with the Whidby team) and it strikes
me that there is a common misconception even within Roger --------------------------------------------------------------
This message is for the designated recipient only and may contain privileged, proprietary, or otherwise private information. If you have received it in error, please notify the sender immediately and delete the original. Any other use of the email by you is prohibited. |
- RE: [ActiveDir] using dsacls.exe Grillenmeier, Guido
- RE: [ActiveDir] using dsacls.exe joe
- RE: [ActiveDir] using dsacls.exe Ulf B. Simon-Weidner
- RE: [ActiveDir] using dsacls.exe Ulf B. Simon-Weidner
- RE: [ActiveDir] using dsacls.exe Grillenmeier, Guido
- RE: [ActiveDir] using dsacls.exe Roger Seielstad
- RE: [ActiveDir] using dsacls.exe Roger Seielstad
- RE: [ActiveDir] using dsacls.exe joseph . e . kaplan
- RE: [ActiveDir] using dsacls.exe Roger Seielstad