ICA Connection Stuck at “Connection in Progress” on StoreFront

When you capture a network trace while the endpoint is attempting to connect over the ICA session, you will notice a TCP-SYN retransmissions on 2598 for that server.

The VDA has two network cards: Legacy and Synthetic. The ICA file which the endpoint receives, is listing an IP Address of the Legacy Adapter (which is non-routable from external network). Hence the ICA connection fails.

We would ideally like to have an address in the ICA file which is reachable from the Internet and the Legacy network adapter is required to communicate with the PVS server initially, mostly in the same subnet. If over the legacy network adapter, we disable Gateway and attempt to connect again, this time ICA should come up with the synthetic adapter’s address.

As per the PVS design, PVS Legacy NIC should have a 169.x.x.x address post the bootup completion. PVS uses the Synthetic network adapter for the communication with the PVS server.

Related:

  • No Related Posts

Unable to Configure Citrix App Layering ELM PVS Connector

The App Layering Agent (PVS Agent) on the PVS server is registered with the App Layering ELM virtual appliance, and the PVS Server enumerates on the App Layering PVS connector screen. However, clicking “check credentials” an error is displayed stating that the ELM cannot use the credentials on the PVS server since it does not have the rights to execute remote PowerShell commands.

You may also see “Cannot communicate with PVS on server ‘ServerName’. Please ensure that the PVS Powershell Snapin has been registered”.

Related:

  • No Related Posts

Devices created with XDSW to Citrix Cloud Result in Devices being left in initial zone 

Short Term Mitigation:

Manually move the devices from the initial zone after creation with the Powershell SDK until upgrade to 1912+ PVS is completed.

Resolution:

Upgrade pvs console and server to a version 1909+

Related:

The wrong database version is being used. Found version: xx Expected version number: xx

An example: After upgrade as per: https://docs.citrix.com/en-us/provisioning/7-8/upgrade/pvs-upgrade-servers.html – In the configuration wizard, if we use “Join to an existing farm” instead of “Farm is already configured” then due to this we will not be asked for a DB upgrade and the software will be upgraded to 7.8 but the DB version will still be the same – ’11’ (however, it should be 40).

The same will be for all other PVS versions too.

FYI PVS software versions and their DB versions:

PVS 7.12 – 70

PVS 7.11 – 60

PVS 7.9 – 50

PVS 7.8 – 40

Related:

  • No Related Posts

Provisioning Server 7.6: Error- “vDisk is locked. 0xffff8017”

Scenario 1: Basic Troubleshooting

To resolve this issue, complete the following procedure:

  1. Shutdown all target devices streaming the vDisk.
  2. Refresh the console.
  3. If any target devices still show as connected to the vDisk, mark them down from the PVS console.
  4. Right click the vdisk and choose manage locks.
  5. Making sure all device are selected click Remove Locks.
  6. Check the console on any other PVS servers in the farm and ensure that they do not show the vdisk as locked.

Scenario 2: Core Troubleshooting

User-added image

As a fix , remove everyone that is still connected and running using that vDisk. So there is an outage involved in this procedure for users using that image.

1. Users that are still connected should save their work and log off. This is going to be a complete outage for anyone that uses that particular image.

2. Go to your DDC and put the Desktop Group in maintenance mode. This will prevent the DDC from attempting to start up VMs and potentially lock up the vDisk while working on it. Then Force Shutdown on all the VMs. Verify in hypervisor console they are all shutdown.

3. RDP to a single PVS server and in the PVS Console, go to the Store and right click on your vDisk. Verify there is no gold lock next to the vDisk. If there is clear all the locks. Then click “Unassign from Selected Devices(s)…”

User-added image

4. Make sure all your VMs are checked and click Unassign

User-added image
5. If you have maintenance versions, you should preferably merge them at this point. Use the “Merged Base – Last base + all updates from that base” option so you get a nice single .vhd file.

User-added image

6. Once you have verified you have a single .vhd file you can rename it if you want. Copy that .vhd file and the associated .pvp file to all your other PVS stores. Get all your PVS servers in sync and check the replication status. They should all have blue dots:

User-added image

7. Now go back to your Store view and right click on your vDisk. You should now see an option to Delete. Click it.

User-added image

8. MAKE SURE you DO NOT check the Delete the associated VHD files check box. Just click “Yes” only. All it does is delete it from the PVS database. It will not touch anything in your Store this way. Do this on all your PVS servers.

User-added image

9. Now right click on “Store” and click “Add or Import Existing vDisk…”

User-added image

10. Click Search to search your Store for vDisks. Only check that new .vhd you had created in step 5 and 6 above. Then click Add once it stops being grayed out.

User-added image

11. It will be imported in Private mode every time. Go ahead and switch it to Standard mode. Also do check the Cache type, Enable Active Directory machine account password management, and KMS on the Microsoft Volume Licensing tab because all that will likely not carry over for you.

12. Now go to your Device Collection. In this example, we have 20+ Devices that need this particular vDisk golden image. We are not going to modify each one. So we will set the vDisk on the first VM only.

User-added image

13. Now right click that VM you just set and click “Copy Device Properties…”

User-added image

14. Hit “Clear All”, then check “vDisk Assignment” only, then hit Copy.

User-added image

15. Now just highlight all your other VMs, right click in the highlighted area, and click Paste. Instantly all your VMs will be assigned that vDisk.

User-added image

