Windows – Install Windows Server 2008 R2 Features and Roles through Group Policy

Having JUST left an academic environment where we were ghosting 1200+ workstations each quarter and needed to keep University students from hacking them to smithereens, I feel your pain. As it happens I spent September through January hacking on that exact problem. I did not find a complete answer, but I did find out some things that helped:

• Nearly all problems are a result of setting up the default user profile for use by students.
• Machines that are properly sysprepped experience this problem a lot less often than profile-copy methods.
• When it happens, sometimes the access to the print server is actually the ghost-user or the profile-copy user, or some other cached credential on the image rather than the logged in user.
  • Jason Berg's delay method will make this work if this is what's nailing you. By the time the GPO fires, profile setup is completed and these cached-user accesses won't happen.
• Sometimes, going into the Options on the Preference and hard specifying "Run with user's permissions" make it work more often.
• This seems to rarely happen when the profile exists on the machine, such as happens when troubleshooting the problem :P. I haven't used Deep Freeze, so don't know if it leaves profiles behind after a login.
• Sometimes Deploying the printer to the user and also setting a GPO Preference to set the default printer works more reliably than Deploying to the computer. You're using loopback processing anyway, may as well just put everything in the User GPO that you can.

And I still didn't get it completely knocked down. It's a tough problem.

AFAIK the only option is to set a specific time.

That being said, I think you're not fully aware of the implications of having ALL the servers doing automated installs/reboots.

What if there is a faulty patch wich breaks the kernel or similar.. do you really want to come to work in the morning and finding all your servers in a boot loop?

I suggest you turn on auto-install only for the servers that are critically to keep updated (internet-facing servers, terminal servers) and do the rest in a manual maintenace schedule.

If that don't work out for you, then atleast set up WSUS, test updates, and then deploy them when you are 100% sure that they dont break your OS or your applications (latter more common).

You can also create separate group policies with different timeslots, and use either OU's or security filtering to choose wich server gets what.