PowerShell Script Support for Installing and Uninstalling Intune Win32 Applications

Posted on by
Reply

This is a quick opinion post on Microsoft’s unveiling of PowerShell script support for installing and uninstalling Intune Win32 applications.

Traditionally, we specified an install and uninstall command line when configuring Intune Win32 applications:

Intune Win32 Apps Install Command

We might specify a command line similar to:

powershell.exe -executionpolicy bypass -file .\deploy-application.ps1

Easy enough, right?

But nowadays, tenants with PowerShell script support for installing and uninstalling Intune Win32 Apps will see that there is another option when deploying Win32 apps in Intune – “PowerShell script”:

PowerShell Script Support Intune for Win32 Apps

This new option allows administrators to paste a chunk of PowerShell code into the Intune console to install and uninstall applications, as opposed to just specifying a command line that points to a PS1 script inside the compiled and encrypted .intunewin payload.

But i don’t see the point of it.  And I don’t necessarily like it.

Microsoft mentioned support for PowerShell scripts in Intune Win32 back in September 2025, and there is now a more recent article that explains when to use the PowerShell script option as opposed to the command line option.

To quote the article:

Consider using PowerShell script installers when:

  • Your app requires prerequisite validation before installation
  • You need to perform configuration changes alongside app installation
  • The installation process requires conditional logic
  • Post-installation actions are needed (like registry modifications or service configuration)

 

Uh?  So in other words, absolutely no benefits from calling a PS1 script from within the .intunewin.  What’s more, these scripts (stored in the application metadata) are limited to 50KB in size?

I’ve read other blog posts on this new feature, explaining why this new functionality is “advantageous” over the command line option.  Reasons such as:

  • “Script changes no longer require a full rebuild and reupload of the app.”
  • “Reduced overhead of testing, repackaging and updating.”
  • “Difficult to see code when it’s compiled inside an Intunewin.”
  • “Can now see the code directly in the Intune portal.”

And I still don’t get it.

To expand on the first two bullets (which made me slightly sick in my mouth when I read them), what we’re essentially advocating here is making changes on the fly in the Intune console without the application being version controlled, and correctly tested and documented. So in other words, this new feature endorses wild-west application management – something which I hate.

And on the last two bullets – surely we all store the original package/source code in an uncompressed, pre-compiled, version-controlled, secure environment with sufficient data retention policies in place?

At the moment, all I see with this new feature is a license for cowboy administrators to make undocumented changes on-the-fly.  When in reality, if the install or uninstall script changes, we should then be releasing a new version of the package, regardless of how small the change is.  Which shouldn’t be too arduous, considering a large part of our application packaging process is automated? (isn’t it?)

Use PowerShell to Read MSI Windows Installer Properties

Posted on by
Reply

This is an example of how we can use PowerShell to read MSI windows installer properties.

It’s a reusable function where we can pass in any MSI property name (ProductCode, ProductName, ProductVersion, ALLUSERS etc) and return the value as a string.

function Get-MSIProperty {
    Param(
    [String]$msipath,
    [string]$msiproperty
    )

   try {          
        $propertyvalue = ""
        $installer = New-Object -ComObject WindowsInstaller.Installer        
        $database = $installer.GetType().InvokeMember('OpenDatabase', 'InvokeMethod', $null, $installer, @($msipath, 0))
        $view = $database.GetType().InvokeMember('OpenView', 'InvokeMethod', $null, $database, ("SELECT Value FROM Property WHERE Property = '$msiproperty'"))
        $View.GetType().InvokeMember('Execute', 'InvokeMethod', $null, $view, $null) | Out-Null
        $record = $View.GetType().InvokeMember('Fetch', 'InvokeMethod', $null, $view, $null)
        if ($record) {
            $propertyvalue = $record.GetType().InvokeMember('StringData', 'GetProperty', $null, $record, 1)
            $view.GetType().InvokeMember('Close', 'InvokeMethod', $null, $view, $null) | Out-Null
        }
        return $propertyvalue
    }
    catch {
        throw 'Failed to get MSI property: {0}.' -f $_
    } finally {
        if ($record)  { [System.Runtime.InteropServices.Marshal]::ReleaseComObject($record) | Out-Null }
        if ($view)    { [System.Runtime.InteropServices.Marshal]::ReleaseComObject($view) | Out-Null }
        if ($database){ [System.Runtime.InteropServices.Marshal]::ReleaseComObject($database) | Out-Null }
        if ($installer){[System.Runtime.InteropServices.Marshal]::ReleaseComObject($installer) | Out-Null }
        [GC]::Collect()
        [GC]::WaitForPendingFinalizers()
    }
}

