Does anyone know of a way to get the “Devices” button to appear in the Linux Receiver’s connection bar? I need to be able to both allow headsets to use audio redirection (Optimized) as well as USB redirection (Nuance PowerMic-II, Generic) in the same profile. It seems as though it’s either one or the other in the IGEL config, though. Here’s a shot of the connection bar that I’m referring to: i.imgur.com/qeB4yXN.jpg
Hi Nick, I didn‘t tried on actual versions, bzt this article may help:
Just to say: activating USB Redirection should stay in a profile. Can you send us a screenshot of your redirection profile?
With the Citrix policy enabled, the devices act like Generic USB redirected microphones. If I disable the Citrix policy, they’re basically optimized USB devices.
USB redirection “removes” it from the endpoint and attaches it directly to the session. Normally a virtual channel is used – so the USB device is shown locally at the endpoint and as “Citrix Audio device” for example in the session.
I would also test only adding the product and vendor ID on one site – in an UMS profile OR in the Citrix policy.
Removing the USB redirection settings in the IGEL policy and disabling the Citrix policy do allow the mics to redirect (optimized), but that’s only going to work for our headsets. Our PowerMic must be generic redirection for full functionality. I know that I can simply create separate IGEL policies for each config, but our providers are going to use any available device, and we can’t limit them to just certain ones based on their microphone type. That’s why that ‘Devices’ button is so important to our workflow.
this is how you enforce the Desktop Viewer toolbar
also ensure to turn off all other toolbar settings
I’ve got the Desktop Viewer toolbar enabled (see the screenshot in my initial post), it’s just missing the Devices button. Ultimately, I just need a way to have headsets mapped as Optimized, and the PowerMic mapped as Generic. I’m still testing every combination I can come up with, with no success as of yet.
I‘m pretty sure that what you are searching, isn‘t available on actual Linux receiver. But let me check on a plain Ubuntu, if I find it there, I will come back to you asap!
I had that with a customer but cannot remember how we got it – assuming it was a Citrix setting, but will ask the customer.
I’d certainly appreciate it, thank you!
@member Even if the Devices tab isn’t available in Linux Receiver (it’s not for Workspace App, per IGEL or Citrix’s documentation), there has to be a combination of policies that allows me to redirect certain devices the way I need to.
That’s why the product and vendor ID are in place (normally) ☺️
@member Any chance you were able find anything out from your customer? Even though Generic mode for all devices seems to work in Dragon, the fact that we have to disable client audio redirection via Citrix policy to get this to work now prevents everyone from using headphones, etc.
Hi didn’t come back to me yet, but it’s vacation time.
So you disabled it for all devices? Using product/vendor ID wasn’t enough?
I’ve tried it all – disabling for all devices, enabling for all devices, etc. Disabling mic and audio redirection via Citrix Policy maps our mics as Generic, which seems to work fine. However, I just found out that other users need sound from their session for training, and they don’t use any USB devices. So if they launch a Citrix Desktop on one of these IGEL thin clients, they have no sound due to audio redirection being disabled via policy. All users access the same devices, so I can’t separate them, nor would I want to.
@member I may get you wrong, but let me bring up a few ideas since I‘m not sure to understand the initial issue.
Igel offers a lot of virtual channels (which I understand as term „optimized“), they are available under the section: Sessions,Citrix,Citrix Global,Mapping,Device Support. There, Nuance is a.e. channel is available for activation.
That implifies that the device shouldn‘t be redirected through USB Redirection but stays locally, and mapped to session.
If that (or similar channels) isn‘t the solution, I would recommend to have a look on shared workplace (kb.igel.com/endpointmgmt-6.01/en/shared-workplace-10323974.html) where you put profiles on the endpoint (as usual) but also on Active Directory user level.
I’m not sure that SWP will work in this scenario, though, since the targeted users would need access to both workflows – using a microphone for Dragon, and using audio redirection for websites, audio playback, etc.
The only thing that I can think of right now would possibly be a script that runs in the background full-time, and if it detects a new USB device that matches the VID and PID of our microphones, it changes the _ClientAudio_ setting in All_Regions.ini to _False_ so that the microphone maps correctly. If no mic is plugged in, then audio redirection would work (assuming that I change my current Citrix policy. I have no idea if this is possible, though.
Sure, a simple rule (like udev) would work, I guess! Dumb question maybe, but how did you solved this issue on fat clients or other endpoint/thinclient vendors?
Here is a udev scrript I wrote for another topic, it might help you a bit:
We don’t need to disable audio/mic redirection on thick clients, so there was never a problem to begin with. I’m honestly not even sure why we have to do it with thin clients.
Sure! Second try!
Thanks. I got it once I expanded the thread. One issue I’m seeing with my plan is that, while I think I have a working script (mostly), in order to make changes to All_Regions.ini, Receiver would have to be reloaded I think. I can’t just have the script running, have a doctor walk up and plug in a mic, and then have the script detect this and change the INI file. Receiver wouldn’t acknowledge that change.
Okay, so I think I’m closer. With the “Client audio redirection” Citrix policy enabled, sound works just fine. In fact, if I launch a Citrix Desktop, let it load, and THEN plug in a microphone, the microphone maps just fine. However, if I start the Citrix Desktop session after I’ve already plugged in the microphone into the UD3, the device shows as Disabled the desktop. I know that audio redirection is supposed to be disabled, but if there’s a way to change this behavior, it would solve our problem.
Well, we could think about a script, that disables the microphone during bootup, waits until a session starts, and then enables the mic.
I’m all ears on that. I’ve got the PIDs and VIDs of the devices that we use.
Are you a bit familiar with linux? If you can issue the commands by hand to get it working, I could help on the script.
Not really, no. I can Google with the best of them, though. To test stuff manually, I’ve simply been SSHing into the device and running commands there.
You could start your tests here:
and / or here:
It looks like doing this requires a reboot to become effective? I don’t think it’d work, since all of this would be happening in realtime
I’m also seeing random results. I’ve logged off and on 5 times now with the mics plugged in, and half of those times, at least one mic actually mapped and show up as enabled. The other times they’re disabled. Makes no damn sense.
Hi Nick – were you able to figure this out? We are trying to get this to work. What set of policy did you configure in IGel and XD? PID and VID, also are you DMO with a single or double hop? Thanks!
Which part? I went through a lot of different things in the thread. Citrix confirmed that there’s no Connection Bar in the Linux Receiver, but I did submit a feature request to have it added. Using a script to disable the microphone was a bust due to the reboot requirement, so for us it’s going to be a workflow thing – users must make sure that they wait until after their Citrix desktop has loaded before plugging in the microphone/headset.
As far as policies go, here are some screenshots of our IGEL and Citrix policies that apply to this for Dragon Medical 360. We’re looking at DMO soon, but not quite there yet. For us, this is a double-hop scenario for most users. We have Dragon installed on the XenDesktop image, and our users are dictating into Epic, which is published in XenApp. We do have other users who dictate into the Office apps in the XenDesktop image.
At the end of the day, all of the mics and headsets will have to connect using Generic USB Redirection. That’s disappointing, but I see no way around it at this point.
Thanks Nick- yeah the audio piece is the one we are testing. With the above configuration were the advance buttons working like the recording and rewind/forward working? Also did you test it the native iGel channels for Nuance/Phillips I am wondering if that by itself works?
I haven’t even gotten as far as testing advance buttons, to be honest. I got sidetracked with other work and haven’t had a chance to revisit it. I did test with the native IGEL channel, but I want to say that support even told me that it doesn’t work. Didn’t do anything in my own testing, that’s for sure.
Continue reading and comment on the thread ‘How to add the “Devices” button to appear in the Linux Receiver’s connection bar? ‘. Not a member? Join Here!
Learn more, search the IGEL Knowledge Base
Ask a question or comment on the above message thread?Join or log in to the IGEL Community to ask us anything and meet other IGEL customers, partners, and EUC enthusiasts.
Submit a question, or Join Today!
Popular Message Threads
- Receiving error: “Citrix Receiver cannot create a secure connection in this browser” when launching a secure connection from Firefox on IGEL OS
- How to Install IGEL OS via a Bootable USB Drive
- Where to delete the certificates that cause ‘invalid certificate’ when trying to import an IGEL into UMS?
- How to change the default IGEL UMS admin password?
- IGEL UD3 (LX50) randomly get this error with Citrix: The X Request 130.1 caused error :”10: BadAccess ( attempt to access private resource denied) any ideas?
- IGEL UMS Universal Update Error: “could not resolve host name”
- Citrix connection via Netscaler Error: “AM_ERROR_AUTH_NETWORK_ERROR” on IGEL OS