Deploy Windows 11 with MDT - Supported

 Introduction

The Microsoft Deployment Toolkit (MDT)  has been used by many companies for the provisioning of operating systems.  It does have a mature and powerful task sequencing engine.  And while not really scalable to enterprise level environments, and being a firmly lite touch rather than a zero touch solution - it does have one major benefit.  It is free.

Many thousands, if not millions of Windows operating systems will have been provisioned in build rooms throughout the world using MDT.  Unfortunately the last client OS to be supported was Windows 10.  Windows 11 is not supported, and in fact you cannot import the Windows 11 Operating system into the Deployment Share.  Nevertheless Windows 11 can be deployed using MDT and in such a way as to be fully supported.  Here is how it is done.

1) Create a task sequence to deploy Windows 10, or use your existing MDT Windows 10 task sequence.  Configure the TS with your applications and settings.

2) Configure the TS to copy the Windows 11 source files to a location on the device being built.

3) Create a TS step to configure a Scheduled Task to run a Windows 10 to Windows 11 upgrade a few minutes after the completion of the Windows 10 Task sequence.

4) Autologon to the device and wait for the Windows 11 upgrade to complete.

The Windows 10 to Windows 11 upgrade is completed after the completion of the Windows 10 task sequence, and because it is started by a task scheduler job, and not MDT; it is a fully supported solution.

This article will cover steps 2,3 and 4.

Copy the Windows 11 Files

You w‎ill need to create a share on your network to contain the Windows 11 source files.  For our purposes we shall call it \\mdtserver\software.

Under this share create a directory called Windows11Files and under this create a directory called Source.  So we have:

\\mdtserver\software\Windows11Files\Source

Copy your Windows 11 source files into this directory.

You will then need to decide on where you will be copying these files on the device itself.  In my case I will be copying these files to c:\support\Windows11.  

Thus I create two task sequence steps to create this path.  The first TS step runs the following command:

cmd.exe /c mkdir c:\support

The second TS step runs the following: 

cmd.exe /c mkdir c:\support\Windows11

The next TS step will need to copy the Windows 11 files to the provisioning device.  The command line I have used to achieve this is as follows:

cmd.exe /c robocopy \\<mdtserver>\software\Windows11Files c:\support\Windows11 /e

Note1:  you may have to select the Run this step as the following account option and then supply an AD account with adequate permissions to access the software share.

Note2: All three of the above task sequence steps are of the type Run Command Line.

Note3: All TS steps detailed in this article should be positioned towards the end of the task sequence, and definitely after the Post Install group.

Create a Scheduled Task to upgrade to Windows 11

Now that we have configured the TS so that the Windows 11 Source files are available locally on the provisioned device, we need to create a Scheduled Task job to perform the upgrade itself.  The script provided here will create a scheduled task to start five minutes after the time the script is executed.  Therefore it should be configured to run as a Run Command Line TS step towards the end of your task sequence so that the task schedular job does not start while the TS is still running.

In this case I call the script win11ug.ps1 and I copy it to the MDT DeploymentShare's script directory, that is: \\<mdtserver>\DeploymentShare$\Scripts.

The Run Command Line TS step contains the following:

powershell.exe -executionpolicy bypass -file "%SCRIPTROOT%\win11ug.ps1"

In addition the Run Command Line step is configured to run under a Domain Admin account.

Here is the script:

#Get ST start time and ensure time format will work with schtasks syntax

$execdate=(get-date).addminutes(5)

$exectime=($execdate).timeofday

$hourchk=[string]$exectime.hours

$minutechk=[string]$exectime.minutes

if ($minutechk.length -lt 2) {

$minute="0"+$minutechk

}

else {

$minute=$minutechk

}

if ($hourchk.length -lt 2) {

$hour="0"+$hourchk

}

else {

$hour=$hourchk

}

$time=$hour+":"+$minute

#Run the schtasks command to create the task schedular job

schtasks /create /tn "Win10Upgrade" /tr "C:\support\windows11\source\setup.exe /Auto Upgrade /EULA accept" /ST $time /RL Highest /ru interactive /sc once

Autologon to the device 

