<?xml version="1.0" encoding="UTF-8"?>
<rss xmlns:content="http://purl.org/rss/1.0/modules/content/" xmlns:dc="http://purl.org/dc/elements/1.1/" xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#" xmlns:taxo="http://purl.org/rss/1.0/modules/taxonomy/" version="2.0">
  <channel>
    <title>JasonP76 Tracker</title>
    <link>https://communities.vmware.com/wbsdv95928/tracker</link>
    <description>JasonP76 Tracker</description>
    <pubDate>Sat, 25 Nov 2023 08:57:35 GMT</pubDate>
    <dc:date>2023-11-25T08:57:35Z</dc:date>
    <item>
      <title>Re: Software Protection Service Errors on instant clones / AppVolumes</title>
      <link>https://communities.vmware.com/t5/Horizon-Desktops-and-Apps/Software-Protection-Service-Errors-on-instant-clones-AppVolumes/m-p/2961082#M98968</link>
      <description>&lt;P&gt;All,&lt;/P&gt;&lt;P&gt;I found the issue.&lt;/P&gt;&lt;P&gt;There is a conflict with FSLogix&amp;nbsp;2.9.8440.42104 and App Volumes 4 (at least the two latest versions I tried).&lt;/P&gt;&lt;P&gt;downgrading FSLogix back to&amp;nbsp;2.9.8361.52326 has fixed the problem.&lt;/P&gt;&lt;P&gt;This issue seems to also affect a lot of Apps that are provisioned using App Volumes. Like Adobe Acrobat Pro, SnagIt, and anything that uses Excel Add-ins&lt;/P&gt;&lt;P&gt;Just completely breaks the VDI&lt;/P&gt;&lt;P&gt;Hope this helps someone&lt;/P&gt;</description>
      <pubDate>Mon, 27 Mar 2023 08:34:13 GMT</pubDate>
      <guid>https://communities.vmware.com/t5/Horizon-Desktops-and-Apps/Software-Protection-Service-Errors-on-instant-clones-AppVolumes/m-p/2961082#M98968</guid>
      <dc:creator>JasonP76</dc:creator>
      <dc:date>2023-03-27T08:34:13Z</dc:date>
    </item>
    <item>
      <title>Software Protection Service Errors on instant clones / AppVolumes</title>
      <link>https://communities.vmware.com/t5/Horizon-Desktops-and-Apps/Software-Protection-Service-Errors-on-instant-clones-AppVolumes/m-p/2960834#M98963</link>
      <description>&lt;P&gt;Hey All,&lt;/P&gt;&lt;P&gt;I have an issue that I have recently come across.&lt;/P&gt;&lt;P&gt;We are running Window 10 22H2 Instant Clones (2212) with AppVolumes.&lt;/P&gt;&lt;P&gt;I have noticed when the App Volumes Service is running we are getting loads of SPP Errors in the event logs:&lt;/P&gt;&lt;P&gt;Failed to schedule Software Protection Service for re-start Error Code 0x80070003&lt;/P&gt;&lt;P&gt;These errors will appear every 30 seconds.&lt;/P&gt;&lt;P&gt;If I stop the the AppVolumes Service, I notice that the Software Protection service also stops. If I start it back up again, but do not restart the AppVolumes service those errors never come back and it actually has a normal log for the re-start.&lt;/P&gt;&lt;P&gt;I also think this is now causing most of our apps we on AppVolumes are now failing to work. Things like Adobe Pro DC.&lt;/P&gt;&lt;P&gt;Anyone seen this or know how to fix this issue?&amp;nbsp;&lt;/P&gt;</description>
      <pubDate>Fri, 24 Mar 2023 16:20:29 GMT</pubDate>
      <guid>https://communities.vmware.com/t5/Horizon-Desktops-and-Apps/Software-Protection-Service-Errors-on-instant-clones-AppVolumes/m-p/2960834#M98963</guid>
      <dc:creator>JasonP76</dc:creator>
      <dc:date>2023-03-24T16:20:29Z</dc:date>
    </item>
    <item>
      <title>Re: Managing Edge Version on Instant Clones</title>
      <link>https://communities.vmware.com/t5/Horizon-Desktops-and-Apps/Managing-Edge-Version-on-Instant-Clones/m-p/2946495#M98373</link>
      <description>&lt;P&gt;Just curious how do you manage the windows updates on the images? because surely you keep the images up to date with them at least?&amp;nbsp;&lt;/P&gt;&lt;P&gt;So if you do base image updates then you can also do Edge updates as they are incorporated within WSUS (to be as simple as you can make it).&lt;/P&gt;&lt;P&gt;We just set a GPO to disable updates on clones when they are pushed out, but we have a policy for the gold image, which is in a separate OU, to have updates enabled.&amp;nbsp;&lt;/P&gt;&lt;P&gt;So when Patch Tuesday roles round everything gets updated. I run my finalize powershell script that runs through the whole process cleans up the image and shuts it down. Then I just clone a version of the gold image (Which I call the Master Gold base image) to another to be the clone image, and snapshot it and push it out for a weekend (I actually wrote a script to do that all, create the clones, replicate them around all sites and create the schedule to push them out for the weekend role out), but even manually it is not that cumbersome.&lt;/P&gt;&lt;P&gt;Separating out the Master from the clone images controls the amount of snapshots needed (in this case there is only 1 snapshot ever on the cloned image and none on the master) and it also prevents screwing around with the Master image to much.&lt;/P&gt;</description>
      <pubDate>Tue, 03 Jan 2023 16:40:17 GMT</pubDate>
      <guid>https://communities.vmware.com/t5/Horizon-Desktops-and-Apps/Managing-Edge-Version-on-Instant-Clones/m-p/2946495#M98373</guid>
      <dc:creator>JasonP76</dc:creator>
      <dc:date>2023-01-03T16:40:17Z</dc:date>
    </item>
    <item>
      <title>Re: Vm Horizon issues</title>
      <link>https://communities.vmware.com/t5/Horizon-Desktops-and-Apps/Vm-Horizon-issues/m-p/2946490#M98372</link>
      <description>&lt;P&gt;I have seen this with many of the users we have.&lt;/P&gt;&lt;OL&gt;&lt;LI&gt;Check your WIFI signal. Also worth testing with your laptop wired in directly if you see a noticeable difference then sort out the WIFI&lt;/LI&gt;&lt;LI&gt;With regards to teams calls and lag I have seen this personally, when I went on a teams call on an iPad or iPhone while I have a VDI session. Actually saw this a lot during the pandemic when we were all at home and my wife was on teams calls. I ended up installing openwrt on my router and setting up SQM on it. Once I did this never had a day of issues. work flawlessly since. Also had 100Mb connection at the time. I could work without issue while the kids were streaming/teams school stuff and wife work teams calls.&lt;/LI&gt;&lt;LI&gt;Teams within a VDI will also give a lot of lag, as it will just push as much as it can especially if the video you sending is over 720p. It won't limit it like it would on an external device.&lt;/LI&gt;&lt;LI&gt;Also check if they have set up UDP as protocol for BLAST. This should help if you suffer from latency. And if you using PCoIP move over to BLAST.&lt;/LI&gt;&lt;LI&gt;The IT Team should also see your network latency on their dashboard.&lt;/LI&gt;&lt;/OL&gt;&lt;P&gt;To be honest any issues that relates to lag and latency on a Horizon session is usually 99% of the time a problem on the User's home network setup. So point 1 is really worth testing out.&lt;/P&gt;</description>
      <pubDate>Tue, 03 Jan 2023 16:26:02 GMT</pubDate>
      <guid>https://communities.vmware.com/t5/Horizon-Desktops-and-Apps/Vm-Horizon-issues/m-p/2946490#M98372</guid>
      <dc:creator>JasonP76</dc:creator>
      <dc:date>2023-01-03T16:26:02Z</dc:date>
    </item>
    <item>
      <title>Re: Horizon Client - Access Denied after implementing MFA on UAG</title>
      <link>https://communities.vmware.com/t5/Horizon-Desktops-and-Apps/Horizon-Client-Access-Denied-after-implementing-MFA-on-UAG/m-p/2946488#M98371</link>
      <description>&lt;P&gt;All,&lt;/P&gt;&lt;P&gt;So I think I found the solution to this issue.&lt;/P&gt;&lt;P&gt;The issue we have really does revolve around DNS round robin and Microsoft Authenticator (Azure AD), but maybe someone can still get an idea from this.&lt;/P&gt;&lt;P&gt;So from a high level look what you see is this:&lt;/P&gt;&lt;OL&gt;&lt;LI&gt;Client opens and you initiate the connection the to the LB/DNS RR. (One set of logs is created for the client)&lt;/LI&gt;&lt;LI&gt;Client forwards Authentication to the SAML Portal on the UAG, which in turn closes the client and opens a browser to this portal&lt;/LI&gt;&lt;LI&gt;Once successfully authenticated the client is then reopened and the session token is passed to the client. (Another set of logs for this client)&lt;/LI&gt;&lt;/OL&gt;&lt;P&gt;Step 3 is where this fails. and the reasons below.&lt;/P&gt;&lt;UL&gt;&lt;LI&gt;within the UAG you should have "Host Port Redirect Mappings" set for each individual UAG to rewrite the URL from the LB URL to the actual Site UAG URL&lt;/LI&gt;&lt;LI&gt;This URL rewrite is used to push to the correct SAML portal on the UAG for auth as stated in step 2&lt;/LI&gt;&lt;LI&gt;Within the Reply URL section of the Enterprise application set in Microsoft Azure for Horizon you would have a default url checked. This URL should really be the same URL as your LB/DNS RR.&amp;nbsp;&lt;/LI&gt;&lt;LI&gt;Between step 2 and step 3 is where this fail occurs. If your TTL is set to low on your DNS RR URL then during the time from step 1 to step 3 of the browser opening the client for you, the DNS entry for your DNS RR would have timed out. Also when the client opens up for the second time it is actually forced to redirect from the exact UAG URL that you set in the&amp;nbsp;"Host Port Redirect Mappings" back to the DNS RR URL that you have set as default for the&amp;nbsp;Reply URL section of the Enterprise application set in Microsoft Azure for Horizon (this can be clearly seen in the second set of logs that get created when the client opens up again). If at this point the TTL timed out on the DNS RR and it tries to resolve it will resolve the other site's IP and therefore give you the Access Denied as that is not the URL you initiated the session from.&lt;/LI&gt;&lt;LI&gt;So you need to increase the TTL on the DNS RR entry. We set ours to an hour and so far we have not had any users have this issue anymore&lt;/LI&gt;&lt;/UL&gt;&lt;P&gt;&amp;nbsp;&lt;/P&gt;&lt;P&gt;Hope this helps someone in the future if they come across the same problem&lt;/P&gt;</description>
      <pubDate>Tue, 03 Jan 2023 16:12:04 GMT</pubDate>
      <guid>https://communities.vmware.com/t5/Horizon-Desktops-and-Apps/Horizon-Client-Access-Denied-after-implementing-MFA-on-UAG/m-p/2946488#M98371</guid>
      <dc:creator>JasonP76</dc:creator>
      <dc:date>2023-01-03T16:12:04Z</dc:date>
    </item>
    <item>
      <title>Re: Horizon View Administrator SAML 2.0 Authenticator Issue</title>
      <link>https://communities.vmware.com/t5/Horizon-Desktops-and-Apps/Horizon-View-Administrator-SAML-2-0-Authenticator-Issue/m-p/2945517#M98341</link>
      <description>&lt;P&gt;I have seen this and from what I have seen is that you cannot have more than one SAML authenticator from the same IDP.&amp;nbsp;&lt;/P&gt;&lt;P&gt;Look at the XML file for the one you currently have and the one you want to add. Search for entityID. If they are the same then that is the reason why.&lt;/P&gt;</description>
      <pubDate>Mon, 26 Dec 2022 20:05:45 GMT</pubDate>
      <guid>https://communities.vmware.com/t5/Horizon-Desktops-and-Apps/Horizon-View-Administrator-SAML-2-0-Authenticator-Issue/m-p/2945517#M98341</guid>
      <dc:creator>JasonP76</dc:creator>
      <dc:date>2022-12-26T20:05:45Z</dc:date>
    </item>
    <item>
      <title>Re: Horizon Client - Access Denied after implementing MFA on UAG</title>
      <link>https://communities.vmware.com/t5/Horizon-Desktops-and-Apps/Horizon-Client-Access-Denied-after-implementing-MFA-on-UAG/m-p/2943604#M98293</link>
      <description>&lt;P&gt;That is exactly how we have it set up already&lt;/P&gt;&lt;P&gt;UAG1 -&amp;gt; CS1&lt;/P&gt;&lt;P&gt;UAG2 -&amp;gt; CS2&lt;/P&gt;&lt;P&gt;TTL on DNS Entry is 10 minutes, so there is no chance that the TTL time out occurs during the User Sign in process. They sign in within a minute of making the connection to the UAG, after which, when they have been successful, there is never a disconnection, because on the UAG you have to set the exact DNS Entry of that UAG for the Blast External URL and the Tunnel External URL. These are passed back to the client when a successful connection is made (which is what the client uses going forward to keep the connection up). the DNS Round robin address is only used at initial point of connection/authentication.&lt;/P&gt;&lt;P&gt;We noticed that when we set the browsers to incognito mode the issue does not occur. Clearing browser cache before logging in also seems to help with this issue, but we can't tell users that they have to keep doing this on their PCs just to connect in. On most occasions they forget.&lt;/P&gt;&lt;P&gt;Also if a user signs into the HTML version of Horizon then closes that and opens the client it works.&lt;/P&gt;&lt;P&gt;There seems to be something with the browsers possibly holding a stale record of a previous session, and when the authentication is made and the session token is passed over to the Horizon Client, it may be sending the old stale token and not the new one, hence giving the user the Access Denied message&lt;/P&gt;</description>
      <pubDate>Tue, 13 Dec 2022 11:32:54 GMT</pubDate>
      <guid>https://communities.vmware.com/t5/Horizon-Desktops-and-Apps/Horizon-Client-Access-Denied-after-implementing-MFA-on-UAG/m-p/2943604#M98293</guid>
      <dc:creator>JasonP76</dc:creator>
      <dc:date>2022-12-13T11:32:54Z</dc:date>
    </item>
    <item>
      <title>Re: Horizon Client - Access Denied after implementing MFA on UAG</title>
      <link>https://communities.vmware.com/t5/Horizon-Desktops-and-Apps/Horizon-Client-Access-Denied-after-implementing-MFA-on-UAG/m-p/2943426#M98273</link>
      <description>&lt;P&gt;Hey All,&lt;/P&gt;&lt;P&gt;I also have the exact same issue, even with UAG 2207 and Horizon CS 2209. Can be any client 8.x version also. They all do the same thing. load up Chrome/Edge and then when authenticated and being passed back to the client it Errors with Access Denied.&lt;/P&gt;&lt;P&gt;This is becoming increasingly frustrating.&lt;/P&gt;&lt;P&gt;&amp;nbsp;&lt;/P&gt;</description>
      <pubDate>Mon, 12 Dec 2022 13:32:15 GMT</pubDate>
      <guid>https://communities.vmware.com/t5/Horizon-Desktops-and-Apps/Horizon-Client-Access-Denied-after-implementing-MFA-on-UAG/m-p/2943426#M98273</guid>
      <dc:creator>JasonP76</dc:creator>
      <dc:date>2022-12-12T13:32:15Z</dc:date>
    </item>
    <item>
      <title>Re: Your client was not launched with valid SAML2 credential please contact your administrator</title>
      <link>https://communities.vmware.com/t5/Horizon-Desktops-and-Apps/Your-client-was-not-launched-with-valid-SAML2-credential-please/m-p/2942919#M98248</link>
      <description>&lt;P&gt;Yes. All within at least .1 or .2 from the UAG and the backend.&lt;/P&gt;</description>
      <pubDate>Thu, 08 Dec 2022 13:26:17 GMT</pubDate>
      <guid>https://communities.vmware.com/t5/Horizon-Desktops-and-Apps/Your-client-was-not-launched-with-valid-SAML2-credential-please/m-p/2942919#M98248</guid>
      <dc:creator>JasonP76</dc:creator>
      <dc:date>2022-12-08T13:26:17Z</dc:date>
    </item>
    <item>
      <title>Re: Your client was not launched with valid SAML2 credential please contact your administrator</title>
      <link>https://communities.vmware.com/t5/Horizon-Desktops-and-Apps/Your-client-was-not-launched-with-valid-SAML2-credential-please/m-p/2942275#M98219</link>
      <description>&lt;P&gt;I am getting the same thing with a lot of users at the moment.&lt;/P&gt;&lt;P&gt;Have you found a solution to this ?&lt;/P&gt;</description>
      <pubDate>Mon, 05 Dec 2022 16:52:39 GMT</pubDate>
      <guid>https://communities.vmware.com/t5/Horizon-Desktops-and-Apps/Your-client-was-not-launched-with-valid-SAML2-credential-please/m-p/2942275#M98219</guid>
      <dc:creator>JasonP76</dc:creator>
      <dc:date>2022-12-05T16:52:39Z</dc:date>
    </item>
    <item>
      <title>Re: Advice on snapvol.cfg file configurations</title>
      <link>https://communities.vmware.com/t5/App-Volumes/Advice-on-snapvol-cfg-file-configurations/m-p/2926426#M9006</link>
      <description>&lt;P&gt;So seeing that the&amp;nbsp;&lt;SPAN&gt;"#virtualize=\" is in place by default, and we are not using writable volumes, does this mean that any exclusions we add to the config file are not even used ? because I thought that the exclusions are put in to tell App volumes NOT to virtualize those exclusions as the rest would be virtualized. But this entry would mean that NOTHING is virtualized any more.&lt;/SPAN&gt;&lt;/P&gt;&lt;P&gt;Correct me if I am wrong.&lt;/P&gt;</description>
      <pubDate>Tue, 30 Aug 2022 12:13:14 GMT</pubDate>
      <guid>https://communities.vmware.com/t5/App-Volumes/Advice-on-snapvol-cfg-file-configurations/m-p/2926426#M9006</guid>
      <dc:creator>JasonP76</dc:creator>
      <dc:date>2022-08-30T12:13:14Z</dc:date>
    </item>
    <item>
      <title>Re: Laggy "rendering" for random users</title>
      <link>https://communities.vmware.com/t5/Horizon-Desktops-and-Apps/Laggy-quot-rendering-quot-for-random-users/m-p/2926424#M97631</link>
      <description>&lt;P&gt;&lt;a href="https://communities.vmware.com/t5/user/viewprofilepage/user-id/2479652"&gt;@SchwarzC&lt;/a&gt;&amp;nbsp;&lt;/P&gt;&lt;P&gt;Yeah ... Got it sorted out last week.&lt;/P&gt;&lt;P&gt;There was a licensing issue. the NVIDIA DLS Server stopped handing out licenses. Looked like we hit some bug / memory leak of sorts. I rebooted the servers and it all came back to life again.&lt;/P&gt;</description>
      <pubDate>Tue, 30 Aug 2022 12:07:21 GMT</pubDate>
      <guid>https://communities.vmware.com/t5/Horizon-Desktops-and-Apps/Laggy-quot-rendering-quot-for-random-users/m-p/2926424#M97631</guid>
      <dc:creator>JasonP76</dc:creator>
      <dc:date>2022-08-30T12:07:21Z</dc:date>
    </item>
    <item>
      <title>Re: Laggy "rendering" for random users</title>
      <link>https://communities.vmware.com/t5/Horizon-Desktops-and-Apps/Laggy-quot-rendering-quot-for-random-users/m-p/2925779#M97618</link>
      <description>&lt;P&gt;&lt;a href="https://communities.vmware.com/t5/user/viewprofilepage/user-id/5248305"&gt;@Jubish-Jose&lt;/a&gt;&amp;nbsp;Well that is the weird thing, sometimes it happens after a few hours, sometimes a user can have a session for a few days. There is no way we can reproduce the issue manually. I had it happen to 3 consecutive logins I did, until I logged in on the 4th time and the VM was fine, then 3 days later I got the issue.&lt;/P&gt;&lt;P&gt;Most users are saying it seems to happen mainly around the O365 product suite. Other apps seem to be ok.&lt;/P&gt;&lt;P&gt;I was also thinking if this could be an app volume related issue, and maybe to exclude all the office apps from the snapvol.cfg file as they are all installed on the golden image. And maybe also to exclude all the NVIDIA related paths and processes. What is your opinion on that?&lt;/P&gt;&lt;P&gt;We have tested with PCoIP and the issue still happens, so it does not seem to be a BLAST specific issue.&lt;/P&gt;</description>
      <pubDate>Thu, 25 Aug 2022 09:58:42 GMT</pubDate>
      <guid>https://communities.vmware.com/t5/Horizon-Desktops-and-Apps/Laggy-quot-rendering-quot-for-random-users/m-p/2925779#M97618</guid>
      <dc:creator>JasonP76</dc:creator>
      <dc:date>2022-08-25T09:58:42Z</dc:date>
    </item>
    <item>
      <title>Re: Advice on snapvol.cfg file configurations</title>
      <link>https://communities.vmware.com/t5/App-Volumes/Advice-on-snapvol-cfg-file-configurations/m-p/2925775#M9001</link>
      <description>&lt;P&gt;&lt;a href="https://communities.vmware.com/t5/user/viewprofilepage/user-id/5283006"&gt;@BenTrojahn&lt;/a&gt;&amp;nbsp; Ok I will go through it and have a look, but I having "#virtualize=\" does that not mean that nothing gets virtualized in the first place? By default that setting is hashed out in our config file. It is not something we have done manually.&lt;/P&gt;&lt;P&gt;Also I noticed in the file an entry for :&lt;/P&gt;&lt;P&gt;reverse_replicate_file=*\chrome.exe&lt;/P&gt;&lt;P&gt;Should we not have the same entries for Edge seeing that they are basically chromium packages?&lt;/P&gt;</description>
      <pubDate>Thu, 25 Aug 2022 09:51:10 GMT</pubDate>
      <guid>https://communities.vmware.com/t5/App-Volumes/Advice-on-snapvol-cfg-file-configurations/m-p/2925775#M9001</guid>
      <dc:creator>JasonP76</dc:creator>
      <dc:date>2022-08-25T09:51:10Z</dc:date>
    </item>
    <item>
      <title>Re: Advice on snapvol.cfg file configurations</title>
      <link>https://communities.vmware.com/t5/App-Volumes/Advice-on-snapvol-cfg-file-configurations/m-p/2925771#M9000</link>
      <description>&lt;P&gt;Would not mess with what specifically?&lt;/P&gt;</description>
      <pubDate>Thu, 25 Aug 2022 09:42:28 GMT</pubDate>
      <guid>https://communities.vmware.com/t5/App-Volumes/Advice-on-snapvol-cfg-file-configurations/m-p/2925771#M9000</guid>
      <dc:creator>JasonP76</dc:creator>
      <dc:date>2022-08-25T09:42:28Z</dc:date>
    </item>
    <item>
      <title>Laggy "rendering" for random users</title>
      <link>https://communities.vmware.com/t5/Horizon-Desktops-and-Apps/Laggy-quot-rendering-quot-for-random-users/m-p/2925433#M97598</link>
      <description>&lt;P&gt;Hi All,&lt;/P&gt;&lt;P&gt;We have a strange issue that we have been seeing occurring over the past couple of months (possibly more).&lt;/P&gt;&lt;P&gt;We run Horizon 2203, with NVIDIA GRID M10s, Windows 10 Instant Clones, with AppVolumes and FSLogix, across 2 completely separate sites.&lt;/P&gt;&lt;P&gt;We have got complaints from users, that all of a sudden the response times on the VDI drops dramatically. They say it becomes very laggy. We have checked the network latency and their latency is like 10ms. there are no issue on their network nor can we see anything on our networks (We have done numerous captures). There is no resource constraints (I had this occur to my own VDI when there were only 10 VDIs across the whole farm). The hardware and software across both sites is exactly the same (Same Golden image), Yet users experience this strange thing. Sometimes a user will log on to a VDI, and it will be perfectly fine, but then maybe a day later, even a week later, things just grind. It is almost like rendering slows down, and you look like you are getting 1fps if that. If the user logs off and logs back on to a new VDI it may "fix" itself, but sometimes you get on to a couple of VDIs doing the same thing. Takes a few log off and on agains for it to come right.&lt;/P&gt;&lt;P&gt;We are using BLAST, only H264 Encoding (I thought it was adaptive encoding that may have been causing the issue, but it still happens after I removed that setting).&amp;nbsp;&lt;/P&gt;&lt;P&gt;I am pretty stumped and wondering if anyone else has experienced this, or have any suggestions of what to try.&lt;/P&gt;&lt;P&gt;Thanks&lt;/P&gt;</description>
      <pubDate>Tue, 23 Aug 2022 20:58:18 GMT</pubDate>
      <guid>https://communities.vmware.com/t5/Horizon-Desktops-and-Apps/Laggy-quot-rendering-quot-for-random-users/m-p/2925433#M97598</guid>
      <dc:creator>JasonP76</dc:creator>
      <dc:date>2022-08-23T20:58:18Z</dc:date>
    </item>
    <item>
      <title>Advice on snapvol.cfg file configurations</title>
      <link>https://communities.vmware.com/t5/App-Volumes/Advice-on-snapvol-cfg-file-configurations/m-p/2925422#M8993</link>
      <description>&lt;P&gt;Hi All,&lt;/P&gt;&lt;P&gt;I hope some of you can give me a little advice on our current AppVolumes setup.&lt;/P&gt;&lt;P&gt;We are running version 4.6. We do not use writeable volumes only use AppStacks to publish applications to users. We use FSLogix to do all the profile management (Already have those exclusions in the snapvol.cfg file)&lt;/P&gt;&lt;P&gt;We run most of the common applications like Adobe Reader and Office 365 Pro Plus directly in the the base image of the instant clones.&lt;/P&gt;&lt;P&gt;I would like to know, in the custom&amp;nbsp; snapvol.cfg file, should I go through the base image and add exclusions for all apps that are installed on it, Like office, Adobe, notepad++, 7zip etc ...&lt;/P&gt;&lt;P&gt;Also add in exclusions for the process names as well as the process path for all those applications ?&lt;/P&gt;&lt;P&gt;One other thing, I assume that the line:&lt;/P&gt;&lt;P&gt;#virtualize=\&lt;/P&gt;&lt;P&gt;is correct that it should be hashed out along with the other ones to virtualize the registry ?&lt;/P&gt;&lt;P&gt;Thanks&lt;/P&gt;</description>
      <pubDate>Tue, 23 Aug 2022 20:36:14 GMT</pubDate>
      <guid>https://communities.vmware.com/t5/App-Volumes/Advice-on-snapvol-cfg-file-configurations/m-p/2925422#M8993</guid>
      <dc:creator>JasonP76</dc:creator>
      <dc:date>2022-08-23T20:36:14Z</dc:date>
    </item>
    <item>
      <title>Re: Issue with Teams Screen Sharing and BLAST Protocol</title>
      <link>https://communities.vmware.com/t5/Horizon-Desktops-and-Apps/Issue-with-Teams-Screen-Sharing-and-BLAST-Protocol/m-p/2909656#M97015</link>
      <description>&lt;P&gt;Yes ... the link provided just above by the Vmware employee is the workaround. (&lt;A href="https://enterprise-support.nvidia.com/s/article/Invisible-Microsoft-Teams-Control-Bar-and-Minimized-Window-on-VDI" target="_blank"&gt;https://enterprise-support.nvidia.com/s/article/Invisible-Microsoft-Teams-Control-Bar-and-Minimized-Window-on-VDI&lt;/A&gt;)&lt;/P&gt;&lt;P&gt;This article was put in as a result of the ticket I had in place with VMware, Nvidia and MS. we worked on this for months to find this.&lt;/P&gt;&lt;P&gt;The issue is actually an OS problem. Came about after 1909 as 1909 code for the desktop duplication API was changed after. So I suggest you raise a ticket with MS also to make them aware you have also had the issue.&lt;/P&gt;&lt;P&gt;I have done so, and the more people raise it with the more they will address the issue I hope, as I am worried that this workaround will only work until such a time MS changes the way they do the desktop duplication API again and then nothing will work at all.&lt;/P&gt;</description>
      <pubDate>Wed, 18 May 2022 08:42:06 GMT</pubDate>
      <guid>https://communities.vmware.com/t5/Horizon-Desktops-and-Apps/Issue-with-Teams-Screen-Sharing-and-BLAST-Protocol/m-p/2909656#M97015</guid>
      <dc:creator>JasonP76</dc:creator>
      <dc:date>2022-05-18T08:42:06Z</dc:date>
    </item>
    <item>
      <title>Re: Issue with Teams Screen Sharing and BLAST Protocol</title>
      <link>https://communities.vmware.com/t5/Horizon-Desktops-and-Apps/Issue-with-Teams-Screen-Sharing-and-BLAST-Protocol/m-p/2887873#M95961</link>
      <description>&lt;P&gt;I have actually. And that does not change anything.&lt;/P&gt;&lt;P&gt;I have also removed the vGPU from the VDI and created a new pool and tried it. That works.&amp;nbsp;&lt;/P&gt;&lt;P&gt;So some interaction between the NVidia vGPU Driver and the Blast protocol that does not seem to be working.&lt;/P&gt;</description>
      <pubDate>Thu, 13 Jan 2022 09:02:03 GMT</pubDate>
      <guid>https://communities.vmware.com/t5/Horizon-Desktops-and-Apps/Issue-with-Teams-Screen-Sharing-and-BLAST-Protocol/m-p/2887873#M95961</guid>
      <dc:creator>JasonP76</dc:creator>
      <dc:date>2022-01-13T09:02:03Z</dc:date>
    </item>
    <item>
      <title>Issue with Teams Screen Sharing and BLAST Protocol</title>
      <link>https://communities.vmware.com/t5/Horizon-Desktops-and-Apps/Issue-with-Teams-Screen-Sharing-and-BLAST-Protocol/m-p/2887545#M95933</link>
      <description>&lt;P&gt;Hi All,&lt;/P&gt;&lt;P&gt;I have a slightly odd one here.&lt;/P&gt;&lt;P&gt;About 6 months or so ago we upgraded to the latest version of Teams on our VDI infrastructure. All of a sudden when a user wanted to do a screen share and try give someone control there was no bar at the top of the screen to allow this. The other user could request this, but there presenter could not click on a button to allow it. After quite a lot of troubleshooting and raising a ticket with Vmware, we found that the bar was actually there, but invisible. Literally invisible. You could move your mouse over to the general area and you would actually see the info popups saying "Presenting..." and "Only give control to people you trust". So the feature was there but was not being rendered. If we change the protocol to PCoIP or even Microsoft RDP, the bar would be rendered and shown. This only happened using Blast. The workaround at the time was actually disabling H264 from the client and only allowing HEVC. This happens with both users connecting inside or from outside the infrastructure (So with a UAG or direct).&lt;/P&gt;&lt;P&gt;At the time we were running:&lt;/P&gt;&lt;UL&gt;&lt;LI&gt;Windows 10 1909&lt;/LI&gt;&lt;LI&gt;Agent and Connection Server 7.13.1&lt;/LI&gt;&lt;LI&gt;NVIDIA vGPU (2GB per VDI) - 11.6 Driver&amp;nbsp;&lt;/LI&gt;&lt;LI&gt;Instant Clones&lt;/LI&gt;&lt;LI&gt;Latest Machine wide Teams installed (currently 1.4.00.29469)&lt;/LI&gt;&lt;/UL&gt;&lt;P&gt;We have now upgraded our VDIs to Windows 10 21H2 and Agent/Connection Server 8.4 (2111), and without changing any of the settings we had previously for the clients, this issue has come back again, but this time neither running the client with HEVC or H264 on Blast works, but once again any other protocol does work.&lt;/P&gt;&lt;P&gt;Has anyone seen this issue before ?&amp;nbsp;&lt;/P&gt;&lt;P&gt;I have had Vmware pointing the finger at Microsoft and Microsoft pointing the finger at Vmware. Neither wanted to take responsibility for this. Personally I think this is a Vmware issue considering that this issue only occurs using the Blast protocol.&lt;/P&gt;&lt;P&gt;Any help would be greatly appreciated.&lt;/P&gt;&lt;P&gt;Thanks&lt;/P&gt;</description>
      <pubDate>Tue, 11 Jan 2022 15:11:08 GMT</pubDate>
      <guid>https://communities.vmware.com/t5/Horizon-Desktops-and-Apps/Issue-with-Teams-Screen-Sharing-and-BLAST-Protocol/m-p/2887545#M95933</guid>
      <dc:creator>JasonP76</dc:creator>
      <dc:date>2022-01-11T15:11:08Z</dc:date>
    </item>
  </channel>
</rss>

