Evergreen has been around for a little over six years now. What started as a handful of functions to retrieve application version data has grown into a module that today tracks more than 500 applications. Over that time, I’ve also built several solutions that integrate Evergreen into packaging workflows - automating downloads, managing Evergren libraries, importing packages into Microsoft Intune, and more recently into Nerdio Manager Shell Apps.

All of that has always lived firmly within an automation framework, PowerShell and the command-line. If you know PowerShell and know the module, it’s powerful. If you’re new to it - or you’re looking to understand Evergreen’s capabilities - the entry point can feel steep. I’ve been thinking about this for a while, and I’m excited to share two new graphical interfaces for Evergreen that I hope will make the module’s capabilities more visible and accessible.

I’m calling them the Evergreen Workbench - available in two editions: a Desktop Workbench for Windows, and a Web Workbench that runs in any modern browser. These UIs won’t replace existing PowerShell-based use of Evergreen; they wrap the same cmdlets and data behind an interactive interface. Think of them as a front door to functionality that was previously only available to those comfortable in a terminal.

This is still early days, particularly for the Desktop Workbench, and I’d love feedback and contributions as these tools mature.

Most of the desktop and web Workbench has been written with the help of Claude and GitHub Copilot. Given how complex these two features are, it’s likely that most of the development will continue this way.

Why a Workbench?

This is something I’ve wanted to do for some time, but the honest answer is that I’ve accumulated a collection of automation solutions that use Evergreen under the hood - pipelines for building Intune Win32 packages, scripts for updating Nerdio Manager Shell Apps, library management workflows, and more. These are powerful, but they’re scattered, and they each require some setup to understand and use.

The Workbench is an attempt to aggregate that functionality into a single place that’s easier to discover and use. Rather than knowing the right cmdlet or digging through GitHub repos to find the right script, the goal is to make that functionality visible in a UI - whether that’s browsing available app versions, managing a local library, or eventually importing a package into Intune or Nerdio Manager.

The Web Workbench takes a different angle - it provides a read-only view of all Evergreen-tracked applications without requiring PowerShell and can run on any platform. It’s useful for looking up a download URL, checking what versions are tracked, or keeping an eye on recent application updates via RSS. This is essentially a new version of the Evergreen App Tracker.

The Workbench editions

Both editions are open source and available on GitHub:

• Desktop Workbench: EUCPilots/evergreen-ui
• Web Workbench: EUCPilots/workbench

Here’s how they compare:

Full documentation for both editions is available at https://eucpilots.com/evergreen-docs/workbench.

The Web Workbench

The Web Workbench is the easiest place to start - no installation required. Open https://eucpilots.com/workbench in any browser and you have access to all Evergreen-tracked application data.

Dashboard

The Dashboard gives you an at-a-glance view of everything Evergreen tracks.

The Web Workbench Dashboard.

At the top you’ll see the headline numbers: total applications tracked, total version records, distinct architectures, installer file types, and applications updated in the last 48 hours. Below that, bar charts break down the data by CPU architecture and installer file type - useful for getting a sense of what Evergreen is actually tracking. There’s also a URI lookup field where you can paste a download URL to find which application it belongs to, and a recent activity list showing the applications with the most recent data updates.

Browsing and filtering apps

The Apps view lists all Evergreen-supported applications in a sidebar with version detail on the right. Select an application to view its version entries - version string, language, file size, architecture, and direct download URI.

The Apps view with version detail for the selected application.

Each column in the version table has a text filter below the header, and checkbox filters at the top of the pane let you narrow results by architecture and file type. These filters work together - for example, you can select x64 and type “English” in the Language column to see only English x64 installers.

Column filters and architecture checkboxes working together to narrow results.

The toolbar above the table includes a copy button for the Get-EvergreenApp PowerShell command to retrieve the same data - making it simpler to discover function usage in Evergreen.

Searching

The sidebar search filters the application list by name as you type.

Sidebar search filtering the application list by name.

For a broader search, press Ctrl+K to open the global search overlay. This searches across all application names and download URIs - useful when you have a URL and want to know which app it belongs to.

The global search overlay finds matches across app names and download URIs.

Other features

A few additional features worth noting:

• RSS feeds - each application has an RSS feed available from the toolbar. If you want to be notified when a specific application’s version data changes, subscribe to its feed.
• PWA install - the Web Workbench is a Progressive Web App. Use your browser’s install option to add it to your desktop or home screen for a standalone app experience on Windows, macOS, Linux, or mobile.
• Export to CSV - export the current filtered view to a CSV file.
• Light and dark themes - toggle with the sun/moon icon in the top-right corner.

The Desktop Workbench

The Desktop Workbench is a WPF-based application that ships as the EvergreenUI PowerShell module. It wraps the same Evergreen cmdlets - Get-EvergreenApp, Save-EvergreenApp, Start-EvergreenLibraryUpdate, and others - behind an interactive Windows desktop interface.

Note that this is currently a pre-release module, so features and commands may change before the stable release.

Installing and launching

The EvergreenUI module is published to the PowerShell Gallery. Because it’s currently pre-release, you need the -AllowPrerelease flag:

Install-Module -Name EvergreenUI -AllowPrerelease

The Evergreen module is listed as a dependency, so if you don’t already have it installed, PowerShell will pull it in automatically.

Once installed, import the module and run Start-EvergreenWorkbench:

Import-Module -Name EvergreenUI
Start-EvergreenWorkbench

The workbench opens to the Apps view by default. You can change the startup view and other preferences in Settings.

Requirements are Windows 10 or Server 2019 or later, PowerShell 5.1 or 7.0+, and .NET Framework 4.7.2+ (for PowerShell 5.1) or .NET 6+ (for PowerShell 7+). Full installation details are in the documentation.

Apps and downloads

The Apps view displays all 500+ Evergreen-supported applications in a searchable list. Select an application to view its version and download metadata in the data grid on the right.

The Desktop Workbench Apps view.

The filter panel updates dynamically based on the properties that application returns. Selecting Adobe Acrobat Reader DC, for example, shows filters for Language, Architecture, and File type. Selecting Microsoft Edge shows Channel and Architecture filters. The available filter properties vary by application and can include architecture, channel, ring, language, installer type, and release.

The filter panel updates dynamically based on the selected application’s properties.

To download an installer, select versions in the Apps view and click Add to download queue, then switch to the Download view to manage and start downloads.

The Download view showing the download queue and progress.

Downloads are processed sequentially and tracked with a progress bar. You can remove individual items, clear the queue, or open the output folder from the toolbar.

Library management

If you have an existing Evergreen library, the Library view provides a GUI for browsing and updating it. Browse to your library path to load the contents - a table of applications with version counts and paths, and version detail for the selected application which will include the details for that application.

The Library view for managing an existing Evergreen library.

From the toolbar you can create a new library (New-EvergreenLibrary), refresh the contents (Get-EvergreenLibrary), or update the library with the latest application versions (Start-EvergreenLibraryUpdate). These map directly to the PowerShell cmdlets you’d run manually, just surfaced in the UI.

Import - Microsoft Intune and Nerdio Manager

The Nerdio Manager Shell Apps import is functional but not yet validated in production. The Microsoft Intune import is still in development.

The Import tab is where some of the more ambitious integration work lives, with sub-tabs for Microsoft Intune Win32 Apps and Nerdio Manager Shell Apps.

The idea here is that you point the workbench at a directory containing package definitions, it compares those definitions against what’s currently in your Microsoft Intune tenant or Nerdio Manager environment, and you can import new apps or update existing ones from the UI.

The Microsoft Intune import view comparing package definitions against apps in the tenant.

I’ll have more to share on the package definitions when these features are further down the track, but the intent is to create a unified package definition that works for Intune and Nerdio Manager.

The Nerdio Manager Shell Apps import view.

Authentication to Entra ID, the Nerdio Manager API, and optionally Azure Storage is managed via the Authentication sub-tab.

The Authentication sub-tab for configuring tenant and API connections.

This is the integration work that is the most complex components, but also the area that still needs the most development and testing. If you’re using Intune and/or Nerdio Manager and want to help test or contribute, I’d love to hear from you.

Install

This feature is in development and may not function as expected.

The Install view compares package definitions against what’s currently installed on the machine, letting you install or update applications directly from the workbench.

The Install view comparing installed versions against the latest versions available from Evergreen.

Point the workbench at a directory containing package definitions and click Load definitions. The view shows each application’s name and architecture, the currently installed version (if any), the latest version available from Evergreen, and a status indicating whether it’s up to date, needs an update, or isn’t installed. From there you can select applications and click Install selected to install or update them. If the workbench isn’t running elevated, installers may prompt for UAC elevation.

The Install view is hidden by default - enable it in Settings.

Settings

The Settings view covers general preferences - download output path, theme, and which views appear in the navigation - alongside provider-specific configuration for Nerdio Manager and Intune. The Import and Install tabs are hidden by default until these features are working as expected.

The Settings view for configuring general preferences and provider connections.

Wrap Up

The Evergreen Workbench is something I’ve wanted to build for a while - a way to make Evergreen’s capabilities more visible and accessible without replacing the PowerShell workflows that many environments already rely on. The Web Workbench is production-ready and a good starting point if you want a quick look at what Evergreen tracks. The Desktop Workbench is still in pre-release, but already functional for browsing apps, managing downloads, and working with libraries.

Full documentation for both editions is at https://eucpilots.com/evergreen-docs/workbench.

If you try either edition and run into issues, have ideas for features, or want to help with development - particularly around the Intune and Nerdio Manager integrations - I’d love to hear from you. Leave a comment below or open an issue or Pull Request on GitHub. It’s been more than six years since Evergreen’s first release, and I think this is a genuinely exciting new direction for the project.

Is this turning Evergreen into a Windows package manager? I’m inclined to say no, even though much of the Workbench functionality does what package managers do. Like Evergreen itself, I’ve had a “build it, and they will come” mentality, which probably isn’t ideal way to approach any sort of product. Luckily, Evergreen is for the community and likewise the Workbench.

Here’s a quick post on configuring strong authentication requirements for Azure Virtual Desktop and Windows 365 using Entra Conditional Access.

Customers may want to protect these virtual desktop resources because these desktops provide access to sensitive resources. For example, you could be using AVD as a protected administrator workstation or providing access to internal applications. To provide confidence that these resources are protected, strong authentication requirements are needed.

In this article, I’ll walk through configuring a Conditional Access policy that requires strong multi-factor authentication every time these resources are accessed, to govern virtual desktop access.

This configuration is specifically tailored for high security requirements, so I’ll also demonstrate the client experience with this policy in place, along with some considerations.

Entra Conditional Access policy details

Assignments

To configure authentication requirements, let’s create a new Conditional Access policy:

• Policy name - I’ve given this policy a descriptive name: Require strong authentication for Azure Virtual Desktop and Windows 365
• Users - I want to target All Users with this policy so that any user with access to AVD or Windows 365 is covered with strong authentication. We could exclude a break glass account in this policy; however, there may be other methods to access to Entra ID; therefore there may not be a need to exclude specific accounts.

• Target resources - select Azure Virtual Desktop and Windows 365. If your tenant was previously enabled for Windows Virtual Desktop, you may see that application instead of Azure Virtual Desktop.

• Network - select Any network or location. The intention of this policy will be to require strong authentication regardless of location. The network you are connected to should not be an indicator of trust in this scenario.

Access controls

• Grant - select Grant access, choose Require authentication strength and select Phishing-resistant MFA, then choose For multiple controls / Require all the selected controls. The last setting is not necessarily required but a good practice in the event this policy is updated with additional controls.

• Session - select Sign-in frequency and then choose Every time. This will require reauthentication each time these resources are accessed and will impact end users who need to provide MFA responses.

User Experience

Here’s a look at the end-user experience. In this demo, I’m signing into the Windows 365 web client and authenticating with a FIDO2 key for strong authentication and connecting to my Cloud PC a couple of times. You’ll see that the sign-in experience is fast and simple, but I am not asked to reauthenticate each time I launch a Cloud PC:

Let’s try again after a period of time - this time we can see that I am asked to re-authenticate to access my Cloud PC:

Why No Prompts for Re-Authn?

At first glance, it might look like our policy is not working and is allowing the user to re-launch their desktop without being re-authenticated. Behind the scenes, the user still has a valid Entra ID token with a claim for strong authentication which satisfies the requirement.

This access still works because Entra ID tokens have a minimum lifetime of 10 mins as listed here: Access, ID, and SAML2 token lifetime policy properties. This document covers an in-preview feature configurable token lifetimes and has an important consideration for these lifetimes:

Reducing the Access Token Lifetime property mitigates the risk of an access token or ID token being used by a malicious actor for an extended period of time. (These tokens can’t be revoked.) The trade-off is that performance is adversely affected, because the tokens have to be replaced more often.

