Trouble getting rid of them really old citrix receiver versions (6.x / 7.x)?

Came across an issue removing some really old citrix clients (version 7.x) in a locked-down environment that was running (ahem) windows vista machines. Had issues upgrading the receivers on the machines.

As these machines had ICA clients using a version that was packaged using installshield they used an EXE file. The method to remove these files was somewhat different than the later MSI method. To remove successfully:

isuninst –f C:\PROGRA~1\Citrix\ICACLI~1\Uninst.isu –c C:\PROGRA~1\Citrix\ICACLI~1\uninstpn.dll –a.

 

Advertisements

Troubleshooting HTML5 receiver issues

Recently in the lab updated the HTML5 receiver (version 2.3) on my storefront servers. After which hit issues with my connection going “in and out”.

Turns out my patching wasn’t up to scratch. XenApp 6.5 environment and moving hotfix rollup pack 7 (per CTX129229) resolved the issue.

What was instructive was enabling HTML5 logging per https://support.citrix.com/article/CTX217352

What did help me gather from it was it was session reliability-related. Sure enough when I switched it off all worked. Ultimately though did want to leave enabled so updating to latest HRP resolved but the HTML5 logging was very useful on this occasion as reasonably negligible so a good takeway

 

Citrix PVS tip: how to install PVS powershell snap-in

Recently was looking to utilize the vDisk replicator utility (see: https://www.citrix.com/blogs/2017/04/12/vdisk-replicator-tool/) which had a requirement for the PVS powershell snap-in. After a few times did manage to get the snap-in to work but have to be careful to get the syntax correct which was in the end:

C:\Program Files\Citrix\Provisioning Services Console>C:\Windows\Microsoft.NET\Framework64\v4.0.30319\installutil.exe Citrix.PVS.SnapIn.dll

After that was up and running with my replicator

 

 

 

Getting “Aw, Snap!” on launch of google chrome in citrix environments?

See plenty of pain on this one in the field. Not quite sure what is going on with chrome as seen as same from my own machine.

Anyways in order to circumvent message below which is what greets you launch simply need to do the following:

C:\Program Files (x86)\Google\Chrome\Application\chrome.exe” –no-sandbox –disable-infobars –disable-gpu

 Editing the shortcut is the simple method. Use shift+right click to edit the one on the taskbar. Sure there is noise in the forums on this but been busy to check what root cause is/ultimate fix but above should get you over the hump for now.

 

 

Windows VDI environment? getting poor performance on SCCM downloads?

Recently been tasked with migrating a fair ton of apps from Win7->10. One of the challenges in this space is testing. Previously with Windows 7 the guys worked on static persistent VM’s rolled out to testers to run their updated app through it’s paces. Few obvious problems with this approach

I) Quite a bit of VM admin to do – clean up post test of apps

2) Quite a bit of email admin to do – separate mails tailored for specific app owners detailing their specific machine to test etc

Luckily things have moved on a bit most importantly regards “delivery” of the apps. By that I mean previously was hamstrung with only allowing a VDI-type scenario being of use to cover app-v sequenced apps as they where using the “follow-the-user” model (user added to SCCM user collection and deployment type set to include VDI. As such at the time experience was limited with app-v which meant a VDI solution wasn’t practical for testing as vast majority of apps where MSI’s.

To that end we have been able to get over that hurdle by publishing the MSI’s as applications in SCCM rather than packages this gives us the flexibility to use the same follow-the-user approach as with app-v sequences. That being so a Win10 VDI then would have merit.

So recently got going on standing one up (XenDesktop 7.13 back-end). Tested adding a few of the team to a few random app-v sequences / MSI’s applications and noticed horrible download performance for all our apps/packages in Software Center. For example a 200mb MSI took 40 minutes to download.

Issue was put down to the BITs client configuration. For all workstations in general in an environment there is a cap on download speed. Enclosed illustrates what’s in my lab environment

as you can see there is cap’s on performance at certain times of the day. That makes sense for the general workstation population in an environment particularly for remote users over VPN as SCCM does not have an elegant way to identify a user that roams between local and VPN.

As such of course for VDI its not a requirement so in order to switch off I inserted a GPP into my GPO to set no limit on download rate. Registry key is called EnableBitsMaxBandwidth and set to 0 (located under HKLM \Software \ Policies \ Microsoft \ Windows \ BITS)

once I place was rocking and rolling and downloads flew along

PVS write cache filling up? handy filter in Procmon to give a clue as to what’s causing it

So of course with write cache filling up issues no simple way to tell what’s going on. Needless to say like most quirks that happen in Windows the sysinternals tools can come to you rescue.

Recently started work on a windows 10 PVS image and after about 10 minutes the write cache would fill up.

So using Procmon (https://technet.microsoft.com/en-us/sysinternals/processmonitor.aspx) was able to determine what was going on.

In order though to filter out the extraneous stuff found the following 2 filters gave me info on the offenders.

To do click Filter and filter out everything except write activity by making two filters as follows:

Operation begins with WriteFile Include
Operation begins with WriteConfig Include

and you’ll be on our way.