I’m excited to speak at the in-person event Workplace Ninja User Group Switzerland | Edition 2204 | #WPNinjaCH. The Usergroup event will be held this Friday April 1th in Zürich (Switzerland) at Digicomp. We drive the User Group since a while with the main focus on Endpoint Management, Microsoft Security, Identity and PowerShell. Check out the event website.

Delivering a session in front of “real” people changes a lot again. The nervousness rises a few days earlier than at a virtual event. You want to do it especially well and be well prepared. Not that you don’t do the same in a virtual session, but it’s different. Because of the pandemic, the event could no longer take place in person. Now we are of course super happy that this has changed (at least for this event).


I will speak about Microsoft Information Protection and some more topics. Make sure to bring your use cases for MIP.


Microsoft Information Protection – Getting started and keep an eye on your data! Session 1, 8:15 AM – yes, 8:15 AM


“You started with Microsoft 365, great! A lot of your data now moved to the cloud, so what’s next? This session will show you how to get a good start on data protection using Microsoft Information Protection (MIP). Get the full overview of what Microsoft Information Protection is and how it can help protect our data at rest. Covering everything you need to know, to get started with data classification and how to use Sensitivity Labels on file and group levels to protect your data. And one of the most important: Know where your data is stored, even if data is travelling!”


We will cover those topics:

Hope to see you at the event!


Often an app needs to be checked and/or uninstalled quickly or less quickly. This can be the case when a built-in app installs a component that is actually not wanted. I have made an example script here, which uses the Proactive Remediation of Endpoint Manager (MEM). I will not go into detail what MEM or Proactive Remediation is. Only, use Proactive Remediation :-)!

No matter if you use MEM or MEMCM, you will surely know the uninstall string of an app in the registry. I use this to query the details of the app. This has the advantage, if a version changes or is not 100% identical with the same parameters, that the remove still works.

So first I query the registry and search for the app in the uninstall keys. In this case I know that it was registered in the WOW6432Node. In this example it is about the “Intel Driver & Support Assistant”. As this software uses a new GUID for new versions, it make sense not to use the GUID as a parameter, only if you like to uninstall a specific version this maybe make sense.


Getting the app details. For sure you could use any property of the $appdtails to query. In my case I use the “InstallLocation” and the “DisplayName”

