DEV Community: DeviceManager

Intune Win32 App: Run huge app updates with Powershell

DeviceManager — Wed, 30 Apr 2025 13:47:31 +0000

Introduction

Intune Win32 apps can register apps up to 30GB in size. However, registering large apps takes a considerable amount of time at the upload stage, making it difficult to do this manually.
I used the MS Graph Powershell sample to see if there was a way to upload more efficiently.

Available scripts

The scripts here allow you to do everything from registering to updating Win32 apps, and it seems to have improved usability in many ways.

https://github.com/MSEndpointMgr/IntuneWin32App

Meanwhile, the following sample is available in the official Microsoft Graph SDK powershell.

https://github.com/microsoft/mggraph-intune-samples
https://github.com/microsoft/mggraph-intune-samples/tree/main/LOB_Application
https://github.com/microsoft/mggraph-intune-samples/blob/main/LOB_Application/Win32_Application_Update.ps1

I would like to try using the official MS version if possible, so I will experiment with this sample.

Testing and modification

For testing purposes, create an install.intunewin file of about 8GB in advance.

Also, register the Win32 app with empty content in advance.

Then, try running it like this by calling the sample function.

# Now we'll dot source the sample file so that we can use the functions.
. ".\Win32_Application_Update.ps1"

# This is a must-have spell before you can use Graph. It authenticates you.
Connect-MgGraph

# Specify the ID of the previously registered Win32 app and the path of the intunewin file that you created.
Invoke-Win32AppUpdate -AppId "2bdc5c92-cc6b-477d-9ee2-7b2624136910" -UpdateAppContentOnly $true -SourceFile ".\install.intunewin"

You can also check the Win32 app ID in your browser as follows.
When the target app is open, you can see the long ID in the address bar.

And when I tried to run it, I encountered a number of problems. I'll solve them one by one.

Trouble 1

This is simple. The file size probably doesn't fit into Uint32, so change the Uint32 to Uint64 to solve the problem.


        # Upload the file to Azure Storage
        Write-Host "Uploading the file to Azure Storage..." -ForegroundColor Yellow
        $file = WaitForFileProcessing $fileUri "AzureStorageUriRequest"
        [UInt64]$BlockSizeMB = 4
        UploadFileToAzureStorage $file.azureStorageUri $IntuneWinFile $BlockSizeMB  $fileUri

Trouble #2

After updating, the upload proceeded for a while, but then I got this error.

What does 403 mean? I looked at the aforementioned IntuneWIn32App and other sources, and it seems that the Win32 app uploads to Azure Blob, but the SAS has a time limit. If you don't update it periodically even during upload, you'll get this error. So I improved the UploadFileToAzureStorage function and added SAS Renewal as logic. It updates every 450000 msec = 7.5 minutes.

function UploadFileToAzureStorage($sasUri, $filepath, $blockSizeMB,  $fileUri) {
    # Chunk size in MiB
    $chunkSizeInBytes = (1024 * 1024 * $blockSizeMB)

    # Read the whole file and find the total chunks.
    #[byte[]]$bytes = Get-Content $filepath -Encoding byte;
    # Using ReadAllBytes method as the Get-Content used alot of memory on the machine
    $fileStream = [System.IO.File]::OpenRead($filepath)
    $chunks = [Math]::Ceiling($fileStream.Length / $chunkSizeInBytes)

    # Upload each chunk.
    $ids = @()
    $cc = 1
    $chunk = 0

    # Start the timer for SAS URI renewal
    $SASRenewalTimer = [System.Diagnostics.Stopwatch]::StartNew()


    while ($fileStream.Position -lt $fileStream.Length) {
        $id = [System.Convert]::ToBase64String([System.Text.Encoding]::ASCII.GetBytes($chunk.ToString("0000")))
        $ids += $id

        $size = [Math]::Min($chunkSizeInBytes, $fileStream.Length - $fileStream.Position)
        $body = New-Object byte[] $size
        $fileStream.Read($body, 0, $size) > $null
        $totalBytes += $size

        Write-Progress -Activity "Uploading File to Azure Storage" -Status "Uploading chunk $cc of $chunks" -PercentComplete ($cc / $chunks * 100)
        $cc++

        UploadAzureStorageChunk $sasUri $id $body | Out-Null
        $chunk++

        # Ensure the SAS Uri is renewed
        if ($SASRenewalTimer.ElapsedMilliseconds -ge 450000) {
            Write-Host -Message "SAS Uri renewal is required, attempting to renew"
            $RenewSASURIRequest = Invoke-MgGraphRequest -uri "$($fileUri)/renewUpload" -Method "POST" -Body "{}"
            $Stage = "AzureStorageUriRenewal"
            do {
                $GraphRequest = Invoke-MgGraphRequest -uri $fileUri -Method "GET"
                switch ($GraphRequest.uploadState) {
                    "$($Stage)Pending" {
                        Write-Host -Message "Intune service request for operation '$($Stage)' is in pending state, sleeping for 10 seconds"
                        Start-Sleep -Seconds 10
                    }
                    "$($Stage)Failed" {
                        Write-Host -Message "Intune service request for operation '$($Stage)' failed"
                        throw
                    }
                    "$($Stage)TimedOut" {
                        Write-Host -Message "Intune service request for operation '$($Stage)' timed out"
                        throw
                    }
                }
            }
            until ($GraphRequest.uploadState -like "$($Stage)Success")
            Write-Host -Message "Intune service request for operation '$($Stage)' was successful with uploadState: $($GraphRequest.uploadState)"

            $SASRenewalTimer.Restart()
        }
    }

    # Stop timer
    $SASRenewalTimer.Stop()

    $fileStream.Close()
    Write-Progress -Completed -Activity "Uploading File to Azure Storage"

    # Finalize the upload.
    FinalizeAzureStorageUpload $sasUri $ids | Out-Null
}