$msifile = "C:\Alkane\alkane.msi"
$property = Get-MSIProperty $msifile "ProductCode"
write-host $property

Evergreen Application Packaging converting Winget to MSIX

Posted on by
Reply

In this post we demonstrate evergreen application packaging converting Winget to MSIX.

Further to our previous blog where we convert MSI, App-V, PowerShell and PSADT to MSIX, in this blog we demonstrate how to automatically convert Winget packages to MSIX.

We use a similar principle of configuring a packages.json file to iterate through all the Winget packages we want to convert, using out in-house conversion tool.

If you’d like to explore converting Winget packages to MSIX, please reach out!

Evergreen Application Packaging with Automated MSIX Packaging

Posted on by
Reply

In this video we demonstrate evergreen application packaging with automated MSIX packaging.

It’s an in-house tool that we use to convert MSI, App-V, Powershell and PSADT into the MSIX packaging format.  We create a JSON file defining the applications we want to convert, and point to a Hyper-V virtual machine snapshots where we do all the conversions on a clean image.

In the video, we convert 5 applications in just under 20 minutes, with one of the applications being around 1.5GB in size.

If you’re considering moving to MSIX and would like a proof of concept for your most critical business applications, please contact us.

Windows 11 and Microsoft 365 Migration for a Local Council

Posted on by
Reply

In this case study, we walk through some of the challenges we faced and the strategy we used to successfully deliver a Windows 11 and Microsoft 365 migration for a local council.

Challenges

  • We needed to perform in-place upgrades from Windows 10 to Windows 11 for ~3000 devices over the corporate (predominantly wireless) network and VPN, ensuring that we didn’t disrupt day-to-day business operations and maintained network performance.
  • We needed to identify hardware and software that didn’t support Windows 11.
  • The council utilised applications that were heavily-reliant on Microsoft Excel macros, integrated with Microsoft Outlook, used legacy Microsoft Access forms and COM automation. Coupled with transitioning from a 32-bit instance of Microsoft Office to a 64-bit instance of Microsoft 365, many business-critical applications were failing to work.
  • We needed to identify all critical business applications and prioritise testing and remediation of these applications prior to commencing the rollout.
  • We needed to initiate a process that enabled us to test business applications in a coordinated and semi-automate way.

Planning and Strategy

We developed a comprehensive migration plan covering:

  • Identification of Incompatible Hardware and Software – We identified devices that didn’t meet Windows 11 requirements and defined swap-out criteria for the hardware refresh. We also identified and remediated software that was preventing the Windows 11 upgrade from initiating.
  • Application Testing and Remediation – We identified 85 critical business applications and their owners.  We used Microsoft Bookings to schedule testing with application owners, and used a SharePoint list with a bespoke PowerShell application that facilitated note taking, status updates and virtual machine orchestration, providing management with real-time progress.
  • Deployment Rings – We created deployment rings to facilitate Windows 11 operating system deployment (OSD) pilot testing, and identify general performance/usability refinements.  The pilot deployment rings included select IT users, application owners and digital leaders.  For the live rollout we created dynamic deployment rings that enabled us to scale up/down the rollout depending on network performance.
  • Communication and FAQs – We contributed to comprehensive help documentation for Microsoft 365 and Windows 11 usability, enabling non-technical end-users to seamlessly transition to the new experience.
  • Real-Time Updates – We built dashboards to provide management with real-time visibility of rollout progress, combined with weekly face-to-face meetings.

Application Packaging and Remediation

Not all applications were ready for Windows 11 or Microsoft 365 out of the box. We performed:

  • Application Remediation – We packaged and remediated troublesome applications in MSI, App-V and PSADT formats. We also scripted disk clean-up activities on remote endpoints, purging temporary and cached application data to free up disk space and ensure Windows 11 deployment success.
  • Complex Debugging – We debugged integration issues between business applications and Microsoft 365 components using Process Monitor, updating Office 365 cloud policies where appropriate with trusted locations, file block settings, ActiveX settings, macro settings and otherwise.
  • Macro Rewriting and Access Form Modifications – We rewrote legacy Microsoft Excel macros to ensure compliance with modern Microsoft 365 standards, ensuring business-critical spreadsheets continued to function post-migration. We also re-authored Microsoft Access forms that used legacy 32-bit components no longer supported on 64-bit versions of Office.

Outcome

