Jul 262026
 

Recently I connected an NVIDIA RTX4500 Blackwell Server Edition Datacenter GPU on the Minisforum MS-A2 mini computer (aka homelab server) running VMware vSphere and NVIDIA vGPU.

As a proof of concept, I wanted to share how I did this, what parts I used, and share my success running NVIDIA vGPU.

This PoC can be used to run VDI workloads (example Omnissa Horizon), and/or AI models.

Minisforum MS-A2

As an introduction, the Minisforum MS-A2 is a mini-computer that packs a punch. The ones I purchased have the following specs:

  • AMD Ryzen 9 9955HX Processor
  • 128GB of RAM
  • M.2/U.2 NVME Support (plenty of M.2 slots)
  • Dual 10Gbps SFP+ NIC (supports VMware vSphere)
  • Built-in PCIe x16 slot that supports bifurcation
  • Numerous other goodies that I’m not listing

These have performed well in my homelab, and run VMware vSphere reliably.

Note that my preference for the MS-A2 systems is because they are running the AMD processor which handles VMware ESX without modification or disablement of cores which is required on some Intel newer generation systems.

Installing VMware ESX was simple.

Minisforum MS-A2 running VMware ESX

In my systems, I installed a dual OCuLink PCIe adapter, and enabled bifurcation in the BIOS. This allows us to connect the MS-A2 to external devices using an OCuLink cable.

Dual OCuLink PCIe Adapter Card

The card installs nicely, see below for images of the card installed internally, and ports on the rear of the Minisforum MS-A2.

As you can see, it’s a nice clean install.

On the other end of the OCuLink cable, I connect the Minisforum DEG1 eGPU dock. Below is a picture of the unit.

Minisforum DEG1 OCuLink eGPU Dock

You can use an ATX Power supply to power both the DEG1 dock, along with your preferred GPU.

NVIDIA RTX 4500 Blackwell Server Edition Datacenter GPU

In this specific test, I decided to use the new NVIDIA RTX Pro 4500 Blackwell Server Edition Datacenter GPU. This card is built off the NVIDIA Blackwell GPU architecture, has 32GB of GDDR7 memory, consumes 165W, and has a PCIe 5 x16 interface.

Please note:

  • Due to OCuLink being used in this PoC, only 4 lanes will be supplied to the GPU using this configuration.
  • I used a 3D printed air baffle and fans I purchased on eBay to cool the car (as the card is passively cooled).

Installing the card was fairly easy:

Again, pretty clean and nice looking install.

Moving the DEG1 over to my MS-A2 in my homelab, in excitement I quickly connected it.

Minisforum MS-A2 with DEG1 OCuLink doc and NVIDIA RTX 4500 Blackwell Server Edition
Minisforum MS-A2 connected to DEG1 OCuLink Dock, with NVIDIA RTX 4500 Blackwell Datacenter GPU

After powering it on and waiting for VMware vSphere ESX to boot, I checked the Graphics Devices section in on the ESX host (I already had the latest NVIDIA vGPU 20.1 drivers in the ESX lifecycle image, so the drivers were present on the host).

VMware vSphere ESX Graphics Devices with NVIDIA RTX 4500 Blackwell GPU

Confirming that the card was detected and host vGPU drivers loaded, I proceeded to attach a vGPU profile (4Q) to a test VM, disable the vGPU framerate limiter, and powered on the VM. I then enabled SSH, connected to the host via SSH, and ran “nvidia-smi -q” to query the GPU status.

Running “nvidia-smi -q” using the RTX 4500 Blackwell SE GPU

Testing

I went ahead and used Omnissa Horizon to connect to the VDI VM using Blast. This resulted in a high quality hardware encoded/decoded session using NVENC AV1 as the automatically negotiated encoder.

While running through some normal applications, the temperature fluctuated on the card between 33-38C. Note that the fans I’m using are 12V fans, however they were underpowered during this testing and running at 5V.

Loading up Heaven Benchmark, running a test at 1080p using high setting, I was able to achieve 699fps continuously. During this period, the card showed “GPU-Util” in the 90 percentile, and temperatures raised to 80-83C.

Overall, for a quick proof of concept, this was a great test and I’m super happy all the components worked out together.

Feb 222026
 
Missing Ghost Icons with Omnissa DEM and Windows 11 AppX Packages

When deploying Windows 11 with Omnissa Dynamic Environment Manager (Omnissa DEM) you may experience blank, missing, or ghost icons when pinning AppX packages to the Taskbar, such as Calculator, the Snip tool, or other AppX packages.

AppX packages are a newer style software package commonly used with Windows 8, Windows 10, and Windows 11. In newer feature releases of Windows 11, we are seeing these AppX packages replacing common applications such as Calculator, Paint, the Snip tool, and Windows Terminal from the traditional command prompt.

These new AppX packages are deployed to the Windows install as AppX Provisioned Packages, which then get provisioned to the user space when the user profile is created.

The Problem

When using Omnissa Dynamic Environment Manager (formerly known as VMware Dynamic Environment Manager), with non-persistent VDI, every time a user logs in they get a new profile, which DEM then imports their user settings which can include AppData, files, registry, and other settings that create the appearance of profile persistence.

What Omnissa DEM is actually doing is called “User Settings Persistence”.

Because a new profile is created at each log in, the AppX packages deployed in to userspace do not persist, and must be provisioned on every login. Because of this process, if a user has AppX packages pinned to their taskbar, the icon is not available, therefore resulting in a blank icon.

Missing ghost icons with AppX packages on Windows 11 with Omnissa DEM

