This is another post to deal with one of the (pointless) limitations of the various licensing editions of Windows.
To be specific, there are certain features that are only available if you have an Enterprise or Education edition of Windows.
In some cases, I find myself wondering why certain features are limited in this way.
For some features, it completely makes sense. Some goes in features of security and manageability, others regarding consumer vs enterprise orientation etc.
For others on the other hand, I find the logic to be utterly and completely pointless. The one in this post, being in the latter category.
One example of this was a previous post about the limitation to set wallpaper and lock-screen – this is also limited to Enterprise and Education – post here for reference.
When dealing with device management for organizations via the cloud using tools like Endpoint Manager (Intune), this becomes more visible as well.
The possibilities for what to configure and control etc., via Endpoint Manager is always evolving.
A good part of this, is basically much about moving what we used to control via Group Policy over to the cloud based polices.
Knowing what Group Policy all is about (the windows registry), this essentially means the ability to push registry settings to a device in a controlled manner.
Often to areas in the registry where the user cannot change them after “\Software\Policies\” comes to mind.
The reason for this is as easy as, the cloud doesn’t need your computer to be on the network to check what the GPO was to get your settings.
When it comes to setting restrictions on the GUI, environment, various settings for the user, customizations, tweaks and so, on this is easy to achieve.
This can also give the user a good experience, saving time for helpdesk calls i.e., and save a lot of “manual” labor for IT ,- while also standardizing how the “company setup” should be – also via “cloud”
But – and there is always a but somewhere – Quick rant incoming
But nr1: “Endpoint Manager is always evolving”
What was, and is available in GPO, is not necessarily available as a administrative template in the configuration profiles in endpoint manager today. Neither as a template or as a settings catalog setting.
This means, you may need to do it via a custom profile, this means you need to do custom oma-uri insertion to do stuff. It’s just annoying
But nr2: “Settings Catalog”
When doing configuration profiles, and adding settings from the “settings catalog”, you may notice this.
The (Preview) text is worth to note. This means, do not be surprised if you make a setting, and your devices/users do not get it.
But nr3: The big one – the “fracking” Windows editions limitations
As stated in the start of the post, some stuff is limited to Enterprise and Education editions of Windows.
If you need to look up if a setting is supported on your licensed edition of windows, a good source to look it up, is the “The Policy configuration service provider” documentation.
Scroll the page, or search for the setting or GPO your are looking to do via Intune to look it up.
As this post is about the screen saver, we will look up this one: ADMX_ControlPanelDisplay/CPL_Personalization_EnableScreenSaver.
And we will quickly see the following:
Stating that.
If you want to configure screensaver settings via Intune, go ahead and invest in an Enterprise edition of Windows.
I mean, that seams like a perfectly logical limitation for such a complicated setting. I mean, certainly, no other companies and organizations smaller than an enterprise level customer need to enforce a screensaver on their devices.
No hard feelings Microsoft – But this just seems like an ignorant limitation.
Workaround
So, like the last time with the lock screen/wallpaper issue, there is always a workaround to be made.
Microsoft also has PowerShell, thank you for that Microsoft ❤.
Since we are basing this on Intune, there is reason to believe that the devices involved are personal device, for the most part.
This means the devices mostly will belong to one person.
Maybe the users have admin rights, maybe not.
So, we may have to handle the following:
– Set screensaver, with password lock, and specific screensaver (as policy) – ser cannot override.
– Users with no admin rights on the device.
– Devices with more than one user logging on.
– Handle eventual new users logging on.
This can be handled via the PowerShell script on my GitHub here.
The script has sections depending on what part you need.
For the most part, you will get around all the points above with the last section, starting from 72>135.
This means you need line 1>24 +72>135 in one script.
This script can then be deployed to your devices and run as system in intune.
It will put the settings to the last logged on user on the device, and put the setting into the “.default” profile for the registry, meaning new users not being logged on the device before will get the settings as well.
Your script (if you combine the lines mentioned above) will then look like this:
<#
Script to Set specific screen saver on non enterprise editions of windows 10/11 via intune
as this is not supported via native intune policies.
script will set screen saver to the "blank" screen saver, with requirement for password to unlock.
PS: remove the sections for the part you are not going to use, and deploy the script using user credentials or system in intune, depending on what section you are going to use
edited: 13:07 10.02.2022 - Geir Dybbugt - Dybbugt.no
#>
# Restart Process using PowerShell 64-bit
If ($ENV:PROCESSOR_ARCHITEW6432 -eq "AMD64") {
Try {
&"$ENV:WINDIR\SysNative\WindowsPowershell\v1.0\PowerShell.exe" -File $PSCOMMANDPATH
}
Catch {
Throw "Failed to start $PSCOMMANDPATH"
}
Exit
}
# Generic Variables
$ScreenSaverTimeout = "900"
$ScreenSaverName ="scrnsave.scr"
# Section to set values for current user with admin rights
# Specific Variables for the section
$RegPath = "HKCU:\Software\Policies\Microsoft\Windows\control panel\desktop" # Change to HKLM to set for the device
# Section to set values via HKU as System user - to last logged on user on device
# Specific Variables for the section
$RegPath3 = "Software\Policies\Microsoft\Windows\control panel\desktop"
# Get info about the last logged on user
$GetLastLoggedOnUser = "HKLM:\SOFTWARE\Microsoft\Windows\CurrentVersion\Authentication\LogonUI"
$LastLoggedOnUserSID = Get-ItemProperty -Path $GetLastLoggedOnUser
$LastLoggedOnUserSID = $LastLoggedOnUserSID.LastLoggedOnUserSID
# Create HKU path for the system process to use
$HKUpath = "HKU:\$LastLoggedOnUserSID\$Regpath3" # Path for the last logged on user on the device
$HKUpath
$HKUpath2 = "HKU:\.DEFAULT\$Regpath3" # Path for the .Default user profile - for all new user profiles
# Map HKU in registry as available drive in OS
New-PSDrive -PSProvider Registry -Name HKU -Root HKEY_USERS
# Liste available PS drives
#Get-PSDrive
# Set the config
# Values for Last logged on user
if((Test-Path -LiteralPath $HKUpath) -ne $true) {
New-Item $HKUpath -force
if ($?) {
New-ItemProperty -LiteralPath "$HKUpath" -Name 'ScreenSaveActive' -Value '1'-PropertyType String -Force -ea SilentlyContinue;
New-ItemProperty -LiteralPath "$HKUpath" -Name 'ScreenSaverIsSecure' -Value '1' -PropertyType String -Force -ea SilentlyContinue;
New-ItemProperty -LiteralPath "$HKUpath" -Name 'SCRNSAVE.EXE' -Value $ScreenSaverName -PropertyType String -Force -ea SilentlyContinue;
New-ItemProperty -LiteralPath "$HKUpath" -Name 'ScreenSaveTimeOut' -Value $ScreenSaverTimeout -PropertyType String -Force -ea SilentlyContinue;
} else {
write-host "failed" -ForegroundColor Red
}
} else {
New-ItemProperty -LiteralPath "$HKUpath" -Name 'ScreenSaveActive' -Value '1'-PropertyType String -Force -ea SilentlyContinue;
New-ItemProperty -LiteralPath "$HKUpath" -Name 'ScreenSaverIsSecure' -Value '1' -PropertyType String -Force -ea SilentlyContinue;
New-ItemProperty -LiteralPath "$HKUpath" -Name 'SCRNSAVE.EXE' -Value $ScreenSaverName -PropertyType String -Force -ea SilentlyContinue;
New-ItemProperty -LiteralPath "$HKUpath" -Name 'ScreenSaveTimeOut' -Value $ScreenSaverTimeout -PropertyType String -Force -ea SilentlyContinue;
}
# Values for the .Default profile
if((Test-Path -LiteralPath $HKUpath2) -ne $true) {
New-Item $HKUpath2 -force
if ($?) {
New-ItemProperty -LiteralPath "$HKUpath2" -Name 'ScreenSaveActive' -Value '1'-PropertyType String -Force -ea SilentlyContinue;
New-ItemProperty -LiteralPath "$HKUpath2" -Name 'ScreenSaverIsSecure' -Value '1' -PropertyType String -Force -ea SilentlyContinue;
New-ItemProperty -LiteralPath "$HKUpath2" -Name 'SCRNSAVE.EXE' -Value $ScreenSaverName -PropertyType String -Force -ea SilentlyContinue;
New-ItemProperty -LiteralPath "$HKUpath2" -Name 'ScreenSaveTimeOut' -Value $ScreenSaverTimeout -PropertyType String -Force -ea SilentlyContinue;
} else {
write-host "failed" -ForegroundColor Red
}
} else {
New-ItemProperty -LiteralPath "$HKUpath2" -Name 'ScreenSaveActive' -Value '1'-PropertyType String -Force -ea SilentlyContinue;
New-ItemProperty -LiteralPath "$HKUpath2" -Name 'ScreenSaverIsSecure' -Value '1' -PropertyType String -Force -ea SilentlyContinue;
New-ItemProperty -LiteralPath "$HKUpath2" -Name 'SCRNSAVE.EXE' -Value $ScreenSaverName -PropertyType String -Force -ea SilentlyContinue;
New-ItemProperty -LiteralPath "$HKUpath2" -Name 'ScreenSaveTimeOut' -Value $ScreenSaverTimeout -PropertyType String -Force -ea SilentlyContinue;
}
# Unmap HKU from available PS drives before exiting
Remove-PSDrive hku
# Clears the error log from powershell before exiting
$error.clear()Until next time 🙂
Consultant manager & SME @ iteam, localized in Kristiansund, Norway.
Focused on EUC, security, mobility, virtualization, management and a modern workplace. Highly specialized around RDS/Citrix/EUC/Mobility.
Hi Geir,
What’s if I want to create a screensaver for our company and deploy it via Intune to all our devices?
Instead of having a blank screensaver as suggested here, can I change that to custom screensaver that we created and deploy it this way? How would that work?
Thank you,
Chad