Group Policy Update Failure

Ok, I spent nearly all day racking my brain over this one, and just figured out the solution -- However, I still can't identify the root cause even though I've resolved the problem, so I'd like to dig a little further and see if I can identify what exactly happened.

So here's the lowdown:

The IT deparment I'm in not long ago changed their policy on formatting laptop hard drives. Before, laptops had two partitions, an OS C: partition and data D: partition. Nowadays that's no longer the case, as everyone is set up with just the one C: partition.

So, due to having remote users who are rarely in the office, we still have some laptops floating around out there with two partitions. One such laptop was just brought in for me to re-image with the one partition. It's important to note here that going from two partitions to one is the ONLY thing actually being changed. So settings, files, etc. are backed up to be restored after the fresh Windows install. Security settings are the same, networt settings, gpo, everything is the same as it was.

So, I figured it would be safe to back up the user's profile folder and then recopy everything in it into the user's fresh new profile folder after the fresh install, so as to restore some of her settings and whatnot.

And that's when everything went screwy...

After copying the profile over from backup, I can login to her Windows user profile just fine, BUT group policy fails to update. Our group policy forces uniform desktop wallpaper and removes the wallpaper tab from display properties menu. Yet her profile is the standard blue desktop, and she has the tab. Run gpupdate /force, no error message. Run a couple of other specific gp updates, no errrors. Reboot, login, blue desktop, screensaver tab's still there.

Meanwhile, I login to the my user profile or even the domain admin user profile, uniform desktop, no screensaver tab. So the group policy problem is ONLY with her login, which I found further perplexing.

Event logs didn't offer much. I found some userenv errors in application logs showing the gp update failure, but those disappeared after installing some hotfixes. So even after the userenv errors ceased, the problem remained.

So I finally just deleted her user folder in C:\Documents and Settings\ and logged into her account fresh to reset everything. That did the trick! Wallpaper set right, screensaver tab gone, etc.

So the solution was to start fresh with her profile. But that still doesn't tell me what happened.

Given that her previous profile that I was trying to somewhat restore was set to the exact same group policy settings, I don't see how restoring it could have triggered the gp update failure. But obviously something in there somewhere was the source of my problem...

Does that make sense? Any thoughts?

Yes, this makes perfect sense.

I had the exact same problem and resolved it with the exact same solution.

As to why is happened, I put it down to a permissions issue within the OS but I haven't actually found a reason for it. Once I fixed it, it slipped my mind again but as I have some time, I'm off to google again.

it sounds like the user logged into laptop locally to start off their account
from then on the locally stored cache would be examined to get details

after you deleted the docs and settings entry, the logon HAD to fully / completely authenticate from a domain server, and viola,
the GPUPDATE worked its magic

James, I guess it's too late to ask for the system log? I bet there would be a cryptic error or warning entry.

Not much at all to look at it. In System log, I have some typical benign looking errors, except for a NETLOGON 5719 that caught my attention. However, the same error pops up on my own laptop and doesn't cause any trouble -- I suspect it's just the result of a failure to connect to the network fast enough at initial boot up. Pops up every time the laptop's rebooted, but that's the only time I see it.

Application log's pretty clean too. There were some userenv errors that I've already resolved, but unfortunately I've cleaned out the logs since then, so I don't recall the exact ID.