Force Intune apps to redeploy

Force Intune apps to redeploy

by | Jan 1, 2025 | Azure, Deployments, Information Technology, PowerShell, RMM Tools

Last month, I had an app that had some issues for a single end user. I wasn’t sure why it was causing issues, but one of the troubleshooting steps we needed to do was uninstall it and have Intune reinstall it. We uninstalled the application. However, Intune, being Intune, sat there. We forced a sync, and nothing. I wish there was a redeploy option in the Intune interface, but there isn’t. So what can you do? Well, there is a small secret. Intune has registry keys that keep track of the deployments on the machine itself. These linger even after uninstalling the app. So, removing them is the gravey. So today we are going to force Intune apps to redeploy.

Intune Registry Keys / App ID Number

Intune’s registry keys are located in the Local Machine > Software > Microsoft > IntuneManagementExtension > Win32App. Let me tell you what now. My southern is going to come out some yall. This is where we can see the users. The system has it’s own user, which is the all zeros, but each other user has it’s own code.

When you open this folder, you will be taken to a beautiful list of what? Yeah, it’s a mess. You need to know some things about this list in order to force intune apps to redeploy. You will need to have the app’s ID number. To get this number, you will need to navigate to your Intune. We will be heading to the app you want to uninstall. I’m doing my 7zip today as an example. At the end of the url, you will see the appID. That’s what you will need.

Once you have that code, you will be ready. What you will need to do now is delete the folder with that code. Then navigate to the GRS folder. It will have a bunch of hashes. No, not the drug, but math code. Wait, is hash still what people call it now days? I feel old. Anyway, you have two options here. One, you can go to the logs and search the logs for the hash. This can take a while, and shockingly, it is not reliable as logs get deleted. The other way is to go through this registry folder, folder by folder, until you find the key, as seen below. I prefer PowerShell. Once you delete the required registry keys, all you have to do is restart the Microsoft Intune Management Extension service.

Powershell To the Rescue

If you have read this blog long enough, you know PowerShell is coming somehow. Today’s script will save you a crap ton of time. Let’s dive right in. 

$Path = "HKLM:\SOFTWARE\Microsoft\IntuneManagementExtension\Win32Apps"
$AppID = "Your-App-Code-Goes-Here"

$Users = (Get-ChildItem -Path "$Path").name | Where-Object {($_ -like "*-*-*-*-*") -and ($_ -notlike "*00000000-0000-0000-0000-*")}

