Hey all, I am getting the following error:
Event Type: Error Event Source: Userenv Event Category: None Event ID: 1000 Description: The Group Policy client-side extension Security was passed flags (17) and returned a failure status code of (3). Microsoft (Via Q article # 259398) Says... _____________________________________________________________________________________________________________ CAUSE The \\Active Directory Domain Name\Sysvol share is a special share that requires the distributed file system (DFS) client to make a connection, and a valid Domain name record in DNS. If the DFS client is disabled, the domain records are missing, or the DNS records are not being registered properly, the error messages are generated. RESOLUTION WARNING: If you use Registry Editor incorrectly, you may cause serious problems that may require you to reinstall your operating system. Microsoft cannot guarantee that you can solve problems that result from using Registry Editor incorrectly. Use Registry Editor at your own risk. Check the following registry value: HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Mup DisableDFS: REG_DWORD: range: 0 or 1 0 = enabled; 1 = disabled Default: 0 Make sure that the value is set to 0, enabling the Dfs client. Also, File and Printer Sharing for Microsoft Networks must be enabled on the interface. _____________________________________________________________________________________________________________ I went to my registry, and I do not have the "DisableDFS" entry. Do I need to add this? or... What? John Parker, MCSE IS Admin. Senior Technical Specialist Alpha Display Systems. Alpha Video 7711 Computer Ave. Edina, MN. 55435 952-896-9898 Local 800-388-0008 Watts 952-896-9899 Fax 612-804-8769 Cell 952-841-3327 Direct [EMAIL PROTECTED] "Be excellent to each other" ---End of Line--- -----Original Message----- From: Joe [mailto:[EMAIL PROTECTED] Sent: Sunday, December 07, 2003 11:16 AM To: [EMAIL PROTECTED] Subject: SPAM: RE: [ActiveDir] Exchange 2000 and its interaction with AD - Yes a gain... LOL. You sound like the MS folks. :op These project is in its third year (on again off again though), about 15 months into actual work. I was lightly involved about a year ago and got heavily involved back in around April or so. I think they all realized that AD was important, but probably not to the extent that it was. A lot of it comes down to not really knowing the product and I will point at both MCS and PSS in that regard. They tend to know the generic deployments and the pat answers. That doesn't work once you get to certain levels of complexity and size. It is like a paper MCSE going into a small site, they will be fine; a bigger site and they are an idiot. I actually think we have one of the better MCS consultants already here for E2K. Though I think he knows about 4 times more now than he knew when he walked in the door. He will admit to knowing probably twice as much. :op I think that is my biggest gripe with MS people is the lack of willingness to simply say, you know what, I don't know. Instead they will say something like that is god's word on it and then later it comes about that they thought it worked that way but in reality it doesn't. I think I have seen instances of that all the way up the MS chain but I haven't ever directly spoken with an Exchange Dev guy so maybe they know what is up and everyone else is losing the stuff in the translation. As a rule they won't let me near the Dev guys. I think it is because I ask too many difficult questions usually starting with "why in the world...". On our side the issue is that this project stopped and started multiple times and management changed a couple of times and hardware vendors changed and storage changed, etc. Lots of crap, however I still blame MS for the bad design we have and the bad supportability review they did of the design. This delegate issue never should have seen the light of day but it goes back to my statement about them not really understanding how the product works. Public Folder shouldn't be an issue as we don't really allow their use. Occasionally someone will get something out there when a new server comes online and the ACL's get changed but that gets caught and they get killed. Pretty much we use Exchange for mail and calendar. None of the other stuff fancy stuff. If there was a decent calendar app outside of Exchange that integrated well with Mail that wouldn't have caused us massive migration headaches and custom writing of tons of code we would have probably went to it. RUS has been doing ok but then we really dumbed it down from what I understand. The email address stamping is all handled by our internal provisioning system. ADC has been a bit painful and in fact right now our European ADC just stops working every now and then with no error messages or nothing. Just stops. I am now embroiled in debate with PSS concerning the DSACCESS/DSPROXY/Categorizer document as I started reading it and found typoes and issues in it and things that I flat out don't think are correct. MS has done what they usually do which is to get to a point where the analysts is flying blind and wants to take things into a conference call. My personal feeling on that is so that it gets lost and dropped because the info isn't as well documented. The document did nothing to lull me into confidence of what was going on with us and in fact now has me concerned about the categorizer and what might possibly be breaking in that as it has verbage similar to the verbage for DSPROXY and I really think DSPROXY has issues with its DC scrubbing that it is supposedly doing. Outside of all the design issues we have with our specific implementation I am really concerned about the overall supportability of a large Exchange deployment. The tool set completely sucks that MS supplies and the documentation for writing your own tools is poor and inaccurate at best. I do not see how any large implementation of Exchange could exist without a veritable sea of admins managing it through the GUI. Mailbox reconnects alone are a pain in the complete butt and that is just one aspect. Oh well, I will be dead or I will get it figured out. One or the other will be fine at this point. joe -----Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Mulnick, Al Sent: Monday, December 01, 2003 9:57 AM To: '[EMAIL PROTECTED]' Subject: RE: [ActiveDir] Exchange 2000 and its interaction with AD - Yes a gain... Interesting Joe. You make some good points and I feel for your situation; It's not where I'd like to be if I was in a deployment situation like yours. If I was a Microsoft Consultant (and I'm not for the record) I may not have the highest regard for somebody like a Ranger that comes in, takes over the project and takes responsibility for the design and architecture especially if it was my project. However, as a customer, I would probably have to think twice about having an extension to the design team come aboard, if I was part of a project that didn't think Active Directory was an important bit for Exchange until well after kick off. But that's just me I guess. :) An Exchange Ranger doesn't go into situation ahead of problems every time, but when they do it can be a lot better experience. If they go in late, you can figure that they'll at least manage to succeed where others have so far failed. It's what they do. I'll leave that alone since it's really none of my business anyway (I just hate for people to have such a bad experience when it would be easier to properly set expectations up front and mitigate the risks prior to letting them hit the customer in the face; we all manage projects differently I'd guess). I don't have any specifics of what you'll face next as I'm not familiar enough with your environment. However, because of the information shared so far, it's likely that you have other issues not thought up yet. The lack of expectation setting leads me to believe that you'll be in for surprises when it comes to things like performance (OWA comes to mind), Public Folders, RUS, etc. Hopefully it's a bad guess. Good luck Joe. Hope it works out well. Al -----Original Message----- From: Joe [mailto:[EMAIL PROTECTED] Sent: Tuesday, November 25, 2003 11:02 PM To: [EMAIL PROTECTED] Subject: RE: [ActiveDir] Exchange 2000 and its interaction with AD - Yes a gain... Sorry for the delay on responding to this. > Exchange Rangers We actually have some MS people onsite who don't have the highest opinion of the rangers. Could be the ones they have dealt with but overall I haven't found many people at MS period that seem to able to talk about Exchange. I haven't met anyone that I knew was a ranger, so I can't directly comment other than what I have said as a general rule that I have found. I agree on the hardcoding the servers. The current direction is that MS is again relooking at the modifications needed. It was turned down and then we had some escalations go up the MS chain and they are again checking it out. In the meanwhile they have sent us a web dev guy to put together a temp solution which is a web page that will handle setting the delegation stuff for users. Personally I think that is going to not work well. Plus it doesn't address any other possible issues that are present with this bad software design. >Pre-O2K clients don't need it, so you don't have all of your clients >to worry about. The Exchange server will handle those. So have you tested whether or not the Exchange Server does this correctly through DSPROXY. I would expect it doesn't. If they had thought to do it right for that piece of DSPROXY, I think they would have done it right for the other part of DSPROXY handing out the GCs in the first place. >Having a mail client I agree with your statements in this area. If I was working the outlook client project, my angle would have been plugin protocol modules. I.E. If I am talking to E2K I talk through this certain module and it works this way, I'm talking to 5.5 I use this other module. If you don't need one or the other, you can disable it. I think overall that would be a great way for MS to go, allow for legacy stuff but in a way that can be disabled so it doesn't hold you back or harm you. Take the whole samaccountname scenario. You can have huge security principal names in AD, except for the samname... Should be able to say, we are now out of sam compatability mode. Have a nice day. > you've got other issues that will start to surface Hints please? joe -----Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Mulnick, Al Sent: Monday, November 17, 2003 10:11 AM To: '[EMAIL PROTECTED]' The part about them not seeing the issues is a problem that I think is being addressed at some levels (see note about Exchange Rangers and what they should do for you in previous emails). The hardcoding of servers is the one that is likely going to pay back the way you want. It gives predictability and it means you have a particular set of servers that will do the work. DSACCESS is a process that works for most people. Then again, most people don't have an environment as large or as complex as yours. Nor do they have the issues you face. They can afford to listen to the recommendation to leave it to do it's own job and be happy with that. You may not have that luxury. Also, many people with 180K+clients don't have the bandwidth to have a totally centralized mail deployment. They have to decentralize for technical and political reasons on a regular basis. That's slowly changing, but many companies still do it that way. Centrally fixing the problem is much more of a solution than Outlook hacks, but the Outlook hacks are one way of doing it. Pre-O2K clients don't need it, so you don't have all of your clients to worry about. The Exchange server will handle those. I think part of the problem you are seeing is still related to expecatations and dealing with someone who has done this on this scale. MCS has plenty of people that have done this large scale and some of the issues you run across are already known by them. Some aren't but that's because every org is different right? Back to the other email you had written about this: If some of the users are not in a domain, how is Outlook supposed to figure out the closest GC? Or are you just referring to the way that Exchange finds the GC for it's own use? There's a lot of favorable attention being given to the concept of a 5.5-like deployment of Exchange where the servers and the GC's are in the same centralized site. The 5.5-likeness is that you have one router hop to get to the data and the directory again while still getting the benefits of higher mailbox density servers that weren't possible in 5.5 due to the operating overhead of a directory and a single database. Client hardcoding isn't a really good option for everyone. Like I said, it is one option. Pre-loading the GC's is another option. There are still others, but not knowing the environment and such, it's better left to the consultants you work with right? One other thing to consider: Part of the issue is Microsoft's attempt to be all things to all people. Having a client that can work well with your latest mail server and directory product is a big deal. Having a mail client that also works with down-level mail servers (so peopl aren't forced to buy the mail server so they can use the latest office suite) is a good idea in my opinion. To do that, you have to make some decisions such as will I use the same method as the older clients to find the mail store? The older mail clients asked the server, because that's where the data was. MAPI is designed to do this. So if I'm designing the mail client specs, I'm thinking future and past at the same time. I'm thinking it's likely that my client will come out prior to the new mail server and since we earn more money we must be more important. (something like that I suppose). Reality is that as a customer I expect both to work properly. You've found the gap in what is happening and the difficulty in bringing legacy protocols and applications to the light of day. They have to ask the server what to do for legacy reasons. What the server gives back is questionable as you've pointed out, but there is a way to pre-load the responses for at least some modicum of predictability. Had you known up front, it may have been an easier pill to swollow. "Microsoft" has known about it for some time. Your consultants may not have, but that's different than saying all of Microsoft isn't it? FWIW Joe, you've got other issues that will start to surface as well that you may not have reached yet. Some of them are handled better in Exchange 2003 vs. Exchange 2000. Others you should be aware of prior to completion of deployment. Al -----Original Message----- From: Joe [mailto:[EMAIL PROTECTED] Sent: Saturday, November 15, 2003 10:15 PM To: [EMAIL PROTECTED] Subject: RE: [ActiveDir] Exchange 2000 and its interaction with AD - Yes again... > 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/ 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/