$appdetails = (Get-ItemProperty Registry::HKLM\SOFTWARE\WOW6432Node\Microsoft\Windows\CurrentVersion\Uninstall\*) | Where-Object {$_.InstallLocation -eq "C:\Program Files (x86)\Intel\Driver and Support Assistant\" -and $_.DisplayName -eq "Intel Driver && Support Assistant"}

In a second detection step you can check if the app is present or not. If not,
Exit 0 is used. If available exit 1 is used. Exit 1 forces the remediation.

try {
    if ($appdetails.DisplayName -eq "Intel Driver && Support Assistant"){
    Write-Output "Intel Driver & Support Assistant is installed and will now be removed"
    Exit 1

    else {
    Write-Output "Intel Driver & Support Assistant is not installed. No action required"
    Exit 0

    $errMsg = $_.exeption.essage
    Write-Output $errMsg


Now lets go to the remediation. As soon as the detection script is terminated with exit 1, the remediation script is started.

First I start with a view parameters such as argumentlist. This details can also be found in the regkey or our variable $appdetails. Again, I check the app details:

param (

    [string]$msiname ="Intel Driver and Support Assistant Installer.msi",
    [string]$pathsw = $appdetails.InstallLocation,
    [string]$argumentlist = "/X" + $appdetails.PSChildName + " /qn" + " /noreboot",
    [string]$uninstallsource = $appdetails.InstallSource + $msiname

$appdetails = (Get-ItemProperty Registry::HKLM\SOFTWARE\WOW6432Node\Microsoft\Windows\CurrentVersion\Uninstall\*) | Where-Object {$_.InstallLocation -eq "C:\Program Files (x86)\Intel\Driver and Support Assistant\" -and $_.DisplayName -eq "Intel Driver && Support Assistant"}

Then I create a new region block with the remediation to uninstall the app. This is done with the start-process command.

#region Uninstalling Intel Driver & Support Assistant
try {
    if ($appdetails.DisplayName -eq "Intel Driver && Support Assistant") {
    Start-Process "msiexec.exe" -ArgumentList $argumentlist -Wait -NoNewWindow
    Write-Output "Intel Driver & Support Assistant removed"
    exit 0

    Write-Output "Intel Driver & Support Assistant is not installed. No action required"
    exit 0
    $errMsg = $_.exeption.essage
    Write-Output $errMsg


Save both scripts so that they can be imported into the MEM. Under endpoint.microsoft.comReports Proactive Remediation create a new script package and use the following properties:

Name: Detect and remediate Intel Driver & Support Assistant (or similar)
Settings: Detection script – select your saved detection script
Settings: Remediation script – select your saved remediation script
Run script in 64-bit PowerShell: Yes
Assignments: Select a group, all devices and/or filters (I love filters)
Schedule: I use “Hourly”, Repeats every hour

Deploy the package to your devices. As soon as the client has made an agent update via IME, the script packages will be executed and reports back to Endpoint Analytics.

To get more insights, use the “Columns” View. This will show you the Write-Output messages we have defined in the script earlier.

For example the Pre-remediation output message:

Let me know if this was helpful or leave a comment if you have any questions.


Maybe you’re aware of the Office cloud policy service config.office.com where you can configure your Microsoft 365 Apps for Enterprise policies. If you select this strategy to configure the policies instead of using GPO’s, policies will be applied even on unmanaged devices. This is a huge benefit to combine the company security requirements and the flexibility to apply all configuration to any office apps and based on the user who is logged in to his office applications.

During rollouts, changes or even using an automated way for service providers, there is an API available but not pretty well documented (for not to say, not documented :-)). Let me know if you have any good links for that specific topic.

The first steps of all is to get the API backend URI and a Bearer token to authenticate with VS Code. Therefore you can use your browser in F12 mode or tools such as Fiddler Everywhere.

Browse to config.office.com within the new browser window and Sign in. Make sure that you have the proper permissions to use the App Admin Center. Required permissions:  Global Administrator, Security Administrator, or Office Apps Admin.

To get the Bearer token, use the F12 Dev Tools from Edge Chromium or any other browsers or Fiddler. Start the Dev Tools, select Network clear the history an make sure you’re recording the network session.

Go to Policy Management on config.office.com. In the network recording, Headers, you will now see the Name “policy” where also the Bearer token is listed under authorization.

Copy the token to PowerShell or to VSCode and create a variable such as $accesstoken:

#Insert token from Browser
$accesstoke = @"
Bearer Bearer token here

Next, build your authHeather:

#Form request headers
$authHeader = @{
"Content-Type" = "application/json"

Your $authheader will look like this:

From here, you can use the token to request your policies or also to create new policies, depending of your role of course. Get all your current policies by using the Invoke-RestMethod command. As you can see in the example bellow, the API URI is https://config.office.com/api

#Get all Policies
$uri = "https://config.office.com/api/OfficeSettings/policies/"
Invoke-RestMethod -Method GET -Uri $uri -Headers $authHeader


In the next post, I will show you ho to create or update a policy using the -POST Invoke-RestMethod


Many of you are joining our user group events on a regular basis and since years. Thanks to all of you, for this great community support! Yesterday, my buddy, Roger Pollini, and I defined the event dates for 2022. Find them bellow:

Event 1: 17.02.2022 – (REMOTE) Cloud Workplace Meetup #11
Event 2: 31.03.2022 – (REMOTE) Cloud Workplace Meetup #12
Event 3: 12.05.2022 – (REMOTE) Cloud Workplace Meetup #13
Event 4: 04.10.2022 – (REMOTE) Cloud Workplace Meetup #14
Event 5: 24.11.2022 – (REMOTE) Cloud Workplace Meetup #15

Link to the events: https://www.meetup.com/CloudWorkplace/

Of corse, its a free event! Jus make sure to click on “I’m going” 🙂
If you’re new, feel free to subscribe and join the first event in less than a month.


Depending on the current pandemic situation, we try to to organize an in person event during May 2022. There is for sure no guarantee right know, that we can held this that way. However, we’re super happy to welcome you also remote and having your support!


This year, we will have some new speakers on the stage. This is super cool, as this is part of community work to give persons a chance to start their speaker journey. But for sure, we will also host some experienced speakers. If your a MVP or you would like to have a session, feel free to contact Roger or myself. The sessions are mainly held in German.

Thank you again for being a part of the Microsoft Cloud Workplace User Group!


This is a short post about how to use the serial number of your computer as computer name.

During a deployment, maybe a cloud deployment of your Windows 10/11 clients (not talking about Autopilot), you will have to define a computer name. The easiest way to get a random and never the same name, is to use the serial number.

Not all vendors do use the same style of the serial number. For example HP uses 11 characters while Fujitsu only has 10 (depends on the models as well). So let’s get started:

First we need to get the serial out of the device. I always use Get-ComputerInfo


Be aware, that there is a small bug in the Paramater BiosSerialNumber. On some Windows versions (I guess all Windows 10) the parameter is called (missing an “i”):


As a next step, you may would like to have a prefix within your computer name. If you decide to use a prefix, put that in a variable such as:

$prefix = "LDC-"

So let’s put it together using the command without a bug. This works on Windows 11. And then put the serial in to the variable $serial:

$prefix = "LDC-"
$serial = Get-ComputerInfo | Select-Object BiosSerialNumber
$serial = $serial.BiosSerialNumber

As a computer name (NetBIOS) has a limit of 15 characters, we need to shorten the serial to, let’s say, 10 characters (0, 10), starting from the beginning (0, 10):

$serial = $serial.substring(0, 10)

Now let’s put the computer name together into the $computername variable using the $prefix and the $serial variables:

$computername = $prefix + $serial

The result will looks like that (based on your hardware and serial):


Finally run the rename computer cmdlet and reboot the machine. You computer has a new name with a prefix and a part of your serial.

Rename-Computer -NewName $computername -Force -ErrorAction SilentlyContinue

Let me know what you think. Cheers!