So after 10 minutes, the lifetime expires and the user is asked to re-authenticate. For all but the most restrictive customer environments, this behaviour should be OK.

Addressing Secure Requirements

In scenarios where the requirement for re-authentication cannot be met and access to Azure Virtual Desktop or Windows 365 needs to be protected, you could consider implementing additional requirements:

Grant controls - where you are protecting access to sensitive information and privileged access workstations, select Require device to be marked as compliant in addition to Require authentication strength. This ensures that access is only allowed from a trusted, managed device that meets Intune compliance policies.

Session controls - enable Require token protection for sign-in sessions. This feature can further protect from token theft, and supports the Windows App on a Windows client OS now (with macOS in preview): Token Protection in Microsoft Entra Conditional Access.

Enabling this session control also requires you to update the CA policy to support only Windows, macOS, and iOS (optionally, with a separate policy that blocks other platforms). This requirement will also prevent users from using the Windows 365 web client. I did encounter issues getting this to work with the current Windows app on macOS (I haven’t tested with a preview client).

Improving the End-user Experience

This type of policy is typically required for highly secure environments and isn’t necessarily used to support general access to Azure Virtual Desktop or Windows 365 for most users. To improve the authentication experience, here are few considerations:

• Scope the policy to Entra ID administrator roles - policies that include strict sign-in frequency requirements would be best scoped to accounts with privileged roles with a separate policy for longer sign-in frequency for general users.
• Use separate Azure Virtual Desktop host pools for general end-users and administrator accounts. Users with access to both could then have a simplified sign-in experience on a corporate desktop with stricter sign-in to an administrator desktop.
• All users should use at least password-less authentication with the Microsoft Authenticator to speed, simplify and secure sign-ins.
• Don’t use Sign-in frequency with high sign-in frequencies without number matching or password-less authentication in the Microsoft Authenticator. Making it easier on users to sign-in will help balance experience with security.
• Follow the recommended authentication scenarios from Microsoft: Conditional Access adaptive session lifetime policies.

Now that we have a workflow that uses Evergreen to find application versions and binaries, and imports these along with application definitions to create and update Nerdio Manager Shell Apps, let’s take a look at supporting custom applications. These might be legacy applications, in-house custom apps, applications that require manually downloading (i.e. require a login to get to binaries) or perhaps even existing packages in ConfigMgr that you want to import into Shell Apps.

Custom Applications

As with any Shell App, the application binaries, detection, installation and uninstallation scripts are required. Unlike leverging Evergreen or VcRedist as an automatic source to find the latest binaries and versions, custom application require defining these properties manually.

The pipeline will require at least three things:

1. Configure the Source to be "type": "Static" in the definition.json
2. A URL to download the binaries - only a HTTPS source is supported. In a future update, I might support local paths for upload
3. A version number of the target application to be used for detection

When the application source is updated, the definition.json file can be modified to reflect the new version, pushed to the repository and the pipeline will import the new version of the application.

Example application

Here’s a simple example of a custom application using the Microsoft Configuration Manager Support Center available from the ConfigMgr ISO. This is updated every so often and requires downloading the updated ISO or extracting the MSI file from a ConfigMgr install.

In the definition.json, I have specified a URL that is publicly available and have manually determined the application version number from installing the application on a test machine. this is a basic MSI file, so the install script performs a silent install.

{
    "name": "Configuration Manager Support Center",
    "description": "Support Center has powerful capabilities including troubleshooting and real-time log viewing.",
    "isPublic": true,
    "publisher": "Microsoft",
    "detectScript": "#detectScript",
    "installScript": "#installScript",
    "uninstallScript": "#uninstallScript",
    "fileUnzip": false,
    "versions": [
        {
            "name": "#version",
            "isPreview": false,
            "installScriptOverride": null,
            "file": {
                "sourceUrl": "#sourceUrl",
                "sha256": "#sha256"
            }
        }
    ],
    "source": {
        "type": "Static",
        "version": "5.2403.1209.1000",
        "url": "https://stavdghthbdflhzmvc.blob.core.windows.net/binaries/SupportCenterInstaller.msi",
        "path": null
    }
}

Detection script

The detection script I’ve written for this, validates that the file C:\ProgramFiles (x86)\Configuration Manager Support Center\ConfigMgrSupportCenterViewer.exe exists and matches the expected version or is higher. An alternative approach could query for the installed application.

# Variables
[System.String] $FilePath = "${Env:ProgramFiles(x86)}\Configuration Manager Support Center\ConfigMgrSupportCenterViewer.exe"

# Detection logic
if ([System.String]::IsNullOrEmpty($Context.TargetVersion)) {
    # This should be an uninstall action
    if (Test-Path -Path $FilePath) { return $true }
    else {
        if ($Context.Versions -is [System.Array]) { return $null } else { return $false }
    }
}
else {
    # This should be an install action, so we need to check the file version
    if (Test-Path -Path $FilePath) {
        $Context.Log("File found: $FilePath")
        $FileItem = Get-ChildItem -Path $FilePath -ErrorAction "SilentlyContinue"
        $FileInfo = [Diagnostics.FileVersionInfo]::GetVersionInfo($FileItem.FullName)
        $Context.Log("File product version: $($FileInfo.ProductVersion)")
        $Context.Log("Target Shell App version: $($Context.TargetVersion)")
        if ([System.Version]::Parse($FileInfo.ProductVersion) -ge [System.Version]::Parse($Context.TargetVersion)) {
            $Context.Log("No update required. Found '$($FileInfo.ProductVersion)' against '$($Context.TargetVersion)'.")
            if ($Context.Versions -is [System.Array]) { return $FileInfo.ProductVersion } else { return $true }
        }
        else {
            $Context.Log("Update required. Found '$($FileInfo.ProductVersion)' less than '$($Context.TargetVersion)'.")
            if ($Context.Versions -is [System.Array]) { return $null } else { return $false }
        }
    }
    else {
        $Context.Log("File does not exist at: $($FilePath)")
        if ($Context.Versions -is [System.Array]) { return $null } else { return $false }
    }
}

Install script

The install script performs a simple Windows Installer install - no additional command lines are required for this package.

If this was an existing package with an install script that already exists, this script could be a simple wrapper to call that script. If you were to use a PSADT package and leverage the existing Invoke-AppDeployToolkit.ps1 script, update that script to call the installer with $Context.GetAttachedBinary().

$Context.Log("Installing package: $($Context.GetAttachedBinary())")
$params = @{
    FilePath     = "$Env:SystemRoot\System32\msiexec.exe"
    ArgumentList = "/package `"$($Context.GetAttachedBinary())`" /quiet"
    Wait         = $true
    NoNewWindow  = $true
    PassThru     = $true
    ErrorAction  = "Stop"
}
$result = Start-Process @params
$Context.Log("Install complete. Return code: $($result.ExitCode)")

Uninstall script

The uninstall script uses a function to dynamically find the MSI product code for this package and then call msiexec to uninstall the package using the discovered code.

If this was an existing package with an uninstall script that already exists, this script could be a simple wrapper to call that script.

function Get-InstalledSoftware {
    $UninstallKeys = @(
        "HKLM:\SOFTWARE\Microsoft\Windows\CurrentVersion\Uninstall\*",
        "HKLM:\SOFTWARE\Wow6432Node\Microsoft\Windows\CurrentVersion\Uninstall\*"
    )

    $Apps = @()
    foreach ($Key in $UninstallKeys) {
        try {
            $propertyNames = "DisplayName", "DisplayVersion", "Publisher", "UninstallString", "PSPath", "WindowsInstaller", "InstallDate", "InstallSource", "HelpLink", "Language", "EstimatedSize", "SystemComponent"
            $Apps += Get-ItemProperty -Path $Key -Name $propertyNames -ErrorAction "SilentlyContinue" | `
                . { process { if ($null -ne $_.DisplayName) { $_ } } } | `
                Where-Object { $_.SystemComponent -ne 1 } | `
                Select-Object -Property @{n = "Name"; e = { $_.DisplayName } }, @{n = "Version"; e = { $_.DisplayVersion } }, "Publisher", "UninstallString", @{n = "RegistryPath"; e = { $_.PSPath -replace "Microsoft.PowerShell.Core\\Registry::", "" } }, "PSChildName", "WindowsInstaller", "InstallDate", "InstallSource", "HelpLink", "Language", "EstimatedSize" | `
                Sort-Object -Property "DisplayName", "Publisher"
        }
        catch {
            throw $_.Exception.Message
        }
    }
    return $Apps
}

Get-InstalledSoftware | Where-Object { $_.Name -match "Configuration Manager Support Center*" } | ForEach-Object {
    $Context.Log("Uninstalling Windows Installer: $($_.PSChildName)")
    $params = @{
        FilePath     = "$Env:SystemRoot\System32\msiexec.exe"
        ArgumentList = "/uninstall `"$($_.PSChildName)`" /quiet /norestart"
        Wait         = $true
        PassThru     = $true
        NoNewWindow  = $true
        ErrorAction  = "Stop"
    }
    $result = Start-Process @params
    $Context.Log("Uninstall complete. Return code: $($result.ExitCode)")
}

Preparing a package

Packages can come from any source; however for applications with multiple files in the install package, they will need to be first compressed into a single zip file to enable Shell Apps to download the binaries during install. Don’t forget to enable "fileUnzip": true in the definition.json file so that the zip file is automatically extracted before running the install script.

This approach should enable you to utilise existing packages that include install and uninstall scripts, including those that might already be leveraging the PowerShell App Deployment Toolkit.

Shell Apps will require you to create a new detect.ps1 script to enable detection of the application, but this could be done using the existing metadata from these applications sources (e.g. Configuration Manager detection info, PSASDT detection functions etc.).

Summary

In this article, I’ve demonstrated how to support custom applications or applications that require manual updates, with our automated pipeline tto create or update Shell Apps in Nerdio Manager.

Using the approaches outlined in this series of articles, we now have a method to automatically update off-the-shell apps with Evergreen and VcRedist. Along with a simple approach to adding those manually managed apps, or existing packages, we can use Shell Apps along side existing application delivery mechanisms.

In the previous article, we explored how to automate the creation of Nerdio Manager Shell Apps with Evergreen.

Although running a PowerShell script that runs through a list of applications and creates Shell Apps might be fun to watch in an interactive console window, we can take this further and use Azure Pipelines to create a fully automated pipeline. The pipeline can now run on a schedule to import new version of applications or as new application definitions are added to the repository.

In this screenshot, we can see the pipeline running to read the application definition files, find new versions of the application and create or update the Shell Apps as needed.

An Azure Pipeline run that imports Nerdio Manager Shell Apps.

Tools to Build a Pipeline

To create this pipeline, we need to set up a few things:

1. An Azure DevOps organisation - see Create an organization
2. An Azure DevOps project with a Git repository - see Create a project in Azure DevOps
3. An Azure resource group and storage account - this is used to host the application binaries in blob storage and we need to assign permissions to enable the pipeline to upload files
4. An Azure managed identity - this will be used by Azure Pipelines to securely authenticate to the target storage account. See What are managed identities for Azure resources?

In this article, I’m not going to run through the creation of these resources in detail, instead I am assuming you are familiar with these services and may have configured them in your environment already.

A note on secure environments

The pipeline covered in this article, assumes that you will use Microsoft-hosted Azure Pipelines agents, which will require the target storage account to be publicly accessible. If you have requirements to only access the storage account over private endpoints, you can use self-hosted Azure Pipelines agents that run in an Azure virtual network that has direct access to the storage account.

Additionally, if you also have restrictions on internet access, the Evergreen API can be used to list the required endpoints to detect and download application binaries.

DevOps Project

After you have created an Azure DevOps project with a Git repository, you’ll need to add several files and an expected directory structure:

• pipeline.yml - this is the Azure Pipeline that defines how the pipeline should execute and import Shell Apps
• NerdioShellApps.psm1 - a module with functions required for automating the import of Shell Apps

• apps - a directory that contains Shell App definitions with a directory per-application with the following files:

  • Definition.json - includes a definition of the Shell App required during import. This file also includes logic that tells Evergreen how to find the application version and binaries
  • Detect.ps1 - is used in the Shell App to detect the installed application
  • Install.ps1 - installs the Shell App
  • Uninstall.ps1 - uninstalls the Shell App

The apps directory can be organised how you like, for example, applications can be organised as sub-directories in a directory for each application vendor, but this is not a hard requirement. Just ensure that each application is organised in its own directory.

An example Azure DevOps project repository with the expected directory and file structure.

We will look at the pipeline in more detail later, but managing the application definitions in a Git repository allows you to use version control for the files, manage the code as maturely as your processes allow, and for the pipeline to trigger when new applications are added to the repository.

