You're seeing the dreaded scourge of asynchronous policy processing. It's not a "feature" (and was default-off in Windows 2000 but default-on in Windows XP and above) and causes exactly what you're seeing-- non-deterministic behaviour with processing some types of GPO settings.
In a GPO that applies to that computer, add the following setting:
- Computer Settings
- Administrative Templates
- System
- Logon
- Always wait for the network at computer startup and logon - Enabled
After you set that (and allow the GPO to replicate if you're in a multi-DC environment), do a "gpupdate /force /boot" on the subject PC. It will reboot and you should see the software installation occur.
The "Always wait for the network at computer startup and logon" slightly slows down the startup and logon because all GPO extensions are allowed to process, but the upside is that all GPO extensions are allowed to process.
This has been a fun topic of discussion on Server Fault. There appear to be varying "religious views" on the topic.
I agree with Microsoft's recommendation: Use a sub-domain of the company's already-registered Internet domain name.
So, if you own foo.com
, use ad.foo.com
or some such.
The most vile thing, as I see it, is using the registered Internet domain name, verbatim, for the Active Directory domain name. This causes you to be forced to manually copy records from the Internet DNS (like www
) into the Active Directory DNS zone to allow "external" names to resolve. I've seen utterly silly things like IIS installed on every DC in an organization running a web site that does a redirect such that someone entering foo.com
into their browser would be redirected to www.foo.com
by these IIS installations. Utter silliness!
Using the Internet domain name gains you no advantages, but creates "make work" every time you change the IP addresses that external host names refer to. (Try using geographically load-balanced DNS for the external hosts and integrating that with such a "split DNS" situation, too! Gee-- that would be fun...)
Using such a subdomain has no effect on things like Exchange email delivery or User Principal Name (UPN) suffixes, BTW. (I often see those both cited as excuses for using the Internet domain name as the AD domain name.)
I also see the excuse "lots of big companies do it". Large companies can make boneheaded decisions as easily (if not moreso) than small companies. I don't buy that just because a large company makes a bad decision that somehow causes it to be a good decision.
Best Answer
What is Group Policy?
Group Policy is a tool that is available to administrators that are running a Windows 2000 or later Active Directory Domain. It allows for centralized management of settings on client computers and servers joined to the domain as well as providing a rudimentary way to distribute software.
Settings are grouped into objects called Group Policy Objects (GPOs). GPOs are linked to an Active Directory organizational unit (OU) and can be applied to users and computers. GPOs cannot be applied to groups directly, though you can use security filtering or item-level targeting to filter policy application based on group membership.
That's cool, what can it do?
Anything.
Seriously, you can do anything that you want to users or computers in your domain. There are hundreds of pre-defined settings for things like folder redirection, password complexity, power settings, drive mappings, drive encryption, Windows Update, and so on. Anything that you can't configure via a pre-defined setting you can control via scripting. Batch and VBScript scripts are supported on all supported clients and PowerShell scripts can be run on Windows 7 hosts.
How are Group Policy Objects applied?
GPOs are applied in a predictable order. Local policies are applied first. There are policies set on the local machine via gpedit.msc. Site policies are applied second. Domain policies are applied third, and OU policies are applied fourth. If an object is nested inside of multiple OUs, then the GPOs are applied at the OUs closest to the root first.
Keep in mind that if there is a conflict, the last GPO applied "wins." This means, for example, that the policy linked at the OU that a computer resides in will win if there is a conflict between a setting in that GPO and one linked in a parent OU.
Logon and Startup Scripts seem cool, how do those work?
A logon or startup script can live on any network share as long as the
Domain Users
andDomain Computers
groups have read access to the share that they are on. Traditionally, they reside in\\domain.tld\sysvol
, but that's not a requirement.Startup scripts are run when the computer starts up. They are run as the SYSTEM account on the local machine. This means that they access network resources as the computer's account. For example, if you wanted a startup script to have access to a network resource on a share that has the UNC of
\\server01\share1
and the computer's name wasWORKSTATION01
you would need to make sure thatWORKSTATION01$
had access to that share. Since this script is run as system, it can do stuff like install software, modify privileged sections of the registry, and modify most files on the local machine.Logon scripts are run in the security context of the locally logged on user. Hopefully your users aren't administrators, so that means that you won't be able to use these to install software or modify protected registry settings.
Logon and startup scripts were a cornerstone of Windows 2003 and earlier domains, but their usefulness has been diminished in later releases of Windows Server. Group Policy Preferences gives administrators a much better way to handle drive and printer mappings, shortcuts, files, registry entries, local group membership and many other things that could only be done in a startup or logon script. If you're thinking that you might need to use a script for a simple task, there's probably a Group Policy or preference for it instead. Nowadays on domains with Windows 7 (or later) clients, only complex tasks require startup or logon scripts.
I found a cool GPO, but it applies to users, I want it to apply to computers!
Yeah, I know. I've been there. This is especially prevalent in academic lab or other shared computer scenarios where you want some of the user policies for printers or similar resources to be based on the computer, not the user. Guess what, you're in luck! You want to enable the GPO setting for Group Policy Loopback Mode.
You're welcome.
You said I can use this to install software, right?
Yep, you can. There are some caveats, though. The software must be in MSI format, and any modifications to it must be in an MST file. You can make an MST with software like ORCA or any other MSI editor. If you don't make a transform, your end result will be the same as running
msiexec /i <path to software> /q
The software is also only installed at startup, so it's not a very fast way of distributing software, but it's free. In a low-budget lab environment, I've made a scheduled task (via GPO) that will reboot every lab computer at midnight with a random 30 minute offset. This will ensure that software is, at a maximum, one day out of date in those labs. Still, software like SCCM, LANDesk, Altaris, or anything else that can "push" software on an on-demand basis is preferable.
How often is it applied?
Clients refresh their Group Policy Objects every 90 minutes with a 30 minute randomization. That means that, by default, there can be up to a 120 minute wait. Also, some settings, like drive mappings, folder redirection, and file preferences, are only applied on startup or logon. Group Policy is meant for long-term planned management, not for instant quick-fix situations.
Domain Controllers refresh their policy every five minutes.