Configure registry with CSP
There are a several ways to change/add/edit/delete Windows Registry settings.
We need to decide if the registry key is located under the Policy hive or not. If this is the case, you need to run a PowerShell script.
But let’s start with the easy way to publish registry keys with CSP.
We assume that we want to configure Office settings via the registry. Some are in HKLM and some are in HKCU.
In general its quite easy to add a registry key via custom profile.
<wap-provisioningdoc id="1164DF07-F217-449B-95F8-FB85A34D3CA5" name="customprofile">/
<characteristic type="com.airwatch.winrt.registryoperation" uuid="4fa91319-eac0-4a16-9d10-093ba845b698">
<parm RegistryPath="HKCU\SOFTWARE\Test\FakeApp" Action="Replace">
<Value Name="SetupURL" Data="fakeapp.com" Type="String" />
<Value Name="FakeAppFeatureFlag" Data="4a" Type="REG_BINARY" />
</parm>
</characteristic>
</wap-provisioningdoc>
First – as always with custom profiles, make sure that you create unique ID and UUID. With PowerShell its a oneline to create a random guid. Just run this command:
[guid]::NewGuid()
In this example, we would create a new Regkey under HKCU\Software. As you see the “RegsitryPath” is the Path to the parent key. With the replace option you can make sure that even if the values are already set, they get overwritten. Of course, you can also use “Add” or “Delete” instead.
After we defined the path, we can now add the values – it is possible to add several values to one path. So, there is no need to create different profiles for registry configuration.
“Name” is the value name, “Data” is the data and “Type” is the registry type – so everything as expected.
It is also possible to add different paths to your profile:
<wap-provisioningdoc id="1164DF07-F217-449B-95F8-FB85A34D3CA5" name="customprofile">/
<characteristic type="com.airwatch.winrt.registryoperation" uuid="4fa91319-eac0-4a16-9d10-093ba845b698">
<parm RegistryPath="HKCU\SOFTWARE\Test\FakeApp" Action="Replace">
<Value Name="SetupURL" Data="fakeapp.com" Type="String" />
<Value Name="FakeAppFeatureFlag" Data="4a" Type="REG_BINARY" />
</parm>
<parm RegistryPath="HKCU\SOFTWARE\Test2\FakeApp" Action="Replace">
<Value Name="SetupURL" Data="fakeapp.com" Type="String" />
<Value Name="FakeAppFeatureFlag" Data="1" Type="DWORD" />
</parm>
</characteristic>
</wap-provisioningdoc>
You only need to add a new “parm” section.
CAUTION
Working with registry keys, or with PowerShell means we need to switch the target of the profile to “Workspace ONE Intelligent Hub”.
Change the Policies key
Basically, this is it – for normal registry keys. If you now try the same thing with e.g. “HCKU\Software\Policies” this will fail. This is because the \Policies key is restricted, and we can not make changes via CSP in it.
If you still want to add keys in the \Policies hive, we need to build a workaround.
This workaround will use the PowerShell function of the VMware Workspace ONE Intelligence HUB.
Let’s start with the basic PowerShell command:
New-ItemProperty -Path "HKLM:\Test\TEst" -Name "Name" -Value ”Value” -PropertyType "String"
We can’t copy paste the command in the custom profile setting – since this would be too easy.
We first need to encode the script to Base64. This is done by this command:
$Script = Get-content -Path C:\Temp\Regkey.ps1 -Raw
$bytes = [System.Text.Encoding]::Unicode.GetBytes($Script)
[Convert]::ToBase64String($bytes) | out-file C:\Temp\test.txt
Of course, you need to change the paths of the input and output file to fit your requirements.
Now we have the encoded script and we can start to build our custom profile ind Workspace ONE.
<wap-provisioningdoc id=“b0774572-29ec-4015-8bde-8f0281682f1b” name=“customprofile” >
<characteristic type=“com.airwatch.winrt.powershellcommand” uuid=“f060bc02-bc0d-4ff8-b5d7-3fdfd24274bb” >
<parm name=“PowershellCommand” value=“Invoke-Command -ScriptBlock {
powershell.exe -encodedCommand %ENCRYPTEDCOMMAND%}
“/>
</characteristic >
</wap-provisioningdoc >
Like in the example above, you need to create unique GUIDS for the “ID” and “UUID” part.
After we changed the UUID and ID, we replace the %ENCRYPTEDCOMMAND% with the encoded string of the “C:\Temp\Test.txt” file.
It should look like this:
<wap-provisioningdoc id=“b0774572-29ec-4015-8bde-8f0281682f1b” name=“customprofile”>
<characteristic type=“com.airwatch.winrt.powershellcommand” uuid=“f060bc02-bc0d-4ff8-b5d7-3fdfd24274bb”>
<parm name=“PowershellCommand” value=“Invoke-Command -ScriptBlock {
powershell.exe -encodedCommand TgBlAHcALQBJAHQAZQBtACAAQwA6AFwAVABlAG0AcABcAFAAUgBPAEYASQBMAEUAVABFAFMAVAAgAC0ASQB0AGUAbQBUAHkAcABlACAARABpAHIAZQBjAHQAbwByAHkAIAAtAEYAbwByAGMAZQAgAA}
“/>
</characteristic>
</wap-provisioningdoc>
CAUTION NO
If you have a long string, the Workspace ONE console might add spaces or line breaks into the string. Make sure you extend the window to see the spaces and remove them!
Current User registry
To change the current user, the script needs to be changed.
See the example for the current user:
# check if HKU branch is already mounted as a PSDrive. If so, remove it first
$HKU = Get-PSDrive HKU -ea silentlycontinue
#check HKU branch mount status
if (!$HKU ) {
# recreate a HKU as a PSDrive and navigate to it
New-PSDrive -Name HKU -PsProvider Registry HKEY_USERS | out-null
}
$Users = (Get-ChildItem HKU:\ | Where-Object {$_.Name -notlike “*S-1-5-18*” -and $_.Name -notlike “*S-1-5-19*” -and $_.Name -notlike “*S-1-5-20*” -and $_.Name -notlike “*.DEFAULT*” -and $_.Name -notlike “*_Classes*“}).Name
foreach ($UserSID in $Users)
{
$SID = $UserSID.Remove(0,11)
$path = “HKU:\$($SID)\Software\Policies\Microsoft\office\common\clienttelemetry”
$RegCheck = Test-Path $path
if($RegCheck -eq $false)
{
New-Item -Path $path -Force
}
New-ItemProperty -Path $path -Name “sendtelemetry” -PropertyType DWORD -Value 3 -Force
}
You are welcome to add more registry keys to change here. Remember to encode the command again before adding it to the custom profile.
Empowering customers in client management since 2012.
Empowering customers in modern management since 2018.
Travis Robertson
Grischa, thank you for this guide. We have had a manual process in place for PC setup that we were able to convert into a few registry entries and deploy via UEM thanks to your instructions. In our case we have to make changes to Excel which are stored in HKCU which of course are only created after the end-user first login. Now we can automate this so we do not have to configure these settings post-deployment. Great work and thanks for sharing.