Note
Access to this page requires authorization. You can try signing in or changing directories.
Access to this page requires authorization. You can try changing directories.
Question
Tuesday, March 26, 2013 8:37 PM
I have deployed an application through SCCM 2012 (vbscript install) which writes to the HKCU key. The script runs successfully with no errors and I can see the entries in the registry. However, the detection rules fail when a clause is setup to look for the registry entry under the HKCU key. The User Experiece is set to Install for User. Detection rules for other applications work fine when looking the HKLM. Is there something I am missing?
All replies (11)
Wednesday, March 27, 2013 10:18 PM âś…Answered
It appears the install is running as the logged in user, as I specified, however, the verification likely runs as SYSTEM. Rather counter intuitive for SCCM since selecting the HKCU key as a possible location for application detection is available.
That is not a correct statement, see my example here: http://blog.configmgrftw.com/?p=414
Jason | http://blog.configmgrftw.com
Tuesday, March 26, 2013 9:39 PM
according to me the detection for HKCU stuff will fail, because software is usually installed by sccm with the system account.
you could try using the hkey_users sid instead.
maybe by modifying your script to detect which of the sids listed under hkey_users can be resolved to the actual user via the profilelist key?
Tuesday, March 26, 2013 10:15 PM
Similar to what grundlichkeit said, have you verified that the value is actually in the HKCU hive after deployment using ConfigMgr?
There also is a known timing issue that happens when installers spawn other installers: basically the detection run when the wrapper installer ends but spawned installers may still be going so whatever the detection is looking for isn't there yet but by the time you manually check, it is. To solve this, you need wrap the installer in a batch file and add a delay to the end.
Jason | http://blog.configmgrftw.com
Wednesday, March 27, 2013 6:30 PM
Thanks for replies. Yes. I have verified the values are actually getting entered in the HKCU. Also after re-running the install, it still does not detect the application was installed even though the value is present.
We cannot select specific SIDs because it we only want it to install the application when the logged in user chooses to install it no matter who that use is.
It appears the install is running as the logged in user, as I specified, however, the verification likely runs as SYSTEM. Rather counter intuitive for SCCM since selecting the HKCU key as a possible location for application detection is available.
Also, I did find that using a custom script as a detection method with run as the logged in user (when install for user is selected), but the vbscript to detect the registry key does not work.
Wednesday, April 3, 2013 3:58 PM
Then why was the presence of the key not detected when manually checking the registry, the key is present? I have also seen this issue when I use %APPDATA%\... as a detection condition and have seen in error logs it is expanded to C:\USERS\SYSTEMS rather than C:\USERS\Username
Wednesday, April 3, 2013 4:17 PM
That all depends on how you are deploying the apps. If %APPDATA% is being expanded into something other than the user's AppData directory, you were running the app in the system's context and not as a user.
Jason | http://blog.configmgrftw.com
Wednesday, April 3, 2013 4:35 PM
I have Install for User set under User Experience for the application's deployment type
I can also confirm it is running the install under the user context because the install scprit uses the HKCU key and it is present when I check the registry.
Wednesday, April 3, 2013 4:48 PM
Exactly what detection methods do you have configured?
Jason | http://blog.configmgrftw.com
Wednesday, April 3, 2013 5:54 PM
Well this is embarassing. I checked the path in the registry detection and it was pointing to the wrong key. Once I updated the detection with the correct key, it began to work. Thanks for you help
Wednesday, April 3, 2013 6:12 PM
:-)
Glad it was something simple.
Jason | http://blog.configmgrftw.com
Friday, May 24, 2013 7:48 PM
It's been a while, but I came across an example where the install runs as user but detection runs as system or another user (at least when expanding %USERPROFILE%). I have an app which copies a file into the user's profile folder, but when the detection runs, it expands the %USERPROFILE% variable to C:\Users\Default rather than C:\Users\Username. The install runs as user and installs the file correctly, but fails the detection. I found this line in the DcmWmiProvider.log
CAppExecutionLibrary::ExpandEnvironmentVariables: %USERPROFILE%\Unlock\ evaluated to : C:\Users\Default\Unlock\
Using a custom script to check for the file in the user's profile folder, does succeed.