Jump to content
Welcome to our new Citrix community!
  • 0

VDA 7.12 Volume Control


Thomas McDonaugh

Question

The volume control in the published desktop das not work properly.

 

We have VDA 7.12 installed on Windows Server 2016 as our workers and roaming profiles on a netshare.

Once in Session if you left click on the speaker icon in the system tray nothing happens. This should bring up a volume bar, as it does in a plain win 10 installation. Right click brings up the context menu and you can change the volume through the mixer.

We would like to have the volume control function the  users are used to.

Is this a known issue? Is there a workaround? Or is this part of the problem with roaming the windows 10 start menu?

I have found nothing specific to

 

Thank you in advance,

 

Link to comment

22 answers to this question

Recommended Posts

  • 1

Hi Thomas

 

We have seen this recently and there is a case open with the developers.

 

There are permissions missing on a registry key that holds the Audio device information for the session.

The key is HKEY_LOCAL_MACHINE\SOFTWARE\WOW6432Node\citrix\Audio\status\Session xx where xx is the session id.

The problem is that ShellExperienceHost.exe runs at below normal permission level. So even though it is running under the user account and the user account has permissions to read the key and in fact the EVERYONE group has read permissions it still cannot read the key.

In order for the key to be readable the local group ALL APPLICATIONS PACKAGES must be given read permissions. After making this change I can open the volume icon with left click.


you can set the permissions manually at the \Audio\ level and then force inheritance to resolve the issue. The exact steps are;
1.    Open regedit
2.    Navigate to HKEY_LOCAL_MACHINE\SOFTWARE\WOW6432Node\citrix\Audio
3.    Right click -> permissions -> advanced
4.    Add -> Select a principal
5.    Locations -> Select the local machine
6.    Type ALL APPLICATIONS PACKAGES -> OK
7.    Give Read permissions
8.    Tick the Replace all child object permission entries with inheritable permissions entries from this object box
9.    Ok -> OK
10.    Test if the audio icon still causes the ShellExperienceHost crash
11.    That should resolve it for all users on that machine
 

 

 

  • Like 4
Link to comment
  • 3

Hello,

 

I did accidentally encounter an alternative solution for the volume control.

 

There is a registry-setting, which brings the old volume control back.

The old volume control opens on left-click without any other modifications as non-admin-user.

 

Key-Path: "HKLM:\SOFTWARE\Microsoft\Windows NT\CurrentVersion\MTCUVC"   (*)
Value-Name: "EnableMtcUvc"
Value-Type: "DWord"
Value-Data: "0"

(*) The "MTCUVC"-Key has to be created if it doesn't exists.

 

