Relevant mostly to OS X admins
As a mac-based organization, there are always times you have to deal with the occasional non-mac software. My employer’s daily use is our accounting vendor’s software, as they’ve not yet transitioned to delivering all the services via web browser. To provide this to Mac clients, we use XenApp. For those who haven’t yet met XA, it involves installing applications on a Windows server, and “publishing” them. These published apps are accessible from multiple endpoints via Citrix Receiver- laptops, phones, tablets, ect. It’s much like VDI, but without the desktops, just the app.
Last week, I was informed that our research department would have the task of analyzing data a client had obtained from NPD. Of course, there is no native MacOS (app or web) to work with their data, it’s provided in their proprietary format, and accessed by their Win2K era viewer app. Reluctant to bring up 2 new local VMs for users when the real task is to access this data, I started installing it on my XenApp server.
All went normally to publish the NPD Viewer app, with a slight departure from the normal procedure because the end goal isn’t specifically the app, but the data it provides, which must be accessed through the app. That’s handled by a Command line formatted as <“path to .exe” path to data file>. For my admin user, it all worked perfectly.
However, when the user accounts tried, the app would launch, start a gray box where the image for the splash screen would go (but never did), and halt:
I tried opening up permissions on 2 paths that NPD writes to- C:\Program Files\NPD and C:\Program Files (x86)\NPD, with no change in results. Expecting there was still a permission error somewhere, I grabbed a copy of Sysinternals Process Monitor, set up a quick filter of “company” “contains” “NPD”, started capturing, and launched the published app from an account I knew would fail.
In just a few seconds, I was showing 4,636 events of a 586,538 captured- Process Monitor will grab an overwhelming amount of data. Not really knowing what I was seeking, I started scanning for anything that looked suspicious, learning much about what is and isn’t suspicious in such a capture along the way. I eventually found my way to a couple of entries with a result of ACCESS DENIED.
Reading the whole line, I see that the powrview.exe process, launched by User2 is trying to read C:\Users\<admin account that installed the software>\Windows\cPopMenu6.ocx. App launched by User2 has no business trying to access that path or file, and is hitting a dead stop when default permissions appropriately say it can’t get there. By granting read access to that folder for the few users that can access this published app, I was able to get the needed results. It’s not pretty, but when an app does ugly things, the fixes sometimes are too.