This is not ideal.

The Fix

To resolve this issue, when prepping your gold image and snapshot for deployment, after you complete “Finalization” with the OSOT tool, you’ll need to create a folder in the default user profile.

Please Note: You must have all the appropriate DEM configuration files deployed for Windows 11 (including Start Menu, Explorer, Taskbar, etc).

To resolve this issue, post-finalization, create the “WindowsApps” folder inside of “C:\Users\Default\AppData\Local\Microsoft\” as seen below:

Screenshot adding "WindowsApps" folder to the Default User AppData for AppX icon fix

After creating this folder, continue to shutdown your image, snapshot, and push to a Desktop Pool on Omnissa Horizon.

You’ll now notice:

  1. On user logins, all AppX packages will be immediately visible in the start menu, whereas previously there was a 1-2 minute delay where they would need to be fully provisioned before appearing. You may now notice that ~30 seconds after login, a quick flash of a progress bar will appear, this is Windows provisioning these packages.
  2. Your pinned AppX package shortcuts on your taskbar will now appear properly, with their applicable icon on subsequent future logins.

I’m speculating that the OSOT tool removes this folder, which delays/removes the linking of AppX packages in new profiles. The steps above corrects this.

A big thank you to “HER_MUN” and Sunil Nair on the Omnissa Community Forums, who helped figure this out:

A big thanks also goes to Daniel Keer for spending 4 hours working through this with me!

Oct 032025
 
What’s the deal with TPMs, vTPMs, vSphere NKP, and VDI?

In this video, I sit down and chat with Joe Cooper to find out “What’s the deal with TPMs, vTPMs, vSphere NKP, and VDI?”

We’ll be talking about everything from Physical TPMs, to Virtual TPM (vTPM), VMware vSphere Native Key Provider (NKP), and specialized workloads such as Virtual Desktop Infrastructure (VDI).

A big thank you to Joe Cooper for co-producing and joining me on this video.

Guest: Joe Cooper (Omnissa)

In this video, we’ll cover:

  • What is a TPM, and what is a vTPM?
  • How does VMware vSphere and the Native Key Provider (NKP) play in to this?
  • Do TPM and vTPMs have any correlation on their own, or with NKP?
  • How are TPMs handled with environments like VDI?

References:

Stephen Wagner: How to create a VDI Windows 11 Gold Image with proper vTPM for Omnissa Horizon

Broadcom: Deploy Windows 11 in virtual machine using bootable Windows PE (WinPE) Image

Omnissa: Manually creating optimized Windows images for Horizon VMs

Stephen Wagner: Create and Deploy Virtual Machines with vTPM and NKP on VMware vsphere

THEDXT: VMware vCenter Native Key Provider

Sep 292025
 
How to create a VDI Windows 11 Gold Image with proper vTPM for Omnissa Horizon

In this video, I’ll show you how to properly create a Windows 11 gold image, for use with Omnissa Horizon VDI (both persistent VM template full-clones, and non-persistent Instant Clones).

We’ll be using the manual process to create the VDI Golden Image.

In this video, I’ll show you how to:

  • Use Windows ADK and WinPE add-on to create a WinPE ISO to pre-boot the Windows 11 Installer
  • Use the WinPE ISO to pre-boot and install Windows 11, without a vTPM
  • Prepare the Windows 11 image for deployment
    • Install Omnissa Horizon agent
    • Install Microsoft 365 using the ODT (Office Deployment Toolkit)
  • Use the Omnissa Operating System Optimization Tool (OSOT)
    • Optimize the image using OSOT
    • Generalize the image using OSOT
    • Finalize the image using OSOT

Note on VDI (Virtual Desktop Infrastrucutre), TPM and vTPM devices

When deploying Windows 11 in VDI environments there are special considerations due to Windows 11 TPM requirements. Windows 11 Golden images should not have a vTPM, nor should they ever have a vTPM attached and then removed. Attaching and removing a vTPM or TPM from Windows 11 is considered data loss, and can cause issues with the image.

If you are deploying persistent full-clones, after the cloning process you can add a vTPM to the persistent VM.

If you are deploying non-persistent Instant Clones, the desktop pool in Horizon should be configured to add a vTPM to Instant Clones on provisioning.

References

A big thank you goes out to Graeme Gordon and Hilko Lantinga for their documentation and techzone articles providing this information for Partners, Customers, and Community!

Refernced Links and Documents:

Sep 242025
 
Update Omnissa Unified Access Gateway Network Configuration via SSH or Console

So you’re in a situation where you need to update the Omnissa UAG IP Configuration via Shell or Console.

Your Omnissa UAG (Unified Access Gateway) network configuration usually takes place on deployment, or can be modified via the Web Admin interface running on port 9443.

In some scenarios you may lose access, or have to change the networking configuration when you don’t have access to the web administration GUI. This could be because of firewall rules, network changes, or troubleshooting.

PLEASE NOTE: Normally it is considered best practice to deploy new UAGs if an IP change is required. UAG deployment should be automated (using the powershell scripts from Omnissa). This post is for informational purposes only for special situations, troubleshooting, or in scenarios where deploying a new UAG, isn’t possible.

Updating your UAG IP Network Configuration

If you need to update or change your network configuration on your UAG, via console or SSH, you can run the following command:

/opt/omnissa/root/scripts/scripts/configureNetwork.sh

After executing this command, you’ll be presented with these options:

You can note numerous options for network configuration of the UAG appliance.

You can then select option “1” to view your configuration, or option “6” to configure your IP, subnet, gateway, etc.