RE: [ActiveDir] Extremely weird issue

[Eric Fleischman]

Title: Kerberos question

You might have done it, but you didn’t share it with us. :) Can’t help if you don’t share the data. Sorry.   ~Eric     From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Alex Etin Sent: Friday, August 06, 2004 7:08 PM To: [EMAIL PROTECTED] Subject: RE: [ActiveDir] Extremely weird issue   Already done that…. Like I said there are some things there that are of interest, specifically the MACHINEPOLICYCALLBACK flag…. But so far, even MS internal doesn’t have a clue….we are waiting for CRITTEAM to take a look   From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Eric Fleischman Sent: Friday, August 06, 2004 7:31 PM To: [EMAIL PROTECTED] Subject: RE: [ActiveDir] Extremely weird issue   Hi Alex,   There isn’t much data in this thread so I don’t really know what the problem is I’m afraid. Of interest (bare minimum): 1)       userenv log after UserEnvDebugLevel set to 10002 2)       winlogon log after increased winlogon logging was enabled 3)       network trace of the boot sequence Lining up all three of these (IE doing them simultaneously) would be of interest so a picture of what the box is doing could be understood.   You could also (optionally) dump the box during one such instance and put the dump in a location those of us that could analyze it could access to see what it is doing during the “stuck” space. If you do this please do it in a separate boot than the boot where you collect items 1-3 above. Else you interrupt that data collection as it is not as interesting of a data set.   Anecdotally, I’ll say network-level issues are suspect here as it is a common root cause to this problem (name resolution being the most common of them I’d think). But I couldn’t say for sure if that is your problem or not w/o some data.   ~Eric     From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Alex Etin Sent: Friday, August 06, 2004 6:12 PM To: [EMAIL PROTECTED] Subject: RE: [ActiveDir] Extremely weird issue   No, dns is funcitonal. This is definitely beyond the traditional stuff…. Actually this situation has just been raised to Level A at Microsoft the so called CRITSIT team…. Hope they figure it out…. :(   But to answer your question, the AD environment is working perfectly, there are no dns issues, no dns islanding, i.e. everything is top notch in AD itself. All policies apply properly. Its just that Delay on the custom build workstation….. but policies still apply properly. App log and sys log are all correct, no errors.   From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of David Houston Sent: Friday, August 06, 2004 6:39 PM To: [EMAIL PROTECTED] Subject: Re: [ActiveDir] Extremely weird issue   A quick question for you. How large is the domain? are we talking about a few users with static ip addresses? Is Dhcp enabled? Is tere more than 1 dc at the site? Is there more than one dns server? What is going through my head is that there  might be a corruption in the dns server database or in the dns settings themselves. I have seen a similar situation occur when the dns primary server is set to a something other than a windows dns server. Its just a thought   Dave ----- Original Message ----- From: Alex Etin To: [EMAIL PROTECTED] Sent: Thursday, August 05, 2004 10:45 PM Subject: [ActiveDir] Extremely weird issue   I have encountered a very weird issue at this client.       The situation is as follows (i will do my best to try not to confuse    anyone).       Client has an AD domain. AD domain is 2003 based. Forest level: 2003    native. Domain level - 2003 native.       There is a few policies that are being applied. Some of them are applied    at the domain level, and some are applied at an OU level.       Being tested are 2 workstations. One of them has a clean build of Windows    2000 Pro, service pack 4. The other one, is also W2K Pr0 SP4, but it is a    custom client image. This image does not have any special application, but    it does have a few registry patches/entries applied to it, although from    what i have seen, its not distructive.       Here is the problem:       When the both machines, in the same OU start up, the client image    machine "gets stuck" during applicaiton of one of the domain wide policies    (before logon screen even appears, so it is computer policy that is being    processed). It will sit on this "stuck" stage, while "Processing Policy A"    is displayed. After 1.5 - 2 minutes the logon screen appears and all is    well. The clean build machine starts up with no delay. Now here is the    interesting bit: IF i unlink domain policy A, then the machine simply gets    stuck on policy B. If i unlink B and A, it will stuck on policy C. If i    Unlink A,B and C, it will get stuck on policy D (which applies at OU    level). None of these policies are complex, in fact A B and C only have 2-    3 entires in them. Plus, the clean build machine has no delays. Another    note - while in "stuck" stage, the HDD of the machine goes like crazy!       I have turned on UserEnvLogging, and i have a Severity B ticket open with    Microsoft, in fact i am on the phone with them now (have been for about 4    hours).       I have USERENV.LOG dumps if anyone is interested, i even found something    of interest there and i have pointed it out to MS support guy as well. So    far, nothing. The client needs this resolved asap, we need to find what in    the build is causing this problem. Redesigning the image is not an option    as client spend years developing it.       If anyone has seen anything like this, i would greatly greatly appreciate    your help!