DC policy dictates cli screensaver timeout...

Greetings "“ Can you take a look at this pesky problem "“ has anyone seen this before?

Server: Windows 2003 Server R2 (up on all SP’s and patches)

Clients: WinXP SP3, (up on all patches)

Goal: To meet security requirements, a timeout value must be placed on the screensaver so that it auto-locks after 4hours. The screensaver timout is being pushed to the clients via policy, at time-of-login. The XP workstations are domain-members.

Problem: Upon creating a brand new user in AD user, and that user logs into one of the XP domain-members, the 4h screensaver timeout works just fine. However, if an administrator touches the user in any way (changing properties, changing PW, etc etc), then that same user, logged into the domain does not time-out after 4h anymore; the screen stays open indefinitely. After that, if an administrator adjusts the timeout policy down to 1h on the DC, then the client will "˜fix’ itself, and start timing out at 1h.

In a nutshell, a new user will use the existing policy, until that user is touched administratively. Then no timeout value is observed at the Client. Setting the policy down to 1h will fix the client, and the client will use the 1h value, but 4h is the requirement.

 

Is this a computer or user policy? If it is a user policy you may want to try it as a computer policy. You might also try doing a policy refresh on the system after any changes are made by entering gpupdate /force at the command prompt on the target machine.

 

amdace - I'll post an answer as soon as I can. --Im posting this on behalf of someone else. --Stay tuned....

 

OP here: This is a 'user-policy'. The people in charge of the DC are on vacation in the vicinity of Thanksgiving, so we'll have to wait for their return, for more answers.

 

I received this from the administrator of the Domain Controller:

We verified that it is a User-Setting, and was not a Computer-Setting. Also, a policy-refresh is always forced when a change is made at the DC.

 

Could this possibly be a permission policy on the target machine. Possibly the user rights are causing this poilcy to not be properly applied.
Might be a stretch, but this is a head scratcher.