Configure Authentication

To allow the pipeline to upload application binaries to the target storage account, we need to configure a service connection. This will use the Azure managed identity

Creating an Azure Pipelines service connection using a managed identity.

1. Create a new service connection and select Azure Resource Manager
2. Select the subscription, resource group and managed identity
3. Select the scope for the service connection - subscription or management group
4. Select the resource group for the service connection - this is optional, but useful for scoping the connection to the resource group that contains the target storage account
5. Give the service connection a name and save to create the service connection. The pipeline will need to be updated with the name of the service connection under Variables / service

Configure Permissions

After creating the service connection, don’t forget to assign the Storage Blob Data Contributor role to the managed identity on the target storage account.

The screenshot below shows the managed identity with the Contributor inherited from the resource group and with the Storage Blob Data Contributor role directly on the storage account. Either approach will work; however, it is best to assign the most finely grained permission to the managed identity as you can. You may also want to dedicate a storage account to hosting application binaries so the managed identity only has access to that storage account and no others.

Assign the ‘Storage Blob Data Contributor’ role on the storage account to the managed identity.

Configure Pipeline Variables

The pipeline requires variables to be passed into during execution. These should be stored in a variable group named Credential in in Asset library. These variables can be stored directly in the library or be linked from an Azure Key Vault.

• TenantId - the Entra ID tenant
• ClientId - the app registration client ID specified in Nerdio Manager (Settings / Environment / Integrations / REST API)
• ClientSecret - the app registration client secret specified in Nerdio Manager (Settings / Environment / Integrations / REST API). Ensure this variable is configured as secret to protect its value
• ApiScope - the API scope specified in Nerdio Manager (Settings / Environment / Integrations / REST API)
• OAuthToken - the OAuthToken specified in Nerdio Manager (Settings / Environment / Integrations / REST API)
• NmeHost - the Nerdio Manager host name (in the format nmw-app-s6uhdllx6esom.azurewebsites.net)
• SubscriptionId - the Azure subscription that hosts the target storage account
• ResourceGroupName - the Azure resource group that hosts the target storage account
• StorageAccountName - the target storage account that will host application binaries
• ContainerName - the blob container name on the target storage account

Credential variables stored in a DevOps asset library.

After creating the pipeline, enable access the variable group by authorising the pipeline: Use variable groups in pipelines

Create the Pipeline

With the code committed to the repository and resources configured, create the pipeline:

1. Select Pipelines
2. Click New Pipeline
3. Select Azure Repos Git
4. Select the repository
5. Choose Existing Azure Pipelines YAML
6. Select the ‘main’ branch and then /pipeline.yml in the path
7. Review and save the pipeline

The pipeline should now be ready to execute and import Shell Apps into Nerdio Manager.

Pipeline Code

The pipeline code is listed below and is available here. The pipeline essentially does the following:

• Run when new or modified application definitions are added to the apps directory in the main branch
• Run every 24 hours to update existing Shell Apps with new application versions
• It queries for existing Shell Apps to determine whether the app already exists
• If the Shell App does exist, it then determines whether a new version is available before updating the existing Shell App with a new version
• Old version of Shell Apps will be pruned to ensure only 3 version exist (change this number to keep more versions)
• Finally, the list of Shell Apps in Nerdio Manager will be displayed, along with the lasted version of each Shell App

# Automate the import of Nerdio Manager Shell Apps with Evergreen

# Trigger the pipeline on change to the 'apps' directory
trigger:
    branches:
        include: [ main ]
    paths:
        include: [ "apps/**" ]

# Also run the pipeline on a schedule to update new versions of apps
schedules:
  - cron: "0 17 * * *"
    displayName: Daily 2AM Run (AEST)
    branches:
      include:
        - main
    always: true

# Run the pipeline on an Ubuntu runner (and in PowerShell 7)
pool:
  vmImage: ubuntu-latest

# Variables - the credentials group and the service connection name
variables:
- group: 'Credentials' # Update to match your environment
- name: service
  value: 'sc-rg-Avd1Images-aue' # Update to match your environment

jobs:
- job: Import
  displayName: 'Import Nerdio Shell Apps'

  steps:
  # Checkout the repository so we have access to the module and app definitions
  - checkout: self
    displayName: 'Checkout repository'

  # Install the required PowerShell modules
  - pwsh: |
      Install-Module -Name "Evergreen", "VcRedist" -AllowClobber -Force -Scope CurrentUser
    name: modules
    displayName: 'Install Modules'
    workingDirectory: $(build.sourcesDirectory)
    errorActionPreference: stop

  # Validate connection to Azure using the service connection
  - task: AzurePowerShell@5
    name: auth
    displayName: 'Azure Login'
    inputs:
      azureSubscription: '$(service)'
      ScriptType: 'InlineScript'
      Inline: |
        Write-Host "Authenticated to Azure using service connection: $(service)"
        Set-AzContext -SubscriptionId $(SubscriptionId) -TenantId $(TenantId)
      azurePowerShellVersion: 'LatestVersion'
      errorActionPreference: stop
      pwsh: true
      workingDirectory: $(build.sourcesDirectory)

  # Authenticate to Nerdio Manager, set the Azure context, and import the shell apps
  # This code checks whether the app already exists before importing or updating it
  - task: AzurePowerShell@5
    name: import
    displayName: 'Import Shell Apps'
    inputs:
      azureSubscription: '$(service)'
      ScriptType: 'InlineScript'
      Inline: |
        $InformationPreference = "Continue"
        Import-Module -Name "./NerdioShellApps.psm1" -Force
        Set-AzContext -SubscriptionId $(SubscriptionId) -TenantId $(TenantId)
        $params = @{
            ClientId           = "$(ClientId)"
            ClientSecret       = "$(ClientSecret)"
            TenantId           = "$(TenantId)"
            ApiScope           = "$(ApiScope)"
            SubscriptionId     = "$(SubscriptionId)"
            OAuthToken         = "$(OAuthToken)"
            ResourceGroupName  = "$(resourceGroupName)"
            StorageAccountName = "$(storageAccountName)"
            ContainerName      = "$(containerName)"
            NmeHost            = "$(nmeHost)"
        }
        Set-NmeCredentials @params
        Connect-Nme
        $Path = Join-Path -Path $(build.sourcesDirectory) -ChildPath "apps"
        $Paths = Get-ChildItem -Path $Path -Include "Definition.json" -Recurse | ForEach-Object { $_ | Select-Object -ExpandProperty "DirectoryName" }
        foreach ($Path in $Paths) {
            $Def = Get-ShellAppDefinition -Path $Path
            $App = Get-AppMetadata -Definition $Def
            $ShellApp = Get-ShellApp | ForEach-Object {
                $_ | Where-Object { $_.name -eq $Def.name }
            }
            if ($null -eq $ShellApp) {
                Write-Information -MessageData "$($PSStyle.Foreground.Cyan)Importing: $($Def.name)"
                $NewApp = New-ShellApp -Definition $Def -AppMetadata $App
                $NewApp.job.status
            }
            else {
                Write-Information -MessageData "$($PSStyle.Foreground.Cyan)Updating Shell App: $($Def.name)"
                $UpdateApp = Update-ShellApp -Id $ShellApp.Id -Definition $Def
                $UpdateApp.job.status
                $ExistingVersions = Get-ShellAppVersion -Id $ShellApp.Id | ForEach-Object {
                    $_ | Where-Object { $_.name -eq $App.Version }
                }
                if ($null -eq $ExistingVersions -or [System.Version]$ExistingVersions.name -lt [System.Version]$App.Version) {
                    $NewAppVersion = New-ShellAppVersion -Id $ShellApp.Id -AppMetadata $App
                    $NewAppVersion.job.status
                }
                else {
                    Write-Information -MessageData "$($PSStyle.Foreground.Yellow)Shell app version exists: '$($Def.name) $($App.Version)'. No action taken."
                }
            }
        }
        Remove-NerdioManagerSecretsFromMemory
      azurePowerShellVersion: 'LatestVersion'
      errorActionPreference: stop
      pwsh: true
      workingDirectory: $(build.sourcesDirectory)

  # Prune Shell Apps versions
  - task: AzurePowerShell@5
    name: prune
    displayName: 'Prune Shell Apps versions'
    inputs:
      azureSubscription: '$(service)'
      ScriptType: 'InlineScript'
      Inline: |
        $InformationPreference = "Continue"
        Import-Module -Name "Az.Accounts", "Az.Storage", "Evergreen", "VcRedist" -Force
        Import-Module -Name "./NerdioShellApps.psm1" -Force
        Set-AzContext -SubscriptionId $(SubscriptionId) -TenantId $(TenantId)
        $params = @{
            ClientId           = "$(ClientId)"
            ClientSecret       = "$(ClientSecret)"
            TenantId           = "$(TenantId)"
            ApiScope           = "$(ApiScope)"
            SubscriptionId     = "$(SubscriptionId)"
            OAuthToken         = "$(OAuthToken)"
            ResourceGroupName  = "$(resourceGroupName)"
            StorageAccountName = "$(storageAccountName)"
            ContainerName      = "$(containerName)"
            NmeHost            = "$(nmeHost)"
        }
        Set-NmeCredentials @params
        Connect-Nme
        $KeepCount = 3
        Get-ShellApp | ForEach-Object {
            $ExistingVersions = Get-ShellAppVersion -Id $_.id | `
                Where-Object { $_.isPreview -eq $false } | `
                Sort-Object -Property @{ Expression = { [System.Version]$_.Version }; Descending = $true }
            if ($ExistingVersions.Count -gt $KeepCount) {
                $VersionsToRemove = $ExistingVersions | Select-Object -Skip ($ExistingVersions.Count - $KeepCount)
                foreach ($Version in $VersionsToRemove) {
                    Write-Information -MessageData "$($PSStyle.Foreground.Cyan)Removing Shell App Version: $($_.id) $($Version.name)"
                    $Result = Remove-ShellAppVersion -Id $_.id -Name $Version.name -Confirm:$false
                    $Result.job.status
                    if ($Result.job.status -eq "Completed") {
                        $File = $Version.file.sourceUrl -split "\?"
                        $FileName = $File -split "/" | Select-Object -Last 1
                        Remove-AzStorageBlob -Container $(containerName) -Blob $FileName -Confirm:$false
                    }
                }
            }
            else {
                Write-Information -MessageData "$($PSStyle.Foreground.Yellow)No versions to remove for Shell App: $($_.id)"
            }
        }
        Remove-NerdioManagerSecretsFromMemory
      azurePowerShellVersion: 'LatestVersion'
      errorActionPreference: stop
      pwsh: true
      workingDirectory: $(build.sourcesDirectory)

  # List the Shell Apps in Nerdio Manager
  - task: AzurePowerShell@5
    name: list
    displayName: 'List Shell Apps'
    inputs:
      azureSubscription: '$(service)'
      ScriptType: 'InlineScript'
      Inline: |
        Import-Module -Name "./NerdioShellApps.psm1" -Force
        $params = @{
            ClientId           = "$(ClientId)"
            ClientSecret       = "$(ClientSecret)"
            TenantId           = "$(TenantId)"
            ApiScope           = "$(ApiScope)"
            SubscriptionId     = "$(SubscriptionId)"
            OAuthToken         = "$(OAuthToken)"
            ResourceGroupName  = "$(resourceGroupName)"
            StorageAccountName = "$(storageAccountName)"
            ContainerName      = "$(containerName)"
            NmeHost            = "$(nmeHost)"
        }
        Set-NmeCredentials @params
        Connect-Nme
        Get-ShellApp | ForEach-Object {
            $ExistingVersions = Get-ShellAppVersion -Id $_.id | `
                Where-Object { $_.isPreview -eq $false } | `
                Sort-Object -Property @{ Expression = { [System.Version]$_.Version }; Descending = $true }
            [PSCustomObject]@{
                publisher     = $_.publisher
                name          = $_.name
                versionCount  = $ExistingVersions | Measure-Object | Select-Object -ExpandProperty "Count"
                latestVersion = ($ExistingVersions | Select-Object -First 1).name
                createdAt     = $_.createdAt
                fileUnzip      = $_.fileUnzip
                isPublic      = $_.isPublic
                id            = $_.id
            }
        } | Format-Table -AutoSize
        Remove-NerdioManagerSecretsFromMemory
      azurePowerShellVersion: 'LatestVersion'
      errorActionPreference: stop
      pwsh: true
      workingDirectory: $(build.sourcesDirectory)

Summary

In this article, I’ve demonstrated how to create an automated pipeline that will continuously run to create or update Shell Apps in Nerdio Manager. Leveraging Azure Pipelines enables you to manage the Shell Apps creation pipeline as a completely automated solution and saves Nerdio Manager administrators many hours of valuable time.

