Group Ploicy not deploying for an OU

make sure the computer is moved to the relevant container in AD - also, you should go to the command prompt and type gpupdate /force

There is a time of 60 minutes before a policy is refreshed.
In a  command promt on the client machine launch

"gpupdate /force"

to manually refresh policies.

For implementation, remove

 "In Security filtering I have added the user Bwyd Ci."

you may also need to install Group Policy Client Side Extensions

http://www.microsoft.com/downloads/details.aspx?displaylang=en&FamilyID=e60b5c8f-d7dc-4b27-a261-247ce3f6c4f8

XML Lite is also a requirement for the extesion

http://www.microsoft.com/downloads/details.aspx?familyid=D7B5DC81-AD14-4DE2-8AD5-8C4A9AAB5992&displaylang=en

Here's the vista version of the client side extensions

http://www.microsoft.com/downloads/details.aspx?familyid=AB60DC87-884C-46D5-82CD-F3C299DAC7CC&displaylang=en

Giving administrator rights because they need to do *some* things that need admin rights is not the way to do things.  You give admin access to administrators.  If the user needs to be limited in any way, they should not be an admin.  You can give the user the specific rights that it will need through GP, without giving it admin access.

slinkygn, not all GPOs are available, we've had to provide our entire company with admin rights because GPO couldn't do certain things we needed.

Have you linked the GPO to the Teledu OU?

The Group Policy Objects folder shows all GPO's for the Domain, not what they are linked too.

Also run RSOP via the MMC from the DC in planning mode and specify the user and computer and it will show you what will be applied.

Oh and I doubt VERY much that the user would require local admin rights over that machine. Nearly all policy settings are not implemented using the logged on users account. I've implemented a huge amount of settings in my time, and never once had to grant the affected users admin rights over a PC to achieve it.

I just wanted to specify that as you stated that you're new to GPO, and I don't want you to come away from this thinking it's standard to give users admin rights when trying to implement GPO settings for them! :)

Pete

And one final comment @Stoner79 - His screenshot does show the link, but you're probably looking for for the physical icon within the Teledu OU on the tree - Look on the right hand side, you will see a list of where the selected GPO is linked. :)

Pete

Yep, good spot Pete :)

Ignore my top two paragraphs on my previous post ;)

I'm not being picky or anything, it's just as the asker is new to this, I want to ensure that he/she gets an accurate measure of policies etc from this thread...

:)

Hi, thanks for your input.

I have now added my workstation account (it came up as TELEDU$) to the Security Filtering bit of "Polisi Teledu".

I tried a "gpupdate /force" in the command line.  Is said that the policy updated successfully.  I then rebooted, but still no luck.

Below is the output of doing "gpresult"

Perhaps I should clarify my situation with admin rights issue.  I want admin rights for users, because there are only a few specific things that I want to stop the user from being able to do, rather than making it a restrictred user and then adding permissions onto that.

By the way, in GPM, when I right-click on "Polisi Teledu" (the link that resides in the Teledu OU, not the actual policy in Group Policy Objects) above "Link Enabled" is an option called "Enforced".  What does this do?  I have tried ticking this (and doing gpupdate /force) but with no luck.

Can you guys suggest something else for me to try?

thanks

Microsoft Windows XP [Version 5.1.2600]
(C) Copyright 1985-2001 Microsoft Corp.
 
C:\Documents and Settings\Bwyd Ci>gpresult
 
Microsoft (R) Windows (R) XP Operating System Group Policy Result tool v2.0
Copyright (C) Microsoft Corp. 1981-2001
 
Created On 15/05/2009 at 17:26:17
 
 
RSOP results for GELLIOER\Bwyd Ci on TELEDU : Logging Mode
-----------------------------------------------------------
 
OS Type:                     Microsoft Windows XP Professional
OS Configuration:            Member Workstation
OS Version:                  5.1.2600
Domain Name:                 GELLIOER
Domain Type:                 Windows 2000
Site Name:                   Default-First-Site
Roaming Profile:
Local Profile:               C:\Documents and Settings\Bwyd Ci
Connected over a slow link?: No
 
 
COMPUTER SETTINGS
------------------
 
    Last time Group Policy was applied: 15/05/2009 at 17:24:29
    Group Policy was applied from:      gweinydd.gellioer.lleol
    Group Policy slow link threshold:   500 kbps
 
    Applied Group Policy Objects
    -----------------------------
        Default Domain Policy
 
    The following GPOs were not applied because they were filtered out
    -------------------------------------------------------------------
        Local Group Policy
            Filtering:  Not Applied (Empty)
 
    The computer is a part of the following security groups:
    --------------------------------------------------------
        BUILTIN\Administrators
        Everyone
        BUILTIN\Users
        NT AUTHORITY\NETWORK
        NT AUTHORITY\Authenticated Users
        TELEDU$
        Domain Computers
 
 
USER SETTINGS
--------------
 
    Last time Group Policy was applied: 15/05/2009 at 17:24:44
    Group Policy was applied from:      N/A
    Group Policy slow link threshold:   500 kbps
 
    Applied Group Policy Objects
    -----------------------------
        Default Domain Policy
 
    The following GPOs were not applied because they were filtered out
    -------------------------------------------------------------------
        Local Group Policy
            Filtering:  Not Applied (Empty)
 
    The user is a part of the following security groups:
    ----------------------------------------------------
        Domain Users
        Everyone
        BUILTIN\Users
        NT AUTHORITY\INTERACTIVE
        NT AUTHORITY\Authenticated Users
        LOCAL
 
C:\Documents and Settings\Bwyd Ci>

Select allOpen in new window

Looks fine, I think you may need to install the Group Policy Client Side Extensions on the client machine.

I'm failing to see how the gpresult output is ok?? It clearly states that the only policy applying to either the user or the computer is the default domain policy, and the new policy created is called "Polisi Teledu".

It's not even being filtered out, it just isn't there, which I find strange as the policy is clearly linked to the correct OU containing both objects.

In answer to your separate question, an 'enforced' policy will basically push it's way through to EVERY child object that can apply it, regardless of any nested OUs (OUs within it in the hierarchy) having 'Block inheritance' etc.

Anyway, something is definitely not right there, as neither the user object or comp object are even attempting to apply this new policy... To clarify for you, if you run that command again, you SHOULD see the "Polisi Teledu" listed just beneath 'Default Domain Policy' in 'Applied Group Policy Objects' under both the user config and comp config.

I would check this again before continuing, in case it's now there after all this time. Let me know if it's still not listed when you next check and we'll take it from there...

