After installing the November 2026 Windows Updates on your Omnissa Horizon gold images, you may notice during login an error message reporting “Connection Error (Manager FQDN): Unable to Contact App Volumes Manager.”
App Volumes Connection Error, Unable to contact App Volumes Manager
The Problem
This issue is caused because Omnissa App Volumes uses NTLM authentication for the agent contacting the App Volumes Managers, and changes were made to Ntlm authentication with the November 2026 Windows Updates.
Specifically reaching “Phase 1 (November 10, 2026): Windows client devices begin offering NTLM signing on all connections by default. Servers accept both signed and unsigned clients. Auditing events identify clients not using signing.”
New registry keys were enabled as part of this implementation of NTLM signing. Specifically the “ClientAllowUnsignedNtlm” key.
The Fix (Workaround)
To workaround this issue, we must use the new registry settings to modify Ntlm authentication settings. Please note, changing these settings modifies and/or adjusts your security settings. Do not perform these actions unless you are aware of what this does and how it may change your security posture.
To resolve in our environment we used the “ClientAllowUnsignedNtlm” and set it to “1” which sets the mode “Client does NOT offer SIGN. Use only for temporary compatibility”.
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.
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.
Minisforum DEG1 OCuLink eGPU Dock
On the other end of the OCuLink cable, I connect the Minisforum DEG1 eGPU dock. Below is a picture of the unit.
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 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).
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” to query the GPU status.
Running “nvidia-smi” 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.
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.
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:
After creating this folder, continue to shutdown your image, snapshot, and push to a Desktop Pool on Omnissa Horizon.
You’ll now notice:
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.
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:
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.
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!
This website uses cookies to improve your experience. We'll assume you're ok with this, but you can opt-out if you wish.
Do you accept the use of cookies and accept our privacy policy? AcceptRejectCookie and Privacy Policy
Privacy & Cookies Policy
Privacy Overview
This website uses cookies to improve your experience while you navigate through the website. Out of these cookies, the cookies that are categorized as necessary are stored on your browser as they are essential for the working of basic functionalities of the website. We also use third-party cookies that help us analyze and understand how you use this website. These cookies will be stored in your browser only with your consent. You also have the option to opt-out of these cookies. But opting out of some of these cookies may have an effect on your browsing experience.
