> as a kludge... Yep. We know about this one. However it only works for certain revs of outlook. Try that trick on Outlook 2003 and watch it change what you put in as soon as it starts up. From what I understand you can change it while outlook is running though and it will "take". However that is fun to manage. Go to pre-O2K and everything is done through DSPROXY, no reg entries will help.
Actually the whole thing is fun to manage when you are talking about 180,000 clients involved with many that aren't part of domain structures, at different OS levels (Win9x -> XP) and OS/2 and UNIX users not using Outlook, but instead OWA which means the exchange servers themselves need to know to go to the right place. Exchange Dev has come back and said that the changes needed will be too complicated for now but will look at some unknown future product. They had two basic solutions which I already saw, first was to try and manage hard coding all of the clients on the fly in some dynamic and fault tolerant way. Cough cough hack ha ha ha ha. The other was to redesign the site layout as indicated below which will cost a great deal of money and time and bring our migration to a halt yet again. I didn't like the answers so have escalated within MS to a higher level. The client hardcoding truly isn't feasible both because of the wide range of client os's and client rev levels but also because the script or whatever would have to be pretty damn intelligent to do the work as it would have to handle fault tolerance and dynamic resource location, etc. All of the stuff all ready built in. Plus if you went into failover, you blew the whole thing anyway because the client will ask the exchange server what it thinks and it will pick some random GC again so not only do you create a huge maintenance nightmare, you can't fix the issue in any consistent way. The real solutions are to correct the site layout or correct the application. The real correct way is to fix the app in my book. The site layout will be a pain, though I have come up with another thought that may work, that is to hard code what GC's an exchange server uses by the dsaccess reg hacks to ready pick the GC's and bypass the dynamic lookups. This is another maintenance headache but better than doing it on a couple hundred thousand clients. It also still requires some extra hardware but not as much. What really gets me is that MS was right in bed with us the whole time this design was worked up and involved with every decision involving this design and implementation, heck they have been so closely involved they have been combing through our directory looking for garbage right next to us. We can't turn around without running into MCS or PSS and they never saw this coming. It is also why I think MS really needs to try hard to work this one out on their end. It isn't just non-MS people implementing and screwing up Exchange 2000 deployments. That indicates several things. At least to me... joe -----Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Tony Murray Sent: Wednesday, November 12, 2003 10:26 AM To: [EMAIL PROTECTED] 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/