Pete

I think what Zoooink meant was that group policies are propagating from the server properly.  Obviously the policy created is not applying to the workstation/user -- if it was, there wouldn't be a problem, would there?

So you did a gpresult, and now know what policies the client is saying applies to it.  Next step is probably to pull an RSOP (Logging) from the server for the user and computer objects.  Post the results here, and we can all compare the two and see what it looks like.

On a side note, I've had clients run into the problem of accidentally having made two different user accounts with the same long name but different short names, and applying things to the wrong one accidentally.  Might want to make sure you don't have any more users with the same long name anywhere else in the directory.  Can't hurt to check.

Gpresult output is clear: there is no "polisi teledu" policy applied to the machine.

So there are some additional info that can be helpful.

1) gweinydd.gellioer.lleol is the server onto you have created and applied the GPO ?
2) how many domain controllers are in place for the domain gellioer.lleol ?
3) ping the server gweinydd.gellioer.lleol from the client machine and post the result
4) ping the client machine from the server and post the result.

I have rebooted the DC and the client between every step that I've tried.

When I go to AD and attempt to do a RSoP on TELEDU (logging), I get an access denied message, although I am attempting this whilst logged on to the DC with a domain admin account.

So, does this mean that domain admins are not local admins on workstations, so in this case the domain admin is not an administrator locally for the teledu workstation?

How do I change this in AD or GPMC?


I then tried the planning mode, and it carried it out OK.  But looking through it doesn't look it's taken any of the settings from Polisi Teledu.  Also it doesn't contain any of the ADM files that I've imported into GPMC - the adm for WinXP and Win2003.


As for GRMC I have taken both computer and user out of the Security Filtering section, and refreshed accordingly, but still the same.


slinkyqn

I have checked my users and their long names do not conflict.  Thanks


Point-In-Cyberspace...

1) Yes
2) 1
3) Ping OK
4) Ping OK


Thanks all.

Try to link the GPO "polisi teledu" to the domain GELLIOER and restart the client computer.
Now, with gpresult check if the policy is applied or not. Maybe there is a trouble with the GPO linked to the OU.

Ok, 1 question at a time:

By default members of a domain should have domain admins added to their local admin group - You can check just by looking at the membership of the local admin group, to see if the domain admin group is a member.

If you've imported any custom adm templates, just check that uncheck the options in filtering (right-click admin templates under comp and user config) for "Only show configured policy settings" and "Only show policy settings that can be fully managed".

As for the RSOP, I don't believe this requires admin priviledges on the local machines themselves - I believe it just gathers information based around the object in question, and the GPOs etc that apply to that object (in greater detail than this, but I'm speaking generally).

A domain admin account should have the permissions to run this for any objects within it's domain, so again I'm lost as to why you're getting the access denied error. It may be worth checking the permissions on the OU itself, as I recollect seeing a specific permission for being able to run RSOP... But it's late and my brain isn't working, so I'll check back tomorrow morning with a fresh head!

Pete

Access denied?

Domain admins are local admins.  They get added to the local administrators group when you join the domain.

Pull Teledu out of the domain (put it in its own workgroup for now).  Then look through your AD tree for any phantom Teledu computer accounts, and delete them.  Then run dcdiag /fix on your domain controller, looking for any failures -- if you see any, run it again, and if you still keep seeing them, run a dcdiag /v and post it here.

If dcdiag comes out clean, add your workstation back to your domain and place it back in its OU.

Right, here's an interesting twist...

First of all I must apologise that I didn't think of this earlier.  Said laptop, TELEDU, is newly installed.  Before that there was an older laptop there, also called TELEDU.  The user, Bwyd Ci, was also logging in to this.  Since then, unknown to me, the laptop was still being used occasionally just to go on the internet.

I checked the state of the settings on this laptop and lo and behold, the policy was running on it!

I have now fully decomissioned the old 'TELEDU', taken it off the domain, returned IP to dynamic, and changed PC name.

I have then taken the current TELEDU off the domain, rebooted, then added it back on, but the policy still wasn't being applied to the current TELEDU.

Is there a way to flush any traces of the old computer from the domain?

I then experimented with different users and PCs.  I have created an identical user called Tew and placed this also in the Teledu OU.  Logging in as Tew to TELEDU still doesn't apply the policy.

I then placed another PC in the OU and rebooted it.  I then tried logging in as both Bwyd Ci and Tew to that PC, but the policy was still not applied.

As suggested by Point-In-Cyberspace, I linked Polisi Teledu to the whole gellioer domain, then rebooted, but still didn't apply the policy.

Many thanks for your continued cooperation.

HeHe, not far off what slinkygn was saying earlier! :) It's ok, it's all part of the learning process!

Still when I first started reading that post, I had high hopes by the end it would all make sense to me. However that's still a little odd! E.g. you should not have been able to have 2 PCs called Teledu both using the same computer object in AD, yet you only refer to having one comp object? There must've been 2 objects, 1 for each physical PC, and the object names must've been unique? So that bit doesn't make much sense to me either!

What sort of time scale did you have for all of the above? Did you do it all within a short period of time? You MAY find that simply waiting a while will suffice...

However, assuming that's not the case - Can you confirm that when you say 'Still not applying', you're actually checking gpresult rather than just seeing if the settings you're trying to implement are taking affect or not? And if you are, is the policy still simply not listed within gpresult AT ALL, or is it shown in the list but showing as 'Not applied'?

There's a big difference between a policy being recognised as linked but not applying, and it being not recognised as linked at all... So just want to clarify that first! :)

Pete

Yes, it sure is.  :-)  I've seen that a whole lot.  It's a pretty common problem.

Yes, there is a way to flush the old computer out of the domain.  Simply follow the steps I presented in my last post.

Pull the current computer out of the domain.  When you do, you'll see that the Teledu computer account is still listed in your domain.  Delete it (look for any and all instances of that name, just to be sure).  Then rejoin the new computer to the domain.  It is a good idea to run dcdiag before you re-join, just to be on the safe side.

Thanks.

Here's what I've done.  I took (current) TELEDU off the domain and onto its own workgroup.  I then deleted its workstation account in AD.

I searched through every branch of my AD and there were no other instances of pc name TELEDU.

I ran "dcdiag /v" - see below for output.

I then waited over an hour before rejoining TELEDU to the domain.


I then did gpresult on the following scenarios:

Tew logged onto LAPTOPGWYN (the other laptop that I was testing on yesterday)
Bwyd Ci logged onto LAPTOPGWYN
Bwyd Ci logged onto TELEDU
and
Tew logged onto TELEDU

