Since the Vista launch, I’ve had several incidents with Windows 2000 Domains (be cautious with Windows 2003 too!) where a customer would join up Vista clients into their production domain and find they can’t get an IP address following the reboot after Group Policy is applied. The symptoms were they ran an IPConfig /renew they would get an access denied. The first thing that pops into everyone’s mind is “do I need to be running this from an elevated command prompt?” and the answer is no, but would apply if you’re doing an IPConfig /release.<?xml:namespace prefix = o ns = “urn:schemas-microsoft-com:office:office” />
Moving on I notice the DHCP Client Service is stopped; I proceeded to collect a Process Monitor trace and see Local Service is getting an access denied when we try to start the service. So I take a look over the Default Domain Policy they have (only applicable policy in this case) and see they are setting the DHCP Client service to Automatic. What this is doing is overwriting the default security descriptor on the DHCP Client service with what we would expect to see on a Windows 2000 client. To fix the already affected clients we had to dump out the security descriptor from a working machine (sc sdshow dhcp) and import this on those clients (sc sdset dhcp <insert SDDL here>). Since this customer didn’t have any business requirements for setting the DHCP Client service to Automatic in Group Policy, we removed the setting and everything worked as desired.
If you’re Domain is Windows 2003, then other alternatives are available. For instance, I would break these settings out of the Default Domain Policy and create a new GPO, apply my DHCP service settings and use a WMI Filter to only apply it 2000/XP workstations.
Group Policy is great, but when it comes to a new operating system I’d highly recommend testing your current GPO’s with client machines in a test lab against the necessary test matrix your company has in place prior to launching clients into production to avoid this gotcha.