The Evergreen Workbench and the EvergreenUI PowerShell module - has reached its first stable release with version 1.0.24. This module adds graphical front-end to the Evergreen module and provides many of the functions of Evergreen. It also includes a few workflows that integrate Evergreen, including importing Win32 packages into Microsoft Intune, importing Shell Apps into Nerdio Manager, and installing local applications.

If you’re not already familiar with Evergreen, it’s a PowerShell module that returns the latest version and download URI for 500+ applications. The Desktop Workbench wraps those same cmdlets (Get-EvergreenApp, Save-EvergreenApp, Start-EvergreenLibraryUpdate, and more) behind an interactive Windows GUI, so you don’t need to fire up a terminal for day-to-day tasks.

In this article, I’ll walk through every view in the Desktop Workbench so you know what to expect when you install it.

The Desktop Workbench is Windows-only - it’s built on WPF, so it requires Windows 10 / Windows Server 2019 or later, PowerShell 5.1 or 7.0+, and .NET Framework 4.7.2+ (or .NET 6+ for PowerShell 7). No additional DLLs are needed beyond what ships with Windows.

Installing the Desktop Workbench

With the stable release, installation is straightforward from the PowerShell gallery:

Install-Module -Name EvergreenUI

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

Import-Module -Name EvergreenUI
Start-EvergreenWorkbench

The workbench depends on these additional modules: ‘Az.Accounts’, ‘Az.Resources’, ‘Az.Storage’, ‘IntuneWin32App’, ‘Microsoft.Graph.Authentication’. To install EvergreenUI and all depdendencies, use the following commands:

Install-Module -Name EvergreenUI, Evergreen, Az.Accounts, Az.Resources, Az.Storage, IntuneWin32App, Microsoft.Graph.Authentication
Import-Module -Name EvergreenUI
Start-EvergreenWorkbench

Apps View

The Apps view shows all 500+ applications supported by Evergreen in a searchable list on the left, with version and download metadata on the right. Use the search box at the top of the list to filter by application name.

Screenshot: Apps View with Microsoft applications.

Select an application from the list and click Refresh to see what Get-EvergreenApp returns for it - Version, and URI, along with additional data such as Date, Channel, Release, Architecture depending on the application. Metadata is cached so that a refresh does not need to be run each time.

Dynamic Filters

When you select an application, the filter options update automatically based on that application’s properties. The available filters vary by application and can include:

Use Clear filters to reset, or Export to CSV to save the filtered results to disk.

Screenshot: Dynamic filters for Adobe Acrobat Reader DC.

Favourites and Column Management

You can star frequently used applications directly from the list - favourites are pinned to the top and saved in your local Workbench settings. The app detail header also shows a Last refresh timestamp when cached data is available.

Right-click any column header to show or hide optional columns. Structural columns like Version and URI stay visible; everything else is optional. Click a column header to sort ascending, then again to sort descending.

Download View

To download application installers, select one or more versions in the Apps View and click Add to download queue, then switch to the Download View to manage and kick off downloads.

Screenshot: Download View with a queued item.

Downloads are processed sequentially in queue order. The toolbar gives you the usual controls - remove selected, clear queue, open folder, and download all. A progress bar at the bottom tracks the active download. Once complete, the Path column fills in with the local file path.

Library View

If you’re already using an Evergreen library (New-EvergreenLibrary, Start-EvergreenLibraryUpdate), the Library View puts a GUI on top of it. Point it at your library directory and it loads the contents - applications, version counts, and paths.

Screenshot: Library View showing installed versions and file details.

Select an application from the library list to see version details: version string, URI, type, size, SHA256 hash, release, and full file path for each version on disk. The toolbar covers the full library lifecycle - browse, open folder, create a new library, refresh the library contents, and trigger an update to pull the latest versions.

Import Tab

The Import Tab is where the workbench includes workflows for Microsoft Intune or Nerdio Manager application management. It has four sub-tabs: Microsoft Intune Win32 Apps, Nerdio Manager Shell Apps, Microsoft 365 Apps, and Authentication.

Import-related modules are loaded when you first open the tab. Sign-in and import actions stay disabled until the required modules finish loading.

Each of the tabs relies on application package definitions that can be found here: https://github.com/EUCPilots/evergreen-packages. This repository includes as set of package definitions for importing supported apps into Intune and Nerdio Manager, including the Microsoft 365 Apps. The Intune and Nerdio Manager packages are currently seperate, but I would like to combine these into a single package definition in the future. The Microsoft 365 Apps configuration files support both Intune and Nerdio Manager.

Microsoft Intune Win32 Apps

