KenArcher's Posts

Just sharing the fix in case anyone else comes across this. We had Remove Lock Computer enabled in a group policy. With this policy enabled the drag and drop would function on the initial connection but not after a reconnect. Wit the policy disabled or not configured the drag and drop works on both initial connection and reconnect. VMware support informed me they do not support enabling that policy, so we set it to not configured.

We are testing via the Client to Agent. We have the CDR feature installed on the parent image but are using Smart Policies to disable just the drive redirection. The DND functions correctly on the initial logon with drive redirection disabled via the Smart Policies, just not on reconnects. I'm not sure what you mean by string or picture, as that is controlled via the clipboard redirection Smart Policy in DEM. We are using the Horizon Client, version 2111.1. The Agent is currently 2103. Restarting the Horizon client does not fix the issue, nor does restarting the desktop its running on.   

The green check means the current value equals the expected value, as defined by the template. You can edit the template using the My Templates tab at the top of the screen. You'll need to locate the value in the template you are using and then decide how to proceed. First and foremost, back up your template files before you edit anything. Then you have the option of removing the step entirely. You can also edit the value to explicitly be what you want it to be. Personally, I change the name of the template with an organization identifier appended to the beginning of the name string and then change the expected data to the value I want it to be. This makes identifying custom changes to the template easier should a new version of OSOT drop and I want to compare my current template with a newly released template. Before changing your template you may want to apply the registry values using a group policy to test that you have the right keys. Group Policies will overrule the OSOT template changes and are far easier to back out if you get unexpected results. Once you know you have the right keys you can then migrate the changes from the group policy to the OSOT template, so future builds have the customization, and back the policy out of the GPO so it's only applied in one location.

We are running AppVolumes (4.4.1.4), but only a few of the users who reported the issue are entitled to an app volume. We only deploy AppVolumes to a small subset of users. Our parent image has a large number of preinstalled applications, but I am able to confirm the issue began after upgrading Chrome and only Chrome to 103.0.5060.66 from a version I believe ended in .53.

Are you using the VMware OS Optimization Tool as part of the build process for your parent image. Some of the default policies in that tool disable toast notifications by default and you need to modify the template to enable the notifications. We had the same issue and had to change these policies in OSOT. Group policy - Turn off toast notifications had to be set to a DWORD value of 0 Windows Settings - Get notifications from apps and other senders had to be set to a DWORD value of 0

Is there some trick to getting Zoom for VDI to launch using https://zoom.us/test? I tried both Chrome and Edge after installing the client and neither will automatically launch the meeting. The users have to manually start the client/meeting.

We are Horizon 2103 Win 21H1. Rollback isn't an option at this time so I may have to get creative and script a solution. If I come up with something I'll post it here in case anyone else has the same issue. Thanks. 

Thanks for the response. Unfortunately, refreshing triggered tasks at either reconnect or disconnect or both is not having the same effect for us. After the lock/tsdiscon.exe the user can no longer reconnect to their desktop. It looks as if Windows is triggering a lock on reconnect, which in turn has DEM triggering tsdiscon.exe. I was able to replicate similar behavior using the option to send a message in the triggered task instead of tsdiscon.exe. If I lock the session and stay connected the message would pop up once. However, if I lock the session and disconnect/reconnect I get the message pop up twice.  We are currently using 10.2 as well so I don't think it's an issue with that. Instead I suspect it's a windows 10 behavior that's causing the extra lock.

We had a similar issue when first setting up our VDI environment. It turned out we needed to add more VRAM to the parent image. Depending on your resolution and the number of monitors needed the parent needs a certain minimum amount of VRAM. Check out https://docs.vmware.com/en/VMware-Horizon/2006/horizon-architecture-planning/GUID-10ED49A9-56B6-4BD7-8425-94900F53AB02.html.

I've been fighting with the same issue. Unfortunately triggering a tsdiscon.exe on lock along with the refresh on disconnection doesn't have the same results for me. I get an instant disconnect on every reconnect attempt. The DEM logs show a user environment refresh on the first disconnect but nothing on subsequent reconnection attempts. At this point I'm forced to reboot the desktop via Horizon Admin. Are there any additional settings that may need to be applied for the provided fix to work? I should note that triggering a tsdiscon via command line without the two triggered tasks does not cause the same issue. The session will disconnect at that point and can reconnect without issue. Interestingly enough, if the user hasn't triggered a Windows lock the session will return without prompting the user for the password. After Windows lock has been triggered even once reconnections after a tsdiscon will always prompt for a password. Edit: Another behavior has been identified. If I configure DEM to send a message on unlock I get three messages instead of one. So it looks like the system is locking on reconnect on its own.

I'm not certain about the GPO, but there is an option not to install client drive redirection in the Horizon Agent that might work for you. In addition to this if you use DEM you should be able to use a Hoziron Smart Policy in the User Environment tab to control client drive redirection at a more granular level.

Unfortunately, no it did not get resolved using DEM. We disabled the folder redirection there and resorted to a script at logon to redirect the documents and desktop. We plan on trying DEM again after some upgrades to Horizon and see if that helps.

I reconfigured as a shutdown script but I'm still seeing over 30s per folder. I saw the same behavior on three subsequent logons. The FlexEngine profiles are stored on a virtual server on a separate vCenter instance. The datastore is hosted on a Pure Storage array, all SSD with four 10Gbps NICs. The storage network is physically separate from the typical data network. The server hosting the shares we are redirecting to is running on the same vCenter instance / array. IOPS are low and keep in mind we only see slow redirection via DEM, while group policy redirection is fast. Because of that I don't think its a problem on the storage side.

Adding "C:\Windows\System32\net.exe stop /y workstation" did not resolve the issue for me. I configured it after FlexEngine.exe -s, but do not know if the order matters in this particular case. I'm still seeing delays of 30 seconds or more during redirection. Client RSOP: