<quote from Joe> This actually also goes back to something I have been saying MS needed for a while. Domain Specific DNS entries for GC's as well as an additional call type from dsgetdc....</quote>
I was kinda thinking that too... clients are using DNS to find lots of other SRV info, seems a logical place to put this too. On the client update issue, MS should realize the only places this oversight is an issue are the huge enterprises where you don't just push a fix in a day - it needs to be easy, automated, and foolproof - not really MS attributes but they could outsource :) Rich -----Original Message----- From: Joe [mailto:[EMAIL PROTECTED] Sent: Saturday, November 15, 2003 9:40 PM To: [EMAIL PROTECTED] Subject: RE: [ActiveDir] Exchange 2000 and its interaction with AD - Yes a gain... > What you're referring to as an Exchange problem > could really be looked at as an Outlook/MAPI > problem if you want to split hairs. Exchange > runs fine, but the Outlook behavior has changed > over the versions. I know where you are coming from on this but would certainly try to argue it. Look at dsproxy. For pre-O2K clients it isn't any smarter than the o2k+ clients are on their own. Additionally, Exchange Dev knew (or should have known) these issues when building the product and were shooting for legacy compatability. The DSPROXY/DSACCESS components should be smarter in what GC's they hand out. Unfortunately like Todd indicated, I don't think they got much past a single domain in a single forest for their dev and testing work. Looking at it that way explains a lot of the issues. > It means some sort of metadirectory. It means > a lot of work typically. Yep but it would mean not touching and maintaining registry entries on hundreds of thousands of clients. I am a big one for solving issues in a centralized fashion. Much much cheaper and easier to control and do correctly and consistently. Recall my team is 3 members and a manager. There are other teams but anytime it comes back to AD for anything, at some point, one of us, usually me, will be pulled in to deal with inconsistencies or issues. I'm good, but maintaining hundreds of thousands of clients that are various OS revs and client revs and possibly in or out of the forest structure, etc is beyond me. Just another indicator of Exchange not being enterprise class yet in my opinion. I would rather deal with the issues with the couple of thousand password changes handled daily (that is a normal day with a normal expiration policy) by the systems than a single issue based on the fact that Exchange/Outlook isn't smart enough to make an attempted change in the right place. > How is Exchange going to understand your domain > membership or GC location based on the MAPI calls > given to it on startup? In a centralized deployment I think it is better for outlook clients to use the centralized GC's that the exchange servers are using, you get away from funky results due to replication latency and such. If you have a site configuration with a centralized exchange server and a GC locally that is set to replicate once per day, there is going to be a lot of confusion and issues with it. Even being 3+ hours out would be difficult. If you have a decentralized deployment then the same GC the exchange server is using is probably the same that the client is using anyway so no hoohoo there. I would expect the info in the mapi calls has at least the userid. That could be used to generate a GC lookup for the users info - oh wait that has to happen anyway to find their homemta/mdb/quota's and other items. Well that info returned will tell you what domain the user is in, the GC then looks at its list of GC's and says, hmmm probably best to give one in the same domain and picks it and does it. If there isn't one, it gives what it can. This actually also goes back to something I have been saying MS needed for a while. Domain Specific DNS entries for GC's as well as an additional call type from dsgetdc. You should be able to say, give me a GC that is a DC for domain X or ask for the _gc._tcp.site._sites.domain.forestroot.com records instead of just saying give me a GC or give me _gc._tcp.site._sites.forestroot.com records. This would be handy for many purposes especially for Applications doing updates (like outlook/exchange) or enumerating information that would be maintained by a GC of a specific domain but not a GC of another domain like group memberships. joe -----Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Mulnick, Al Sent: Wednesday, November 12, 2003 2:11 PM To: '[EMAIL PROTECTED]' Tony's on to something that has worked for many other Exchange deployments that ran into the read-only copy issue of the GC. What you're referring to as an Exchange problem could really be looked at as an Outlook/MAPI problem if you want to split hairs. Exchange runs fine, but the Outlook behavior has changed over the versions. This is one of the problems that has prompted people to try going back in time to the Exchange 5.5 model of having a dedicated directory: a la a dedicated forest for this type of deployment. What's that mean to you? It means your downlevel clients may notice. It means more overhead since you no longer have a single centralized directory. It means some sort of metadirectory. It means a lot of work typically. History: that issue has come up many times in the past and the real solution belongs on the Outlook side IMHO. Why? How is Exchange going to understand your domain membership or GC location based on the MAPI calls given to it on startup? What about the clients that are not GC-Aware? Will they break if you make changes to the MAPI responses the Exchange server gives? At some point you'll have to rewrite Outlook to make anything work, so I wouldn't expect Microsoft to be able to rewrite Exchange to hand out a solution like you're looking for. But you are in good company asking for that I expect ;) One workaround that's been had is to do like Tony said and push registry hacks to clients that are GC-aware. Upgrading the clients to at least post SP2 for Outlook 2000 is helpful here if they're going to be part of the GC-aware crowd. I'm sure other things can be done depending on your own situation, but that's one idea based on the information given. My $0.02 anyway. Al -----Original Message----- From: Myrick, Todd (NIH/CIT) [mailto:[EMAIL PROTECTED] Sent: Wednesday, November 12, 2003 1:50 PM To: '[EMAIL PROTECTED]' Subject: RE: [ActiveDir] Exchange 2000 and its interaction with AD - Yes a gain... 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/ 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/ -------APPLEBEE'S INTERNATIONAL, INC. CONFIDENTIALITY NOTICE------- PRIVILEGED / CONFIDENTIAL INFORMATION may be contained in this message or any attachments. This information is strictly confidential and may be subject to attorney-client privilege. This message is intended only for the use of the named addressee. If you are not the intended recipient of this message, unauthorized forwarding, printing, copying, distribution, or using such information is strictly prohibited and may be unlawful. If you have received this in error, you should kindly notify the sender by reply e-mail and immediately destroy this message. Unauthorized interception of this e-mail is a violation of federal criminal law. Applebee's International, Inc. reserves the right to monitor and review the content of all messages sent to and from this e-mail address. Messages sent to or from this e-mail address may be stored on the Applebee's International, Inc. e-mail system. 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/