foreach ($user in $Users) {
    $Name = $User -replace "HKEY_LOCAL_MACHINE","HKLM:"
    $UserID = $user.split("\")[-1]
    $Applications = Get-ChildItem -Path $Name | Where-Object {$_.name -like "*$($AppID)*"}
    foreach ($App in $Applications) {
        $AppName = $App -replace "HKEY_LOCAL_MACHINE","HKLM:"
        Write-Host "App Name: $AppName"
        remove-item -Path $AppName -Recurse -Verbose -force
    }
    $GRSPath = "HKLM:\SOFTWARE\Microsoft\IntuneManagementExtension\Win32Apps\$UserID\GRS"
    $GRSes = Get-childitem -path $GRSPath
    foreach ($GRS in $GRSes) {
        $GRSProps = $GRS | Get-ItemProperty
        $Count = $GRSProps.psobject.Properties.count 
        if ($Count.count -gt 5) {
            $TotalKey = $GRSProps.psobject.Properties.name | where-object {$_ -like "*-*-*-*-*"}
            if ($TotalKey -like "*$($AppID)*") {
                $PathToRemove = $GRS.name -replace "HKEY_LOCAL_MACHINE","HKLM:"
                Remove-Item -Path $PathToRemove -Recurse -Force -Verbose
            }
        }
    }
}
Get-Service -DisplayName "Microsoft Intune Management Extension" | Restart-Service -Verbose

There are many versions online for this script. Most use the logs, and that’s cool. This script doesn’t use the logs, and for a good cause. In my case, the logs were deleted. Why were they deleted, you shall ask? Humans, that’s always going to be my answer until it’s AI.

The break down

Let’s break this bad boy down, shall we? The first part of the script is the path we are going to be playing with, followed by the code of the app. You will have to grab this from your intune. 

$Path = "HKLM:\SOFTWARE\Microsoft\IntuneManagementExtension\Win32Apps"
$AppID = "Your-App-Code-Goes-Here"

Next, we want to grab all the users. So, remember I said the system uses all zeros. Well, we want to exclude those. However, users use the hypens. It’s the Fantastic 4, hypens, not the Marvel characters. Using a basic where object, we sort through all of the ones that have our hypens and are not the system and drop their ID numbers into the users variable. 

$Users = (Get-ChildItem -Path "$Path").name | Where-Object {($_ -like "*-*-*-*") -and ($_ -notlike "*00000000-0000-0000-0000-*")}

Handling the App Side

Now we start our loop. Everyone should like a good loop. Each user will have it’s own path. The first thing we run into is that the above command gave us HKEY_Local_Machine instead of a searchable HKLM. So we change them using the replace. Then we grab the userID for later. Finally, we grab all the applications. Notice the name is the new name we made. It’s important to have the HKLM: because without it, you will get an error with get-childitem.
No candy was stolen from any children while writing this blog post. 

    $Name = $User -replace "HKEY_LOCAL_MACHINE","HKLM:"
    $UserID = $user.split("\")[-1]
    $Applications = Get-ChildItem -Path $Name | Where-Object {$_.name -like "*$($AppID)*"}

Notice we are looking for the appid at the end. Sometimes, there will be more than one entry like this. To force Intune apps to redeploy, we must remove all of them. I liken them to bed bugs. Burn them all. With that said, we start our loop. For each App inside the applications. We will get the app name and then remove it. Once again, we used get-childitem. Goodness, I need to stop still items from kids. So we need to convert the name like we did before changing the HKEY_Local_machine to HKLM: with a nice replace. Once we have it, we delete the path and everything inside by force. 

foreach ($App in $Applications) {
        $AppName = $App -replace "HKEY_LOCAL_MACHINE","HKLM:"
        Write-Host "App Name: $AppName"
        remove-item -Path $AppName -Recurse -Verbose
 }

Handling GRS Side

Now we need to handle the GRS side. The GRS keeps the datetime stamps. Like I said before, most people use the logs. Today we will navigate through the registry. The first thing we are going to do is set the path and get the kids on that path. This is where the UserID we made at the start of this big loop comes into play. 

$GRSPath = "HKLM:\SOFTWARE\Microsoft\IntuneManagementExtension\Win32Apps\$UserID\GRS"
$GRSes = Get-childitem -path $GRSPath

Now we have the children’s items. We start our looping. The first thing we get is our GRS properties with the get-itemproperty commands. Now here is the magic. A standard check has only 1 or maybe 2 items inside the folder. While more advanced items will have more than that. So, if we convert the properties into a Powershell object, we can count them. 

$GRSProps = $GRS | Get-ItemProperty
$Count = $GRSProps.psobject.Properties.count

Yes, the second line works. You can pretty much convert anything into a PowerShell object. All we have to do now is count how many counts per object are there. When we convert the item property into a powershell object, we gain a few extra items. So, anything past 5 in this case will be our special stuff. So, if it is past 5, we get to work.

We first look at the keys, looking for our fantastic 4. We will do this by calling the psobject.properties.name because it will be the name of the property. Then we will compare it to the appid. If they are the same, we correct the hkey_local_machine and drop our nuke, remove-item. Nested ifs are fun, but can get complex quick if you don’t watch out. 

if ($Count.count -gt 5) {
        $TotalKey = $GRSProps.psobject.Properties.name | where-object {$_ -like "*-*-*-*-*"}
        if ($TotalKey -like "*$($AppID)*") {
            $PathToRemove = $GRS.name -replace "HKEY_LOCAL_MACHINE","HKLM:"
            Remove-Item -Path $PathToRemove -Recurse -Force -Verbose
        }
}

The GRS has been removed after this.

Restarting the service

After the large loop of Fantastic Four, we have to restart the intune extension. So, using get service, we pipe it into restart service. Then we are done! Right? Well, kind of. 

Get-Service -DisplayName "Microsoft Intune Management Extension" | Restart-Service -Verbose

Final Step

After the script has done it’s thing and stolen candy for kids and nuked stuff, you will need to resync the computer. You can do this via the Accounts setting, or you can do this via Intune. In my case, the application we were redeploying was our remote application. So, I had to do it via Intune.

Navigate to the device under Windows > Device Name and hit the sync button. Now you are done. Force Intune apps to redeploy, check.

What can we learn as a person?

Restarting is sometimes the only option. Taking a step back, clearing things away, and starting new is good, whether you’re troubleshooting an Intune app deployment or dealing with a hard time in life.

When an app in Intune stops working, we don’t just sit around and hope it gets fixed (at least for a while). After we empty the registry and do some troubleshooting, we gently push it to redeploy. Life is no different. When things don’t work out the way you expected, that’s okay; setbacks are inevitable. Starting over equalizes the situation; it’s not a sign of surrender.

Restarts, in reality, are chances for growth. By doing so, they demonstrate our flexibility, competence, determination and insight to put things right. Our fantasic four. When something feels stuck, whether it’s an app or your thinking, don’t be scared to reset. Do not be afraid, especially with our thinking. That’s where real change happens.

Test a Registry Value with PowerShell

Test a Registry Value with PowerShell

by | Sep 30, 2022 | Information Technology, PowerShell

The other day I needed to test if a registry key was present on an end user’s computer and make it if it didn’t exist. I performed a registry key value test with PowerShell. Since I was doing more than one, I pulled an older tool from my tool box for this one. It’s small but easy to use.

The Script

function Test-RegistryValue {
    param (
        [parameter(Mandatory = $true)][ValidateNotNullOrEmpty()][string]$Path,
        [parameter(Mandatory = $true)][ValidateNotNullOrEmpty()][string]$Value,
        [switch]$ShowValue
    )
    try {
        $Values = Get-ItemProperty -Path $Path | select-object -ExpandProperty $Value -ErrorAction Stop 
        if ($ShowValue) {
            $Values
        }
        else {
            $true
        }
        
    }
    catch {
        $false
    }
}

The Breakdown

This script is only a “Try Catch” with some added inputs. We are first grabbing what we want to test in our parameters. We have two mandatory strings and a switch. The first string is for the path in which we are going to test. The second is the value we want to test. for example, if we want to see if google earth has a version number, we would give the path of HKLM:\Software\Google\Google Earth Pro and the value of Version. If we want to see that version we flip the next part which is the only switch, show value. Instead of saying true or false it will say the value.

Try Catch

$Values = Get-ItemProperty -Path $Path | select-object -ExpandProperty $Value -ErrorAction Stop

Inside our try-catch box, we are using the Get-ItemProperty command. We select the $Value. Finally, we stop the command using the error action flag stop. This prevents the command from falling apart. Next, we throw all that information into the $Values parameter. 

try {
    $Values = Get-ItemProperty -Path $Path | select-object -ExpandProperty $Value -ErrorAction Stop 
    if ($ShowValue) {
        $Values
    } else {
        $true
    }      
} catch {
    $false
}

Aftward, we use a basic if statement. We show the value when the “showvalue” flag is set. However, if it’s not, we just send a true. Finally, the catch will tell us a false statement if the Get-ItemProperty command failed for any reason.

Conclusion

There are other ways to do this, but this was the quickest I have found. I added the show Value recently because I needed it for troubleshooting the code. Overall, this little guy is perfect to add to any script that deals with registry changes.

More Links:

Tattooing with Group Policy

Tattooing with Group Policy

by | Nov 20, 2020 | Group Policy, Information Technology

No, we are not using group policy to put your skull and crossbones tattoo on people. Tattooing is in reference to policies that make changes to the registry that are not removed after the policy is removed. These changes are Permanent and require the admin to manually remove them. I have seen Tattooing become a problem after windows upgrade/update. Polices that effect anything outside 4 registry zones, will tattoo.

  • HKEY_LOCAL_MACHINE\SOFTWARE\Policies
  • HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Policies
  • HKEY_CURRENT_USER\SOFTWARE\Policies
  • HKEY_CURRENT_USER\SOFTWARE\Microsoft\Windows\CurrentVersion\Policies

Thankfully, most out-of-box Microsoft windows policies fall under these four registry keys. Microsoft has also made almost everything they need to be inside these registry keys as well. For example, all the explorer policies live under:

HKCU\Software\Micorosoft\Windows\CurrrentVersion\Policies\Explorer

Thus whenever you remove a policy setting for the Explorer, when the computer pulls down the new policy settings, it will detect the change and remove the explorer policies that were in place.

What kind of policies will tattoo then if everything is set to write to the correct registry locations? Well, custom software will do this. Back in the day, Adobe Reader’s ADM would write to HKLM\Softwares\Adobe. Thankfully it now writes to the policies hive. Chrome will also do this and sometimes needs to be manually removed.

Other Types of Tattooing

Anything that changes the system as a whole. For example, Folder Redirection policies can leave people’s folders on other servers and such. Roaming profiles also provide issues as the files live on another server. My favorite problem child is printers. The printer is installed and will need to be removed with the GPO or you will tattoo. Another good one is direct registry edits with group policy. Icons are another example of another tattooing. WDS application pushouts as well will tattoo the system with software.

Final Words

CYA! Always test a GPO before sending it out. Add it and then remove it. Research the GPO, and plan everything out. GPO is easy to do, almost a no brainer. Anyone can go to youtube and figure out how to do it. The truth behind GPO is why you should do it, and can it be undone. I have personally tattooed icons and printers in my past. So, always and I mean always, plan it out, test, undo, test again, and then deploy.