The last Run Command Line TS step is required to run a script that will perform an autologon.  The command line that worked for my scenario was as follows:

Powershell.exe -executionpolicy bypass -noprofile -file "%SCRIPTROOT%\AutoLogon.ps1"

And here is the script itself.  Obviously replace credentials accordingly.

reg add "HKLM\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Winlogon" /t REG_SZ /v AutoAdminLogon /d 1 /f

reg add "HKLM\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Winlogon" /t REG_SZ /v DefaultPassword /d <password> /f

reg add "HKLM\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Winlogon" /t REG_SZ /v DefaultUserName /d <local admin account name> /f

reg add "HKLM\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Winlogon" /t REG_DWORD /v AutoLogonCount /d 1 /f

This script needs to be copied to a file called Autologon.ps1 and then copied to the DeploymentShare's script directory: that is,  \\<mdtserver>\DeploymentShare$\Scripts.

The last step in your TS will be to perform a reboot.  A few minutes after the reboot completes, and after the autologon completes, the upgrade to Windows 11 will commence.

To help you position each of the steps covered in this article, in the correct order, I have included a capture of the steps towards the end of my task sequence. 

Now after your task sequence completes, and within five minutes, the Windows 10 to Windows 11 upgrade will commence and there will be no requirement for any user input.

Conclusion

It might be that your client is not in a position to install an OSD solution that will deploy Windows 11 - in which case this solution may help you. It is a Heath Robinson type workaround to MDT's limitation.  It works well but you will have to decide if an upgrade solution, rather than a pure baremetal to Windows 11 solution, is something your organisation can accept.

I hope you have enjoyed reading this little blog.

Win 11 Let's Connect you to a Network - After OSD Task Sequence completes

Introduction

Recently I put together an MECM task sequence to install Windows 11 Enterprise.  The task sequence would run through and complete all the steps successfully.  After completion the "Let's connect you to a network" window would appear.  The engineer then had to click on "I don't have internet access" and then on "Continue with a Limited setup" in that order, to arrive at the sign in page.  Yes this is only two mouse clicks but I did want to bypass this in an automated way and arrive at the sign in page without this manual input.

The Fix - Part 1

The key to bypassing this "Let's Connect you to a network" screen was to kill the oobenetworkconnectionflow.exe process using the taskkill.exe tool.  If run from a command prompt, the line would be as follows:

taskkill /F /IM oobenetworkconnectionflow.exe

The Problem

Initially I thought that creating a task sequence step to run this command at the end of the Task Sequence would do the trick, however it did not.  This is because the Network Connect page only appeared after the task sequence completed.

My next idea was to run the command as a value for the SMSTSPostAction task sequence variable.  This variable allows you to specify a command to run after the task sequence completes, but before exiting the task sequence - which sounds a bit contradictory.  This approach did not work either - probably because the Network Connect page had not started at the point in time at which the SMSTSPostAction command executed.

The Fix - Part 2

The taskkill command had to be run at a time that I was sure the oobenetworkconnnection.exe 

process was actuated - that is, at a time in which the Let's connect to a network was really displaying on the screen.  This occurred 30-60 seconds after the completion of the task sequence.  Thus I created a PowerShell script that would create a task schedular job to run two minutes after the time the script was run.  The script would be run as the last step in the build task sequence.

This is the PowerShell script:

$execdate=(get-date).addminutes(2)

$exectime=($execdate).timeofday

$hour=[string]$exectime.hours

$minute=[string]$exectime.minutes

$time=$hour+":"+$minute

$sta=new-scheduledtaskaction -execute "taskkill" -argument "/F /IM oobenetworkconnectionflow.exe"

$stt=new-scheduledtasktrigger -once -at $time

register-scheduledtask CancelNetworkFlow -action $sta -trigger $stt -runlevel highest -user "NT AUTHORITY\SYSTEM"

I saved this script as stopncf.ps1

The MECM Package

There are many different ways to run a PowerShell script in MECM - I got this one working by using the good old fashion legacy package.  I then plugged this as a last step in the OSD Windows 11 task sequence as an Install Package step.  The package contained a Program Command Line consisting of the following:

