World of EUC

<@ULTGG1KDJ> try to disable *"Check for publisher's certificate revocation"* and *"Check for server certificate revocation"* in Internet Explorer and restart all Studio instances as a primary workaround.
Are the DDCs in the same zone/physical location?

Yes DDCs are on same LAN.  Using Studio directly on DDC is equally painful.  Thanks will give your suggestions a try.

Google mmc.exe.config regarding PublisherEvidence. Check your Internet/PublisherEvidence. Check your internet/proxy configuration. 

Sorry everyone, but these recommendations (while very, very common) are not the best way to tackle this. It is limited in scope (e.g. mmc.exe.config will fix only MMC console).

Instead, you can use a Group Policy to disable CRL checks for whole machine: <https://www.citrix.com/blogs/2012/06/05/slow-web-interfacemmc-console-crl-explained/>

<@ULGKFDUVD> Can’t believe I have overlooked this blog post :face_with_hand_over_mouth:. Thanks!

Thanks all. My issues are more moving around within Studio rather than waiting for it to start. Removing all proxy settings (and a reboot) seem to have made an improvement - though could of course just be the reboot. I will go through your recommendations Martin - thanks.

no. pretty sure that's just a problem that will always exists

not done anything with the new O365 installer but with other apps that used click-to-run we could not get them to work

my best luck with them have been to install it, look through and see if i can just copy the files somewhere else change points and call it good.

i've found most aren't done right and you can get away with it

Used C2R with O365 on XenApp multiple times at different customers. Never seen login issues

```&lt;Configuration ID="5dc430a2-8984-4b31-972f-31b5821ddb6d"&gt;
  &lt;Info Description="" /&gt;
  &lt;Add OfficeClientEdition="32" Channel="Monthly" SourcePath="\\blah.local\voa\streamedapps\o365-voa" AllowCdnFallback="TRUE" ForceUpgrade="TRUE" MigrateArch="TRUE"&gt;
     &lt;Product ID="O365ProPlusRetail" PIDKEY=""&gt;
      &lt;Language ID="en-us" /&gt;
      &lt;ExcludeApp ID="Groove" /&gt;
      &lt;ExcludeApp ID="OneDrive" /&gt;
      &lt;ExcludeApp ID="Teams" /&gt;
    &lt;/Product&gt;
   &lt;Product ID="ProjectProRetail" PIDKEY=""&gt;
      &lt;Language ID="en-us" /&gt;
      &lt;ExcludeApp ID="Groove" /&gt;
      &lt;ExcludeApp ID="OneDrive" /&gt;
      &lt;ExcludeApp ID="Teams" /&gt;
    &lt;/Product&gt;
    &lt;Product ID="VisioProRetail" PIDKEY=""&gt;
      &lt;Language ID="en-us" /&gt;
      &lt;ExcludeApp ID="Groove" /&gt;
      &lt;ExcludeApp ID="OneDrive" /&gt;
      &lt;ExcludeApp ID="Teams" /&gt;
    &lt;/Product&gt;
  &lt;/Add&gt;
  &lt;Property Name="SharedComputerLicensing" Value="1" /&gt;
  &lt;Property Name="PinIconsToTaskbar" Value="FALSE" /&gt;
  &lt;Property Name="SCLCacheOverride" Value="0" /&gt;
  &lt;AppSettings&gt;
    &lt;Setup Name="Company" Value="Company" /&gt;
  &lt;/AppSettings&gt;
  &lt;Display Level="Full" AcceptEULA="TRUE" /&gt;
  &lt;Logging Level="Off" /&gt;
&lt;/Configuration&gt;```

Depending on if you're using FSLogix or not, you may need to move the activation parts

Hmm I am not using monthly release cycles. I will also compare the gpos. Everyone using 2019?

that's just an example.  :slightly_smiling_face:

I have to imagine that this is the release that'll be used for the next major LTSR release in December.

oh wow yeah its been a while since the last LTSR

Yes squeezing x64-only and name changes in before LTSR :)

Hey, I'll take it. We're on 7.15 LTSR and we're probably 682 enhancements and features behind.

do they stick in features in the CU's every now and again or are they just strictly security and bug fixes?

Strictly security/bug fixes in the LTSR CUs.

That's the intention, though. I only complain because LTSR was forced on us by some muppets who didn't understand Citrix. I don't think we'll be on LTSR much longer after the next major release.

switched off LTSR after 7.6 and was kinda rough for a bit with the rapid Windows releases and trying to line up the compatiblity for everything but now that MS is doing longer support for the xx09 releases it's not too bad

sort of true.. they slipped BCR into 7.15 LTSR..

Did they include it in the initial 7.15 release or a CU? If the former, that makes sense given that they should be included new features in the major builds.

no, it was like CU2 or something they added it