Browse to a directory of Intune package definitions, load them, and the Workbench compares them against what’s currently deployed in your Intune tenant. The reconciliation grid shows each app with its Intune version, latest Evergreen version, status, and the action to take:

• Import new app - the definition isn’t in Intune yet
• Import new version - an update is available
• Fix in definition - there’s a definition issue (duplicate GUID, etc.)

Screenshot: Intune Win32 Apps import tab with reconciliation view.

The Update definitions action resolves the latest Evergreen version for each definition and updates App.json and detection rules in place - useful for keeping your definition files current before importing.

Nerdio Manager Shell Apps

The Nerdio Manager sub-tab works the same way: point it at your Shell App definitions directory, compare against your Nerdio Manager environment, and import new apps or new versions as needed.

Screenshot: Nerdio Manager Shell Apps import tab.

Microsoft 365 Apps

Browse to a folder containing Office Deployment Tool XML configuration files, load them, and the grid shows each configuration with its display name, products, and validation status. From here you can package and import directly to either Nerdio Manager or Intune.

Screenshot: Microsoft 365 Apps import tab.

Authentication

The Authentication sub-tab manages connections to Entra ID (for Intune), the Nerdio Manager API, and optionally Azure Storage for storing Shell App packages. Connection indicators on the other import sub-tabs show the current authentication state.

Screenshot: Authentication configuration sub-tab.

Install View

The Install tab is where you can run a local install of an application. Load the same directory of Intune package definitions, and it compares the defined versions against what’s currently installed on the machine. Each row shows the App, Publisher, Installed version, Latest version from Evergreen, Status, and the available Action.

This tab enables you to install apps locally for a quick install, test your application packages before uploading to Intune or Nerdio Manager, or it can provide a simple way to install set of a application into a gold image.

Screenshot: Install View showing version comparisons and install status.

Status values are straightforward - Installed (up to date), Installed (update needed), or Not installed. Use Find latest versions to query Evergreen for each defined application, then Install selected to install or update the selected rows.

If the Workbench isn’t running elevated, installers are likely to launch a UAC prompt for elevation. The typical workflow for this tab should run from an elevated Terminal instance.

Update View

The Update View runs Update-Evergreen from the GUI - it synchronises the local application definitions cache from the evergreen-apps repository. The output panel shows timestamped log messages for the cache check, download, hash validation, and sync progress.

Screenshot: Update View running Update-Evergreen.

Settings

The Settings tab includes - download output path, the Evergreen apps cache path (read-only), light/dark theme, visibility toggles for the Import and Install tabs, and app version cache management, the Microsoft Intune package output path, and a Logs section for opening or clearing the local log directory.

Screenshot: Settings View.

Log Panel

Every operation - version lookups, downloads, library updates, imports - writes timestamped messages to the Log Panel at the bottom of the window at Info, Warning, or Error level. You can copy the log to clipboard, save it to a file, or toggle the panel visibility. Log messages come from background runspaces in real time, so you can watch progress as it happens.

Wrap Up

With version 1.0.24, the Evergreen Workbench moves from pre-release experiment to stable, general-availability release (to be fair, the workbench might forever be experimental). It covers the full workflow from browsing app versions and managing an Evergreen library, through to installing applications from package definitions and importing Win32 apps and Shell Apps directly into Microsoft Intune and Nerdio Manager. Install it from the PowerShell Gallery:

Install-Module -Name EvergreenUI
Start-EvergreenWorkbench

Full documentation is available at eucpilots.com, and the source code and package definitions are on GitHub - star, fork, and contribute to the project:

• EUCPilots/evergreen-ui - Desktop Workbench source
• EUCPilots/evergreen-packages - package definitions for Install and Import workflows

Bonus: Web Workbench

The Web Workbench is also available - it’s a browser-based view of all Evergreen-tracked applications, accessible on any platform. If you just need a quick way to look up an application’s latest version or download URL - on any platform, without installing anything - view the Web Workbench. It also provides a dashboard, per-column filters, global search, CSV export, and per-app RSS feeds. It can be installed as a PWA for a standalone app experience.

The Web Workbench and the Desktop Workbench complement each other - the Web Workbench is great for quick lookups; the Desktop Workbench is where you go to actually act on that information.

Overview

Managing Azure Virtual Desktop (AVD) session hosts at scale requires a reliable way to target them with policies, compliance rules, and configuration profiles in Microsoft Intune - without manually maintaining static group membership. Entra ID dynamic device groups solve this: membership is evaluated automatically based on device attributes, so session hosts are added or removed as they are provisioned or decommissioned.

For AVD, the most useful targeting attribute is device.devicePhysicalIds, which stores metadata that Azure writes onto each enrolled device during provisioning. One of those metadata values is the Azure Resource ID of the resource group the VM lives in. By building a membership rule that matches on that value, you get a group that precisely tracks every session host in a given host pool resource group - with no manual intervention required.