Using Evergreen as a source for discovery of application version and installers, enables the deployment of Shell Apps from a library of 374 applications and 6712 unique application installers. This list covers most of the off the shelf applications typically used in Windows desktop environments.

In the next part of this article series, I’ll cover how to use this framework to import other applications, not supported by Evergreen, into Nerdio Manager Shell Apps.

Nerdio Manager for Enterprise 7.2 introduces API endpoints for managing Shell Apps. This provides an exciting opportunity for automating Shell Apps management for a repeatable and structured method for creating and updating Shell Apps. Even better, we can integrate this approach with Evergreen for automatic discovery of new application binaries.

Winget vs. Shell Apps + Evergreen

Nerdio Manager supports deployment of applications via Winget with Unified Application Management supporting the public Winget repository or a private repository.

There’s an inevitable comparison then between using Winget or Shell Apps + Evergreen to deploy applications. Winget is certainly the simpler approach and supports a wide range of applications, but relies on application deployment from the internet. Nerdio Manager can create private Winget repositories to keep application deployment within the customer tenant; however, private repositories require several Azure resources including a Cosmos database.

Shell Apps with Evergreen requires just an Azure storage account, keeping application binaries within the customer tenant while using the simplest architecture possible. Additionally, using Evergreen provides you with clear visibility into and auditing of application discovery and download, all within your environment.

Using Evergreen as a source for discovery of application version and installers, enables the deployment of Shell Apps from a library of 374 applications and 6712 unique application installers.

PowerShell Module

To create this integration, I’ve created a custom PowerShell module - the official Nerdio Manager PowerShell module will be updated in the future and may replace some of the functions in this custom module.

The custom module is hosted in my nerdio repository on GitHub - see NerdioShellApps.psm1. The repository also includes files for a set of supported applications that can be imported into Shell Apps.

Create-ShellApps.ps1 demonstrates how to use the module to import applications into Nerdio Manager Shell Apps.

These support modules are also required: Az.Accounts, Az.Storage, Evergreen.

Application Definitions

Several files are required for defining a Shell App. The module expects a directory for each application with the following files:

• Definition.json - includes a definition of the Shell App required during import. This file also includes logic that tells Evergreen how to find the application version and binaries
• Detect.ps1 - is used in the Shell App to detect the installed application
• Install.ps1 - installs the Shell App
• Uninstall.ps1 - uninstalls the Shell App

For details on the detect, install and uninstall scripts, see this article: Shell apps technical reference guide.

Here’s a look at an example Definition.json - this example defines Microsoft Visual Studio Code, including placeholder values that will be replaced later, and values that Evergreen will use to find the 64-bit version of the Stable release of Visual Studio Code.

{
    "name": "Visual Studio Code",
    "description": "Visual Studio Code is a code editor redefined and optimized for building and debugging modern web and cloud applications.",
    "isPublic": true,
    "publisher": "Microsoft",
    "detectScript": "#detectScript",
    "installScript": "#installScript",
    "uninstallScript": "#uninstallScript",
    "fileUnzip": false,
    "versions": [
        {
            "name": "#version",
            "isPreview": false,
            "installScriptOverride": null,
            "file": {
                "sourceUrl": "#sourceUrl",
                "sha256": "#sha256"
            }
        }
    ],
    "source": {
        "type": "Evergreen",
        "app": "MicrosoftVisualStudioCode",
        "filter": "$_.Architecture -eq \"x64\" -and $_.Channel -eq \"Stable\" -and $_.Platform -eq \"win32-x64\""
    }
}

Importing a Shell App

To import a Shell App with the module and an application definition, this high-level workflow is followed:

1. Create a storage account and blob container
2. Import the module
3. Authenticate to Azure and Nerdio Manager
4. Read the application definition
5. Find the latest application version and binary with Evergreen
6. Create the Shell App, or add a new version to an existing Shell App

Create a storage account

We need an Azure storage account to store application binaries. We just need a standard tier storage account to host blob storage and a blob container to upload files to. The container can be configured for Private access, because we configure a SAS token for each file hosted in that container.

Azure storage account blob storage with Private access configured.

Import the module

This step is simple enough, save the NerdioShellApps.psm1 file locally and import with:

PS > Import-Module -Name ".\NerdioShellApps.psm1" -Force

Authentication

Authentication to Azure is required - you will need to authenticate with an account that has at least the Storage Blob Data Contributor role. When run manually, use the Connect-AzAccount cmdlet to authenticate.

Authentication to Nerdio Manager is similar to Connect-Nme in the official Nerdio Manager PowerShell module; however, we also need to authenticate to the target Azure subscription to upload files to a storage account.

The following credentials, secrets and values are required - in my lab environment I have these saved in JSON files that my script reads when executed; however, these would be best stored securely - for example, in an Azure Key Vault:

• ClientId - Id of the Entra ID app registration configured with the Nerdio Manager REST API
• ClientSecret - Secret used to authenticate with the app registration
• TenantId - Entra ID tenant Id
• ApiScope - API scope provided by the Nerdio Manager REST API
• OAuthToken - OAuth token provided by the Nerdio Manager REST API
• NmeHost - Nerdio Manager hostname
• SubscriptionId - Azure subscription Id
• ResourceGroupName - Azure resource group that contains the storage account
• StorageAccountName - Azure storage account used to host application binaries
• ContainerName - Azure storage account blob container where application binaries will be uploaded to

Because I’m storing these credentials locally, authentication looks like the code below where I’m reading the stored values from JSON files and passing them to Set-NmeCredentials. This function stores the credentials, secrets and values for use later with other functions.

$EnvironmentFile = "/Users/aaron/projects/nerdio/api/environment.json"
$CredentialsFile = "/Users/aaron/projects/nerdio/api/creds.json"
$Env = Get-Content -Path $EnvironmentFile | ConvertFrom-Json
$Creds = Get-Content -Path $CredentialsFile | ConvertFrom-Json
$params = @{
    ClientId           = $Creds.ClientId
    ClientSecret       = (ConvertTo-SecureString -String $Creds.ClientSecret -AsPlainText -Force)
    TenantId           = $Creds.TenantId
    ApiScope           = $Creds.ApiScope
    SubscriptionId     = $Creds.SubscriptionId
    OAuthToken         = $Creds.OAuthToken
    ResourceGroupName  = $Env.resourceGroupName
    StorageAccountName = $Env.storageAccountName
    ContainerName      = $Env.containerName
    NmeHost            = $Env.nmeHost
}
PS > Set-NmeCredentials @params

To authenticate to Nerdio Manager use the Connect-Nme function. Note that this function name clashes with the official Nerdio Manager PowerShell module, so configure your environment appropriately if you have both modules installed:

PS > Connect-Nme
Authenticated to Nerdio Manager.
Token expires: 29/7/2025 5:17:18 pm

Read the application definition

Our first step after authentication is to read the application definition. Get-ShellAppDefinition accepts a path to a directory that contains the Definition.json, Detect.ps, Install.ps1, and Uninstall.ps1 files, and returns a single object which is the application definition (still with some placeholder values).

$Path = "/Users/aaron/projects/nerdio/shell-apps/Microsoft/VisualStudioCode"
$Def = Get-ShellAppDefinition -Path $Path

Find the application details

The application definition should have details that Evergreen will use find the application version and download URL:

$App = Get-EvergreenAppDetail -Definition $Def

Be sure to test that this function returns a single object only. In this example, we have an object that describes the 64-bit, Stable channel version of Visual Studio Code:

Version      : 1.102.2
Platform     : win32-x64
Channel      : Stable
Architecture : x64
Sha256       : cfd0ce29f75313601ae5cd905c7cd12e4b2b759badfc2c1c9ec1691fa82a2060
URI          : https://vscode.download.prss.microsoft.com/dbazure/download/stable/c306e94f98122556ca081f527b466015e1bc37b0/VSCodeSetup-x64-1.102.2.exe

Create the Shell App

Now that we have authenticated to the target environment and have the details requires to create the Shell App, we should first check whether the Shell App already exists before attempting to import. Right now we only match by the application name defined in the definition, so unless we first perform a check, we will have two Shell Apps imported with the same details.

The following code should either return null or an existing Shell App that matches the name defined in the application definition:

$ShellApp = Get-ShellApp | ForEach-Object {
    $_.items | Where-Object { $_.name -eq $Def.name }
}

If no Shell App is returned, we can then use New-ShellApp to create the Nerdio Manager Shell App for Visual Studio Code. This function requires the application definition object from Get-ShellAppDefinition and the Evergreen object from Get-EvergreenAppDetail:

if ($null -eq $ShellApp) {
    New-ShellApp -Definition $Def -AppDetail $App
}

This function provides output that looks similar to the below. Note that file name for the uploaded binary, in this case 6ba28b61c8aeb0cc506dff509d2e5d11.VSCodeSetup-x64-1.102.2.exe. The MD5 hash of the Sha256 file hash is appended to the file name to create a idempotent file name for the uploaded binary so that we can uniquely identify the installer for a specific Shell App version.

Downloaded file: /Users/aaron/Temp/shell-apps/VSCodeSetup-x64-1.102.2.exe
Get storage account key from: rg-Avd-Images-wus3 / stavd7urlg3fm4odtn
Uploading file to blob: 6ba28b61c8aeb0cc506dff509d2e5d11.VSCodeSetup-x64-1.102.2.exe
Uploaded file to blob: https://stavd7urlg3fm4odtn.blob.core.windows.net/shell-apps/6ba28b61c8aeb0cc506dff509d2e5d11.VSCodeSetup-x64-1.102.2.exe
Using SAS token for source URL.
Shell App created successfully. Id: 20620

Update the Shell App with a new version

Where a Shell App already exists and a new version is available, we can use the following code to add a new version to an existing Shell App. This reads the version from the Shell App and compares the version against what Evergreen has found. If Evergreen finds a newer version, New-ShellAppVersion will add a new version to the same Shell App:

$ExistingVersions = Get-ShellAppVersion -Id $ShellApp.Id | ForEach-Object {
    $_.items | Where-Object { $_.name -eq $App.Version }
}
if ($null -eq $ExistingVersions -or [System.Version]$ExistingVersions.name -lt [System.Version]$App.Version) {
    New-ShellAppVersion -Id $ShellApp.Id -AppDetail $App
}

Downloaded file: /Users/aaron/Temp/shell-apps/VSCodeSetup-x64-1.202.2.exe
Get storage account key from: rg-Avd-Images-wus3 / stavd7urlg3fm4odtn
Uploading file to blob: 6ba28b61c8aeb0cc506dff509d2e5d11.VSCodeSetup-x64-1.202.2.exe
Uploaded file to blob: https://stavd7urlg3fm4odtn.blob.core.windows.net/shell-apps/6ba28b61c8aeb0cc506dff509d2e5d11.VSCodeSetup-x64-1.202.2.exe
Using SAS token for source URL.
Shell App version created successfully. Id: 20623

Summary

Using this approach, we can define a set of application to import as Shell Apps into Nerdio Manager and use a script that reads each application definition, finds the latest application version, downloads the binaries, uploads to the Azure storage account and creates the Shell App in Nerdio Manager. See the sample script here: Create-ShellApps.ps1.

Nerdio Manager Shell Apps imported via PowerShell.

In this article, I’ve shown you how to interactively import a set of applications to Nerdio Manager Shell Apps; however, we don’t really want to be sitting in front of a console and running this each time we want to import new apps. In the next article, I’ll cover updating this workflow for use in an Azure Pipeline to automate the entire process.

Background

When the initial version of Evergreen was released, it included support for a handful of applications. Each application was supported as an individual function - for example:

Get-Microsoft365Apps

As the module grew to support additional applications, this approach was not sustainable as discoverability of supported application was difficult. Therefore, the approach was changed to include a single Get function for applications. So this became:

Get-EvergreenApp -Name Microsoft365Apps

The issue

Since that time the supported number of applications has grown to 375 while continuing to include all of the per-application functions and manifest in the module. This means that any time a new application is added or a fix to an application is made, an entirely new release of Evergreen is required.

To make changes to the module, I loosely follow standard change control processes by creating a development branch, making the changes to the code, testing those changes, creating and merging a pull request in the main branch, then pushing the new version of the module to the PowerShell gallery.

This is time consuming and can sometimes create issues where someone hasn’t updated the module in their environment that includes the fix.

Addressing the issue

For a long time, I’ve been looking at separating the per-application functions from the module so they can be updated on demand and newly supported applications or fixes to existing applications can be delivered faster.

An upcoming change to Evergreen will address this issue by separating the per-application functions and manifests from the core module, by storing these in a separate repository and including a method to download and update a locally cached copy of these functions.