FYI, Citrix announced today (in the _What's New..._ webinar I was in) that 1912 LTSR is, in fact, going to be based on 1909 CR.

<https://docs.citrix.com/en-us/citrix-virtual-apps-desktops/whats-new.html>

oo they now provide the SDK as both a Snap-in and Powershell module

Question, we're using CVAD1906 with a VMware hypervisor connection. The VMware vCenter now uses a self signed certificate. We're planning to change this to a certificate from our CA (which is trusted bij the delivery controllers). The host name will be the same.
Can I expect any problems with the hypervisor connection. Or will it be smart enough to 'recognize' the new certificate and that it can be trusted?
I've read <https://support.citrix.com/article/CTX224551> but this seems to be about changing to another self signed certificate or when the CA is not already trusted?

I changed mine recently to a cert from a CA and didn’t encounter any issues

In earlier version of XAD I think that was the case. No longer though.

Could be right as havent had to do it for a while....  i would just copy the new vcenter cert to trusted people store and remove old cert and then test the hosting connection and run get-brokerhypervisorconnection any issues u will have to update the thumbprint as per that article

Spot on as always dude. You at the next CUCG in November?

Hmmmhmmm now I've mixed feelings about it. I use VDI pooled desktops only. So when vCenter is not reachable my CVAD is useless.

Lab it, test it, make sure you have a fallback scenario. Make things (almost) 100% foolproof? Opinions on the web will only get you the results of their specific scenarios

^^ worst case you can just put the old vcenter cert back ... tbh i have done it numerous times and not had a issue as long as the new vcenter cert is in the trusted people cert store on your DDCs and old cert removed and thumbprint has been changed u should be fine. Roll back you can just put the old certs back. A hosting connection test in studio / get-brokerhyporvisorconnection test will quickly identify any issues

When its a completley new vcenter with a different name and datastore names /vm port group names now that is a pain in ass  but what your doin is straight forward

Kofax doc management stuff?  I believe we have it, (large environment), another from my team set it up,l.  What type of issues are you seething?  I’ll compare notes and ask my coworker.

Yes, the app team that supports Kofax does sometimes complain about performance issues since upgrading to WS2016, but I don’t have any details.  What kind of issues are you seeing?

I don't have the details since I'm not actively engaged with the respective customer but they're aware it's not in scope for our contract. Still, I'm trying to go beyond that and help them.
I just heard the customer has massive performance issues after moving to XenApp 7.x and WS2016 and that cost to fix that isn't really a problem so it's a nasty one.
Was thinking there might be some best practices they're not following...

All I know is out ops guys get an occasional ticket about slowness, I don’t know the specifics, I’d have to do some digging.

I've handled thousands of applications back in my days and while I don't remember exactly why, I'm getting goosebumps when I've heard the name "Kofax".

I did a brief search in our ticketing system.  There have been a handful of Kofax tickets that are about vague slowness.  It looks like the resolutions in the tickets have been to reset their profiles, I'm not fond of this as a resolution.  I'll reach out to the app team too to see if there is a best practice they can get from the vendor.

following because somsone just asked us to deploy it on session hosts

I sent an email to our app team asking for some details, I haven't received a response yet.

What is your worry? If you have a fully automated deployment just roll it out and test test test.

Just being overly cautious. Ideally, I'd be doing them separately to help with troubleshooting any issues, but we've got to cram a number of things in at once due to other timelines, so I'm likely going to roll these out at the same time.

I don't know if there's a consensus, but we set the pagefile to a static 2GB (initial and max) on our W10 non-persistent PVS devices. Testing proved that it works well for our use case.

It's all about the use case and how much memory your apps actually use. I believe Trent tye wrote a great article about analyzing it and making the right decision.

Actually trentent and me had a discussion about this: <https://blogs.technet.microsoft.com/motiba/2015/10/15/page-file-the-definitive-guide/>

This is my rule of thumb.

Any one faced issue with Multiple per device RDS CALS are issued the same device

Stretching sql across two datacenters with a multi subnet cluster and SQL always on availability groups and a 3rd location for file share witness. How many cluster nodes is recommended two in each datacenter so four total? Primary DB in primary Datacenter with secondary readable replicas with synchronous  commit with a multi subnet listener ? Also is it recommended to leave the DDCs in each datacenter in the primary zone or have seperate zones for each  Datacenter? I presume alot depends of the connectivity between datacenters latency/bandwith... ive also looked at the powershell command set-configsite -primaryzone to set the secondary zone as primary if primary zone is down.  I much prefer seperate XDsites in each datacenter and use storefront aggregation and user mapping and Netscaler OGR but not a option unfortunately

It's all about the link speed mate. Love where you brain is going though. If the link speed isn't fast I would go with separate sites as you suggested too.

Defo log a support call after performing a trace on the affected VDA.

You may want to try a packet trace initially to see if you see any negotiation happening.

That's annoying.  EDT seems to be fragile. :confused:  I've had it break on multiple upgrades as well.

What I will try now is VDA Cleanup and do a fresh install of VDA 7.15.4