The project was a resounding success. We successfully migrated ~3,000 devices to Windows 11 and Microsoft 365 with zero disruption to business operations:

  • 100% of critical business applications were successfully tested and remediated to work with Microsoft 365 and Windows 11.  All applications are now recorded in a centralised SharePoint repository with comprehensive notes and assigned application owners.
  • Our dynamic deployment rings enabled us to scale our rollout in accordance with network monitoring performance metrics. This proved highly effective since the council were heavily reliant on their wireless network, and we were able to marginally scale back the rollout to mitigate initial performance bottlenecks.
  • Users now have access to comprehensive help documentation, highlighting fundamental differences in functionality between Windows 10/Windows 11 and Office 2016/Microsoft 365.

Thanks to collaboration with the superb internal team, the council can now benefit from improved security, performance and collaboration across Microsoft 365 and Windows 11.

Preferred Application Packaging Supplier to a Large IT Service Provider

Posted on by
Reply

Alkane are the preferred Application Packaging supplier to a large IT service provider.

At Alkane, we pride ourselves on being recognised as industry leaders in the application packaging industry. Our reputation has been built over many years; advising the wider IT community on public forums, demonstrating best practices, consulting for government bodies, banks, councils, NHS Trusts, and information security companies – all while delivering cost-effective and reliable software packaging services.

This expertise and credibility led to Alkane being selected as the preferred application packaging supplier to one of the world’s leading global IT service providers.

Why Alkane?

Our partner required a trusted supplier who could:

  • Deliver application packaging at scale with predictable pricing.
  • Provide security-cleared professionals for sensitive accounts.
  • Support a wide range of packaging technologies and modern deployment platforms.
  • Maintain high quality standards with robust SLAs and long-term support.

Alkane’s fixed-price application packaging service gave the service provider the transparency and accuracy they required. Engagement was simple – costs could be calculated upfront with no hidden surprises.

Flexibility and Scale

One of the key reasons for choosing Alkane was the ability to scale our services instantaneously.

  • Our SC-cleared packaging professionals can be deployed to secure accounts without delay.
  • Capacity can be flexed up or down depending on project demand.

This agility allows the IT service provider to respond quickly to client demands while knowing they have a reliable partner to lean on.

Services Delivered

We provide our partner with a full suite of application packaging and consultancy services, including:

  • Application Packaging – MSI, PSADT, App-V, MSIX and more.
  • Modern Endpoint Management (MEM) consultancy – Intune, Configuration Manager and more.
  • Third-party tooling – guidance and integration of platforms such as Recast Application Workspace.

With expertise spanning traditional and modern packaging formats, Alkane ensures every application is delivered in the most effective format for deployment, compatibility, and lifecycle management.

Quality and Assurance

We back our services with aggressive SLAs and a 12-month warranty on all our work. This commitment gives our partner confidence that every package we deliver is not only production-ready but also supported well beyond initial deployment.

Outcome

By partnering with Alkane, the IT service provider gained:

  • Predictable and transparent pricing for all packaging work.
  • Huge cost savings for their accounts.
  • The ability to scale application packaging capacity instantly.
  • Access to SC-cleared professionals for secure environments.
  • A trusted partner with deep expertise across packaging technologies and MEM platforms.

Recast Application Workspace with Microsoft Teams and Web Browsers

Posted on by
Reply

This post provides a demonstration where we use Recast Application Workspace with Microsoft Teams and Web Browsers.

Following on from our previous video showing how Recast Application Workspace can replace the Microsoft App-V server, where we demonstrated the power of Recast Application Workspace, we now showcase additional features – including web integration using Single Sign-On (SSO) and Microsoft Teams integration. 🚀

✅ Install and launch apps directly from your company website.
✅ Install and launch apps from your intranet portal.
✅ Install and launch apps from Microsoft Teams.
✅ Authenticate securely using Single Sign-On (SSO) with Microsoft Entra.

⏰ The clock is ticking to find an App-V replacement for publishing your apps!

Why not migrate to a single platform that lets you deliver almost any application (App-V, MSIX, App Attach, PowerShell, ThinApp, and more) to almost any environment – physical, virtual, persistent, or non-persistent – with launch metrics and instant delivery?

💡 If you’d like advice on replacing the App-V server components, a demo of Recast Application Workspace, or help migrating your applications, please reach out!

Configuration Manager with Powershell and WQL

Posted on by
Reply

Instead of using Configuration Manager PowerShell Cmdlets, we can use WMI query language (WQL) to search our configuration manager inventory instead.

This blog provides and example of how we can search configuration manager for information on all devices, including name, manufacturer, model, free disk space, organisational unit and last hardware scan.

$configManagerServer = "xxx.yyy.local"
$configManagerSiteCode = "xxx"