Here’s how I’m proposing to make these changes, and I’m welcoming comments and feedback before this change is implemented.

Move Evergreen to a GitHub organisation

To simplify discoverability of the various code repositories related to Evergreen, I’ll be moving the Evergreen GitHub repo to the EUC Pilots organisation. This will still essentially be managed by me, but I think this approach will improve branding and make it simpler to organise repositories.

I may move various Evergreen related sites (e.g. the documentation) away from https://stealthpuppy.com to https://eucpilots.com. I am also looking at moving VcRedist to this organisation as well, as it’s closely related to Evergreen.

Move per-application functions to a dedicated repository

The per-application functions and manifests will be moved to a dedicated repository in this organisation. You can see that repository here: evergreen-apps.

This repository will host the Apps and Manifests directories included in the module today, moving them out of the module and making it easier to make changes to these functions.

This repository includes a release workflow the performs the following:

1. Validate all PowerShell functions - this still needs to be added, but Pester tests are used for validation of Evergreen today.
2. Validate the JSON manifests - the manifest need to have some basic validation applied.
3. Store SHA256 hashes for each PowerShell file and manifest. This enables validation when downloading the files locally.
4. Create a release for changes made to the application functions. Releases will include a list of changed files and with a version number in the format “yy.mm.dd.run”, e.g. 25.07.06.2. The release will include a zip file containing a copy of the Apps and Manifests directories with a SHA256 hash of the file.

Any time changes are pushed to the main branch in this repository, a new release will be created, so that updated functions are available to download.

Creating a method to download per-application functions

When importing the Evergreen module, you’ll be prompted to download the per-application functions:

A new function has been added to Evergreen named Update-Evergreen. This downloads the latest release from the evergreen-apps repository, unpacks the files and stores them locally.

This function supports the -Force parameter to force the download of the latest release of the per-application functions even if you already have these locally. This approach should enable the administrator to update Evergreen where the locally cached copies of the functions are perhaps broken.

When importing Evergreen where the local cache is out of date, you will be prompted to update:

How Update-Evergreen works

To facilite downloading and updating the per-application functions and to ensure that downloaded files are valid, Update-Evergreen performs the following steps:

1. Per-application functions and manifests will be stored in the the following default locations - on Windows in %LocalAppData%\Evergreen and on macOS or Linux in ~/.evergreen.
2. These locations can be overridden by setting an environment variable named EVERGREEN_APPS_PATH pointing to a path of your choice.
3. The locally cached per-application functions and manifests are checked against the list of expected SHA256 hashes (stored here). If the hashes do not match, the administrator is prompted to run Update-Evergreen -Force - they won’t automatically be updated unless there is a new version on the evergreen-apps repository.
4. The updated version of the per-application functions and manifests is downloaded from the latest release (i.e. the zip file).
5. The downloaded zip file is compared against the SHA256 hash stored on the GtiHub release object
6. After downloading unpacking the zip file, the included files are compared against the expected SHA256 hashes. If they do not match, the locally cached copies are not updated.
7. If they do match, the local copies will be updated and Evergreen will now support the latest apps.

Update-Evergreen is recommended as the simplest option to update to the latest version of the per-application functions and manifests; however, there’s no reason an administrator couldn’t do that manually, maintaining some control.

FAQs

Q. When will this happen?

A. I’m not 100% certain, but it’s likely to be around 6-8 weeks from the posting of this article (toward the end of August 2025).

Q. Why download the zip file rather than update individual functions?

A. I think this is the simplest approach - it enables the per-application functions and manifests to be tracked as a specific release and reduces the calls to GitHub (unautheticated calls to api.github.com are limited to 60 per hour). It also simplifies downloading the files by doing so in a single action. If required, Update-Evergreen could perhaps support downloading a specific release rather than the latest release.

Q. Can I test these changes before release?

A. Yes, view and test the changes in the split-repo branch on the Evergreen repository. Please provide bugs and feedback so that I can make improvements before release.

Q. What will I need to do to update my scripts?

A. Update scripts to run the Update-Evergreen function before using any further Evergeen functions. For example:

Install-Module -Name "Evergreen"
Import-Module -Name "Evergreen" -Force
Update-Evergreen

I’m really pleased to release a solution that integrates the Evergreen PowerShell module with Rimo3. This enables you to use Evergreen as a trusted source for your application packages and Rimo3 to test and validate those applications before importing them into Microsoft Intune.

Purpose

This solution enables organisations to have direct visibility into their application sources - because Evergreen runs in your environment and only communicates with approved vendor source locations, you can guarantee the trustworthiness of the application binaries before import.

The workflow provides a way to upload pre-configured application packages to the Rimo3 platform using a manual trigger. So any application supported by Evergreen can be used with workflow by creating an install wrapper with the PSAppDeployToolkit and imported into Rimo3. As new versions of applications are made available, import into Rimo3 is made simple with automated discovery with Evergreen.

About Rimo3

Rimo3 is a comprehensive platform designed for modernizing and managing enterprise workspaces, ensuring that IT teams can transition smoothly to modern environments like Windows 365, Windows 11, Azure Virtual Desktop, and Intune. One of its standout features is its robust approach to application lifecycle management — a process that covers every phase of an application’s existence within an IT ecosystem.

At its core, Rimo3 automates several key tasks that traditionally require significant manual effort. It automatically discovers the full inventory of applications within an organization, ensuring that nothing is overlooked. Once apps are identified, the platform systematically validates them against specific environmental criteria to check for compatibility and performance, which is crucial before any change is deployed. After validation, Rimo3 helps package the applications into modern deployment formats (like Win32 or MSIX) that align with contemporary management frameworks. Finally, it streamlines patch management by automating the testing and deployment of application updates, reducing the likelihood of disruptions or performance issues that can arise from manual patching processes.

By employing automation at each stage—from discovery through to patch deployment — Rimo3 transforms what is often a complex, error-prone manual process into a smooth and efficient workflow. This not only bolsters security and operational continuity but also frees IT teams to focus on more strategic tasks, reducing downtime and minimizing risk across the entire application ecosystem.

About Evergreen

Evergreen is a PowerShell module that automatically retrieves the latest version information and download URLs for a range of common Windows applications by directly querying the vendors’ update APIs. Rather than relying on third-party aggregators, the module pulls data directly from the source, ensuring that the information is both current and trustworthy. This enables you to import application packages into Rimo3 with full visibility into the application sources and reduce supply chain attacks.

Here’s an example - let’s use Evergreen to find the latest version of the Microsoft SQL Server Management Studio. Using the Get-EvergreenApp command, Evergreen will query the Microsoft site and return a list of the available installers. With this detail, we can check whether the latest version is already imported into Rimo3 and if not, download, package, and import into Rimo3:

Get-EvergreenApp -Name "MicrosoftSsms"

Version   Date     Language              URI
-------   ----     --------              ---
20.1.10.0 3/4/2024 English               https://download.microsoft.com/download/7519f0ff-997c-4f36-b5aa-9a51d47dd34c/SSMS-Setup-ENU.exe
20.1.10.0 3/4/2024 French                https://download.microsoft.com/download/7519f0ff-997c-4f36-b5aa-9a51d47dd34c/SSMS-Setup-FRA.exe
20.1.10.0 3/4/2024 German                https://download.microsoft.com/download/7519f0ff-997c-4f36-b5aa-9a51d47dd34c/SSMS-Setup-DEU.exe
20.1.10.0 3/4/2024 Italian               https://download.microsoft.com/download/7519f0ff-997c-4f36-b5aa-9a51d47dd34c/SSMS-Setup-ITA.exe
20.1.10.0 3/4/2024 Japanese              https://download.microsoft.com/download/7519f0ff-997c-4f36-b5aa-9a51d47dd34c/SSMS-Setup-JPN.exe
20.1.10.0 3/4/2024 Korean                https://download.microsoft.com/download/7519f0ff-997c-4f36-b5aa-9a51d47dd34c/SSMS-Setup-KOR.exe
20.1.10.0 3/4/2024 Portuguese (Brazil)   https://download.microsoft.com/download/7519f0ff-997c-4f36-b5aa-9a51d47dd34c/SSMS-Setup-PTB.exe
20.1.10.0 3/4/2024 Russian               https://download.microsoft.com/download/7519f0ff-997c-4f36-b5aa-9a51d47dd34c/SSMS-Setup-RUS.exe
20.1.10.0 3/4/2024 Spanish               https://download.microsoft.com/download/7519f0ff-997c-4f36-b5aa-9a51d47dd34c/SSMS-Setup-ESN.exe
20.1.10.0 3/4/2024 Chinese (Simplified)  https://download.microsoft.com/download/7519f0ff-997c-4f36-b5aa-9a51d47dd34c/SSMS-Setup-CHS.exe
20.1.10.0 3/4/2024 Chinese (Traditional) https://download.microsoft.com/download/7519f0ff-997c-4f36-b5aa-9a51d47dd34c/SSMS-Setup-CHT.exe

About the solution

This solution demonstrates to customers of Rimo3 how to use Evergreen in an automated workflow to download the latest version of an application, wrap the installer with the PowerShell App Deployment Toolkit, and import into Rimo3.

The solution is provided in a GitHub repository and includes workflows for GitHub and Azure Pipelines. The workflows run the Start-PackageUpload.ps1 script which can be run outside of the workflow process (on other platforms or manually).

To use this in your own environment, fork the repository or copy the code and modify to run on your platform of choice.

Components

The workflow can be run via GitHub Actions or Azure Pipelines and uses the following components:

• Evergreen - you can view the list of supported applications in the Evergreen App Tracker
• PSAppDeployToolkit - this provides an install wrapper for the target application and simplifies the application definition when importing into Rimo3. Additionally, standardising on the PSAppDeployToolkit for application installs enables a consistent approach and the ability to interest with the end-user during an application install
• Rimo3 and the Rimo3 API - the API is leveraged to import application packages into Rimo3, including defining how the application package should be processed (Import + Discovery + Baseline + Test + Export to Intune)

When a new version of an application is available, the workflow can be re-run to import the new version into Rimo3 for testing and validation, and if validation is successful, export to Intune.

Application packages imported into Rimo3.

Workflow process

The repository includes workflows for GitHub Actions and Azure Pipelines and supports the import of a single application package; however, multiple packages can be provided to Start-PackageUpload.ps1.

Here’s a high-level look at the workflow process:

1. The Evergreen PowerShell module must be installed before running the workflow. The module is updated approximately every 6 weeks, so ensure the latest version is always installed.
2. Credentials for the API need to be protected, so they can be securely stored as GitHub Secrets or in an Azure Pipelines asset library.
3. The workflow will first check whether the same version of the application has already been imported. If it finds a matching version it will not continue.
4. Each application package includes an App.json file that describes the application including the filter that Evergreen should use to determine the application installer to use
5. The PSAppDeployToolkit 4 is used, and application install and uninstall logic is included in Invoke-AppDeployToolkit.ps1 for each package.
6. The workflow supports EXE, MSI, and MSIX installers, including installers that may be provided as zip files (which require extracting before packaging and sending to Rimo3)
7. During packaging, the latest installer is downloaded and included with the PSAppDeployToolkit. The workflow readies the package for Rimo3 and uploads the package to Rimo3 for processing
8. When the package is successfully uploaded to Rimo3, you can then monitor the processing of the application in the Rimo3 console

Application packages actively being imported into Rimo3.

Under the hood

Application install

Each application package includes at least two files:

• App.json - this file describes the application including how Evergreen should be used to find the application version and binaries, application name and version etc. This also allows for some separation of changing application versions and the PSAppDeployToolkit which is typically static. This file is updated with Evergreen to ensure it includes details of the latest version of each application
• Invoke-AppDeployToolkit.ps1 - this is the primary PSAppDeployToolkit installation and uninstall script for each application, so it includes application specific logic for each application.

Template files for an application package.

The following code can be found in Invoke-AppDeployToolkit.ps1 which reads App.json to find detail of the target application and minimise changes to this script for each application update:

# Read App.json to get details for the app
$AppJson = Get-Content -Path "$PSScriptRoot\App.json" | ConvertFrom-Json

# Get the installer file specified in the App.json
$Global:Installer = Get-ChildItem -Path $AppJson.PackageInformation.SetupFile -Recurse

Initial application list

The project repository includes the following applications:

• Audacity
• Citrix Workspace App (Current release)
• Cyberduck
• Foxit Reader
• Google Chrome
• ImageGlass
• Microsoft PowerToys
• Microsoft SQL Server Management Studio
• Microsoft Visual Studio Code
• Microsoft Azure Virtual Desktop Remote Desktop Client
• Mozilla Firefox
• Notepad++
• Paint.NET
• ScreenToGif
• Tracker Software PDFX Change Editor
• VideoLan VLC Player

