At Synergy San Francisco in May (and re-announced at Synergy Barcelona in October), Citrix introduced Remote PC as part of XenDesktop 5.6 Feature Pack 1 – a new FlexCast model designed to substantially increase workplace productivity and eliminate administration, support, and deployment costs associated with secure connectivity to existing laptop and PC assets.

The compelling piece of Remote PC is that we take advantage of HDX and Citrix Receiver (coupled with SmartAccess in Access Gateway) to provide a superior, secured and controlled experience to cubicle Windows assets.

To see this in action a demonstration is located here: Remote PC Demo

The use case in the demo is that I’ve unshackled myself from the confines of the cubicle during the day, not only the assumptions of a sick day, at night, or regional interruptive event (weather, protests, etc.) situations that typically define “remote access” from outside the DMZ.

Perhaps I’m watching a training video/GotoMeeting presentation at lunch or have meetings down the hall that normally I would have to “pause” working or haul my laptop with me.  Instead of hallway grabs “hey can you come here for a second?”, I just bring my BYO with me to their location and show them.

Another value to Remote PC is that you may be considering VDI or Hosted Shared FlexCast deployment models, so I have a question for you:  Why make your users wait for the delayed benefit of the same HDX and Receiver experience?  Bring it to them right now with Remote PC and build out the infrastructure in stages.  Your users will already be happily using HDX and Receiver by the time their PC/Laptop is replaced permanently.

Perhaps you wish to remain using local images (PC/laptop refresh) and deploy Remote PC on its own merit.  The vast majority of customers that are deploying Remote PC are using it in this way today; to replace mid-2000’s style telework “remote access” connection models.  These customers now have even more added value, in that they also own access to our other fantastic FlexCast solutions at their fingertips to deploy and migrate images, apps, and profiles to VDI, Hosted Shared, XenClient Enterprise and XenApp…when they are ready.  We have a great partner and services network to assist with that, using AppDNA as a key technology to enable it.

However, it’s not just about the user experience and value to FlexCast that Remote PC brings, it’s also the administration and support experience.

One of the most important functionalities released alongside XD 5.6 FP1, is the Remote PC Service; the point of this blog.

From a configure and deploy viewpoint, to create the link for the Remote PC asset in Citrix Receiver as seen in the demo, you must do 3 things in the XenDesktop Studio:

  1. Create the Catalog and add the machine to it
  2. Create the Assignment and add the new machine from the Catalog to it
  3. Assign the user to the machine itself (this is the part when it shows up in the Receiver for that user)

This would certainly mean a lot of clicks and manual administration per user in order to deploy to 10,000’s of Remote PC assets.  The Remote PC Service focuses on eliminating that administrative overhead.

It is a Windows service that is installed on the XenDesktop 5.6 broker that leverages three components:

  1. RemotePCAccess.ps1 file
  2. RemotePCAccessConfig.xml
  3. RemotePCService.exe

…then ultimately being controlled (enabled/disabled) via the Services.MSC at the broker.

To begin with, download the Remote PC Service installer from here:

Run the MSI on a single broker in the XenDesktop 5.6 site (a second one for redundancy but disabled), all components are then installed.  This takes about 30 seconds.  Once it is installed, it’s ready to perform the functionality, but not actually doing anything until you modify the XML file.  This is required to make it work.

Simply “Stop” the Remote PC Service, and edit the XML file in c:\Program Files (x86)\Citrix\Remote PC Service with a “wide open” configuration listed here: …near the end under “Important: To enable…” section.  Also listed are various ways where you can manipulate based on groups and OU.

Note:  Today there is a current limitation on a single XML+Service broker that will only add Machines to one specific Catalog and Assignment based on the XML file settings. You can work around this by having multiple XML files, then swap them out or, manually edit the XML file to “time” your deployment by department and use the OU setting together, or have a separate broker in the same site with a different configuration XML using the OU setting, or a different broker for each catalog group.  We look to improve this limitation in the future.

Once you’ve made the basic setting change, the Remote PC Service will perform the following:

  1. Per XenDesktop Site, creates the Catalog and Assignment based on the XML settings – if they already exist, skip
  2. Within the XD Site, look for “soft registered” machines (these are machines that are registered, but have no “home” yet), and add them to the preconfigured Catalog sourced from the XML file
  3. Adds that machine to the preconfigured Assignment sourced from the XML file, and assigns as a resource available for a user
    1. The Service cannot detect if the machine is physical or virtual, so if combining the Service with a VDI infrastructure, your best bet is to also configure using the OU method.
  4. The last step is user assignment.  This is done by having the user login locally where the Virtual Desktop Agent (VDA) from XD 5.6 FP1 is installed.  Once they have done that a single time, the PC or laptop will show up in Receiver everywhere for that user!  It is important that you use the Feature Pack 1 VDA, as previous VDAs were not coded with Remote PC.  The XenDeskop56.ISO has an older VDA, so make sure to use the “Updated” VDA.

Now you have a functional auto-discovery, auto-registering and auto-assigning solution in about 2 minutes for every user without having to manage it – you just have to deliver the 5.6 FP1 VDA by ESD, GPO, self-service, or via manual deployment.

From a helpdesk support perspective, they will now just be aligning their support with very similar and familiar XenApp-like issues:  general outside network connectivity and Receiver interaction behavior – not specialized VPN tunnels, DMZ appliance configurations, other protocols on the network, and network authentication control. This will help save on support costs from an administration, deployment and support perspective (plus if you feel like you have a plan to disable other protocols that can be susceptable to common attack vectors (virus’, malware, hackers), this may help achieve that).

Lastly, one request that has come in from time to time, is to be able to only assign one user per Remote PC resource.  Today the Service automatically assigns every user that physically successfully logs in to the local PC/laptop where the VDA is installed (and the Remote PC Service is running) to that resource.  To work around this, you can change the RemotePCAccess.ps1 file to “auto-assign on first use, single user only” – by making the following changes:

Warning Problems with the Remote PC service may occur if you modify the RemotePCAccess.ps1 file incorrectly. These problems may require you to reinstall the Remote PC Service. Modify at your own risk.

  1. Stop the Remote PC Service
  2. Make a backup of the RemotePCAccess.ps1 file
  3. Make the following edits in the file:

At line# 238 –

# is this user already assigned to this machine?
 $assignedUsers = @( Get-BrokerUser -MachineUid $dk.MachineUid | %{ $_.SID } )
 if ( $assignedUsers <strong>-contains $dk.SessionUserSid </strong>)

…change to…
# is any user already assigned to this machine?
 $assignedUsers = @( Get-BrokerUser -MachineUid $dk.MachineUid | %{ $_.SID } )
 if ( $assignedUsers <strong>–ne $null</strong>)

Save the file and start the Remote PC Service   Note: you will have to manually remove users assigned to resources prior to enabling this edit.  It does not “cleanse” users from resources already assigned.

Now, after you implement this change you may still notice that when you check to make sure it is working, the Studio shows “In Use” and lists two different users. You need to “right-click” on the machine in the Studio and select “Change User” this will actually show you the assignment (the authorization for the HDX session via Remote PC).  The Studio view shows a combination of the local and remote session if the local session is in use by someone other than the remote session assigned user account.

Thanks for reading!