powershell.exe -executionpolicy unrestricted -file stopncf.ps1

The package content consisted of the above PowerShell script called stopncf.ps1.

I have included below the various screenshots of the package settings, in the case that you would like to follow a similar solution.  The package name is StopNWC.

The Task Sequence Step

As already mentioned this package was added as the last step of the Window 11 OSD task sequence.

And here are the details of the sequence step.

C

Conclusion

This issue is normally seen during the task sequence installation itself - but as can be seen it may occur after the task sequence completes.   We can use the solution presented here to remove this unwanted screen, using the task schedular service and a little bit of PowerShell. For those who like to have the entire process automated, I hope you have benefited from this little blog.

VMWare Horizon Client on HP ThinPro Thin Client - Allow connection via an SSL Proxy

Introduction

I wanted to set the security for the Horizon Client, on my HP ThinPro Thin client device, so that it would never connect to untrusted servers.  

Certificates were correctly installed on both the thin client and the Horizon Connection server.  

The demand was that the Horizon client must refuse insecure connections.  

This is the safest configuration and in this particular setup I was able to get this working - however I did have to ensure that the Allow Connection Via an SSL Proxy setting was enabled as a preference on the Horizon connecting client.

Without this particular setting enabled, I would receive the following error whenever I tried to connect to the Horizon connection broker: The tunnel server presented a certificate that doesn't match the expected certificate.

The Problem

Having an acceptable workaround was great but deploying this workaround, in an automated fashion, was a challenge.  Typically with these sort of settings I could:

1) Manually enable the setting on the Thin Client itself.

2) Use the HPDM console to capture a profile of the HP ThinPro client.

3) Deploy the captured profile to all HP ThinPro clients using the HPDM console.

This did not work - the setting did not get captured as part of the HPDM profile capture operation.

The Solution

I could not find any VMWare documentation in relation to the HP ThinPro Horizon client, to assist me with this task.  I did however find a VMWare article about the Linux Horizon client.

Configuring the Certificate Checking Mode for End Users (vmware.com)

Now the HP ThinPro operating system is Linux based, and so I thought it might work - and it did.  All I had to do was create a HPDM deployment task to deploy the solution.  Here is how I did it.

1) On the HPDM server create a file, using notepad, called view-mandatory-config.  Ensure the file has no extension such as .txt

2) Populate this file with the following two entries and save the file.

view.allowAllowSslProxy="True"

view.allowSslProxy="True"

3) After saving the file, open the HP Device Manager console.

4) Click on Templates & Rules and then click on Add a Rule.

5) Provide a rule name - in this case I type in Deploy view-mandatory-config.  Click on Next.

6) On the Target page click on Next.

7) On the Constraints page click on Next.

8) On the When page specify when you would like your file deployed and click on Next.

9) On the Action page double click on _File and Registry.  The Template editor appears.

10) Click on Add and then click on Deploy Files and then on OK.

11) The Deploy Files window appears.  Click on Add from local and select your view-mandatory-config file.

12) Under the Path On Device column type in /etc/vmware/ and hit Enter and click on OK and OK again.

13) Back at the Action page click on Next.

14) On the Task Parameters window click on Next.

15) At the summary window click on Run Now if desired and then click on Finish.

16) The Package Description Editor window appears.  Click on Generate.

17) The new rule appears under Scheduled Rules.  Again you can right click on the rule, if desired, and select Run Now.

Conclusion

When this rule has run on the HP Thin Pro client,  the Allow connection via an SSL proxy option will be selected.  As long as you have the Never Connect to Untrusted option selected, you can then be sure that you have a secured connection to your Horizon Connection Broker.  I hope you have enjoyed this article.

Recover your corrupted Linux HP ThinPro Thin Client Device

Introduction

While testing some functionality in my HP  T530 Thin Client's Linux based ThinPro 8 operating system, I found myself with a corrupted partition.  I was testing the BIOS password removal process using the inbuilt hptc-bios-cfg tool.  After running the tool and initiating a reboot, the ThinPro operating system refused to load, leaving me in an initramfs shell.  Now I am not a Linux expert but I did try a few things, even finding myself in a grub shell where I could list and search each partition for the expected operating system files.  I couldn't find the expected partition with the expected files.  How was I to recover this thin client's ThinPro operating system with my limited Linux know how?  I did find a way out of this mess, which I will write about in this blog.  It might work for you as well.

