RE: [ActiveDir] Univ group problem

[Joe]

Oh yes... I think I know a little about this one... :o)   As Hunter and Ken alluded to I have been in debate with MS about this "feature" for some time. I have recently won some small victory in that some or all of this problem is actually going to be fixed but they don't know if the fix will be in DSACCESS/DSPROXY or in the NSPI portion of the logic in Global Catalog servers. I really hope the fix is in Exchange because I really don't think AD should do anything special for Exchange at all including the initial NSPI stuff. AD, IMHO, should be a simple directory that everyone uses the same although I realize that may be pie in the sky thinking as you will see below.   As was previously indicated, the issue is that while the group and security can be enumerated, you try to make a change against a GC that isn't a DC of the domain that the group really exists in. A lot of folks think Universal groups "live" on Global Catalogs. That is simply incorrect, they live on the DCs of the domain that they are a part of (look at the DN, the last part is the domain). The membership is simply available on the GCs which is not something you see for the other groups. Don't worry, this is a common mistake, I have actually seen posts in the newsgroups from Microsoft Support staff saying that a Universal group would survive the removal of the domain they were created in because they were part of the Global Catalog... A lot of confusion here.   So anyway, what can you do.... You can wait for MS to fix the issue - we were told probably a year depending on where the fix is and the SP release timings for the product in which they fix it and the fix probably won't get back ported, you will need E2K3 or W2K3. The fix could vary and could give limited support for DL's. In fact the only way, I think, to give full support to any kind of use of DLs would be to make the change where I don't want them to make the change. I.E. In the NSPI portion of the code on domain controllers and make it so they will do referrals on behalf of the clients which is the current root cause issue - no referrals.   You can minimize the problem by putting your DL's on the domain where the users who will most likely do the modifications exist. Then whereever those users have Exchange Servers, only having GCs of the one domain readily available. That way you should get a GC that is a DC of the domain of the user and the group, then when you make a change, you will be ok. If you have GCs from both domains, you could randomly get one or the other and if you randomly get the one that doesn't have the writeable group object, you aren't making any changes. Read the other chains mentioned to get the full gist of the problem but it affects DLs, Public Delegates, Certs, etc. Anything that needs to be updated by the Outlook clients.   The "official" answer on how to handle DLs and how MS does it (sort of) is with a product called AutoDL. MS actually internally uses a tool called AutoGroup which is nicer but they won't have that ready for any kind of release for probably a year last I talked to the product team playing with that. They won't even let us in to play with it in a beta non-supported method right now as the code is a hodge podge of technologies thrown together. Note that I do not believe any of that info to be NDA. If you have a PSS or MCS person on site, they would probably be happy to show you AutoGroup which is a pretty smooth little tool. I was oohing and ahhing when I first saw it. Anyway AutoDL is out there in, I think, the Exchange 2000 Res Kit and downloadable. You set a side a server to do the work, I believe you will need SQL Server as well. If you have a spare server sitting around, it is probably a good solution.   You may also look at solutions from companies such as Quest/Fastlane or NetPro as well. I am supposed to be looking at some tools from Quest but have been swamped with our E2K migration. On the positive side it is going pretty well now and we are moving about 5000 people a night. I'm simply running around with bandages staunching the blood as it gushes out in different areas. :o)   Again, for this issue you need to check your public delegates to make sure they are being set correctly, DLs, and also Certs. There may be more (and I have specific concerns about the categorizer) but don't have any solid info from MS or otherwise yet on that. Just keep an eye out. With public delegates what you can find will be really inconsistent setting of the publicdelegate attribute in AD which gives the "Send on Behalf" right to users (not to be confused with send as). If you use the publicdelegates tab to set permissions on the folders that will always work ok as that is done directly on the store, but the info in AD may or may not get updated properly meaning you may not take away or you may not grant the send on behalf properly. We are getting around this by MS writing up a web page for us for handling publicdelegates. From what I understand they need it internally as well as they centralize their E2K architecture.   I hope that helps. :o)      joe       From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Creamer, Mark Sent: Tuesday, December 23, 2003 3:56 PM To: [EMAIL PROTECTED] Subject: [ActiveDir] Univ group problem Hello, to those who haven’t disappeared for the holidays!   We’re having a problem with a Universal Group. Both domains are native, and therefore the DL is a Universal group, Security type. The Univ group exists in Domain A. The purpose of this group is to control who can go into Address Book and modify members of a particular distribution list   Users from both Domain A and Domain B are in this UG. Users from Domain A are able to modify the distribution list membership, but those from Domain B are not. The OK button is grayed out, indicating they don’t have the permission. Any suggestions?   Thanks!   Mark Creamer