Take the 2-minute tour ×
Server Fault is a question and answer site for professional system and network administrators. It's 100% free, no registration required.

We have an organization of approximately 1200 Windows PC clients on an Active Directory network. We have noticed that there seems to be random systems that don't get policies set.

For example, we have in our policies that the Windows system is to notify of updates but not apply them. We have a group of systems after upgrades over the summer that are downloading updates and rebooting, even without anyone logged in. The issue there is that these systems have Deep Freeze on them, so when they reboot, whatever fix is applied is then erased and so they restart their download/reboot cycle again, ad infinitum. Others, users log in, and it'll pop up a notice that it'll reboot in five minutes unless you click on "Later".

In the past we saw issues with things like blocking access to the C: drive in AD policies; usually systems hid the drives, on some systems, seemingly at random, users would log in and have access.

Policy refreshes from the command line didn't seem to fix the issue but sometimes a couple of reboots would. These systems seem to have network access at startup, so they should be able to communicate with the AD servers (plus users can log in to them, so they must be able to authenticate since frozen systems are frozen without cached profiles).

Is this normal for AD policies to not always "take" on clients, or is there something that should be checked? Do other people run into this as expected behavior? I know AD policies are supposed to randomly refresh on clients but when we ran the command to manually refresh policies it didn't seem to fix the issue.

share|improve this question

3 Answers 3

up vote 2 down vote accepted

The machine account's password is usually changed every 30 days by the machine. If DeepFreeze does not allow the new password to be stored on the computer, computer level GPO will probably fail as the computer cannot log on to AD.

You can disable that automatic password change (although it's not recommended): http://www.microsoft.com/resources/documentation/windows/xp/all/proddocs/en-us/580.mspx

Looks like that is (or at least was) a known problem with DeepFreeze: http://universitytechnology.blogspot.com/2008/03/session-setup-from-computer.html

share|improve this answer
    
Sorry if this is a naive question, but where/when/how does the machine log into the domain at startup after it's already added onto the domain? –  Bart Silverstrim Sep 1 '09 at 13:20
    
I highly suspect Deep Freeze would interfere with the machine accounts. This is a common problem in imaged labs when you try reverting to an old image. Does Deep Freeze take care of this issue for you? If not, is someone manually resetting the machine account and joining the workstations back in to the domain? –  Doug Luxem Sep 1 '09 at 13:24
    
@Bart - When the computer is added to the domain a machine account is created in AD (Computers container by default) and a password is set. The computer then resets the password every 30 days or so. On startup, the computer log into the domain with this account to download computer policies (this account is also used when local system access the network). If Deep Freeze re-images after the computer changes its password, it will no longer be able to access the domain. User will still work fine. You should see errors in the Security event logs on the DC or workstation. –  Doug Luxem Sep 1 '09 at 13:28
    
The machine is on the domain with it's own SID and name before Deep Freeze is set. Is there any material on the machine "resetting" the account in AD every 30 days? I've never run across that information and don't remember it being in any of Faronic's information. –  Bart Silverstrim Sep 1 '09 at 14:06
    
A quick search pulls up this KB article which may help (refers to 2000, but I assume XP/Vista are similar) - support.microsoft.com/kb/154501 –  Doug Luxem Sep 1 '09 at 14:11

Group policy application has been very reliable, in my experience. Nearly every case of troubleshooting that I've performed for Customers having intermittent policy application issues has broken down into:

  • Policies not applied in the right place (i.e. trying to apply computer policy to users, user policy to computers, not understanding loopback policy processing or filtering of policy application by group membership)

  • Dodgy DNS servers in use by client computers (poor network connectivity to DNS, ISP DNS servers named as "secondary" DNS servers)

  • The "media sense" feature causing NICs not to have network connectivity early enough in the boot process (see http://support.microsoft.com/kb/239924).

The "Always wait for the computer at startup and logon" in Computer Settings / Administrative Templates / System / Network should, in my opinion, be forced to "Enabled" in a policy specified at the root of the domain. This setting causes group policy processing at boot and logon to be applied synchronously (i.e. it completes before the logon box comes up on boot, or before the desktop is shown on logon).

Synchronous application was the default behaviour of Windows 2000, and at that time Microsoft recommended against asynchronous application because it could act non-deterministically. Microsoft changed the behavior of Windows XP to asynchronous, and sure enough, some group policy client extensions (like software installation policy) act somewhat random and dodgy. I always force policy application back to the synchronous setting, even if it does slightly slow boot and logon.

I can't tell you how "Deep Freeze" could be interacting with group policy because I've never used software like that. (I know what it does, but I haven't used it.) I've worked with thin client devices running Windows XP Embedded running on flash-based disks that did properly apply policies on each boot, even though they were using the "enhanced write filter" and would effectively "reset" back to a prior configuration on each boot.

Your "couple of reboots" makes me think that you're seeing problems with asynchronous policy processing. Your event log would probably tell you, except that your "Deep Freeze" software is probably not allowing writes to the event log to be persistent, so you'd have to examine the log before rebooting.

share|improve this answer
    
Just asked the boss about the asynch/synch setting of AD and it's already set to enabled on the default policy for the domain :-/ –  Bart Silverstrim Sep 1 '09 at 12:39

Do you have a GPO that tells the Deep Freeze PCs to download and install updates automatically and reboot? You can run rsop.msc to determine what GPOs are being applied to the PC and which policy it is that sets the auto-update policy. In the Group Policy editor (gpedit.msc) it is under Computer Configuration > Administrative Templates > Windows Components > Windows Update. The first thing would be to move those PCs to another OU if this is the case and take them out of the Update GPO path (depending on where in your AD structure it is coming from). Regardless of GP refresh rate settings you will need to stop the update GPO from being applied to the systems if this is the case.

The other scenario is that you have "deep frozen" the auto-update and reboot setting in place and GP does not have a chance to enforce the setting not to do this before it decides to download updates and reboot itself. I am not quite sure how Deep Freeze works - if it prevents some settings from being modified at all or if they can be modified, but they revert back to the previous setting after the reboot.

share|improve this answer
    
Deep Freeze will set a system so you can change anything your user has rights to...down to deleting the Windows directory until it crashes...and at reboot it reverts to the state it was in when first set to "freeze". Changes to the filesystem are allowed until reboot. Must be a run-time driver though. –  Bart Silverstrim Sep 1 '09 at 12:33
    
The default setting we have is to not allow the download/install/reboot of system updates; did that specifically because of users not having privileges on frozen systems (it would be useless for them, of course :-) –  Bart Silverstrim Sep 1 '09 at 12:40
    
Do you know at which GP level that setting is applied? If you just applied it locally to each system in the deep freeze image, then OU and domain GPOs would override it. It is set somewhere in the AD hierarchy I think - running rsop.msc will tell you which GPO has the setting. –  August Sep 1 '09 at 13:47
    
It's set as the default domain policy, top level, as I recall. Not local to the systems. –  Bart Silverstrim Sep 1 '09 at 15:10

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.