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.


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!


Ever wanted to create an approval process for your Windows applications in Endpoint Manager? Some apps require approval as they generate licensing cost at the back end. Sure, you can use many solutions for that like Power Platform (Preferred if you’re not using Identity Governance), Active Roles Server, ServiceNow and more – you name it.

But actually there is a “built-in” solution for that. Not built in with MEM but built in with Azure and Identity Governance. If you’re licensed to use Identity Governance and you use it for services such as Privileged Identity Management (PIM) or Access Reviews your good to go. If not, you first have to onboard it. For the solution here, you need at least an Azure AD Premium P2 license or EMS E5/A5 as user.

In a first step create an application within MEM. Go to the MEM Portal https://endpoint.microsoft.com and select Apps, for example create a line-of-business app using a simple MSI. I have downloaded the latest MIP (AIP) client and uploaded it to Intune without any special configuration or silent install commands (for now).

In a second step, create a group with no user assignment and assign the group to the application created before . This could be an AD synced group or a cloud group. Still nothing special here.

Now the interesting part starts!
Browse to Identity Governance in the Azure Portal / Azure Active Directory and start creating a new Access Package using Entitlement Mangement.

From the Basics settings provide a proper name and description, such as “APP – MIP Client (requires approval)”. This name will also be populated to your end-users (also the description).

Under Resource role select + Groups and Teams and browse for the group you have created earlier. In my case mem-app-u-mip-client. Don’t forget to select also the role the user will have within this group. Usually this is just the “Member” role.

On the Request page you will have 3 options you can select. In the case here, we will use For users in your directory and All members (excluding guests). This does guest users not allow to see or request this particular access package.

Enable the Require approval toggle to Yes. This will give you the options to configure the Approval flow. I have selected the following options, but of course your free to change them:
– Require requestor justification: Yes
– How many stages: 1
– First approver: “my demo user”
– Decision in days: 14 (default)
– Require approver justification: Yes
– If no action taken, forward to alternate approvers?: No (advanced request)
– Enable: Yes

Under Requestor information (preview) you have the option to define some specific questions for the requester of the package. For example, you can request to provide some more information about the reason of the usage of this particular app with some multiple choise values.

Within the Lifecycle options we can now define the time of availability of the Acccess Package itself. Let’s say, this access package is only available for the rollout of our MIP Client and we like to define a timeframe of 1 year (365 days) of availability (this is just a random pick) and we do not allow to extend access to the package.

As next we would also like to enable the Access Review of the package and check back within a couple of month who has access and if this access is still needed (Review of access to our Intune deployed application). The Reviewers could be a specific user (Application Owner for example) or a Self-review where the user has to review the access by himself. Choose the values they fit as its best to your use case.

Review and create your Access Package. This will populate a my access link myaccess.microsoft.com followed by your tenant name and the OpjectId of your Access package. This site is where all the packages and access reviews can be found, ether for the end user to request the package (application) or to review as an application owner.

Enduser experience

Your users are now able to browse to your organization myaccess site by browsing the URL https://myaccess.microsoft.com/ To request the application they select Access package, where our just created package APP – MIP Client (Require approval) will be listed. The request is super easy. The requester has to select + Request access – provide the required information such as the Business reason & justification (if configured within the package) and then to submit the request. During the request process, the user has the opportunity to see the current status of the request including the approval process under his Request history.

Approver experience

The configured approver of the package (which could also be the Manager, currently in Preview) will receive an email to approve or deny the request. As soon the access has been granted, the user account will be added to our created group and the user will receive the assigned application ether to install the application by himself using the Company Portal or if the assignment is set to required within MEM, the application will be forced to install.

Depending on the configured Access review time, the reviewer will receive a similar email to review the access. This could be Self-service for the user or another person within your organization.

Hope this helps to use Access package as your approval process for MEM deployed Windows applications. Let me know what you think! Stay save.