Original (called as admin / as user it won't open):

Screenshot-VC-Before.png.ca68756db7e4fb54f5e6ee935914c51f.png

 

With mentioned registry-setting applied:

Screenshot-VC-After.png.3cdb8627ceb1036dad94ac04208116ac.png

 

The registry-setting does not need a reboot and even not a logoff. Perfect for PVS-Targets. :76_ghost:

Tested on Server 2016 latest CU / Citrix XenApp 7.15 CU3.

  • Like 3
Link to comment
  • 0

Hello,

 

We have a similer issue on server 2008 R2,

some user cant use sound redirecet.
we can see that under
"HKEY_LOCAL_MACHINE\SOFTWARE\WOW6432Node\citrix\Audio\status\Session XX" 

there is not entrie key.

i tried to solved the issue according  workaround but in server 2008 R2 there is not "ALL APPLICATIONS PACKAGES".

can you provide us workaround for server 2008 R2?

 

Thanks.

Link to comment
  • 0

Hi Roni

 

I'm not sure you are experiencing the same issue as the OP as this issue is specific to the volume slider on server 2016 vda 7.12 publish desktop, Not sound redirection.

 

Have a look through the following articles, if you cant resolve using these start a new thread or open a support case with citrix if you have a support contract.

https://support.citrix.com/article/CTX443787

https://support.citrix.com/article/CTX121613

Link to comment
  • 0

As workaround create a startup script and add the following :

 

SetACL.exe -on "HKEY_LOCAL_MACHINE\SOFTWARE\WOW6432Node\citrix\Audio" -ot reg -actn ace -ace "n:ALL APPLICATION PACKAGES;p:read"

 

(to set the permission on the Audio key)

 

SetACL.exe -on "HKEY_LOCAL_MACHINE\SOFTWARE\WOW6432Node\citrix\Audio" -ot reg -actn rstchldrn -rst dacl,sacl

 

(to enherit the permission to all subkeys)

Link to comment
  • 0

Hello,

 

we are on 7.15 LTSR CU3 and have the same issue. Even if I set the Registry-Permissions as Michael explained it works only as long as the master image is booted.

When I start the provsisioned VMs the Volume Control doesn't open again and I get the crashing ShellExperienceHost entries in Eventlog.

 

Citrix, is there a solution for the workaround ?

 

Update : the problem arises because on each logon a sub-key with a random session ID is being generated and on a provisioned XenApp Server the permissions are missing again.

I created some powershell-code that corrects the permissions on logon for the specific user. Please note the group "ALLE ANWENDUNGSPAKETE" relates to a german Server OS.

 

$acl = Get-Acl HKLM:\SOFTWARE\WOW6432Node\Citrix\Audio

$rule = New-Object System.Security.AccessControl.RegistryAccessRule ("ALLE ANWENDUNGSPAKETE","ReadKey","ObjectInherit,ContainerInherit","None","Allow")

$acl.SetAccessRule($rule)

$acl |Set-Acl -Path HKLM:\SOFTWARE\WOW6432Node\Citrix\Audio

 

Maybe this helps some of you.

 

Regards, Markus

Edited by mlffle731
Update
Link to comment
  • 0
On 10.1.2019 at 10:04 AM, Markus Loumlffler said:

Hello,

 

we are on 7.15 LTSR CU3 and have the same issue. Even if I set the Registry-Permissions as Michael explained it works only as long as the master image is booted.

When I start the provsisioned VMs the Volume Control doesn't open again and I get the crashing ShellExperienceHost entries in Eventlog.

 

Citrix, is there a solution for the workaround ?

 

Update : the problem arises because on each logon a sub-key with a random session ID is being generated and on a provisioned XenApp Server the permissions are missing again.

I created some powershell-code that corrects the permissions on logon for the specific user. Please note the group "ALLE ANWENDUNGSPAKETE" relates to a german Server OS.

 

$acl = Get-Acl HKLM:\SOFTWARE\WOW6432Node\Citrix\Audio

$rule = New-Object System.Security.AccessControl.RegistryAccessRule ("ALLE ANWENDUNGSPAKETE","ReadKey","ObjectInherit,ContainerInherit","None","Allow")

$acl.SetAccessRule($rule)

$acl |Set-Acl -Path HKLM:\SOFTWARE\WOW6432Node\Citrix\Audio

 

Maybe this helps some of you.

 

Regards, Markus

I know I have encountered the same problem in the past and solved it with a startup script similar to yours triggered from GPO. If I remember correctly, the problem back then was "ALL APPLICATION PACKAGES" were missing "Read" on "HKEY_LOCAL_MACHINE\SOFTWARE\WOW6432Node\Citrix\Audio". I do not remember what version, but I think it was 7.15. However, when I created a new farm now using 7.18.11, I notice "ALL APPLICATION PACKAGES" was already correct with "Read" on "HKEY_LOCAL_MACHINE\SOFTWARE\WOW6432Node\Citrix\Audio". On all the subkeys located under "HKEY_LOCAL_MACHINE\SOFTWARE\WOW6432Node\Citrix\Audio\Status\Session XX" "ALL APPLICATION PACAGES" were missing. It turned out for some reason "ALL APPLICATION PACKAGES" were missing under "HKEY_LOCAL_MACHINE\SOFTWARE\WOW6432Node\Citrix\Audio\Status" even if inherit is on. So the easy solution for me was to edit the script to look like this:

 

$path = "HKLM:\SOFTWARE\WOW6432Node\Citrix\Audio\Status"

$Acl = Get-ACL $path

$AccessRule= New-Object System.Security.AccessControl.RegistryAccessRule("ALL APPLICATION PACKAGES","ReadKey","ContainerInherit, ObjectInherit","None","Allow")

$Acl.SetAccessRule($AccessRule)

Set-Acl $path $Acl

 

The script is triggered via GPO\Policies\Computer Configuration\Windows Settings\Scripts\Startup\Powershell -> \\fileserver\share$\CitrixAudio.ps1. Make sure to give domain computers read and execute permissions on the share since it is running under system context. I am using PVS as well. Guess it would work to set this on the image in private mode as well, but I prefer to do in GPO to keep track of different tweaks and to re-use easily if needed.

Link to comment

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
×
×
  • Create New...