How I recovered my T530 Thin Client

In summary I was able to restore my TC by:

1) Booting the TC device into the Windows PE environment from a bootable USB key

2) Deleting all partitions on the TC's drive, and creating a new partition.

3) Booting the device into the HP ThinPro PC Converter Tool's environment from a bootable USB key created using the HP ThinPro PC Converter Deployment Tool application.

4) Applying the ThinPro 8 operating system to the TC's drive.

To fix your failing ThinPro operating system you will need to install the following applications on a Windows 10 or Windows 11 device:

• HP ThinPro PC Converter Deployment Tool (HP_ThinPro_PC_Converter_Deployment_Tool_N44254-002.msi) -  get an evaluation license and the installer here: h30670.www3.hp.com/portal/swdepot/displayProductInfo.do?productNumber=HPTPPCCT

• Windows Assessment and Deployment Toolkit (adksetup.exe) -available here: https://learn.microsoft.com/en-us/windows-hardware/get-started/adk-install#download-the-adk-101253981-september-2023

• Windows PE add on for Windows Assessment and Deployment Toolkit (adkwinpesetup.exe) - available here: https://go.microsoft.com/fwlink/?linkid=2243391

Install the above applications using the default installation options.  Ensure you have two USB keys.  These will be wiped clean so make sure you backup any important data on them.

Create a WinPe bootable USB key

• Connect a USB key to your Windows device, after installing the above applications - make a note of the drive assigned to the key; this is usually d:
• Right click on the Deployment and Imaging Tools Environment from the Start menu and select More and then Run as Administrator.

• Extract the WinPE files by running this command: copype amd64 C:\WinPE_amd64
• Create the USB WinPE bootable device with the following command MakeWinPEMedia /UFD C:\WinPE_amd64 <drive of USB Key>.  For instance: MakeWinPEMedia /UFD c:\WinPE_amd64 d:
• Press Y to agree to losing any data on the USB key.

You now have your bootable WinPE USB key.  Remove it from your device.

Create a HP  ThinPro PC Converter USB key

Insert your second USB key and follow these steps to create the HP ThinPro PC Converter USB key.

• From the Start menu run the HP ThinPro PC Converter Deployment Tool.  Browse to your license file or click to Get a Trial License.  Click on Next.

• Click the second option - Installer USB Flash Drive

• If this is the first time you have run the tool you can click to Download v8.0.0, otherwise browse to select the desired image if the image box is not already populated.

• Click on Create and then Exit when the converter key has been created.

Clear your Thin Client's Partitions using WinPE

Insert the WinPE bootable USB key into a slot on your Thin Client and boot to this disk (usually by pressing F9 or ESC).  You will be presented with the cmd.exe shell.

• Type diskpart and Enter and then list disk.  This will display the Thin Client's disks as well as the USB key.  Make a note of the TC's main disk - usually disk 0

• Type select disk <TC's main disk - usually disk 0).  In this case I type select disk 0 and press enter,
• Warning this command will wipe your main disk.  Type clean and enter.
• type create partition primary and press enter.
• Type Active and press enter
• Type Exit and then press enter

You have now reset your primary disk to accept the ThinPro operating system restoration.

Restore the ThinPro Operating System

Remove the WinPE bootable USB key and insert the HP ThinPro PC converter bootable USB key.

• In the WinPE cmd.exe shell type exit.  The TC will reboot.  Pressing ESC or F9 boot into the ThinPro converter USB key

• The ThinPro converter tool will carry out a compatibility Check

• Click on Install ThinPro to internal Storage.
• Click on OK to accept the disk wipe out warning.
• Click No if prompted to Preserve current ThinPro settings.
• The ThinPro OS installation commences.  

• The Running custom ThinState operation completes.  

• Click on OK and click on Details to view the completed events.

