Philips SpeechMike Pro Issue Connecting on Initial Session Launch

[epa80]

Environmental info: 

• Horizon 7.13 Infrastructure
• Windows 10 20H2 guest image
• Wyse ThinOS thin clients
• Philips SpeechMike Pro III microphones

We have the SpeechMike in our environment and, to our knowledge, it's been working fine until this issue was reported. Some steps we had to take to get it to work properly:

1. Connect directly to our instant clone gold image with the Horizon direct connect agent from a Wyse terminal
2. Plug the mic into all ports both at session connect as well as plugged in hot.
3. Pass the VID/PID in from our Wyse Management Suite to redirect the mic (USB redirection not RTAV).
4. Implemented this KB along the way: https://kb.vmware.com/s/article/74931?lang=en_US

Note that for point 4 that issue shouldn't even be there anymore, our logins are much quicker than 60 seconds, but we've left that in anyway.

Again as far as we were aware everything was working. About 3 weeks ago, with no known changes coinciding, we started getting calls about it. After investigating, we found that if a user launched a new VDI session from a thin client, and the mic was already plugged in, 9 times out of 10 the session had an issue with the mic. The mic would appear in the VDI session, but our dictation app as well as Windows itself would behave weird when trying to interact with the mic. The dictation app froze and Windows couldn't adjust the volume out of the mic.

We found that if we rebooted the terminal and connected back to that same session, this time the mic/apps worked fine. More than that, we found that if a session was already connected, and we plugged in the mic hot, it worked every time. The key to reproducing it seemed to be starting a new session with the mic ALREADY being plugged in on the endpoint.

At first we thought perhaps it was 20H2 related, but, I got the issue to happen even when I reverted to 1809. What confuses me there is the users didn't call until lately, after we flipped to 20H2, so, I have no answer there. We're investigating if it's ONLY happening from one building/network (latency perhaps?), but, we're still in the process of getting a test device all setup.

We have a ticket with VMware and they're currently reviewing the logs. We also are opening a ticket today with Dell Wyse to get anything from their side, but, felt it would be good to post here as well to see if anyone else has seen it.

For us these SpeechMikes have been murder to get consistently working. Hardest peripheral we've had to deal with.

Any help is greatly appreciated.

[epa80]

Just to update this some, in case anyone else sees this bizarre issue.

Strangely enough, we found that with a Mic already connected, and launching a new session, Microsoft Edge launching (as auto update runs in the background), caused the Mic break. We're on version 94 on our gold image, and we didn't really have any policies in place yet to control Edge. So when a user logs in right now, Edge probably sees 96 is out and updates. I don't think it's 94/96 that is the cause though, I think it's just flat out running Edge. We put in a policy to disable updating, and now the issue doesn't happen. We also hide Edge so a user can't launch it, but if I navigate to it hidden and launch it, the mic will break.

Even stranger, this trigger does not happen if the mic is plugged in hot after a session is already established.

So in a nutshell, our current workaround is leave 94 on the gold, hide the shortcut, and deploy a GPO that disables Edge updating as well as disable IE's redirect to Edge, and the issue is mitigated. For now. Still trying to find the permanent fix.

Confusing as hell.