Go to Desktop on Sign In on Windows 8.1 via Compliance Settings in ConfigMgr 2012

This weeks’ post will be about Going to the desktop, instead of Start, when signing on Windows 8.1 via Compliance Settings. I will write about the scripts for discovering and remediating this setting, either on a user based, or a computer based configuration, via a Configuration Item. Keep in mind that it won’t be a walkthrough. For a complete step-by-step example, about using scripts in Compliance Settings, take a look at my post about Allowing Direct Installation of Windows 8 Apps via Compliance Settings in ConfigMgr 2012.

Of course, in the most situations, the preferable way for configuring this settings is via a Group Policy (as described in this great post of Sander Berkouwer). There are a only a few reason not to use a Group Policy, and to start looking at Compliance Settings, like when the device is not a member of the domain, or when the company likes one way to configure a setting for all devices.

Computer based configuration

Now lets start with the first scenario. In this case we want to configure it for every user that logs in to a device. The best way to configure this is via HKEY_LOCAL_MACHINE. For this we need to create a discovery and remediation script for the existence and value of the value GoToDesktopOnSignIn in the key HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Microsoft\Windows\Explorer.

Discovery script

The discovery script has only one purpose and that’s to find find the mentioned registry key and its value. When the script finds the registry key, it will return Compliant, otherwise it will return NonCompliant. The Compliance Rule of the Configuration Item should check on the returned value of Compliant.

$strKeyPath = "HKLM:SOFTWARE\Policies\Microsoft\Windows\Explorer" If (!(Test-Path -Path $strKeyPath)) { $Compliance = "NonCompliant" } Else { If ((Get-ItemProperty -Path $strKeyPath).GoToDesktopOnSignIn -ne 1) { $Compliance = "NonCompliant" } Else { $Compliance = "Compliant" } } Return $Compliance

Remediation script

Also the remediation script has only one purpose and that’s to find find the remediate registry key and its value. This script will create registry key and when needed also the path to the registry key.

$strKeyPath = "HKLM:SOFTWARE\Policies\Microsoft\Windows\Explorer" If (!(Test-Path -Path $strKeyPath)) { New-Item -Path $strKeyPath -Force } New-ItemProperty $strKeyPath -Name GoToDesktopOnSignIn -Value 1 -Force

User based configuration

Now lets go on with the second scenario. In this case we want to configure it for specific users on any device. The best way to configure this is usually via the HKEY_CURRENT_USER, but this introduces the following problems when managed via ConfigMgr:

  • By default, ConfigMgr will run the discovery and remediation scripts with the SYSTEM account. In this situation this means that actions written to HKEY_CURRENT_USER will actually be written to HKEY_USERS\.DEFAULT.
  • Running the discovery and remediation scripts by using the logged on user credentials will end-up in an Access Denied message. As a normal user can’t write in the policy registry keys under HKEY_CURRENT_USER.
    • Note: This is a good option when the targeted users are administrators on their devices.

So we need to get creative. The registry keys that we CAN edit, per user, with the SYSTEM account, are under HKEY_USERS. This means that the way to workaround this, is to use the value GoToDesktopOnSignIn in the key HKEY_USERS\<CurrentUserSID>\SOFTWARE\Policies\Microsoft\Windows\Explorer.

Discovery script

The discovery script has only one purpose and that’s to find find the mentioned registry key and its value.The first thing this script does is determining the current logged on user and the corresponding SID. That information will be used with searching the registry key under the HKEY_USERS. When the script finds the registry key, it will return Compliant, otherwise it will return NonCompliant. The Compliance Rule of the Configuration Item should check on the returned value of Compliant.

$strCurrentUser = (Get-WmiObject Win32_ComputerSystem -Computer ".").UserName $objCurrentUser = New-Object System.Security.Principal.NTAccount($strCurrentUser) $strCurrrentUserSID = ($objCurrentUser.Translate([System.Security.Principal.SecurityIdentifier])).Value New-PSDrive HKU Registry HKEY_USERS $strKeyPath = "HKU:\$strCurrrentUserSID\Software\Policies\Microsoft\Windows\Explorer" If (!(Test-Path -Path $strKeyPath)) { $Compliance = "NonCompliant" } Else { If ((Get-ItemProperty -Path $strKeyPath).GoToDesktopOnSignIn -ne 1) { $Compliance = "NonCompliant" } Else { $Compliance = "Compliant" } } Return $Compliance

Remediation script

Also the remediation script has only one purpose and that’s to find find the remediate registry key and its value. Like the discovery script, the first thing this script does is determining the current logged on user and the corresponding SID. That information will be used with creating the registry key, and when needed also the path to the registry key, under the HKEY_USERS.

$strCurrentUser = (Get-WmiObject Win32_ComputerSystem -Computer ".").UserName $objCurrentUser = New-Object System.Security.Principal.NTAccount($strCurrentUser) $strCurrrentUserSID = ($objCurrentUser.Translate([System.Security.Principal.SecurityIdentifier])).Value New-PSDrive HKU Registry HKEY_USERS $strKeyPath = "HKU:\$strCurrrentUserSID\Software\Policies\Microsoft\Windows\Explorer" If (!(Test-Path -Path $strKeyPath)) { New-Item -Path $strKeyPath -Force } New-ItemProperty $strKeyPath -Name GoToDesktopOnSignIn -Value 1 -Force

Conclusion

It is very doable to use a Configuration Item to configure Going to the desktop, instead of Start, when signing on Windows 8.1, in either a user based, or a computer based configuration. The user based configuration needed some creative scripting, but the computer based configuration is very straight forward.

3 thoughts on “Go to Desktop on Sign In on Windows 8.1 via Compliance Settings in ConfigMgr 2012”

  1. Well, it’s smth like catch 22:
    If you execute the script as user, you have no access to policy registry keys,
    If you are system, you have no idea what user/baseline got you to run…
    I’m trying to enforce group policy-like removable drive write restrictions per user, have a non secure implementation, consisting of 2 conf. Items: user-level compliance setting flashes a flag, and a system-ran item sets policy for every profile with flag set. I feel no good about it, but that’s the only way i got that working.
    Thank you for your blog.

    Reply

Leave a Comment

This site uses Akismet to reduce spam. Learn how your comment data is processed.