How device.devicePhysicalIds works

When an Azure VM joins Entra ID (either natively or via hybrid join), the Azure platform writes a set of physical ID tags onto the device object. These tags are queryable in dynamic group membership rules using the -any operator.

The tag relevant to AVD is [AzureResourceId], which takes the form:

[AzureResourceId]:/subscriptions/{subscriptionId}/resourceGroups/{resourceGroupName}

This tag is written for every Azure VM that is enrolled into Entra ID, making it reliable for targeting AVD session hosts regardless of the VM SKU or image used.

The Entra ID dynamic membership rule syntax for matching this tag is:

device.devicePhysicalIds -any (_ -contains "[AzureResourceId]:/subscriptions/{subscriptionId}/resourceGroups/{resourceGroupName}")

To target session hosts across multiple host pool resource groups within the same group, combine clauses with or:

(device.devicePhysicalIds -any (_ -contains "[AzureResourceId]:/subscriptions/{subscriptionId}/resourceGroups/{resourceGroup1}")) or (device.devicePhysicalIds -any (_ -contains "[AzureResourceId]:/subscriptions/{subscriptionId}/resourceGroups/{resourceGroup2}"))

Prerequisites

Before creating a dynamic group, confirm the following:

• Session hosts are Entra joined or hybrid joined. The [AzureResourceId] tag is only written for VMs enrolled in Entra ID. Workgroup VMs or VMs managed purely via Active Directory domain join without Entra hybrid join will not appear.
• You have the Subscription ID and resource group names. Both are required for the rule. The subscription ID is a GUID visible in the Azure portal under Subscriptions, or via the Azure CLI with az account show --query id.
• Intune enrollment is active. The device must be enrolled in Intune for the device object to exist and for policies to be applied to assignments using the group as a target.

Rule builder

Use the tool below to generate the membership rule for your environment. Enter your Azure subscription ID and the name of each resource group that contains AVD session hosts. The rule updates as you type and can be copied directly into the Entra ID portal.

Enter a Subscription ID and at least one Resource Group name to generate the rule.

Creating the group in Entra ID

Once you have the generated rule, create the dynamic device group:

1. Open the Microsoft Entra admin center and navigate to Groups → All groups → New group.
2. Set Group type to Security and Membership type to Dynamic Device.
3. Enter a Group name - for example, devicegroup-avd-sessionhosts-prod.
4. Click Add dynamic query.
5. Switch to the Advanced rule editor and paste the generated rule.
6. Click Validate Rules to test against existing devices before saving.
7. Click Save, then Create.

Membership is evaluated by Entra ID within a few minutes of creation and then kept up to date continuously. New session hosts provisioned into the matched resource groups will be added automatically once they enrol in Intune.

Assigning policies and profiles

With the dynamic group in place, assign Intune configuration profiles and compliance policies to it as you would any other group:

• Device configuration profiles - apply Windows settings, certificate delivery, endpoint protection policies, etc., scoped to AVD session hosts.
• Compliance policies - evaluate session hosts against your organisational standards; non-compliant devices can be flagged or blocked via Conditional Access.
• App assignments - push required or available apps to session hosts. For multi-session hosts shared across users, use device-targeted assignments rather than user-targeted ones.
• Windows Update for Business rings - control servicing cadence per host pool by scoping update rings to individual dynamic groups.

Considerations

AVD Hybrid. This has not yet been tested against virtual machines deployed into an AVD Hybrid environment; however, given that these VMs are registered into a resource group via Azure Arc, this approach should work, in theory.

Subscription scope. Each rule targets a single subscription. If your AVD environment spans multiple subscriptions, create one dynamic group per subscription (or per set of resource groups within a subscription) and nest them under a parent security group where Intune supports group nesting for assignment.

Rule complexity limits. Entra ID enforces a maximum rule length of 3,072 characters. A rule covering many resource groups will grow quickly; split into multiple groups if you approach the limit.

Sync latency. Dynamic membership evaluation is near-real-time for most changes but can take up to 24 hours in large tenants. Newly provisioned session hosts may not appear in the group immediately - factor this into provisioning workflows that depend on policy application at first login.

Hybrid join vs. Entra join. Both join types result in the [AzureResourceId] tag being written, so the rule works for both. However, for hybrid-joined devices there is an additional propagation step through Entra Connect Sync, which adds latency.

Personal vs. pooled host pools. The resource group–based rule does not distinguish between personal and pooled configurations - it matches all VMs in the resource group. If you need to separate policy targeting between personal and pooled hosts, place them in separate resource groups and use separate dynamic groups.

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/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/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.