• Click on Close and remove the Converter USB key.
• The TC reboots and the ThinPro operating system loads.  After a few minutes you are presented with the HP ThinPro setup wizard.  Complete the setup as desired.

Congratulations you have recovered your corrupted HP ThinPro Operating System.

Create a MECM maintenance window using PowerShell

Introduction

There are of course many changes required on a laptop or a desktop.  We need to apply security updates or deploy a new piece of software - we may even need to run a task sequence to upgrade the operating system.  But can we control when these changes occur?  Afterall, it would be very inconvenient for a set of updates to install on a salesperson's laptop while doing a presentation.  The installation may slow the device down or force a reboot; and this can look very unprofessional indeed.

The good news is that we can create maintenance windows on collections of devices.

Creating a maintenance window without PowerShell.

If we right click on a collection in the MECM console and select Properties, we are then able to select the Maintenance Windows node.  Here I have the Maintenance Windows node of my Sales Devices collection.  As can be seen there are no maintenance windows defined, meaning that deployments can run anytime on these devices - if the users have not specified their own maintenance window in Software Center.

We can then click on the yellow asterisk (*) and configure our maintenance window for this collection of devices.

Here I have created a five hour maintenance windows for every Tuesday between 18:00 and 23:00 UTC and for Software Updates.

Clicking on OK and then Apply will ensure that software updates only occur during this time frame on this collection's devices.

Note:  Deployments still may occur outside of the maintenance windows if the deployment has overran its deployment deadline, depending on how the administrator has configured the deployment.

Create a Maintenance Window with PowerShell

Starting with MECM 2307 we are able to create maintenance windows using PowerShell.  In this exercise we shall create the above maintenance window from the PS command console.

First we open the MECM console and click on the top white down arrow in the upper left blue box.  We select the Connect via Windows PowerShell option.

If prompted with "Do you want to run software from this untrusted publisher?" select A for Always.

We use the New-CMMaintenanceWindow PowerShell cmdlet.  Here are the options for using the collection name as the input object. 

 New-CMMaintenanceWindow [-CollectionName] <string> -Name <string> -Schedule <IResultObject#SMS_ScheduleToken> [-ApplyTo    {Any | SoftwareUpdatesOnly | TaskSequencesOnly}] [-ApplyToSoftwareUpdateOnly] [-ApplyToTaskSequenceOnly] [-IsEnabled    <bool>] [-IsUtc <bool>] 

It does look rather complicated, so let's just create one by first using the new-cmschedule cmd line to define the SMS_ScheduleToken input.  To create the above schedule token we would type the following

$ScheduleMW= New-CMSchedule -DayOfWeek Tuesday -DurationCount 5 -DurationInterval Hours -start "21/12/2023 17:00"

Having created the Schedule token we can now use the New-CMMaintenanceWindow cmdlet to create the Maintenance Window on our collection.  The Maintenance Window will be similar to the Software Updates window created above, but will have a start time of 17:00 rather than 18:00.  Its name will be MW for Sales Team,

The command line is as follows:

New-CMMaintenanceWindow -CollectionName "Sales Devices" -Name "MW for Sales Team" -Schedule $ScheduleMW -ApplyTo SoftwareUpdatesOnly -IsUtc 1

As can be seen we do get a very satisfying results return indicating that our maintenance window is created.  And if we check on the properties of the collection itself, we can confirm that the new maintenance windows is created and is correct.

Conclusion

As can be seen, we do not have to rely on the MECM console interface to create a maintenance window.  We can use the New-CMMaintenanceWindow PowerShell cmdlet to create the maintenance window from a script file or from the PowerShell console.  I hope you have enjoyed this article and I wish you similar success with your own testing of the New-CMMaintenanceWindows PowerShell cmdlet.

Microsoft Print To PDF - Setting the Paper Size Preference using PowerShell

Introduction

A client's users would often use the Microsoft Print to PDF printer driver to create a PDF file of a document.  The user would then create a Word document and send this to a printer application.  The printer application GUI would allow the user to attach the PDF so that both the Word Document and the PDF document were sent to the printer application.  Both documents might would then be physically printed and sent to the customer.

