Maybe Exchange 2kX should use instances of ADAM that are synced from MIIS. Here is another question, If you eliminate the additional domains does the problem get easier to solve? There is considerable debate around here that Exchange 2Kx was designed with a single forest single domain mentality, and that the issues running multiple account domains were never fully explored. Granted in 2K3 we have site connectors again, but at the cost of decentralization again.
Todd Myrick -----Original Message----- From: Tony Murray [mailto:[EMAIL PROTECTED] Sent: Wednesday, November 12, 2003 10:26 AM To: [EMAIL PROTECTED] Subject: RE: [ActiveDir] Exchange 2000 and its interaction with AD - Yes again... Exchange 5.5 anyone? :-) I fully agree that the issue should be resolved on the Exchange side, rather than on AD. I can't understand why Exchange has domain dependencies when talking to the GC. The big benefit of the GC is its domain independence. As a kludge you could maybe force the Outlook clients to talk to a specific GC based on the domain membership of the user. When Outlook clients (2000 and beyond) get the GC referral from DSProxy, they cache the FQDN of the GC in the registry setting for the specific Outlook profile: HKEY_CURRENT_USER\Software\Microsoft\Windows NT\CurrentVersion\Windows Messaging Subsystem\Profiles\Profile Name\dca740c8c042101ab4b908002b2fe182 Tony -----Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Joe Sent: Mittwoch, 12. November 2003 15:36 To: [EMAIL PROTECTED] Subject: [ActiveDir] Exchange 2000 and its interaction with AD - Yes again... Hi. :) Ok, I am trying to get a feel for an issue we are dealing with MS on right now and wanted to hear how many people have encountered it and their workarounds if different from our thoughts. You may recall my previous gripes concerning DL management by Exchange users via outlook when dealing with a multiple domain environment. Well we ran into more issues along this same problem corridor. Basically anything that wants to be updated in the directory by the clients gets done by nspi calls. Depending on the specific level of the client this work is done by dsproxy or by the client itself. NSPI calls are stupid in that whatever directory server is targeted, is the only chance for the update, they will not be referred or redirected. By default when an outlook 2K client up to I think O2K SP2 the client will ask Exchange via dsproxy for a directory server the first time and then store that in the registry and continue to use it until it fails. For clients above that level, they will ask for a directory server from the exchange server via some other interface (I want to say RDR but I don't have my notes here) every time the client restarts. Clients previous to O2K will make all updates via NSPI through DSPROXY on the Exchange Server. Due to how the outlook client does directory updates through NSPI, they can not be redirected if the client is pointing at a GC that isn't a member of the domain the update needs to be made on. This means those updates will fail. Sometimes the client will indicate the failure, other times it won't, depending on what it is trying to update. As of right now, I know of two definite cases of failure, the first is in the previously noted issues with modifying DL's and the new one that we ran into is with delegates. We found that when setting up a delegate for yourself (TOOLS|OPTIONS|DELEGATES) and you set it up so that someone can send on your behalf, that configuration can fail if you are pointing at a GC that isn't a DC for the domain your userid exists in because an attribute in AD (publicdelegates) can't be updated. This is bad when initially configuring it and disastrous if it occurs when you are trying to remove it because you can't take away the send on behalf capability then. We have also seen that if you remove a person from the delegate list and that entry can't be removed from AD, when you go back into the delegate list, the user will still be listed, they will just be listed with NONE for permissions since the store permissions are all stripped. Now at no point do you get an error message saying there is a problem so there is immense user confusion (I removed this user 5 times and they were gone from the list but when I went back, they were there again...). I am not sure of anything else Outlook can update in AD via NSPI, we have asked for a list from MS but haven't gotten it back yet. But obviously, the issue with DL's and now these delegates applies to ANYTHING outlook wants to update in the directory so anything along those lines would fail. When this issue gets to be really painful is when you have an admin group stretched across multiple domains in a single Exchange AD site and that AD site has GC's from the multiple domains especially coupled with a centralized Exchange deployment. Say for instance you wanted to use one Exchange Server (or a group of servers) to handle users from 2 or 3 or more AD domains and all of the GC's are next to the Exchange servers and not out in the WAN sites. We have asked MS for a change in how DSACCESS/DSPROXY works in how it hands out GC's to clients. We are asking that it be smarter about it and try to give out GC's that are from the domain that the user exists in. This doesn't solve all problems (specifically DL's in other domains) but will make any changes the outlook clients need to make to the user's own record work (with the caveat that there was a functioning DC/GC of the user's domain available at the time). It is escalating up the chain quickly and is allegedly in the upper levels of the Exchange folks now and they are looking at all the different things they might be able to do and if they are feasible to do and if feasible what kind of time frame to do it in. An alternative solution we are looking at that we know will work is to break up the centralized exchange AD site into multiple eexchange AD sites and only having one domain per AD site. I.E. (and this is way simplified) Initial configuration ===================== Site 1 Dom1 GC GC Dom2 GC GC Dom3 GC Exchange Server serves users of Dom1/2/3. Final Configuration =================== Site 1 Dom1 GC GC Exchange Server serves users of Dom1 -- Site 2 Dom2 GC GC Exchange Server serves users of Dom1 -- Site 3 Dom3 GC GC Exchange Server serves users of Dom1 This would mean that the chances were much greater that Exchange will give out a GC from the user's domain. Note the added overhead in machines though... 2 more exchange servers, 1 more GC. Do this with multiple centralized locations and scale it and think of how much work will need to be done with moving machines and reIPing them and buying all the additional hardward and you start to understand why we would prefer not to go that way. Another alternative solution would be to change our GC strategy from being centralized (where all the apps are) to putting GC's everywhere and punching up replication traffic to WAN sites considerably and the requirements for the capacity of all domain controllers and finding some way to force all outlook clients (ALL VERSIONS) to use the local GC. This still fails if a user is at a site that doesn't host their user account domain, say people bouncing around visiting other sites, people with machines that aren't part of the forest but are workgroup mode because they are off the network a lot, etc. Another alternative would be for the clients to be smarter about what they do. This is nice long term but impossible short term even if a solution were available tomorrow as it involves touching some 180,000 machines at least all at different OS levels and patch levels and client levels. Another alternative would be for the domain controllers to change how they work. When they get the call from an outlook client and if the call is misdirected, the domain controller redirect the call on the clients behalf. I think this is the WORST solution because DC's should be generic and you shouldn't have special functionality in them to support this one app from MS. Exchange and outlook should act like regular applications. Putting special things in like that just fuels the fire against using AD because it isn't standard/consistent/etc. No, this is an Exchange problem and needs to be solved within Exchange. Thoughts? joe List info : http://www.activedir.org/mail_list.htm List FAQ : http://www.activedir.org/list_faq.htm List archive: http://www.mail-archive.com/activedir%40mail.activedir.org/ List info : http://www.activedir.org/mail_list.htm List FAQ : http://www.activedir.org/list_faq.htm List archive: http://www.mail-archive.com/activedir%40mail.activedir.org/ List info : http://www.activedir.org/mail_list.htm List FAQ : http://www.activedir.org/list_faq.htm List archive: http://www.mail-archive.com/activedir%40mail.activedir.org/