There was no mention of Polisi Teledu in the gpresult output in any of the four.  In fact, Tew logged onto TELEDU gave a gpresult of "The policy object does not exist" and only that.  I have tried rebooting.

I then redid the above but rejoined the domain with a different PC name altogether (remembering to delete the old workstation account in between.

Still no mention of Polisi Teledu in gpresult.

What a nightmare!  :(

P.S.  Tha account Bwyd Ci and Tew no longer have local admin rights on the workstations (since a couple of days ago), just to let you know that I've taken onboard your advice on the matter.

P.P.S.  By the way, when I rejoin the domain and log onto it for the first time, at the logon screen I get "Please wait while the domain list is created" for what feels like a two or three minutes, although there are only two, the local domain and gellioer, and the laptop is a recent clean install on windows.

C:\Documents and Settings\Gweinyddwr>dcdiag /v
 
Domain Controller Diagnosis
 
Performing initial setup:
   * Verifying that the local machine gweinydd, is a DC.
   * Connecting to directory service on server gweinydd.
   * Collecting site info.
   * Identifying all servers.
   * Identifying all NC cross-refs.
   * Found 1 DC(s). Testing 1 of them.
   Done gathering initial info.
 
Doing initial required tests
 
   Testing server: Default-First-Site\GWEINYDD
      Starting test: Connectivity
         * Active Directory LDAP Services Check
         * Active Directory RPC Services Check
         ......................... GWEINYDD passed test Connectivity
 
Doing primary tests
 
   Testing server: Default-First-Site\GWEINYDD
      Starting test: Replications
         * Replications Check
         * Replication Latency Check
         * Replication Site Latency Check
         ......................... GWEINYDD passed test Replications
      Test omitted by user request: Topology
      Test omitted by user request: CutoffServers
      Starting test: NCSecDesc
         * Security Permissions check for all NC's on DC GWEINYDD.
         * Security Permissions Check for
           DC=ForestDnsZones,DC=gellioer,DC=lleol
            (NDNC,Version 2)
         * Security Permissions Check for
           DC=DomainDnsZones,DC=gellioer,DC=lleol
            (NDNC,Version 2)
         * Security Permissions Check for
           CN=Schema,CN=Configuration,DC=gellioer,DC=lleol
            (Schema,Version 2)
         * Security Permissions Check for
           CN=Configuration,DC=gellioer,DC=lleol
            (Configuration,Version 2)
         * Security Permissions Check for
           DC=gellioer,DC=lleol
            (Domain,Version 2)
         ......................... GWEINYDD passed test NCSecDesc
      Starting test: NetLogons
         * Network Logons Privileges Check
         Verified share \\GWEINYDD\netlogon
         Verified share \\GWEINYDD\sysvol
         ......................... GWEINYDD passed test NetLogons
      Starting test: Advertising
         The DC GWEINYDD is advertising itself as a DC and having a DS.
         The DC GWEINYDD is advertising as an LDAP server
         The DC GWEINYDD is advertising as having a writeable directory
         The DC GWEINYDD is advertising as a Key Distribution Center
         The DC GWEINYDD is advertising as a time server
         The DS GWEINYDD is advertising as a GC.
         ......................... GWEINYDD passed test Advertising
      Starting test: KnowsOfRoleHolders
         Role Schema Owner = CN=NTDS Settings,CN=GWEINYDD,CN=Servers,CN=Default-
First-Site,CN=Sites,CN=Configuration,DC=gellioer,DC=lleol
         Role Domain Owner = CN=NTDS Settings,CN=GWEINYDD,CN=Servers,CN=Default-
First-Site,CN=Sites,CN=Configuration,DC=gellioer,DC=lleol
         Role PDC Owner = CN=NTDS Settings,CN=GWEINYDD,CN=Servers,CN=Default-Fir
st-Site,CN=Sites,CN=Configuration,DC=gellioer,DC=lleol
         Role Rid Owner = CN=NTDS Settings,CN=GWEINYDD,CN=Servers,CN=Default-Fir
st-Site,CN=Sites,CN=Configuration,DC=gellioer,DC=lleol
         Role Infrastructure Update Owner = CN=NTDS Settings,CN=GWEINYDD,CN=Serv
ers,CN=Default-First-Site,CN=Sites,CN=Configuration,DC=gellioer,DC=lleol
         ......................... GWEINYDD passed test KnowsOfRoleHolders
      Starting test: RidManager
         * Available RID Pool for the Domain is 1605 to 1073741823
         * gweinydd.gellioer.lleol is the RID Master
         * DsBind with RID Master was successful
         * rIDAllocationPool is 1105 to 1604
         * rIDPreviousAllocationPool is 1105 to 1604
         * rIDNextRID: 1139
         ......................... GWEINYDD passed test RidManager
      Starting test: MachineAccount
         Checking machine account for DC GWEINYDD on DC GWEINYDD.
         * SPN found :LDAP/gweinydd.gellioer.lleol/gellioer.lleol
         * SPN found :LDAP/gweinydd.gellioer.lleol
         * SPN found :LDAP/GWEINYDD
         * SPN found :LDAP/gweinydd.gellioer.lleol/GELLIOER
         * SPN found :LDAP/8951b42d-78a0-4b42-9a86-2b7178a61d3a._msdcs.gellioer.
lleol
         * SPN found :E3514235-4B06-11D1-AB04-00C04FC2DCD2/8951b42d-78a0-4b42-9a
86-2b7178a61d3a/gellioer.lleol
         * SPN found :HOST/gweinydd.gellioer.lleol/gellioer.lleol
         * SPN found :HOST/gweinydd.gellioer.lleol
         * SPN found :HOST/GWEINYDD
         * SPN found :HOST/gweinydd.gellioer.lleol/GELLIOER
         * SPN found :GC/gweinydd.gellioer.lleol/gellioer.lleol
         ......................... GWEINYDD passed test MachineAccount
      Starting test: Services
         * Checking Service: Dnscache
         * Checking Service: NtFrs
         * Checking Service: IsmServ
         * Checking Service: kdc
         * Checking Service: SamSs
         * Checking Service: LanmanServer
         * Checking Service: LanmanWorkstation
         * Checking Service: RpcSs
         * Checking Service: w32time
         * Checking Service: NETLOGON
         ......................... GWEINYDD passed test Services
      Test omitted by user request: OutboundSecureChannels
      Starting test: ObjectsReplicated
         GWEINYDD is in domain DC=gellioer,DC=lleol
         Checking for CN=GWEINYDD,OU=Domain Controllers,DC=gellioer,DC=lleol in
domain DC=gellioer,DC=lleol on 1 servers
            Object is up-to-date on all servers.
         Checking for CN=NTDS Settings,CN=GWEINYDD,CN=Servers,CN=Default-First-S
ite,CN=Sites,CN=Configuration,DC=gellioer,DC=lleol in domain CN=Configuration,DC
=gellioer,DC=lleol on 1 servers
            Object is up-to-date on all servers.
         ......................... GWEINYDD passed test ObjectsReplicated
      Starting test: frssysvol
         * The File Replication Service SYSVOL ready test
         File Replication Service's SYSVOL is ready
         ......................... GWEINYDD passed test frssysvol
      Starting test: frsevent
         * The File Replication Service Event log test
         ......................... GWEINYDD passed test frsevent
      Starting test: kccevent
         * The KCC Event log test
         Found no KCC errors in Directory Service Event log in the last 15 minut
es.
         ......................... GWEINYDD passed test kccevent
      Starting test: systemlog
         * The System Event log test
         Found no errors in System Event log in the last 60 minutes.
         ......................... GWEINYDD passed test systemlog
      Test omitted by user request: VerifyReplicas
      Starting test: VerifyReferences
         The system object reference (serverReference)
         CN=GWEINYDD,OU=Domain Controllers,DC=gellioer,DC=lleol and backlink on
         CN=GWEINYDD,CN=Servers,CN=Default-First-Site,CN=Sites,CN=Configuration,
DC=gellioer,DC=lleol
          are correct.
         The system object reference (frsComputerReferenceBL)
         CN=GWEINYDD,CN=Domain System Volume (SYSVOL share),CN=File Replication
Service,CN=System,DC=gellioer,DC=lleol
         and backlink on CN=GWEINYDD,OU=Domain Controllers,DC=gellioer,DC=lleol
         are correct.
         The system object reference (serverReferenceBL)
         CN=GWEINYDD,CN=Domain System Volume (SYSVOL share),CN=File Replication
Service,CN=System,DC=gellioer,DC=lleol
         and backlink on
         CN=NTDS Settings,CN=GWEINYDD,CN=Servers,CN=Default-First-Site,CN=Sites,
CN=Configuration,DC=gellioer,DC=lleol
         are correct.
         ......................... GWEINYDD passed test VerifyReferences
      Test omitted by user request: VerifyEnterpriseReferences
      Test omitted by user request: CheckSecurityError
 
   Running partition tests on : ForestDnsZones
      Starting test: CrossRefValidation
         ......................... ForestDnsZones passed test CrossRefValidation
 
      Starting test: CheckSDRefDom
         ......................... ForestDnsZones passed test CheckSDRefDom
 
   Running partition tests on : DomainDnsZones
      Starting test: CrossRefValidation
         ......................... DomainDnsZones passed test CrossRefValidation
 
      Starting test: CheckSDRefDom
         ......................... DomainDnsZones passed test CheckSDRefDom
 
   Running partition tests on : Schema
      Starting test: CrossRefValidation
         ......................... Schema passed test CrossRefValidation
      Starting test: CheckSDRefDom
         ......................... Schema passed test CheckSDRefDom
 
   Running partition tests on : Configuration
      Starting test: CrossRefValidation
         ......................... Configuration passed test CrossRefValidation
      Starting test: CheckSDRefDom
         ......................... Configuration passed test CheckSDRefDom
 
   Running partition tests on : gellioer
      Starting test: CrossRefValidation
         ......................... gellioer passed test CrossRefValidation
      Starting test: CheckSDRefDom
         ......................... gellioer passed test CheckSDRefDom
 
   Running enterprise tests on : gellioer.lleol
      Starting test: Intersite
         Skipping site Default-First-Site, this site is outside the scope
         provided by the command line arguments provided.
         ......................... gellioer.lleol passed test Intersite
      Starting test: FsmoCheck
         GC Name: \\gweinydd.gellioer.lleol
         Locator Flags: 0xe00003fd
         PDC Name: \\gweinydd.gellioer.lleol
         Locator Flags: 0xe00003fd
         Time Server Name: \\gweinydd.gellioer.lleol
         Locator Flags: 0xe00003fd
         Preferred Time Server Name: \\gweinydd.gellioer.lleol
         Locator Flags: 0xe00003fd
         KDC Name: \\gweinydd.gellioer.lleol
         Locator Flags: 0xe00003fd
         ......................... gellioer.lleol passed test FsmoCheck
      Test omitted by user request: DNS
      Test omitted by user request: DNS
 
C:\Documents and Settings\Gweinyddwr>

Select allOpen in new window

There are a few places we can go from here.  The most common reason I've seen for "policy object does not exist" is incorrect DNS settings on the domain.  Could you post an ipconfig /all from one (or both) of the two client machines?

Beyond that, run a gpupdate /force, wait a few minutes, and then copy and post the last few errors from the System Event Log.  That'll help narrow down the next steps if it's not a DNS issue.  (Though all the symptoms combined is starting to make me suspicious of that, specifically.)

See below for the IPCONFIG /ALL results.

Note that I had changed the PC name of the client in question to TELEDU2 - this had also been moved to the Teledu OU.

TELEDU2 is connected via ethernet, with a fixed IP (I've tried this with the DHCP option as well).  Gweinydd is the DC and has an IP of 192.168.1.100.  LAPTOPGWYN connects via wireless but it uses WZC to connect the Wi-fi, which connects before logging in.  You may also notice that on this I have set the ISP's DNS as an alternate DNS server in the TCP/IP settings, in case my DC goes down for whatever reason.  Is this wise, or does it just complicate things?

Right at the end of this I did a gpupdate /force on TELEDU2 and checked the logs.  There were no errors in the System log, but the Application log said something about not being able to find the domain controller.  I then tried to ping gweinydd.  It was actually trying to resolve gweinydd as 192.168.1.102 !!!  I can't remember but I think I may have momentarily changed the IP of gweinydd to .102 weeks ago when I was first setting up the domain, but it has been .100 the whole time apart from that.

So, I went to gweinydd and checked Admin Tools -> DNS.  There was indeed an entry there for gweinydd as .102.  I got rid of this and also did ipconfig /flushdns on TELEDU2.  I then re-did gpupdate /force and rebooted.  Still no luck I'm afraid.

One thing, in the DNS entries there was another unexplained entry for 192.168.1.100 with (same as parent folder).  What is this and is it OK/useful to delete?

Is there a way to flush old entries from the DNS cache on gweinydd?

I feel as though we're slowly getting somewhere here, and I really appreciate your efforts.

****TELEDU2****
 
Microsoft Windows XP [Version 5.1.2600]
(C) Copyright 1985-2001 Microsoft Corp.
 
C:\Documents and Settings\Bwyd Ci>ipconfig /all
 
Windows IP Configuration
 
        Host Name . . . . . . . . . . . . : teledu2
        Primary Dns Suffix  . . . . . . . : gellioer.lleol
        Node Type . . . . . . . . . . . . : Hybrid
        IP Routing Enabled. . . . . . . . : No
        WINS Proxy Enabled. . . . . . . . : No
        DNS Suffix Search List. . . . . . : gellioer.lleol
 
Ethernet adapter Local Area Connection:
 
        Connection-specific DNS Suffix  . :
        Description . . . . . . . . . . . : Intel(R) PRO/1000 MT Mobile Connecti
on
        Physical Address. . . . . . . . . : 00-08-0D-1A-F4-D9
        Dhcp Enabled. . . . . . . . . . . : No
        IP Address. . . . . . . . . . . . : 192.168.1.106
        Subnet Mask . . . . . . . . . . . : 255.255.255.0
        Default Gateway . . . . . . . . . : 192.168.1.1
        DNS Servers . . . . . . . . . . . : 192.168.1.100
 
C:\Documents and Settings\Bwyd Ci>
 
 
 
 
 
 
 
****LAPTOPGWYN****
 
 
Microsoft Windows XP [Version 5.1.2600]
(C) Copyright 1985-2001 Microsoft Corp.
 
C:\Documents and Settings\Gwyn120L.GELLIOER>ipconfig /all
 
Windows IP Configuration
 
        Host Name . . . . . . . . . . . . : laptopgwyn
        Primary Dns Suffix  . . . . . . . : gellioer.lleol
        Node Type . . . . . . . . . . . . : Hybrid
        IP Routing Enabled. . . . . . . . : No
        WINS Proxy Enabled. . . . . . . . : No
        DNS Suffix Search List. . . . . . : gellioer.lleol
                                            gellioer
 
Ethernet adapter Local Area Connection:
 
        Media State . . . . . . . . . . . : Media disconnected
        Description . . . . . . . . . . . : Broadcom 440x 10/100 Integrated Controller
        Physical Address. . . . . . . . . : 00-15-C5-74-B4-87
 
Ethernet adapter Wireless Network Connection:
 
        Connection-specific DNS Suffix  . : gellioer
        Description . . . . . . . . . . . : Dell Wireless 1370 WLAN Mini-PCI Card
        Physical Address. . . . . . . . . : 00-19-7D-0C-65-CB
        Dhcp Enabled. . . . . . . . . . . : Yes
        Autoconfiguration Enabled . . . . : Yes
        IP Address. . . . . . . . . . . . : 192.168.1.19
        Subnet Mask . . . . . . . . . . . : 255.255.255.0
        Default Gateway . . . . . . . . . : 192.168.1.1
        DHCP Server . . . . . . . . . . . : 192.168.1.100
        DNS Servers . . . . . . . . . . . : 192.168.1.100
                                            212.74.112.67
        Primary WINS Server . . . . . . . : 192.168.1.100
        Lease Obtained. . . . . . . . . . : 21 May 2009 13:08:30
        Lease Expires . . . . . . . . . . : 29 May 2009 13:08:30
 
C:\Documents and Settings\Gwyn120L.GELLIOER>

Select allOpen in new window

I'm in agreement with slinkygn - DNS is a likely cause of these problems... Either way it's apparent at this point that you've got a more fundamental problem than GP. Resolve that and you'll likely resolve your GP problems, and any others you may have that you may not know about yet!

What is the DNS server address configured on the DC? It should be pointing ONLY to itself for DNS, adding in your ISPs DNS server (as I think I can see on the laptop config - 212.74.112.67) has caused problems for people in the past... In my opinion, the clients should ONLY be looking to the DC for DNS, and the DC should ONLY be looking at itself for name resolution.

You then set up a forwarder on the DNS server to your ISPs DNS. Is that how you've done it? So the DC does not have the ISP DNS as an 'alternate DNS'?

Oh and I forgot to answer another of your questions - The 'same as parent folder' entries should be left well alone. They're the IP addresses for your zones and name servers etc, so basically the ip records for your domain.

And it may also be worth running an ipconfig /flushdns on the DC too by the way, get rid of any 'old' cache, specially if you've been changing things... :)

Pete

Go ahead and enable DHCP on Teledu2.  Active Directory DNS uses DHCP to register machines.  When the machine makes the DHCP request and the DHCP server reports the IP it should take to the machine, it also reports the IP address to the DNS server which ties it to the machine name.  If you want it to always have the same IP address, make a reservation for it in the DHCP server.

I was unclear on a bit in my last post -- when I mentioned the System Event Log (and you were right to look in the Application Log as well), I meant for both the client and the server.  And go ahead and look before the gpupdate -- ideally, what I really would like to see are any errors that cropped up around the time you last rejoined the machine to the domain.  I suppose you could also just repeat the remove/rejoin the process and check again -- that would probably be a good idea after we get all the DNS issues resolved.

Putting your ISP's DNS as a secondary has never caused me any problems.  That is fine.  However, since we're troubleshooting DNS right now, it might be a good idea to take it out for the short term.

That secondary DNS entry is coming from DHCP, right?  Not hard-coded into the client?

The (same as parent folder) entry should be fine.  That's the SOA entry.  In fact, if you delete it, I'm pretty sure the server will just recreate it.

The only problem that comes from those is if you have multiple NICs in that machine.  DNS could potentially think that the wrong network card is the one that should be on .100.  If you do have multiple NICs in it, make sure the ones that you're not using are explicitly disabled in Device Manager.

If there was a DNS record for gweinydd at .102, the DC must've thought that was its IP address at some point -- you mentioned you had it there before; are we sure it's there now?  Could you post an ipconfig /all on the server?

If you go into your DNS management console and right-click on the server, you'll see a ton of options, including for clearing the cache and for scavenging old resource records.  Clearing the cache, I'm pretty sure, just clears stuff from the forwarding servers.  You can set up record scavenging now so that you won't have such a problem with phantoms, but that won't kick in for another week or so.  The best way to get inactive records cleared post-haste for right now is to just go in to the zones and hand-delete them yourself.  Setting up scavenging is probably a little beyond our scope here.  There are a number of TechNet articles on it, if you want to check that out later.  (There's also a Technet blog on scavenging whose name I don't recall, but has "just be patient" in the title -- if you can find it, IMHO that's required reading for setting up scavenging.)

Does pinging the server from Teledu now hit .100 correctly?

Didn't notice Pete's comments there.  Just to clarify -- he mentions that some have problems with specifying an external secondary DNS.  I never have.  What I'd say about that is, theoretically, yes, that could cause problems if you couldn't reach the domain controller and fell back on the secondary, and you were trying to use some internal resources -- but for any practical purpose I can imagine, if you can't reach your domain controller, you have much bigger problems to deal with than your secondary DNS.  It's a useful catch-all to maintain clients' ability to resolve DNS names if and while your DC goes down for whatever intentional or unintentional purpose, and if your DC's down, you're not going to be doing much internal name resolution anyway until that's fixed.

That reminds me, it may be useful to enable verbose logging for DNS as well, using this registry key:
HKLM\system\CCS\services\NTDS\Diagnostics
It just adds additional info the event logs for DNS related errors etc.

And coming back to the point about ISPs DNS added as an alternate DNS server - I don't see any purpose in doing so, even if it doesn't cause problems? Forwarders are used for external DNS domains, adding the ISPs DNS as an alternate achieves nothing, as it can't resolve anything for your internal DNS domain anyway. A quick google search on DNS best practises and flicking through the articles, a lot specifically state not to do so, for example here (this article is actually referring to configuring your DNS server, though it mentions clients in this quote):

"Do not configure your ISP's DNS server as an "alternate" DNS server. I have seen many configurations where the DNS server for a company's ISP provider was added here. I have only seen one case where putting another DNS server in a client's TCP/IP settings was justified. Your client can't authenticate against it, it can't find internal resources and that name server won't register the A record." - http://searchwindowsserver.techtarget.com/tip/0,289483,sid68_gci1244449_mem1,00.html

It may actually be useful for you to run through an article like this from top to bottom, to see if you configured DNS as suggested. Another very good article you may want to use is by a very reputable MVP Daniel Petri - http://www.petri.co.il/how_to_install_active_directory_on_windows_2003.htm

This may help you identify any areas you may have misconfigured or possibly just plain missed out.

Anyhoo, it's late again, and I need my beauty sleep... :)

Pete

Many thanks for the latest round of comments.

I went to the DNS Management utility and this time to the properties of the GELLIOER DNS Server.  On the Interfaces there were two entries - 192.168.1.100 and 192.168.1.102 !!

I removed the .102 and told it to only listen on 192.168.1.102, but I was still concerned about why .102 reappeared when I would later click on All IP Addresses.

It the dawned on me what .102 was - it wasn't that I'd previously changed gweinydd to .102 - it was something else - as slinkyqn has guessed.

I'm running Virtual Server 2005 on Gweinydd (the DC), and my virtual XP machine had been sharing the primary NIC on Gweinydd to connect to the network.  I was recently advised by the good people of this website that I should get a second NIC to be used solely by the VM.  I installed this a couple of weeks ago, but I didn't configure anything to use it, and it wasn't even plugged in because the was no free port on my router.  It's only today (when I bought a new gigabit switch) that I could start using it for sole use by the VM.  For some reason I had given this second NIC a static IP of .102 on the host.  I hadn't realised that I needed to 'hide' it from the host OS.  So after installing my switch today this is what I did, and in the Network Properties of my second NIC I unticked all protocols apart from "Virtual Machine Network Services".

So now 192.168.1.102 no longer exists, because the virtual machine's static IP had been .101 all along anyway.

I'm sorry that I've somewhat complicated matter no end, but I wanted to lay all my (network interface) cards on the table.


After this I did a flushdns on the DC.
Now DNS Management no longer sees .102 - great!


I have now enabled DHCP on TELEDU2, and made a reservation for it, which works fine.


P.S. Just to be on the safe side I've taken the alternate DNS away from the DNS settings on LAPTOPGWYN, so now all clients are looking only to the DC for DNS.  The DC has always only been looking at itself for DNS, i.e. 127.0.0.1, and has a forwarder that is my ISP's DNS server.


I'm sorry that I haven't haven't yet tried all that was suggested in the last couple of posts from PeterJThomas - time has beaten me.  I am going away tomorrow for a couple of days and need to start packing!  I will re-read the last few posts, and any others that may be there, as soon as I get back.

Thank you.

Good -- let us know!  I think we're getting pretty far on ironing out all the DNS issues.

The discussion on an external secondary DNS server has become a pretty big side issue, so I thought I'd address it again.  Again, I should note as I did earlier that what I'm saying applies *after* everything is working.

The objections listed on the TechTarget site are the same we mentioned earlier -- and again, I think they're fine in theory but meaningless in practice.  Yes, if that secondary DNS gets used, you won't be able to reference anything internal.  But the fact you're using the secondary DNS means the primary DNS server is not responding -- that's your domain controller!  If your DC's DNS isn't responding, you wouldn't be able to access internal resources *whether or not* you had the external secondary in place.  Not to mention the fact that you will have far bigger problems from losing your DC -- like no one being able to authenticate to the domain, for example.  The concern of "no internal resolution" is pretty minor by comparison.

Pete|J, you mention that "you don't see any purpose, even if it doesn't cause problems."  Here's the purpose:  Clients receive their DNS servers through DHCP.  That DHCP lease only needs to be renewed on expiration -- meaning it's still active even if the DC goes down.  So if the DC goes down for *whatever* reason -- even an intentional restart -- clients with an external secondary DNS will still be able to resolve addresses on the Internet, while clients without a secondary DNS defined would not be able to resolve anything at all.  This is a *huge* benefit to companies who use some sort of external web services, which are a good deal of them -- perhaps they use an external Salesforce.com client management system, or an externally hosted wiki for document management, Google Apps for email -- heck, maybe they just need to Google something every once in a while.  The benefit of all the company employees being able to continue being productive during server downtime is a big one.  And I have, again, yet to see an instance in "real life" use where it has caused a problem.  (Heck, some would argue that is the *purpose* of a secondary DNS!)

I should also note that in this specific case, we are talking about a home deployment -- where Internet access would be very likely a desired use case, and in fact is one that is specifically named in the original question.

And to cover the petri.il link -- man, I usually love Daniel Petri's stuff, but I honestly disagree with a critical point of his walkthrough.  Nowhere does it mention DHCP setup.  That is a glaring omission on a DC.  Furthermore -- and this is probably more controversial, but I'd love to hear an actual reason against this -- I do *not* think the DC should be using a static address if it's also the DHCP server!  (And it *should* be the DHCP server!)  Call me crazy, but I think it should have a reservation for its own address and listen to its own DHCP service.  That is a cheap and easy way to know for sure that DHCP is working correctly and properly authorized to update the DNS zones before any clients are on.  A static address on a DHCP server smacks of selling something you wouldn't use yourself. :-)  Again, that's something I've done a lot and tested plenty, and it works.  So I'll disagree with petri.il, and maybe someone can enlighten me on what I'm missing here (that hasn't cropped up yet as a problem on any of the ADs I've managed...)

Excellent news! Feels like we're getting somewhere for sure!

I know this is the wrong place to be debating this alternate DNS issue, but hey, whilst we're waiting for a response - I actually agree with what you've said now you've said it, I guess the 'flaw' in my opinion is that all my experiences have been drawn from company's with more 1 than DC, and also that don't really count internet connectivity as critical - I can see how it would be useful in a single DC environment (such as this one!) and therefore in this case they're all all valid points - Though I would still argue that for anywhere that has more than 1 DC, this would be essentially pointless, as you'd just have the second DC as the alternate DNS, and that would forward any requests to the ISP as the primary would.

On the Daniel Petri article I would imagine the argument would be that the article is titled 'How to *install* Active Directory, for which DHCP is not a requirement (i.e. just to get it installed in the first place). It would be the very next step I'm sure, however in literal terms the article is correct, though I agree it would be a significant improvement if it did have a section for DHCP config (maybe covered in a diff article?).

And I was running through your DHCP reservation idea in my head, and I think you're probably right for the most part - i.e. I can only think of one possible issue you may have with that set up (and it's just an idea as I'm not 100% on the particulars), but would it not be possible that if the DHCP server failed on the DC (*just* the DHCP service), it may give itself an APIPA address which may in turn be registered in DNS? Or not even getting as far as DNS, simply if DHCP failed, *and* the DCs lease expired, though all other aspects may still be functioning perfectly, the DC would no longer have an address...?

Well that's all I could come up with anyway... :)

Pete

Hi, last night I had a chance to try a few more steps.

I ran through Petri's instructions and all seems fine.

PeteJ, I had a look in the registry at

HKLM\system\CurrentControlSet\services\NTDS\Diagnostics

and there was nothing in the Diagnostic key that I could find with either the words 'Verbose' or 'DNS logging'.  Was I meant to add a value there?

A friend told me I should check the contents of the file
C:\Windows\Debug\UserMode\Userenv.log

When I log into the laptop in question, it gives me the following entry:

USERENV(2d8.514) 22:20:07:260 GetGPOInfo:  Local GPO's gpt.ini is not
accessible, assuming default state.

Does this give you guys any clues?

Next I concentrated on system logs.  So that you can synchronise with the times of the logs, here's what I did and when:

23:05      Took TELEDU4 off the domain and onto a workgroup and rebooted
23:09      Changed the PC name to TELEDU5 and rebooted
23:13      Rejoined the GELLIOER domain and rebooted
23:15      At the login screen I get "Please wait while the domain list is created" for 2 minutes
23:19      Logged in as Bwyd Ci
23:36      gpupdate /force

(It wasn't until after this that I put TELEDU5 in the correct OU, but gpresult still didn't recognise the policy after that)

And below is a chronological list of the errors and warnings from the System and Application logs from the client (there were no errors or warnings on Gweinydd's Event Viewer).

Thanks

System
------
 
 
Event Type:	Warning
Event Source:	LSASRV
Event Category:	SPNEGO (Negotiator) 
Event ID:	40960
Date:		26/05/2009
Time:		23:05:21
User:		N/A
Computer:	TELEDU4
Description:
The Security System detected an attempted downgrade attack for server DNS/gweinydd.gellioer.lleol.  The failure code from authentication protocol Kerberos was "The referenced account is currently disabled and may not be logged on to.
 (0xc0000072)".
 
For more information, see Help and Support Center at http://go.microsoft.com/fwlink/events.asp.
 
 
 
 
Event Type:	Warning
Event Source:	LSASRV
Event Category:	SPNEGO (Negotiator) 
Event ID:	40961
Date:		26/05/2009
Time:		23:05:21
User:		N/A
Computer:	TELEDU4
Description:
The Security System could not establish a secured connection with the server DNS/gweinydd.gellioer.lleol.  No authentication protocol was available.
 
For more information, see Help and Support Center at http://go.microsoft.com/fwlink/events.asp.
 
 
 
 
Event Type:	Warning
Event Source:	DnsApi
Event Category:	None
Event ID:	11196
Date:		26/05/2009
Time:		23:05:21
User:		N/A
Computer:	TELEDU4
Description:
The system failed to update and remove host (A) resource records (RRs) for network adapter
with settings:
 
   Adapter Name : {37F40824-D58A-4917-AC7D-B26BDB70F898}
   Host Name : teledu4
   Primary Domain Suffix : gellioer.lleol
   DNS server list :
     	192.168.1.100
   Sent update to server : 192.1.1.1
   IP Address(es) :
     192.168.1.6
 
 The reason for this failure was because of a security related problem. The cause of this could be that (a) your computer does not have permissions to remove and update the specific DNS domain name or IP addresses configured for this adapter, or (b) there might have been a problem negotiating valid credentials with the DNS server during the processing of the update request. For specific error code, see the record data displayed below.
 
For more information, see Help and Support Center at http://go.microsoft.com/fwlink/events.asp.
Data:
0000: 39 23 00 00               9#..    
 
 
 
 
Event Type:	Error
Event Source:	Dhcp
Event Category:	None
Event ID:	1002
Date:		26/05/2009
Time:		23:06:55
User:		N/A
Computer:	TELEDU4
Description:
The IP address lease 192.168.1.6 for the Network Card with network address 00080D1AF4D9 has been denied by the DHCP server 192.168.1.1 (The DHCP Server sent a DHCPNACK message).
 
For more information, see Help and Support Center at http://go.microsoft.com/fwlink/events.asp.
 
 
 
 
Event Type:	Error
Event Source:	W32Time
Event Category:	None
Event ID:	17
Date:		26/05/2009
Time:		23:07:30
User:		N/A
Computer:	TELEDU4
Description:
Time Provider NtpClient: An error occurred during DNS lookup of the manually configured peer 'time.windows.com,0x1'. NtpClient will try the DNS lookup again in 15 minutes. The error was: A socket operation was attempted to an unreachable host. (0x80072751)
 
For more information, see Help and Support Center at http://go.microsoft.com/fwlink/events.asp.
 
 
 
 
Event Type:	Error
Event Source:	W32Time
Event Category:	None
Event ID:	29
Date:		26/05/2009
Time:		23:07:30
User:		N/A
Computer:	TELEDU4
Description:
The time provider NtpClient is configured to acquire time from one or more time sources, however none of the sources are currently accessible.  No attempt to contact a source will be made for 14 minutes. NtpClient has no source of accurate time. 
 
For more information, see Help and Support Center at http://go.microsoft.com/fwlink/events.asp.
 
 
 
 
Event Type:	Error
Event Source:	Dhcp
Event Category:	None
Event ID:	1002
Date:		26/05/2009
Time:		23:10:32
User:		N/A
Computer:	TELEDU5
Description:
The IP address lease 192.168.1.6 for the Network Card with network address 00080D1AF4D9 has been denied by the DHCP server 192.168.1.1 (The DHCP Server sent a DHCPNACK message).
 
For more information, see Help and Support Center at http://go.microsoft.com/fwlink/events.asp.
 
 
 
 
Event Type:	Warning
Event Source:	LSASRV
Event Category:	SPNEGO (Negotiator) 
Event ID:	40961
Date:		26/05/2009
Time:		23:17:24
User:		N/A
Computer:	TELEDU5
Description:
The Security System could not establish a secured connection with the server DNS/prisoner.iana.org.  No authentication protocol was available.
 
For more information, see Help and Support Center at http://go.microsoft.com/fwlink/events.asp.
 
 
Event Type:	Error
Event Source:	Dhcp
Event Category:	None
Event ID:	1002
Date:		26/05/2009
Time:		23:38:08
User:		N/A
Computer:	TELEDU5
Description:
The IP address lease 192.168.1.6 for the Network Card with network address 00080D1AF4D9 has been denied by the DHCP server 192.168.1.1 (The DHCP Server sent a DHCPNACK message).
 
For more information, see Help and Support Center at http://go.microsoft.com/fwlink/events.asp.
 
 
 
 
 
Application
-----------
 
 
Event Type:	Warning
Event Source:	SceCli
Event Category:	None
Event ID:	1202
Date:		26/05/2009
Time:		23:07:30
User:		N/A
Computer:	TELEDU4
Description:
Security policies were propagated with warning. 0x428 : An exception occurred in the service when handling the control request.
 
For best results in resolving this event, log on with a non-administrative account and search http://support.microsoft.com for "Troubleshooting Event 1202's".
 
For more information, see Help and Support Center at http://go.microsoft.com/fwlink/events.asp.

Select allOpen in new window

Apologies, I wasn't very specific - Check this KB, it explains AD logging using that reg key: http://support.microsoft.com/kb/314980

Also, have a look here for some other verbose logging reg keys that could be useful: http://technet.microsoft.com/en-us/library/cc775423.aspx

It sounds like the error in the userenv.log is referring to the gpt.ini that resides in C:\WINDOWS\system32\GroupPolicy (on the client), which is where the policy settings for the LOCAL policy are kept. However if you've not configured anything at all in the local policy, I wouldn't worry about it (I haven't checked but this may well be normal if the local policy has no settings configured).

To be honest, all those errors are probably still being caused by DNS - From what I can see, the client was having trouble deregistering with DNS (when you removed it from the domain etc). Any idea what DNS/prisoner.iana.org is?

Can you check if the DNS zone is allowing Dynamic updates? (found in the properties of the zone, under the DNS tab).

And also that your DHCP server options have the correct DNS domain name configured to issue to the clients?

Most of the problems I'm seeing there are with the client trying to talk properly to the DNS server...

I've had a look through the Microsoft KB article.  Am I right to assume that is number 13, Name Resolution, that I need?

So should I set this to 4 - Verbose?

Thanks

That would definitely make the most sense as that's where we believe the core of this problem is at the moment... It will then start logging all related events. Probably a lot more than we need, but it may help in some way or give further clues...

You don't have a DNS reverse lookup zone set up, according to those errors.  You want to set one up.

Further, you may or may not be generating AD records on the server.  What records do you have under the _msdcs entry in your DNS forward lookup zone?

Also might want to run the recursive query diagnostics in the DNS Server Properties (Monitor tab, if I remember right) and definitely a dcdiag /test:dns -- you ran dcdiag before, but by default it doesn't do DNS tests.

Finally, if you want to log something, I'd say log User Login Failures.  You can set that under Group Policy.

You don't have a DNS reverse lookup zone set up, according to those errors.  You want to set one up.

Further, you may or may not be generating AD records on the server.  What records do you have under the _msdcs entry in your DNS forward lookup zone?

Also might want to run the recursive query diagnostics in the DNS Server Properties (Monitor tab, if I remember right) and definitely a dcdiag /test:dns -- you ran dcdiag before, but by default it doesn't do DNS tests.

Finally, if you want to log something, I'd say log User Login Failures.  You can set that under Group Policy.

Magnifico!!

It's sorted now - the bain of my life for last couple of weeks of my life has finally ceased!

It was a DHCP issue.  When I initially created a DHCP server on the DC, I switched off my router's DHCP.  But doing this somehow caused the internet to not work for anyone (now I realise that this was caused by my DC having two IP addresses and the DNS server being confused between the two), so I had to switch the router's DHCP back on.  And it was this that was causing DNS problems, because the router's DHCP was not passing the correct DNS settings to the clients.

What a relief!

And now, as PeteJThomas said, sorting out this problem might sort out some other problems I may have.  The DC was also not shutting down properly, just hanging on "Windows is shutting down", with the event logs giving me all sorts of errors from Microsoft Exchange.  The DC now switches off fine, with no errors in the logs.  Great!

I want to thank you all for all the priceless knowledge you have given me on these issues.

I can get on with the rest of my my life now.  :)

Fantastic news! I was beginning to worry it might take several more weeks to get to the bottom of this one... It's certainly been interesting that's for sure!

Thanks for the points, and thanks to slinkygn for filling some gaps in my knowledge/experience!

Good luck!

Pete

Aw, man!  Glad you found it.  That's a pretty common one -- it's why I'd asked for an ipconfig /all of the server early on, as I wanted to crosscheck the server's IP address against the clients' listed DHCP and DNS settings.  I thought about insisting, but I let it slide -- that's my fault for it taking an additional week. :-)  It's so often the big obvious things!  This is also why I recommend that the server be set to pull DHCP from itself, as that'll throw up a bunch of easy-to-spot red flags if you have DHCP conflicts.  Glad we could get this figured out for you!