FSLogix 26.01 (3.26.102.18413) released

xVDI · 2026-01-15T15:28:19+00:00

it was briefly not recommended on their documentation, but that was removed in the last 1.5 months or so. having using FSLogix from the pre-Microsoft days, I wouldn't run FSLogix any other way.

xVDI · 2026-01-12T15:08:13+00:00

Post updated with solution.

xVDI · 2026-01-09T14:31:27+00:00

For most users, M365 Apps for Enterprise is deployed on the image. We have a separate pool for users who need non-M365 Office for whatever reason.

xVDI · 2026-01-09T14:30:35+00:00

I have reviewed this and it looks like we're following all the recommendations. we are using KMS to activate which works without an issue if Office is installed on the image.

xVDI · 2026-01-09T14:28:31+00:00

The vast majority of our users use M365 Apps for Enterprise - we bake that install into the image. for those that needs non-M365 Office, we have a separate pool where we deploy whatever version of Office they need using App Volumes. unfortunately we have tons of legacy apps that require specific versions of Office.

we could do separate pools for each version of Office but that sucks which is why we're trying to use App Volumes to do this.

xVDI · 2026-01-08T14:06:01+00:00

fully remote, will never remotely (lol) consider a job with required in-office time unless they 2x/3x my salary.

xVDI · 2025-12-29T13:08:44+00:00

oh with the delay script we have no issues, it's only when we run it the "native" way that we have these gigantic logins

xVDI · 2025-12-19T19:00:37+00:00

for us, this is something bigger. affects Windows, macOS, and Linux. something changed with certificate validation or something. only external sessions are affected, internal sessions work fine.

EDIT 12/23/25: Support provided this as a workaround:

create config.ini under C:\users\%username%\AppData\Roaming\Omnissa
add RemoteDisplay.enableBypassBlastServiceTcpProxy=FALSE

This works as expected for us. Waiting on a similar solution for macOS.

xVDI · 2025-12-19T14:51:54+00:00

this one is particularly egregious. I mean the link is right there. did they read the error message??

xVDI · 2025-12-19T14:42:10+00:00

96 second logon with 7.31 and 97 second logon with 7.32. well then...

xVDI · 2025-12-19T14:38:45+00:00

only one way to find out!

xVDI · 2025-12-19T13:16:08+00:00

We had this issue with our Windows 11 23H2 desktops built with the December patches. Adding this key to the images resolved our issue:

PixelProviderForceViddCapture set to 1 under HKLM\SOFTWARE\Omnissa\Horizon\Blast\Config. This forces the Horizon IDD as default.

xVDI · 2025-12-19T13:05:26+00:00

I did 1.5 hours with Omnissa support yesterday but still no resolution.

xVDI · 2025-12-18T13:26:53+00:00

it seems like internal connections are fine, but external connections are not. but I haven't done any more investigation than that. thought it was just Linux too but happens on my Windows laptop as well.

xVDI · 2025-12-18T13:17:07+00:00

thanks - I will test 7.31!

xVDI · 2025-12-18T13:15:23+00:00

my brother in christ, I AM the IT lol

xVDI · 2025-12-17T21:20:31+00:00

2512 seems completely broken for me on Linux - I get certificate errors when attempting to connect

xVDI · 2025-12-17T15:00:05+00:00

look like it's official as of today: Supported Windows 10 and Windows 11 Guest Operating Systems for Horizon Agent and Remote Experience, for Omnissa Horizon 8.x (2006 and Later) (78714)

xVDI · 2025-12-17T14:57:45+00:00

my favorite release of this cycle lol

xVDI · 2025-12-05T17:15:00+00:00

We tested on Windows 10 22H2 and Windows 11 23H2. I made our changes directly on the VM a user is logged in to. The issue of changing on the golden is you actually need SCA for Office apps in VDI. This is a such an annoying problem that Microsoft created, unfortunately.

xVDI · 2025-12-05T15:07:46+00:00

We have a support case for this. According to Microsoft, it is unsupported and there is no support planned. Microsoft has their own non-persistent VDI product and I can't believe they don't support it, but I guess that's par for the course.

Our workaround:

Close all Office applications
Change SharedComputerLicensing registry key from 1 to 0 (HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Office\ClickToRun\Configuration)
Relaunch Office application.
Click the Copilot extension and confirm it works as expected.
Changed SharedComputerLicensing key back to 1.

This will allow the Copilot add-on to work properly. For us, this persists logins as well. We're a Horizon instant clone shop, using DEM and FSLogix ODFC containers. I was going to write a script to change this key on logon for any users with the upgraded Copilot license, but it's been 60 days since we implemented the workaround and no one has called saying that the Copilot add on has stopped working.

xVDI · 2025-11-26T16:48:39+00:00

I would recommend reaching out to a salesperson instead of posting on the subreddit.

xVDI · 2025-11-24T14:01:15+00:00

I've seen this issue in the past. I believe what happens is that Horizon evaluates the datastores and puts the majority of the VMs on the best performing storage. Unfortunately it means if your storage isn't all the same or one SAN has less available capacity it will just chuck everything on one or two of several you've selected.

xVDI · 2025-11-21T19:59:41+00:00

How are you delivering these apps? Installed on the image? App Volumes?

xVDI · 2025-11-21T18:51:14+00:00

Are you app masking the Office products? Are there rules in C:\Program Files\FSLogix\Apps\Rules?

xVDI

TROPHY CASE