Trouble #3

When I enabled SAS update, the upload went smoothly, probably because updates are made regularly like this.

However, it failed at the very end. What is a 400 error?

This was the only thing I didn't really understand, but I tried putting in a sleep of 180 seconds (3 minutes) before the final update, and it actually worked.


        # Commit the file to the service
        Invoke-MgCommitDeviceAppManagementMobileAppMicrosoftGraphWin32LobAppContentVersionFile -MobileAppId $mobileAppId -MobileAppContentId $ContentVersionId -MobileAppContentFileId $ContentVersionFileId -BodyParameter $params

        # Wait for the file to be processed
        Write-Host "Waiting for the file to be processed..." -ForegroundColor Yellow
        $file = WaitForFileProcessing $fileUri "CommitFile"

        Start-Sleep -Seconds 180

        # Check if we are only updating the content
        if ($UpdateAppContentOnly) {
            $params = @{
                "@odata.type"           = "#microsoft.graph.win32LobApp"
                committedContentVersion = "$ContentVersionId"
            }
        }
        else {
            $params = $mobileAppBody
            $params.committedContentVersion = "$ContentVersionId"
        }

        $params = $params | ConvertTo-Json

        # Update the application with the new content version
        Write-Host "Updating the application with the new content version..." -ForegroundColor Yellow
        Update-MgDeviceAppManagementMobileApp -MobileAppId $mobileAppId -BodyParameter $params

I finally got it to work properly, but it's taking a long time to upload.

It seems that MS's sample didn't take into account uploads of such large sizes.

The updated file is here. I've also submitted a pull request.

https://github.com/keitanak/mggraph-intune-samples/blob/LargeUpload/LOB_Application/Win32_Application_Update.ps1

Interactive installation with the InTune Win32 app

DeviceManager — Wed, 29 Mar 2023 12:51:34 +0000

Backgrouond

Win32 apps are often used when distributing apps using Intune.
Unfortunately, Intune cannot be installed without silent installation.
It would be nice if all apps were installed silently, but in reality there are many cases where this is not the case.
After a lot of research, I found that there are people in overseas communities who are having the same problem, and the following countermeasures have been published.

Use ServiceUI with Intune to Bring SYSTEM Process to Interactive Mode

Isn't there a way other than ServiceUI? I thought, and I suddenly thought that I could do the same thing with psexec? I tried it and it worked, so I'm writing an article.

I think that it can be used for those who are in trouble because they cannot install interactively with Intune's Win32 application distribution, or for temporary support until creating a silent installation package.

About psexec

I will omit the explanation about psexec, but it is a tool published by MS. You may use it when you want the process to run under the System account.

You can use the -i command line option to interact with the specified session.

In the installation command when executing app distribution with intune,

psexec.exe -i /accepteula

By doing so, I think that you can connect the screen to the user's session ID while executing the installation command with the System account.

Example(7-zip)

I'll try it right away, prepare 7-Zip to be distributed with PSAppDeployToolkit, and put the above psexec in the installation command to achieve interactive installation.

I will also omit the explanation about PSAppDepolyToolkit, but it is a collection of helper scripts that you want to have such functions when distributing applications with SCCM or Intune. It's hard to make by myself, so I'm grateful that something like this is open to the public.

PSAppDeployToolkit

File Structure

The source file folder looks like this:

Place the installation files under Files.
This time it will be like this.

Install Script

In the INSTALLATION section write like this.
Acquire the session ID of the logged-in user on the first line (acquire the session ID of Explorer.exe)
The second line uses psexec to actually execute the installation command.



$sid=(Get-Process -Name explorer).SessionId
Execute-Process -Path "$dirFiles\PsExec.exe" -Parameters "-i $sid /accepteula $dirFiles\7z1900-x64.exe" -WindowStyle 'Normal'

I have the actual file here.

Deploy-Application.ps1

Building IntunWin file

Under this folder I kept a set of PSAppdeploy files.
D:\Documents\Intune\Apptest01\Toolkit

The IntuneWin file for uploading was created as follows.

Intune Setting

The Install command can be left as it is PSAppDeployTookit.
Silent is attached, but this is an instruction for PSAppDeployTookit, so the actual installer screen is displayed.

Test Installation result

The installer screen of 7Zip was displayed properly.

It completed normally.

There is no need to make 7Zip interactive, but it seems to be useful for things that require more complicated installations, and for printer drivers and other interactive applications.

Closing

If you think about it, the problem is that you can't do this with Intune in the first place. I posted it on the MS Feedback site, so if you agree, please vote.

Ability to allow Win32 Application(System context) Interactive installation

Enjoy your Intune life!