16. Now boot up a couple of VMs and verify the “Vdisk is locked. 0xffff8017” error is gone. Then disable Maintenance mode on your DDC and you’re back in business.

17. You can delete all those old .vhd, .avhd, and .pvp files from old versions of your image if you like or archive them somewhere.

Related:

PVS 7.13: XenServer PVS-Accelerator Introduction and Requirements

Note: This feature is only available in XenServer 7.1 and PVS 7.13 or later.

XenServer PVS-Accelerator feature offers additional capabilities for customers using XenServer and Citrix Provisioning Services (PVS). With this feature, the read requests from a PVS target device can now be cached on each XenServer host, in a shared tiered read-cache.


How PVS-Accelerator Works

PVS-Accelerator employs a Proxy mechanism that resides in the Control Domain (dom0) of XenServer.

When this feature is enabled, PVS target device (VM) read requests (that is, boot from vDisk, launch an application, and so on) are cached directly on the XenServer host machine (that is, in physical memory and/or a storage repository).

When subsequent VMs (on the same XenServer host) boot from the same vDisk or launch the same application, the vDisk (contents) is streamed directly from cache instead of from the PVS Server. Removing the need to stream from the PVS Server reduces network utilization and processing on the server considerably, resulting in a substantial improvement in VM performance.

User-added image

When a VM with PVS-Accelerator enabled is started, PVS-Accelerator will create flow rules on Open vSwitch (OVS). In this way, all packets from this VM to PVS server will be redirected to PVS-Accelerator.

  1. PVS-Accelerator then checks if this packet is a read request of vDisk image:
    1. If it is not a read, PVS-Accelerator passes it straight back to the OVS;
    2. If it is a read, PVS-Accelerator processes it to see whether it has the data in the cache.
      1. If it’s a cache hit, PVS-Accelerator will return the cached data.
      2. If it’s not a cache hit, PVS-Accelerator passes it back to OVS and then the PVS server. The OVS flow rules work in both directions, so packets from the PVS server going to the VM are also redirected to PVS-Accelerator. If it is a read response coming from the server, PVS-Accelerator populate the cache with a certain PVS site, disk-id, block size and block contents.
  2. There are two Cache Storage modes:
    1. Memory only: explicitly uses Control Domain (Dom0) Memory
    2. On Storage Repository: implicitly uses available Dom0 memory and disk
  3. Cache manager (sub system of PVS-Accelerator) will monitor available space in Cache SR. If PVS Read cache SR is near full (90%) eviction algorithm will kick in and evict least recently used data.

XenServer PVS-Accelerator capabilities:

  • Caches reads from vDisks but not writes or reads from a write cache.
  • Supports vDisks with any non-persistent write cache type. It does not work for “Cache on Server, Persistent” and “Cache on device hard disk persisted” write cache type.
  • Caches vDisks with the access mode Standard Image. It does not work for vDisks with the access mode Private Image.
  • Caches devices that are marked as type Production. Devices marked as type Maintenance are not cached.

Prerequisites

  • PVS-Accelerator feature requires XenServer 7.1 and PVS 7.13
  • PVS-Accelerator is available for XenServer Enterprise Edition customers or those who have access to XenServer through their XenDesktop/XenApp entitlement
  • PVS-Accelerator feature leverages capabilities of Open vSwitch (OVS) and is therefore not available on hosts that use Linux Bridge as the network backend.
  • PVS-Accelerator Cache works only on the first virtual network interface (VIF) of a cached VM. Therefore, the first VIF should be used for connecting the PVS Server for the PVS-Accelerator caching to work.

Additional Resources

Related:

How to enable HTTPS file transfers to Citrix PVS in V4

By default the PVS connector uses HTTP over port 3009 to transfer Layered Images from the ELM’s local repository to the selected PVS Store. HTTP is used by default since it is roughly 3X faster then HTTPS when publishing multiple Layered Images at the same time.

The PVS connector can be configured to use HTTPS over port 3509 if a customer desires, and understands the performance penalty.

Here are the steps to enable HTTPS transfers for the PVS Connector:

1.Log on to the ELM as root, using SSH

2.Edit the PVS connector config file: /usr/local/lib/node_modules/unidesk-pvs-connector/config.json

3.Change the “useHttpsFileTransfer” setting to true

4.Save the file

5.Reboot the ELM.

The ELM contains three text editors: EMACS, vi and nano. If you are not familiar with any of them, nano is probably the most intuitive editor. Or you could use an SCP client to download the file, edit it in a Linux-aware editor (Wordpad will work, normal Notepad will lose line separation), and upload the result to the ELM before rebooting.

Related:

Provisioning Services and Daylight Saving Time

During a Target Device (TD) boot or reboot, after Daylight Saving Time (DST) but prior to any vDisk maintenance, you might notice that the TD system time is not consistent with the system time of the PVS Server. A user has reported the inability to log on to the domain.

Log on with a local user account and you can notice that the system time on the TD is not equal to that of the PVS Server or the Domain Controllers. Variety of system events might be logged in Eventviewr.exewith reference to GPO processing failures, domain trust relationship and Kerberos errors, and Windows time sync events.

Update: DST handling improvements were introduced from PVS 6.1.21 and 7.1.3 and contained in all subsequent 7.x releases.

However these improvements did not entirely handle all DST changes in all customers environments, and opening VDisk in private mode or similar re-configurations may still be required.

Related: