Yeah understood. However they shouldn't fix it there, it should just be exposed there. It should be fixed in the underlying code. Not everyone is going to use .NET to get at this stuff and everyone shouldn't be coming up with different methods of doing resource location otherwise it defeats the purpose of having it built in. ------------- http://www.joeware.net <http://www.joeware.net/> (download joeware) http://www.cafeshops.com/joewarenet (wear joeware)
_____ From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Roger Seielstad Sent: Monday, April 12, 2004 2:36 PM To: [EMAIL PROTECTED] Subject: RE: [ActiveDir] Active Directory GC Locator Services and why Exchange would STILL be broke if the AD team fixed it - WAS: using dsacls.exe You missed the session that we attended with regards to s.ds.activedirectory - and that was the team that didn't get it. They're writing from scratch a new interface within the .Net Framework that will include "easy to use" methods for retrieving DC/GC info. It struck a number of us that adding the ability to request a GC homed on a specific domain's DC wouldn't be that hard to implement. Roger -------------------------------------------------------------- Roger D. Seielstad - MTS MCSE MS-MVP Sr. Systems Administrator Inovis Inc. _____ From: joe [mailto:[EMAIL PROTECTED] Sent: Monday, April 12, 2004 1:51 PM To: [EMAIL PROTECTED] Subject: [ActiveDir] Active Directory GC Locator Services and why Exchange would STILL be broke if the AD team fixed it - WAS: using dsacls.exe 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 <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 Sent: Monday, April 12, 2004 9:11 AM To: [EMAIL PROTECTED] Subject: RE: [ActiveDir] using dsacls.exe 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 Redmond that "All GC's are Created Equally" - which I think we've seen is NOT the case. Not sure they got the point, however. They were more than willing to blame Exchange for that problem, While its technically an Exchange issue, the hooks just aren't currently there to get the *right* GC every time. Roger -------------------------------------------------------------- Roger D. Seielstad - MTS MCSE MS-MVP Sr. Systems Administrator Inovis Inc. 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.
<<attachment: winmail.dat>>
