We have a self coded service that allows our remote devices to run their GPO-targeted Computer Startup scripts 'after' connecting to the corporate network via VPN. In updating the home-grown code recently (to support an upcoming release of Vista), we were asked to add one new feature by one of our GPO Administrators: "Have the service only run the scripts in GPOs applicable to the device. [Okay, we thought we were doing this. - JC] That is, the device should not get the GPO Computer Startup script when it is a member of a domain security group listed on the GPOs Delegation tab with the following properties: 'Allow-Read' and 'Deny-Apply Group Policy'." [ And we thought this was the case as well. - JC] Because it currently doesn't do this, I have to create separate OUs just to get our Computer Startup scripts correctly targeted. [Ouch, what's up here? - JC] We have been running this code on 150,000+ systems since 2001 and, until now, no one has ever indicated that the list being returned was not the 'absolutely correct' list of GPOs. The service runs under Local System and uses the GetGPOList function (with the lpName and lpHostName parameters) to retrieve the list of GPOs for the computer. Has anyone run into this situation before, specifically that using the lpName and lpHostName parameters, instead of the hToken parameter in the GetGPOList function returns an incorrect list of GPOs? Also, if I ask the developer to switch to using the hToken parameter, which function might be the best to get hToken from [available functions from the article noted below are LogonUser<http://msdn.microsoft.com/en-us/library/cc447468(VS.85).aspx>, CreateRestrictedToken<http://msdn.microsoft.com/en-us/library/cc402001(VS.85).aspx>, DuplicateToken<http://msdn.microsoft.com/en-us/library/cc402013(VS.85).aspx>, OpenProcessToken<http://msdn.microsoft.com/en-us/library/cc447514(VS.85).aspx>, or OpenThreadToken<http://msdn.microsoft.com/en-us/library/cc447517(VS.85).aspx>] considering the remote nature of the device when connected via VPN? MSDN link to GetGPOList http://msdn.microsoft.com/en-us/library/aa373520(VS.85).aspx ... The GetGPOList function is intended for use by services acting on behalf of a user or computer. The service calls this function to obtain a list of GPOs, then checks each GPO for service-specific policy. Calling this function with a token provides the most accurate list. The system can perform access checking for the user or computer. Calling this function with the user or computer name and the domain controller name is faster than calling it with a token. However, if the token is not specified, the system uses the security access of the caller, which means that the list may not be completely correct for the intended user or computer. ==================================================================== More (too much) Info :) ==================================================================== When I tested this out for the GPO Administrators, their statement (and experience) was correct. The Test: I added a test machine account to a domain-side security group, added that security group to a standard GPO (that runs a Computer Startup script) and set the groups rights to 'Allow-Read' and 'Deny-Apply Group Policy'. I rebooted the device twice, verified it knew that it was a member of the group and validated that the GPO was no longer running the script. I unplugged the network cable, rebooted it, and then plugged in a non-company LAN line. Then I established a VPN session. Sure enough the service thought that the GPO 'was' still applicable and ran the script. In researching this, their GPO typically has the Authenticated User group with 'Allow-Read' and 'Allow-Apply Group Policy' permissions along with a second security group used to filter out certain machine accounts using 'Allow-Read' and 'Deny-Apply Group Policy'. Since we created the code in 2001, we cannot be sure that the text about GetGPOList not returning the absolutely correct list (above in red) was there at the time we were first working with it. However, it is there now and we have to deal with it. Jerry Cruz