EUC-QUICLI: Legacy Finance App Conflict in a Non-Persistent Horizon Pool

Legacy Finance App Conflict in a Non-Persistent Horizon Pool

A 1,200-seat Horizon deployment uses instant clones and a single Windows 10 21H2 golden image refreshed monthly. Applications are delivered as App Volumes packages. The finance team of 280 users needs a legacy 32-bit reporting tool that requires a specific version of msflxgrd.ocx and the VB6 runtime. A second packaged tax application installs a newer version of the same OCX. When both packages are attached to the same session, the reporting tool fails at launch with run-time error 339. Roughly 12% of finance users report the failure; those users belong to nested AD groups that inherit both entitlements. Manually re-registering the older OCX fixes the session until the next reboot. Forty power users have writable volumes; the rest do not. There are no persistent desktops, the login SLA is 20 minutes, and a two-week quarter-end change freeze starts in six days. The business will not accept a second image for the whole finance team.

1. Recommend an application delivery design that resolves the OCX conflict for all 280 finance users without persistent desktops. Justify the trade-offs of at least two options.

Read the worked answer

Why the conflict happens. The OCX registers a COM class under HKCR. On a non-persistent desktop the last package to mount wins, and mount order is not deterministic for users who inherit both packages through nested groups. Re-registering the old OCX temporarily fixes the user, which confirms that registration state, not the application binary, is the deciding factor. Writable volumes would preserve a per-user fix, but they do not prevent the conflict at first logon, they add 280 persistent objects to manage, and they weaken the non-persistent model.

Recommended design. Keep the tax application in its existing App Volumes package on the Windows 10 image. Publish the legacy reporting tool from a dedicated RDSH farm of two hosts, sized for 280 light users, where only the older OCX and VB6 runtime are registered. Entitle finance users to the published app through Horizon. The two Windows contexts are isolated, so the version conflict disappears and the desktop image stays unchanged.

Alternatives and trade-offs. Splitting finance into two desktop pools with different package sets also works, but it doubles image and patch testing and still fails the roughly 34 users who need both apps in one session. Application isolation or sequencing for the legacy tool is viable if the vendor supports it, but it adds a packaging tool and a retest cycle. Baking one OCX into the base image does not help because the two apps require different versions.

Validation. Pilot with 25 users drawn from the nested groups. Test launch, printing, file access, and logon time for five days, and leave the existing packages untouched so rollback is simply removing the new entitlement.

2. Before changing the design, what evidence would you collect to prove the OCX registration conflict and rule out a packaging or permission fault?

Read the worked answer

Build a test instant clone from the current image and attach both packages to a test account that matches the nested-group membership. Reproduce the error, then capture evidence in this order:

App Volumes Manager: attachment order and timestamps for the test user, plus any failed or delayed package attachments. If the reporting package mounts after the tax package, the newer OCX wins.
Registry and file state: inspect HKCR\CLSID for the OCX class and its InprocServer32 path; compare the file version in System32 and SysWOW64 before and after re-registration. A 32-bit app on 64-bit Windows can load from either location, so check both.
Package contents: mount each VHD read-only and compare the OCX file version and registration entries. Confirm the tax package actually ships the newer OCX rather than relying on a shared runtime.
ProcMon: filter on msflxgrd.ocx during launch to see which path is loaded and whether access is denied. A permission fault would produce a different error and would not be fixed by re-registration.
Group membership: export effective AD group membership for affected and unaffected users to confirm the correlation with nested groups.

If the test clone reproduces the failure and re-registering the older OCX fixes it, the conflict is proven. If not, investigate package attachment failures and file permissions before redesigning delivery.

3. The change freeze starts in six days. How do you sequence the change, and what rollback do you require before the CAB approves it?

Read the worked answer

Treat this as an additive, reversible change rather than an image change. Sequence it as follows:

Days 1-2: build and patch the two RDSH hosts, install only the legacy tool and VB6 runtime, and confirm the older OCX is the only registered version. Do not touch the golden image or existing App Volumes packages.
Days 3-4: pilot with 25 finance users, including at least ten from the nested groups. Measure logon time against the 20-minute SLA and test the reporting tool's output, printing, and file shares.
Day 5: submit the CAB request with pilot evidence and a rollback that removes the RDSH entitlement from the pilot group. Because the change is additive, rollback does not require a reboot of production desktops or a package rollback.
Day 6: if approved, extend the entitlement to the remaining finance users in two waves, keeping the pilot group as a canary.

If the pilot does not pass before the freeze, do not force the change into production. Instead, document the manual re-registration workaround for the service desk, with a scripted fix and a known-error record, and schedule the full rollout after quarter-end. The CAB should see the residual risk either way: users who need both applications remain intermittent until the design changes.