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
Q came up on the citrix discussions regards this as poster was looking to gather log data for an issue they had with one of their target devices. With version 7 for PVS there was a shift away from using persistent log files to using CDF traces.
More details enclosed
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.
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.
On a certain batch of VDA’s we had running in an environment here they were running 2 versions back (7.11) from current version on our delivery controllers (7.13) noticed tickets coming in relating to general sluggishness with performance. Ops teams did some digging and noticed it was related to WMIprvse.exe. Seen this in the past and wondered if a similar fix adopted to same issue we’d seen in XenApp 6.5 would work.
Sure enough did the trick.
Issue related to performance counters.
On a “happy” VDA (eg one chugging along nice and quiet from a CPU perspective)
export the performance counters
c:\ lodctr.exe /S:C:\counters.txt
On the “unhappy” VDA’s import the counters in
c:\ lodctr.exe /R:C:\counters.txt
A while posted this on the forums luckily Michael in citrix was able to assist with a “full” fix. As mentioned in the thread had a workaround but programmatically have checked the steps outlined and they do work too.
Previously known as folders in the XenApp 6.x environments or earlier. When working in medium / large scale environments generally comes a biting point when applications are better grouped into folders (like files). The simplest way to do this in XenApp 7.x is by doing the following.
– Go into Citrix Studio
– Right click on an application in Studio and select properties
– Select Delivery on the pop-up window
– You will see the application category showing under the icon. Simply create your category there. Whether it be alphabetical eg “A-E Apps” or by type “Administrative apps” and click ok when done