In a number of cases this failed.  On further examination we could see the issue's cause by firstly double clicking on the Microsoft Print to PDF printer, in Control Panel\Devices and Printers, and then selecting Printing Preferences.

Secondly, clicking on Advanced in the Microsoft Print to PDF Preferences window.

We could then see that the Paper Size was set to Letter.  Changing this to A4 resolved the printing issue.

This fix worked nicely, however we could not apply it manually in this way to hundreds or thousands of devices.  How could we change the paper size preference on hundreds of devices in an automated manner?  A search of GPO options did not look promising.  And so I explored a number of scripting options.  

The Set-PrintConfiguration CmdLet Option

The following command should have corrected the issue for us but it did not.

set-printconfiguration -printername 'Microsoft Print to PDF' -papersize 'A4'

The printer's paper size preference was still set to Letter.

The PrintUI.exe Tool option

Another approach I tried was to manually set the paper size preference to A4 and then use the PrintUI.exe tool to create a migration export file. I could then use this export file to import the new paper size preference on the other devices.  The command to create the printer export file was as follows:

printui.exe /Ss /n "Microsoft Print to PDF" /a c:\MicrosoftPrintToPDF.printerexport

This created the named .printerexport file.  I was then able to import this file onto other devices and it did appear to work.  Here is the command used to import the settings onto another device.

printui.exe /Sr /n "Microsoft Print to PDF" /a c:\temp\MicrosoftPrintToPDF.printerexport u

 

I did have some success with this however testing showed it had to be executed under the logged on user context.  And then it would only work when the user had elevated administrator rights.  Normally I could script around this requirement using the execute-processasuser cmdlet from the PSAppDeployToolkit.  For instance:

execute-processasuser -path 'printui.exe' -parameters '/Sr /n "Microsoft Print to PDF" /a c:\temp\MicrosoftPrintToPDF.printerexport u'

It still would not work when deployed via Conifguration Manager to a user with non admin permissions.

The Dism Option

The method that worked reliably for this issue was the Dism Option.  Using the Dism I could uninstall the Microsoft To PDF printer and then re-install it.  This would result in the papersize preference being set to to the A4.  Here is the command to uninstall the printer:

Dism /Online /Disable-Feature /FeatureName:"Printing-PrintToPDFServices-Features"

And here is the command to install the printer once more.

dism /Online /Enable-Feature /FeatureName:"Printing-PrintToPDFServices-Features"

For those who like to use the PSApp Deployment Toolkit for their packaging wrapper, here is the section in the deploy-application.ps1 script that performs the fix.

The Exceptions

In most cases this all worked nicely.  However in some cases the paper size preference was still set to Letter after the printer was removed and then re-added.  In these cases I noticed that the language for non-unicode programs was set incorrectly.  This was set to English (United States) rather than English (United Kingdom).  This setting can be found in Control Panel\Region and the clicking on the Administrative tab.

It can be changed here by clicking on Change System Locale, but only if the user has admin rights.  A reboot is then required.  Obviously this also needed automation and so I found this was possible using the following PowerShell command

Set-winsystemlocale –systemlocale en-gb

Again, a reboot is required and Configuration Manager can be configured to force this.  Once this is done, then the dism commands can be used to correct the paper size preference.

Conclusion

This is a great example of how a simple requirement can often be quite complex to achieve.  But with some tenacity and patience, we can eventually find a way through and keep our client satisfied.  I hope you enjoyed reading this blog and wish you the same success with your printer configuration requirements.

Google Chrome - Set to Unmanaged Using PowerShell

Introduction

Recently a support technician had some issues with the Google Chrome application.  As a support specialist the ability to modify or uninstall an application is useful.  In the same way that just restarting a device can resolve many issues, so can uninstalling and reinstalling an application resolve a great many problems.  In this case however, and even with administrator permissions, the technician was unable to modify or uninstall the Google Chrome application.  If he right clicked on Google Chrome in the Start Menu, and selected Uninstall - this would bring up the Control Panel\Uninstall or change a program window.  The Google Chrome application was not there to uninstall and so the Uninstall selection item was useless.