The approach taken in this project is similar to my PSPackageFactory for Intune, thus more applications can be added quite easily.

Authenticating to the Rimo3 API

Authenticating to the Rimo3 API requires constructing a form with credentials to the API. You can find details in this article Rimo3 API - New endpoint for generating an API Access Token.

Here’s how this looks - the client ID and secret used to authenticate to the API should be securely stored. In this example, these values have been passed to the script, encoded and used with Invoke-WebRequest to post the credentials and return an authentication token.

$EncodedString = [System.Text.Encoding]::UTF8.GetBytes("${ClientId}:$ClientSecret")
$Base64String = [System.Convert]::ToBase64String($EncodedString)
$params = @{
    Uri             = "https://rimo3cloud.com/api/v2/connect/token"
    Body            = "{`"Form-Data`": `"grant_type=client_credentials`"}"
    Headers         = @{
        "Authorization" = "Basic $Base64String"
        "Cache-Control" = "no-cache"
    }
    Method          = "POST"
    UseBasicParsing = $true
    ErrorAction     = "Stop"
}
$Token = Invoke-RestMethod @params

Importing an application

Details on how to use the API to import an application package can be found here: Rimo3 API - Import an Application.

Within the workflow, once the application binaries have been downloaded, and included with a PSAppDeployToolkit template, the package is compressed into a single zip file and posted to the Rimo3 API to import the application package. To provide the API with the information required to describe the application package, details from App.json are used, including the package display name, publisher and version information.

Here’s how uploading the application package looks in detail:

$params = @{
    Uri             = "https://rimo3cloud.com/api/v2/application-packages/upload/manual"
    Method          = "POST"
    Headers         = @{
        "accept"        = "application/json"
        "Authorization" = "Bearer $($Token.access_token)"
    }
    Form            = @{
        "file"             = (Get-Item -Path $ZipFile.FullName)
        "displayName"      = $AppJson.Information.DisplayName
        "comment"          = "Imported by Evergreen"
        "fileName"         = $AppJson.PackageInformation.SetupFile
        "publisher"        = $AppJson.Information.Publisher
        "name"             = $AppJson.Application.Title
        "version"          = $EvergreenApp.Version
        "installCommand"   = $AppJson.Program.InstallCommand
        "uninstallCommand" = $AppJson.Program.UninstallCommand
        "tags"             = $Tags
        "progressStep"     = "2"
    }
    ContentType     = "multipart/form-data"
    UseBasicParsing = $true
    ErrorAction     = "Continue"
}
Invoke-RestMethod @params

Note the value for progressStep in this sample - the workflow defaults to a value of 2 - Import + Discovery + Baseline. This value needs to be changed to 3 to enable Import + Discovery + Baseline + Test.

Once the application package has been imported, you can view its details. Note the file name and install command in the screenshot below, showing the PSAppDeployToolkit components and syntax.

Application packages details in Rimo3.

Orchestration

Workflow execution

There are many ways that you can orchestrate the import of application packages. I typically default to Azure Pipelines or GitHub Actions because these platforms integrate with the code repository and make it simple to schedule workflow execution.

The workflow to import an application package into Rimo3 has been included for Azure Pipelines and GitHub Actions. By default this workflow is run manually and allows you to select an application to import.

Here’s the Azure Pipelines version:

Running the package import workflow in Azure Pipelines.

And here is the GitHub Actions version:

Running the package import workflow in GitHub Actions.

Updating packages

The repository includes a workflow (update-packagejson) that leverages Evergreen to update the App.json file for each application. This currently runs once every 24 hours, checks for application updates with Evergreen, and commits changes back to the repository. This process can be done at packaging time; however, it enables a trigger that can be used to start import on detection of a new version of an application.

Secrets

Add the required secrets to the repository to enable the Start-PackageUpload.ps1 script to authenticate to the Rimo3 API:

• CLIENT_ID - Authentication client ID
• CLIENT_SECRET - secret value to authenticate with the client ID

The following secrets are used by the update-packagejson workflow to commit changes and sign git commits:

• COMMIT_EMAIL - Email address used for commits
• COMMIT_NAME - Display name used for commits
• GPGKEY - Signing key for commits (optional - remove signing options from the workflow if required)
• GPGPASSPHRASE - Passphrase used to unlock the key during commits (optional - remove signing options from the workflow if required)

If you’re running the solution in GitHub Actions, configure the repository secrets:

GitHub Secrets required by the solution, including secrets used by workflows that automatically update the source based on application updates.

If you’re running the solution in Azure Pipelines, configure a variable group and ensure the authentication values are protected:

Azure Pipelines secrets required by the solution, including secrets used by workflows that automatically update the source based on application updates.

Summary

Evergreen is a natural complement to the Rimo3 platform, providing you with a trusted source for your application packages. With the solution provided here, you leverage Evergreen and Rimo3 to discover, validate and modernise your application lifecycle management.

Star, fork and contribute to the project on GitHub here: Rimo3 + Evergreen.

I need a new server

Back in 2016, I purchased an Intel NUC for running various workloads - it’s previously run VMs on Hyper-V (Windows 10) or Ubuntu. For the past few years it has been relegated to home network management by running a UniFi Network Server, AdGuard Home and Homebridge. At over eight years old now, it’s past its prime and I’ve been looking at a replacement for some time.

A couple of options for replacement devices included:

• Raspberry Pi 5 - $260 AUD for a Pi 5, 8GB RAM, 256 GB SSD, SSD NVMe hat, aluminium case and a power supply. This is a great price point for a device that would run a couple of simple services for my home network
• ASUS NUC - $627 AUD for an ASUS NUC 13 Pro Arena Canyon i3, 8GB RAM, 256GB SSD. While this would be more versatile, it’s way above what I’m willing to pay for this project

Why a Mac mini

Recently I picked up a Mac mini M4 Pro as my primary work device, so the thought occurred to me use another Mac mini as a home server. There’s a few reasons why a Mac would make for a good server:

1. Low power consumption. The M series chip should sit somewhere between a Raspberry Pi and an x86 15W chip
2. macOS content caching - with multiple Macs, iPads, iPhones and an Apple TV in the house, we have a good number of devices that can use local caching
3. Time Machine backups - I’ve previously used Time Machine on a Synology NAS, but it would fail every so often. Backup to a macOS Time Machine server should be more stable
4. Silence - our home server sits in our lounge room in the TV cabinet, so silence is important

I went with a Mac mini M1 with 8GB RAM, 256GB SSD and 2 Thunderbolt 3 ports from eBay for $450 AUD. Not at lot of RAM and storage to be sure, but the downside of a second hand Mac is that these are still way overpriced, even with the release of the latest M4 Mac. If you’re looking for a second hand Mac mini on eBay, it pays to be patient and find one at the right price.

Thankfully, mine arrived in the original box, with no marks or scratches, and in good working order.

Set up a Mac mini as a server

Hardware Setup

For this role, I have the Mac mini connected to the network via ethernet. While not strictly required, it also has an HDMI dummy plug so that it thinks it as a 1080p monitor plugged in allowing it to run headless.

For storage I have an old 256GB SATA SSD plugged in via USB-C because that’s what I had to hand; however, I’ll replace this with a Thunderbolt 3 / USB 4 drive enclosure and a PCIe Gen3 M.2 SSD (there’s no point going to Gen4 because Thunderbolt 3 will be the bottleneck).

First Boot Setup

During the initial macOS setup, I’ve skipped iCloud configuration and not used an Apple ID - I don’t want iCloud downloading Photos, Messages and files etc., to this device. Additionally, FileVault is not enabled so that I can remotely start or reboot the machine.

Initially I was running this without being logged in, but I found that /usr/libexec/audiomxd would run with high CPU utilisation like this, so it now logs in automatically to the desktop at boot. This also helps with a couple of apps that I’ll discuss later.

Performance and Power Settings

I’ve configured the following settings to either reduce power consumption or improve performance when accessing the Mac remotely. I don’t have hard proof for every setting here, but these logically make sense based on the potential for local or remote access performance.

• Disable Wi-Fi and Bluetooth - Off. I have no need for these on this machine and disabling these will help to save on power consumption I found that after some time, the system would end up not being accessible remotely, even over ethernet, until Wi-Fi was enabled
• System Settings / Energy / Prevent automatic sleeping with the display is off, Wake for network access, Start up automatically after network failure. These settings are enabled to ensure the device does not got to sleep
• System Settings / Accessibility / Display / Reduce motion, Reduce transparency - On
• System Settings / Appearance / Allow wallpaper tinting in windows - Off
• System Settings / Apple Intelligence & Siri - Off. This feature is certainly not required on a server
• System Settings / Desktop & Dock / Minimise windows using (Scale effect), Animate opening applications - On
• System Settings / Spotlight / Search results - Disable all options. Once the initial indexing is complete, Spotlight probably won’t use too much in terms of resources, but turning it off will eke out that little extra performance or avoid performance issues.

Spotlight can be completely disabled with sudo mdutil -v -E -i off /. Keep in mind that this will likely reduce the effectiveness of searching on mounted shares from remote machines.

• System Settings / Wallpaper / Choose a solid colour
• System Settings / Notifications / Show previews (Never), Allow notifications when the display is sleeping (Off), Allow notifications when the screen is locked (Off)
• System Settings / Sound / Play sound on startup, Play user interface sound effects - Off. The Mac mini has a built in speaker, but doesn’t need to be making sound in the lounge room
• System Settings / Lock Screen / Start Screen Saver when inactive (Never), Turn display off when inactive (For 5 minutes), Require password after screen saver begins or display is turned off (Never), Show large clock (Never) - these settings make sure that the screen saver won’t kick in to consume CPU, but the screen, even with the HDMI headless adapter, will turn off to reduce power consumption
• System Settings / Game Center (Off) - I won’t be gaming on this machine

Sharing Settings

Here’s how I’ve configured sharing settings in macOS:

• System Settings / General / Sharing / File Sharing - On. I don’t need large amounts of remote file storage, but this is for convenience
• System Settings / General / Sharing / Media Sharing - Home Sharing. I’ve copied my music library to this device and this enables remote sharing from the Apple TV etc.
• System Settings / General / Sharing / Screen Sharing - On. This allows remote access to the device via the Screen Sharing app
• System Settings / General / Sharing / Content Caching - Storage (cache location is on an external drive), Clients / Devices using the same public IP address, use only public IP address.

Content Cache stats aren’t fantastic just yet, but over time this will increase. On another machine I’ve seen this at around 45GB cached.

• System Settings / General / Sharing / Remote Login - On. This enables SSH access to perform simple remote management tasks
• System Settings / General / Software Update / Automatic Updates - Download new updates when available, Install macOS updates, Install application updates from the App Store, Install Security Responses and system files - On

Homebrew

Before installing any software, I’ve installed Homebrew, giving me a package manager for macOS that I can use at the command line.

To make updating packages with Homebrew simpler, I’ve added this alias to my .zshrc file:

alias drink="brew update && brew upgrade && brew cleanup"

DNS filtering with AdGuard Home

Installing AdGuard Home on macOS is straight-forward - I followed the automated install instructions to install directly onto macOS (i.e. no Docker etc.).

Before setup, I’ve configured external DNS servers in macOS to be able to complete the download and install of AdGuard, then post setup, the device is using my router as the DNS server, which is how all devices on my network are configured. The router then points to AdGuard for all DNS services.

Extending Apple HomeKit with HomeBridge

I have replaced Homebridge with Home Assistant - I had too many issues with Homebridge and Home Assistant supports Homekit integration, so I have something more stable. I’ve installed the Home Assistant Operating System in a VM using UTM.

The install instructions for HomeBridge on macOS are easy to follow; however, HomeBridge requires Node and that’s more complex to install correctly.

I’ve found the best way to install Node on macOS, is to first install nvm via Homebrew (brew install nvm), then install the latest LTS version of Node via nvm (rather than installing Node directly via Homebrew). To install the latest Node LTS, I’ve useD:

nvm install v22.12.0

Two things I’ve found with Homebridge on macOS:

1. I couldn’t get HomeKit to discover the HomeBridge child bridges, so I’ve not used child bridges (just the base Homebridge bridge)
2. To get discovery to work correctly, I’ve had to add the mdns property with the interface value matching the IP address of the listener, as detailed in this issue:

