Well ..I already had this typed out for a stutus report for my boss so I though I would post here and see if anyone is seeing anything similar.
These are just some notes I have jotted down while I have worked on this today. Hope they are meaningful for you. Ha. I already have a case open…just thought I’d reach out to the community.
Fujitsu scanners not being found Scandall Pro and Adobe Pro. Horizon sees that they are redirected via both scanner redirection and USB redirection. The Scanner is listed in the Device Manager of the VM.
Might scan one or two docs but fails shortly after with a bogus mini driver error.
This seems to have started occurring right after the App Volumes upgrade to 2.18.4 but not many reports of it since very few users are in the office and using their scanners. I remember flipping back to an image with the old 2.16 agent and the problem went away. Rolling back to 2.16 is not an option as best practice is to have both the APP Volumes Manager and Agent running the same version.
Found that by follow this boot sequence, scanning works:
- Ensure scanner is powered off
- Take a view session via the thin client
- Once logged on, power scanner on.
- Scan as much as you can stand
Well This worked for a while but now it is not. HR scanned several documents by following this procedure one week but this week, the sequence makes no difference. This was never going to be a solution.
Tested image with new 2.18.6 agent that was just released. Did not fix.
Recaptured ScandAll pro in App volumes 2.18. Did not fix
Installed and tested Scandall Pro on the master instead of an App Volume. This did not work at first but then I had an “aha” moment.
- Scanning works as desired if Scandall Pro is installed on the master and NO other app stacks are attached. Tested this at least 10 times.
- Scanning does not work if Scandall Pro is installed on the master and the user has App Stacks attached. Also tested this at least 10 times
To me..this screams that the App Volumes filter driver in the 2.18.4 version is causing this.
With this Knowledge, I believe I have proof that this is an App Volumes bug. On 8.25.2020 I created and SR with the VMware App volumes team. Explained what I found and demonstrated to VMware rep. Grabbed the App Volumes logs and Procmon logs and uploaded to the case. Waiting for logs to be examined by engineers now.
This is a very difficult issue to troubleshoot with users and myself being out of the office. It is rare to find a user with a scanner in the office and the scanners hybernate overnight which means when I VNC into a TC, the scanner cannot be redirected for testing.
For additional confirmation that the 2.18 agent cause this issue, I am going to downgrade the app volumes agent to 2.16 as a test to see if the issue still exists.
Release notes for 2.18.6 just came out. Many bugs addressed. See here: https://docs.vmware.com/en/VMware-App-Volumes/2.18.6/rn/VMware-App-Volumes-2186-Release-Notes.html
The Environment variable issue and memory leak issue are concerning.