This post isn't exactly just a Configuration Manager fix for Client Push, however it will help anyone who is trying to connect to an administrative share on a Windows Vista or Windows 7 machine that is having problems with "Access Denied" messages even though you know 100% for a fact that the account you're using is the right one.
User Account Control Remote Restrictions
Starting with Vista, User Account Control introduced some remote restrictions of administrative accounts. You can click the previous link if you want to read up on it. Suffice it to say, to disable these remote UAC restrictions of accounts that are in the local administrators group, do the following:
- Click Start, click Run, type regedit, and then press ENTER.
- Locate and then click the following registry subkey:HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Policies\System
- If the LocalAccountTokenFilterPolicy registry entry does not exist, follow these steps:
- On the Edit menu, point to New, and then click DWORD Value.
- Type LocalAccountTokenFilterPolicy, and then press ENTER.
- Right-click LocalAccountTokenFilterPolicy, and then click Modify.
- In the Value data box, type 1, and then click OK.
- Exit Registry Editor.
HomeGroup
If the machine you're trying to manage happens to be apart of a HomeGroup (introduced in Windows 7) then you may run into some issues. To leave a HomeGroup:
- Click Start, Click Control Panel
- Click View by Small Icons
- Click HomeGroup
- Click Leave HomeGroup
Turn on File and Printer Sharing in the Windows Firewall
If you happen to have the Windows Firewall enabled, you'll need to make sure File nd Printer Sharing is enabled in the firewall settings:
- Click Start
- Click Control Panel
- Click Category and select Small Icons
- Click Windows Firewall
- Click Allow a Program or feature through Windows Firewall
- Find File and Printer Sharing and enable Home/Work and Public network
By following the above tips, you should now be able to access any administrative shares that you have proper credentials for, and should also get client push working for some machines in which you are getting access denied or invalid network path messages and/or Failed to get token for current process (5) messages in the ccm.log.
As most configuration manager administrators know the local system account is used in many cases to install software. One of the biggest challenges though is testing software with the local system account. Creating a package, program, collection, advertisement, refreshing machine policy, etc all take quite a bit of time to test if the package works using the local system account. In many cases, you're likely just testing the ability to install the application silently (especially true for OSD scenarios).
One thing I like to use is PSExec from Sysinternals. In the past with OSes prior to Windows Vista, we could use the AT scheduler from the command line to create an interactive command prompt using the system account. This trick was removed in Vista and we were left with using Psexec.
- Download PSExec from http://technet.microsoft.com/en-us/sysinternals/bb897553 or alternatively, you can use http://live.sysinternals.com/psexec.exe (some web filtering software will not allow an exe to be downloaded in this manner, so the first link might be better).
- Once downloaded, navigate to the location of psexec via command line.
- From the command line enter psexec -si cmd.exe (this opens a new command prompt as the system context that's interactive)
- A new command line should open up. In the new command line type in whoami. You should see the credential as nt authority\system.
- Test whatever software package you want to install via command line (this will end up being the command line you use in your package program)
As I stated before, this is a great way to test command lines, especially silent ones. I know I've ran into a lot of issues where an application has some user interaction but since the process is running as the system account it stays "stuck" waiting for user interaction.
Comments (0) 
Themocracy