In this company Google Chrome was a managed application.  This can clearly be seen by clicking on the ellipses icon to the right of the browser's ribbon.  The lower entry reading Managed by your organisation.

And so the reality here is that the technician is very limited in what he or she can do while troubleshooting an issue relating to the Google Chrome application.  Any setting that has been configured, such as the homepage, cannot be modified.  And neither can the application, at least in this instance, be uninstalled.  And worse - although this is by design for this organization - if Google Chrome is showing as managed on your own personal device; you may indeed have a malware or virus.

The Task

The task given to myself was simply to provide a means for the support technician to uninstall Google Chrome by clicking on an application within MECM's Software Center. A bit of research and some testing and I did find a way to uninstall Google Chrome in this scenario.  

Manually, the administrator could open a command prompt as administrator and navigate to c:\program files (x86)\Google\Chrome\Application\<version>\Installer and run the following command

setup.exe --uninstall --multi-install -chrome --msi --system-level --force-uninstall

But what if the technician only wanted to change some settings?  How could we flip this installation of Google Chrome from Managed to Unmanaged?

Solution: Force Google Chrome into Unmanaged mode

Again a bit of research and some testing and I arrived at a way to remove the Managed by your organization lockdown setting.  This did entail running a few lines of PowerShell code.  If you were to open a command prompt as administrator and then run:

powershell.exe -executionpolicy unrestricted

Within the PowerShell console, running the following commands will switch your instance of Google Chrome over to unmanaged.

remove-item -path "HKCU:\Software\Google\Chrome\*" -recurse -force

Remove-item -path "HKCU:\Software\Policies\Google\Chrome" -recurse -force

Remove-item -path "HKLM:\Software\Google\Chrome\*" -recurse -force

Remove-item -path "HKLM:\Software\Policies\Google\Chrome\*" -recurse -force

Remove-item -path "HKLM:\Software\Policies\Google\Update\*" -recurse -force

Remove-itemProperty -path "HKLM:\Software\WOW6432Node\Google\Update\ClientState\{430FD4D0-B729-4F61-AA34-91526481799D}" -name "CloudManagementEnrollmentToken"

Remove-File -Path '%ProgramFiles(x86)%\Google\Policies' -recurse

Remove Google Managed Mode, Uninstall and Clean up

Let us say you do suspect your device has been infected and you want to be confident that:

1) Registry settings that place Google Chrome under managed mode are removed

2) Google Chrome is removed 

3) Remnants such as Google Chrome taskbar and desktop icons are removed 

You could run the following PowerShell code:

remove-item -path "HKCU:\Software\Google\Chrome\*" -recurse -force

Remove-item -path "HKCU:\Software\Policies\Google\Chrome" -recurse -force

Remove-item -path "HKLM:\Software\Google\Chrome\*" -recurse -force

Remove-item -path "HKLM:\Software\Policies\Google\Chrome\*" -recurse -force

Remove-item -path "HKLM:\Software\Policies\Google\Update\*" -recurse -force

Remove-itemProperty -path "HKLM:\Software\WOW6432Node\Google\Update\ClientState\{430FD4D0-B729-4F61-AA34-91526481799D}" -name "CloudManagementEnrollmentToken"

Remove-File -Path '%ProgramFiles(x86)%\Google\Policies' -recurse

execute-process -path 'setup.exe' -parameters '--uninstall --multi-install -chrome --msi --system-level --force-uninstall'

remove-item "C:\users\*\Desktop\Google Chrome.lnk" -force

remove-item "C:\users\*\AppData\Roaming\Microsoft\Internet Explorer\Quick Launch\Google Chrome.lnk" -force

remove-item "C:\users\*\AppData\Roaming\Microsoft\Internet Explorer\Quick Launch\User Pinned\Taskbar\Google Chrome.lnk" -force

Conclusion

I did include the above script in a PSApp deployment toolkit wrapper, and registered it in MECM so that support staff could easily unmanage and remove Google Chrome for troubleshooting purposes.  Of course you can use any other package deployment solution, such as Intune, to achieve the same thing.  I hope you enjoyed reading this article and I hope my solution works for yourself, if ever you face a similar request.

Colin