$WQLquery = @"
select OS.Caption,S.Name,S.SystemOUName,LD.FreeSpace,WS.LastHardwareScan,CS.Manufacturer,CS.Model
from SMS_R_System AS S
inner join SMS_G_System_OPERATING_SYSTEM AS OS on OS.ResourceId = S.ResourceId 
inner join SMS_G_System_LOGICAL_DISK AS LD on LD.ResourceId = S.ResourceId
inner join SMS_G_System_WORKSTATION_STATUS AS WS on WS.ResourceId = S.ResourceId
inner join SMS_G_System_COMPUTER_SYSTEM AS CS on CS.ResourceId = S.ResourceId
"@

$allResults = Get-WmiObject -Query $WQLquery -ComputerName $configManagerServer -Namespace "root\sms\site_$configManagerSiteCode"

foreach($result in $allResults) {

    $name = $result.S.Name
    $ou = $result.S.SystemOUName
    if ($null -ne $ou) {
        $ou = $ou[$ou.Count-1]
    }
    $freeBytes = $result.LD.Freespace #in MB
    $gb = [math]::Round(($freeBytes / 1024),2) #convert to GB
    $os = $result.OS.Caption
    $lhs = $result.WS.LastHardwareScan
    if ($null -ne $lhs) {
        $lhs = [System.Management.ManagementDateTimeConverter]::ToDateTime($lhs).toString("dd/MM/yyyy")
    }
    $man = $result.CS.Manufacturer
    $mod = $result.CS.Model

    write-host $name
    write-host $ou
    write-host $gb
    write-host $os
    write-host $lhs
    write-host $man
    write-host $mod


}

Reapply the Cloud Policy for Microsoft 365 using Powershell

Posted on by
Reply

In this post we provide an example of how we can reapply the Cloud Policy for Microsoft 365 using PowerShell.

Sometimes when we make changes to a Microsoft 365 policy, we don’t have time to sit around waiting for the policy to take affect if we’re debugging in situ.  And running a device sync doesn’t always work.

The script essentially uses Invoke-Command to run a piece of code on the remote computer, iterating through every user sid in HKEY_USERS and deleting the CloudPolicy key if it exists.

$computerName = "xxx"
Invoke-Command -ComputerName $computerName -ScriptBlock {
    foreach($sid in Get-ChildItem -Path "Registry::HKEY_USERS") {
        $keypath = "Registry::$sid\Software\Microsoft\Office\16.0\Common\CloudPolicy"  
        if (test-path $keypath) {
            write-host "Deleting $keypath"
            Remove-Item -Path $keypath -Recurse -Force
        }
    }    
}

If the user then closes and re-opens their Microsoft 365 application (Word, Excel, Access etc.), the new policy settings should take effect immediately.

Find Installed Applications using PowerShell on a Remote Computer

Posted on by
Reply

This post provides an example of how we can find installed applications using PowerShell on a remote computer.

It will find installed software for MSIX application packages, App-V application packages and locally installed software.

$ComputerName = "xxx"

Invoke-Command -ComputerName $ComputerName -ScriptBlock {
    $apps = @()

    # 1. MSI / Setup.exe installs (Registry Uninstall Keys)
    $regPaths = @(
        "HKLM:\SOFTWARE\Microsoft\Windows\CurrentVersion\Uninstall\*",
        "HKLM:\SOFTWARE\WOW6432Node\Microsoft\Windows\CurrentVersion\Uninstall\*"
    )
    foreach ($path in $regPaths) {
        $apps += Get-ItemProperty $path -ErrorAction SilentlyContinue | Select-Object `
            @{Name="Name";Expression={$_."DisplayName"}},
            @{Name="Version";Expression={$_."DisplayVersion"}},
            @{Name="Source";Expression={"Registry"}}
    }

    # 2. MSIX / Appx packages (from registry)
    $appxKey = "HKLM:\SOFTWARE\Microsoft\Windows\CurrentVersion\Appx\AppxAllUserStore\Applications"
    if (Test-Path $appxKey) {
        $apps += Get-ChildItem $appxKey | ForEach-Object {
            [PSCustomObject]@{
                Name    = $_.PSChildName
                Version = ($_.PSChildName -split "_")[1]
                Source  = "AppX/MSIX (Registry)"
            }
        }
    }

    # 3. App-V packages (if App-V client is installed)
    if (Get-Command Get-AppvClientPackage -All -ErrorAction SilentlyContinue) {
        try {
            $apps += Get-AppvClientPackage | Select-Object `
                @{Name="Name";Expression={$_.Name}},
                @{Name="Version";Expression={$_.Version}},
                @{Name="Source";Expression={"App-V"}}
        } catch {}
    }

    # Filter and sort
    $apps | Where-Object { $_.Name -and $_.Name.Trim() -ne "" } |
        Sort-Object Name -Unique |
        Select-Object Name, Version, Source |
        Format-Table -AutoSize
}