{
    "bridge": {
        "name": "Homebridge 2850",
        "username": "0E:21:D0:DB:28:51",
        "port": 51748,
        "pin": "743-73-994",
        "advertiser": "ciao"
    },
    "mdns": {
        "interface": "192.168.1.4"
    },
    "accessories": [

Remote hardware monitoring with iStatistica

I’ve been using iStatistic Pro for performance monitoring (CPU, RAM, temps etc.) for some time and this application has a web access portal to view stats. For this app to run, a user needs to be signed into the console of the machine.

Serving up media with Plex Server

Installing and configuring Plex Server is very simple - just follow the install instructions. Like iStatistica, Plex Server requires a user to be signed into the console for the app to run.

Plex Server can be installed with Homebrew via this command:

brew install plex-media-server

Download torrents with Transmission

Transmission is my typical go-to for torrent downloads on macOS. It includes a remote web access interface for adding and monitoring downloads. Just like iStatistica and Plex Server, it too requires a user to be signed into the console for the app to run.

One issue I’ve found with the remote access interface, is that I need to access it via the IP address rather than the host name for the app to work.

Usage and Observations

I’ve only been running this server for a week, but so far it performs really well.

• CPU utilisation sits at around 3-5% for normal operation. This increases for various activities including installing updates, Plex Server doing transcoding, etc. CPU does also increase when connecting to the server via Screen Sharing, so I don’t keep a session connected for too long
• CPU, GPU, etc., temperatures stay cool, with the CPU barely getting above 30C
• RAM usage is typically around 2.6 - 2.8GB with all services running and Memory Pressure at around 49%. Most importantly, swap is at 0 bytes. For these services I’m running right now, 8GB of RAM looks to be plenty; however, at 16GB RAM model of the Mac mini would provide plenty of future capacity - Check if your Mac needs more RAM in Activity Monitor
• Disk space should be OK for this device - 256GB capacity for the primary OS disk isn’t a lot these days; however, for this device specifically, I’m keeping used space on the OS disk to a minimum by offloading to external storage
• Power consumption is great at around 6W when idle. This increases to around 7W when watching a 4K video via Plex, and I’ve seen this peak at around 10W. I’m really happy with this power consumption for a device that’s going to be on 24/7 - this replaces the 12-14W the Intel NUC was using at idle

So is a Mac mini suitable as a home server? For me the answer is certainly Yes. This is primarily due to having a good number of Apple devices at home that can take advantage of Apple specific features including Content Caching and Time Machine. The low power consumption is excellent for the number of services that it’s capable of running.

While it’s not as efficient as a Raspberry Pi or as flexible as a customised x86 machine, it’s ended up being right where it needs to be for my purposes.

As with any desktop environment, virtual desktops undergo regular change - monthly OS and application updates, new applications, and configurations all add to the variation. Change must be managed and should be well tested to ensure business services are not impacted with a new or updated image.

Pooled virtual desktops that are deployed from a gold image are useful for managing change at scale - the user environment is separate from the desktop and users can connect to any available desktop in a pool, so all virtual machines must run the same image.

The gold image build and change process can be automated on any platform and version of Windows, but automation can be a time consuming process. Investing in an image automation process will save your bacon when it counts.

A management and validation process is required to manage an image and this process will look similar to this:

flowchart LR
    A[Build]
    A --> B[Validate]
    B --> C[UAT]
    C --> D[Deploy]

When a gold image is updated and deployed, most organisations will rely on manual user acceptance testing before promoting that image into production. Adding automated testing in the VALIDATE phase ensures you can capture things users won’t, or speed the mundane task of manually validating your images.

There are several commercial solutions that can automate application testing (for example, Rimo3), but you may want to augment these with additional valiatdation tests. For example, testing that your image includes the intended applications, application versions, files, registry settings or service status.

Pester + Azure Pipelines

With Pester and Azure Pipelines, we can create an image test framework that runs on a target virtual machine and generates reports to track the results. This approach uses a standard and well supported test framework, along with Azure Pipelines which is available in most enterprises (although, you could replace Azure Pipelines with just about any CI/CD service).

Here’s a look at what we’re going to build:

Azure Pipelines result with 100% of tests passed.

Building this solution will involve a few components:

• PowerShell and Pester, the testing framework in which we can write our tests
• Evergreen to provide application version numbers - regardless of how you install applications, Evergreen enables you to query an image to determine whether it’s running the latest version of an application
• JSON to define our tests so that we don’t have to hard code all tests in Pester
• Azure DevOps to store the tests and code
• Azure Pipelines and self-hosted agents to run tests against our UAT images

Note that in this example, I’m using Azure Virtual Desktop and Nerdio Manager to create images and run session hosts; however, this approach will work with any VDI solution including those deployed on-premises or in a public cloud platform.

Testing with Pester

Single Application Test

Pester can be used to perform an application configuration test. Here’s a simple example of using Pester to ensure that the default home page for Microsoft Edge has been set in the image.

Describe "Microsoft Edge" {
    Context "Application preferences" {
        It "Should have written the correct content to master_preferences" {
            (Get-Content -Path "${Env:ProgramFiles(x86)}\Microsoft\Edge\Application\master_preferences" | ConvertFrom-Json).homepage | Should -BeExactly "https://www.microsoft365.com"
        }
    }
}

This will generate a pass / fail result allowing us to determine whether the image has the correct configuration for Edge. If it fails, we know our image isn’t ready for UAT and can’t be pushed into production.

Additional tests can be written just like this example. Storing application tests in one Pester file per application can be a way to ensure those tests are highly portable between image configurations.

Multiple Application Tests

Our tests will be more scalable if a single script can take input that defines tests for multiple applications. We can scale out our test results for each application without having to write additional code.

Pester file to run tests against a set of applications.

For example, here’s a Pester block that takes input to test various properties of an application:

Context "Application configuration tests" {
    It "Should be the current version or better" {
        [System.Version]$Installed.Version | Should -BeGreaterOrEqual ([System.Version]$Latest.Version)
    }

    It "Should have application file installed: <_>" -ForEach $FilesExist {
        $_ | Should -Exist
    }

    It "Should have shortcut deleted or removed: <_>" -ForEach $ShortcutsNotExist {
        $_ | Should -Not -Exist
    }

    It "Should have the service disabled: <_>" -ForEach $ServicesDisabled {
        (Get-Service -Name $_).StartType | Should -Be "Disabled"
    }
}

This block does a few things:

1. Compares the installed version of the application against the latest version returned by Evergreen
2. Tests that an array of files exists (i.e. key files exist in the expected locations)
3. Tests that an array of shortcuts do not exist (to test that an install script has removed shortcuts)
4. Tests that an array of services has been disabled (some applications include services that are recommended to be disabled in VDI images)

Input File

The Pester script takes input via a JSON file that describes the tests for applications in our image. The script and the input file could be extended to test practically anything in the image. The example input file below lists tests for 3 applications to determine that the application is installed, is current, has files in the expected directories, and services in a disabled state:

[
    {
        "Name": "MicrosoftFSLogixApps",
        "Filter": "Get-EvergreenApp -Name \"MicrosoftFSLogixApps\" | Where-Object { $_.Channel -eq \"Production\" } | Select-Object -First 1",
        "Installed": "Microsoft FSLogix Apps",
        "FilesExist": [
            "C:\\Program Files\\FSLogix\\Apps\\frx.exe",
            "C:\\Program Files\\FSLogix\\Apps\\ConfigurationTool.exe",
            "C:\\Program Files\\FSLogix\\Apps\\frxcontext.exe",
            "C:\\Program Files\\FSLogix\\Apps\\frxshell.exe"
        ],
        "ShortcutsNotExist": [
            "C:\\ProgramData\\Microsoft\\Windows\\Start Menu\\FSLogix\\FSLogix Apps Online Help.lnk"
        ],
        "ServicesDisabled": []
    },
    {
        "Name": "MicrosoftEdge",
        "Filter": "Get-EvergreenApp -Name \"MicrosoftEdge\" | Where-Object { $_.Architecture -eq \"x64\" -and $_.Channel -eq \"Stable\" -and $_.Release -eq \"Enterprise\" } | Sort-Object -Property \"Version\" -Descending | Select-Object -First 1",
        "Installed": "(^Microsoft Edge$)",
        "FilesExist": [
            "C:\\Program Files (x86)\\Microsoft\\Edge\\Application\\master_preferences"
        ],
        "ShortcutsNotExist": [
            "C:\\Users\\Public\\Desktop\\Microsoft Edge*.lnk"
        ],
        "ServicesDisabled": []
    },
    {
        "Name": "AdobeAcrobatReaderDC",
        "Filter": "Get-EvergreenApp -Name \"AdobeAcrobatReaderDC\" | Where-Object { $_.Language -eq \"MUI\" -and $_.Architecture -eq \"x64\" } | Select-Object -First 1",
        "Installed": "Adobe Acrobat.*64-bit",
        "FilesExist": [
            "C:\\Program Files\\Adobe\\Acrobat DC\\Acrobat\\Acrobat.exe",
            "C:\\Program Files\\Adobe\\Acrobat DC\\Acrobat\\AdobeCollabSync.exe"
        ],
        "ShortcutsNotExist": [],
        "ServicesDisabled": [
            "AdobeARMservice"
        ]
    }
]

Azure Pipelines

Azure Pipelines will run the tests against our target image via the Pipelines agent. To run our tests, we need two things - a pipeline, and an agent pool with self-hosted agents.

An Azure Virtual Desktop session host as a self-hosted agent for Azure Pipelines.

Agent Pool

I won’t cover creating an agent pool in detail here, instead refer to the documentation - Create and manage agent pools. The agent pool name is important though as it needs to be referred to in the pipeline file and the agent install script.

Pipeline

The pipeline configuration defines how the pipeline will run and post results back to DevOps for reporting. Below is a code listing of the pipeline file which does the following:

• Install Pester - note that Evergreen is also required, so you will need to add that to the list of installed modules, if Evergreen is not already installed into the image
• Run the tests stored in the tests directory
• Post the test results back to DevOps for reporting - this is displayed as the pass / fail status
• Gather a list of the installed applications and post that back to DevOps as well. This information will enable you to track application versions across images

pool: 'Azure Virtual Desktop aue'

steps:
- powershell: |
    $params = @{
      Name               = "Pester"
      SkipPublisherCheck = $true
      Force              = $true
      ErrorAction        = "Stop"
    }
    Install-Module @params
  name: pester
  displayName: 'Install Pester'
  workingDirectory: $(build.sourcesDirectory)
  errorActionPreference: continue
  continueOnError: false

- powershell: |
    Import-Module -Name "Pester" -Force -ErrorAction "Stop"
    $Config = New-PesterConfiguration
    $Config.Run.Path = "$(build.sourcesDirectory)\tests"
    $Config.Run.PassThru = $true
    $Config.TestResult.Enabled = $true
    $Config.TestResult.OutputFormat = "NUnitXml"
    $Config.TestResult.OutputPath = "$(build.sourcesDirectory)\TestResults.xml"
    $Config.Output.Verbosity = "Detailed"
    Invoke-Pester -Configuration $Config
  name: test
  displayName: 'Validate installed apps'
  workingDirectory: $(build.sourcesDirectory)
  errorActionPreference: continue
  continueOnError: true

- publish: "$(build.sourcesDirectory)\\InstalledApplications.csv"
  artifact: InstalledApplications
  continueOnError: true

- publish: "$(build.sourcesDirectory)\\TestResults.xml"
  artifact: TestResults
  continueOnError: true

- task: PublishTestResults@2
  inputs:
    testResultsFormat: "NUnit"
    testResultsFiles: "$(build.sourcesDirectory)\\TestResults.xml"
    failTaskOnFailedTests: true
    testRunTitle: "Publish Pester results"

Installing the Azure Pipelines agent

The Azure Pipelines agent is required to add a virtual machine as a self-hosted agent. The Azure Pipelines agent should not be built into your gold image - it should be installed into a target session host after it’s been deployed.

In my Azure Virtual Desktop environment, Nerdio Manager is used to create images, deploy session hosts, and manage scaling. Nerdio Manager Scripted Actions can be run when a session host is created. This enables us to install the Azure Pipelines agent on session hosts in a UAT host pool when the session host is created.

Nerdio Manager also makes it simple to pass secure strings into the agent install script at runtime. The install script uses Evergreen to find the latest version of the Azure Pipelines agent, download, unpack and install the agent, including creating a local user account required by the agent and setting Azure DevOps settings.

The install script requires the following variables to be set in Scripted Actions Global Secure Variables

• DevOpsUrl - the URL to our DevOps organisation
• DevOpsPat - the Personal Access Token used to authenticate to Azure DevOps
• DevOpsPool - the agent pool that the self-hosted agent will register with
• DevOpsUser - the local user account name the install script will create. This account will be added to the local administrators group on the target session host; therefore, I recommend you do not deploy this to production workloads
• DevOpsPassword - the password for the local user account

Nerdio Manager Secure Variables for the Azure Pipelines agent.

The block below lists the code for the installing the Azure Pipelines agent. This uses Evergreen to find the latest version and download into the session host:

#description: Installs the Microsoft Azure Pipelines agent to enable automated testing via Azure Pipelines. Do not run on production session hosts.
#execution mode: Combined
#tags: Evergreen, Testing, DevOps

# Check that the required variables have been set in Nerdio Manager
foreach ($Value in "DevOpsUrl", "DevOpsPat", "DevOpsPool", "DevOpsUser", "DevOpsPassword") {
    if ($null -eq $SecureVars.$Value) { throw "$Value is null" }
}

# Download and extract
[System.String] $Path = "$Env:SystemDrive\agents"
New-Item -Path $Path -ItemType "Directory" -Force -ErrorAction "SilentlyContinue" | Out-Null
Import-Module -Name "Evergreen" -Force
$App = Get-EvergreenApp -Name "MicrosoftAzurePipelinesAgent" | Where-Object { $_.Architecture -eq "x64" } | Select-Object -First 1
$OutFile = Save-EvergreenApp -InputObject $App -CustomPath $Env:Temp -WarningAction "SilentlyContinue"
Expand-Archive -Path $OutFile.FullName -DestinationPath $Path -Force
Push-Location -Path $Path

# Create the local account that the DevOps Pipelines agent service will run under
$params = @{
    Name                     = $SecureVars.DevOpsUser
    Password                 = (ConvertTo-SecureString -String $SecureVars.DevOpsPassword -AsPlainText -Force)
    Description              = "Azure Pipelines agent service for elevated exec."
    UserMayNotChangePassword = $true
    Confirm                  = $false
}
New-LocalUser @params
Add-LocalGroupMember -Group "Administrators" -Member $SecureVars.DevOpsUser

# Agent install options
$Options = "--unattended
        --url `"$($SecureVars.DevOpsUrl)`"
        --auth pat
        --token `"$($SecureVars.DevOpsPat)`"
        --pool `"$($SecureVars.DevOpsPool)`"
        --agent $Env:COMPUTERNAME
        --runAsService
        --windowsLogonAccount `"$($SecureVars.DevOpsUser)`"
        --windowsLogonPassword `"$($SecureVars.DevOpsPassword)`"
        --replace"
$params = @{
    FilePath     = "$Path\config.cmd"
    ArgumentList = $($Options -replace "\s+", " ")
    Wait         = $true
    NoNewWindow  = $true
    PassThru     = $true
}
Start-Process @params

This script should be imported into Nerdio Manager as a scripted action, and added to the VM Deployment settings on the host pool, so that the agent is installed when a session host is deployed.

Running the Pipeline

When you have a new version of a gold image, deploy the image to a UAT host pool, then manually run the Azure Pipeline to validate the image.

Right now, it’s a manual process to start the pipeline because we don’t have a self-hosted agent running until a new image has been deployed. With some additional configuration this could be automated so the pipeline kicks off when a new image is deployed. The pipeline could be run via an API call to Azure DevOps when an a new session host is deployed via some external orchestration host.

Manually starting the pipeline on a new image.

Results

A pipeline run only takes a few seconds and the results can be tracked across runs. Update your retention settings to retain reports for longer.

Azure Pipelines result showing passed and failed tests.

Artifacts are stored on the pipeline run - InstalledApplications.csv will help keep track of installed applications and versions.

Artifacts stored on the pipeline.

Getting Started

In this article, I’ve assumed you have an understanding of PowerShell, Pester, and Azure DevOps / Pipelines. If any of the concepts aren’t clear, comment below, and I’ll might be able to expand on some details in future articles.

To get the most out of this approach, I highly recommended that you are also automating the build of new gold images. The framework outlined in this article could also be run at the end of an automated build; however, even if you are manually building images, this approach can assist in validation.

To get started with this test and validation solution, you can fork the code in my vdi-uat repository here: https://github.com/aaronparker/vdi-uat.

I’ve previously written about using IntuneCD in a GitHub or Azure DevOps pipeline to backup and document an Intune tenant in these articles:

• Automate Microsoft Intune As-Built Documentation on GitHub
• Automate Microsoft Intune As-Built Documentation on Azure DevOps

The approach uses Linux runners hosted by GitHub or Microsoft, thus the platform configuration is already taken care of (Python, Node.js, and dependencies etc.). I do often find myself using IntuneCD locally to backup a tenant and produce an as-built document - running locally requires installing the prerequisites which can be a bit of fun (or hair pulling) depending on your target platform.

In this article, I’ll cover the steps to install and configure the prerequisites for running IntuneCD on Windows, Windows Subsystem for Linux (WSL2), Linux and macOS. Note - these are the install steps that have worked for me on each of these platforms. Your mileage may vary.

Running IntuneCD Locally

The scripts below can be used to backup your Intune tenant and create a new as-built document in PDF and HTML formats. This approach is useful where you might not want to go as far as creating a pipeline to automate the entire process. These scripts can be used for an adhoc approach to backup and document generation.

Below is the script in PowerShell format which has been tested on Windows. You can find the original source in my template repository on GitHub.

New-Item -Path "$PWD\prod-backup" -ItemType "Directory"
IntuneCD-startbackup --mode=1 --output=json --path="$PWD\prod-backup" --localauth="$PWD\auth.json"

# Generate the as-built document in markdown
$Auth = Get-Content -Path "$PWD\auth.json" | ConvertFrom-Json
$INTRO="Intune backup and documentation generated locally. <img align=`"right`" width=`"96`" height=`"96`" src=`"./logo.png`">"
IntuneCD-startdocumentation --path="$PWD\prod-backup" --outpath="$PWD\prod-as-built.md" --tenantname="$($Auth.TENANT_NAME)" --intro="$INTRO"

# Generate a PDF document from the as-built markdown
md-to-pdf "$PWD\prod-as-built.md" --config-file "$PWD\md2pdf\pdfconfig.json"

# Generate a HTML document from the as-built markdown
md-to-pdf "$PWD\prod-as-built.md" --config-file "$PWD\md2pdf\htmlconfig.json" --as-html

Below is the same script in Shell Script format - this has been tested on WSL2, Linux and macOS:

mkdir -p "$PWD/prod-backup"
IntuneCD-startbackup --mode=1 --output=json --path="$PWD/prod-backup" --localauth="$PWD/auth.json"

# Generate the as-built document in markdown
TENANT=$(jq .params.TENANT_NAME $PWD/auth.json | tr -d \")
INTRO="Intune backup and documentation generated locally. <img align=\"right\" width=\"96\" height=\"96\" src=\"./logo.png\">"
IntuneCD-startdocumentation --path="$PWD/prod-backup" --outpath="$PWD/prod-as-built.md" --tenantname="$TENANT" --intro="$INTRO"

# Generate a PDF document from the as-built markdown
md-to-pdf "$PWD/prod-as-built.md" --config-file "$PWD/md2pdf/pdfconfig.json"

# Generate a HTML document from the as-built markdown
md-to-pdf "$PWD/prod-as-built.md" --config-file "$PWD/md2pdf/htmlconfig.json" --as-html

Authentication

IntuneCD uses an Azure AD app registration to authenticate to the Microsoft Graph API. The script above uses a local JSON file with credentials (see the example below). If your local backup/export of your Intune tenant is hosted in a git repository, make sure you add auth.json to the .gitignore file - Ignoring files.

{
    "params":{
        "TENANT_NAME": "intunetenant.onmicrosoft.com",
        "CLIENT_ID": "28f60124-eb81-40e1-b1c4-1bb06c44ec91",
        "CLIENT_SECRET": "AsT8Q~j_8MqluNxFi_4TIC8kdXzRdjEwM.tZxcjS"
    }
}

Prerequisites

Running the scripts requires the following dependencies:

• Python - IntuneCD is written in Python
• Node.js - required by md-to-pdf
• jq - this is only required when running the script on WSL2, Linux or macOS. The PowerShell script uses ConvertFrom-Json instead

Platform Configuration

Windows

Use the Windows Package Manager (winget) to install an environment on Windows. Elevate a Terminal window, and run the following winget commands to install Python, NVM for Windows (Node.js version manager), and git for Windows.

# Install Python and NVM for Windows
winget install Python.Python.3.11 --silent
winget install CoreyButler.NVMforWindows --silent

If you’re storing your configuration in git repository you can install git locally. Additionally, install the GitHub CLI will help with authenticating to GitHub:

# Install git for Windows and GitHub CLI
winget install Git.Git --silent
winget install Github.cli --silent

Close and restart an elevated Terminal window and install IntuneCD, Node.js, and md-to-pdf. The Node.js install is using NVM as recommended by Microsoft - Install NodeJS on Windows:

# Install IntuneCD, Node.js and md-to-pdf
pip3 install IntuneCD
nvm install 18.6.1
npm i -g md-to-pdf

WSL2 and Linux

The steps for setting up an environment on WSL2 and Linux will be the same.

If your target platform is Windows, the benefit of WSL2 over Linux is that you don’t need to run an entire virtual machine just to run Linux. Additionally, using WSL2 on Windows instead of natively installing python and Node.js, means that your development environment is containerised within WSL, thus you can remove the entire environment by deleting the WSL instance.

However, you may need to weigh that against wasting hours of your life on getting Linux running that you’ll never get back.

The script below will configure an environment, and assumes you are using WLS2 with Ubuntu or an Ubuntu virtual machine with a minimal installation:

• Install required dependencies including jq with apt-get
• Homebrew this will simplify the installation of additional components including Python. I had issues installing Python with pyenv
• Install Python with Homebrew
• Install IntuneCD
• Install nvm and Node.js
• Install md-to-pdf

# Update the OS and install git, curl and build-essential required for Homebrew
sudo apt-get update; sudo apt-get upgrade -y
sudo apt install -y git curl build-essential jq

# Install Node.js dependencies
sudo apt-get install -y libnss3 libnspr4 libatk1.0-0 libatk-bridge2.0-0 libcups2 libdrm2 libxkbcommon0 libxcomposite1 libxdamage1 libxfixes3 libxrandr2 libgbm1 libasound2 libpango-1.0-0 libpangocairo-1.0-0 libpangoft2-1.0-0

# Install Homebrew and Python
/bin/bash -c "$(curl -fsSL https://raw.githubusercontent.com/Homebrew/install/HEAD/install.sh)"
brew install python@3.11

# Update pip and install IntuneCD
python3.11 -m pip install --upgrade pip
pip3 install IntuneCD

# Install Node.js version manager and Node.js LTS
curl -o- https://raw.githubusercontent.com/nvm-sh/nvm/v0.39.3/install.sh | bash
export NVM_DIR="$HOME/.nvm"
[ -s "$NVM_DIR/nvm.sh" ] && \. "$NVM_DIR/nvm.sh"
nvm install --lts

# Install md-to-pdf
npm i -g md-to-pdf

macOS

The script below will set up the required dependencies and tools on macOS. This assumes you are using the default zsh shell and will install the following:

• Homebrew which is the best package manager for macOS
• pyenv to simplify the installation of Python. Follow the install instructions to set up pyenv for macOS and zsh
• jq and GitHub CLI
• Install Python with pyenv and set the default version
• Install IntuneCD
• Install nvm and Node.js
• Install md-to-pdf

# Install Homebrew, pyenv, and jq
/bin/bash -c "$(curl -fsSL https://raw.githubusercontent.com/Homebrew/install/HEAD/install.sh)"
brew update
brew install pyenv jq gh

# Set up the shell environment for pyenv
echo 'export PYENV_ROOT="$HOME/.pyenv"' >> ~/.zshrc
echo 'command -v pyenv >/dev/null || export PATH="$PYENV_ROOT/bin:$PATH"' >> ~/.zshrc
echo 'eval "$(pyenv init -)"' >> ~/.zshrc

# Install Python and set a global version
pyenv install 3.11.4
pyenv global 3.11.4

# Install IntuneCD
pip3 install IntuneCD

# Install Node.js version manager and Node.js LTS
curl -o- https://raw.githubusercontent.com/nvm-sh/nvm/v0.39.3/install.sh | bash
export NVM_DIR="$HOME/.nvm"
[ -s "$NVM_DIR/nvm.sh" ] && \. "$NVM_DIR/nvm.sh"
nvm install --lts

# Install md-to-pdf
npm i -g md-to-pdf

Wrap Up

The commands listed this article should enable you to set up your local environment to use with IntuneCD. This includes each of the required dependencies. I’ve tested on Windows 11, macOS 13.4 and Ubuntu 22.04 across multiple devices and virtual machines, so the commands should be well tested and hopefully work for you.

My preferred platforms for using IntuneCD locally are macOS and Windows. Both platforms are simple to configure and starting using IntuneCD to export an Intune configuration and create an as-built document. However, if you prefer Linux the commands listed in this article will assist in configuring that platform.