Citrix Blogs

Lessons from the Field: Remote PC Access

Rob Zylowski

With the onset of the COVID-19 pandemic and the increased demand it has created for all organizations to provide ways for employees to work remotely, many of us in Citrix Consulting have been working long days and nights to help our customers provide remote access to their users.

For many customers who had sufficient capacity in their existing virtualization environments, it was fairly easy to ramp up to handle more users. This may have involved adding delivery controllers and making their StoreFront servers bigger or adding a few more Citrix ADCs.

But what if that additional capacity was not readily available? Some customers have been using public clouds to ramp up capacity, and now even public cloud vendors are feeling the stress of this excess demand.

As it turns out, Citrix has another solution — Remote PC Access — that many customers have deployed in vast numbers. Remote PC Access allows remote access to an employee’s physical desktop at work, accessed safely and securely over the internet like other Citrix remote-access solutions. In this architecture, a Citrix Virtual Delivery Agent is installed on each employee’s work PC. Employees are assigned to their PC in Citrix Studio and can then access the PC using a web browser or the Citrix Workspace app. This solution can be set up for customers who use Citrix Cloud or an on-premises Citrix solution and has many advantages, including:

The current crisis has made Remote PC Access very popular, and this is the first time I have worked with the solution. I learned a lot about it quickly, and I wanted to share that knowledge with our customers.

Remote PC Access Features

First, let’s look at some of the main features of Remote PC Access.

  1. Remote PC Access supports auto-addition of desktops into a machine catalog based on OU membership. If enabled, when a Remote PC Access VDA registers with a Controller or Connector, the server will add it into the Remote PC Access Catalog if the desktop’s Active Directory OU matches one of the defined OUs in the Machine Catalog.
  2. Remote PC Access supports auto-addition of the desktops into an “associated” Delivery Group. Using this feature, the desktops will automatically be added to the Delivery Group when they are added to the Catalog. The association is added when you create the Delivery Group and cannot be changed using the Studio UI.
  3. Remote PC Access supports auto-assignment of users who log on locally to a registered Remote PC Access VDA. If enabled, all users who log on locally and who are included in any of the Delivery Group Desktop Assignment Rules will be assigned to the VDA.

These features are meant to ease the deployment of Remote PC Access. Still, in many of the deployments we have done recently, they have not been practical to implement. First of all, the desktops are often spread across many OUs in Active Directory. You can add multiple OUs, but if you have hundreds, keeping track of them can be difficult. This option can be defined at a higher level and traverse sub OUs. Desktops will only be added when the VDA registers with the Controller or Connector. So, if you do not install the VDA software on a desktop, it will never be added, even if it is within the defined OU’s.

Desktop/User Assignments

Another issue with auto-assignment is that users need to be in the office so they can log in to their desktop after the VDA software is installed. Since all the recent deployments are in response to COVID-19, and users are no longer in the office, this process doesn’t work. The answer to this is to define a mapping between desired desktops and users, then import that mapping into Citrix Studio. The import can be performed using the Studio UI for on-premises deployments or with a PowerShell script for both on-premises and Citrix Cloud deployments. I prefer the PowerShell script option because it can provide better logging.

I created a script that takes a csv input file that maps users to desktops. It adds the desktops to the Machine Catalog and assigns users. It will log success, failure, and errors. It will also create two csv files: one for desktops that could not be added and one for users that could not be assigned. The script also allows assigning multiple users to a desktop. The script is available on GitHub and includes full documentation. The script is pretty fast: It takes about 20 minutes to load 10,000 machines and user assignments.

To use the Studio UI-based import, see the Citrix Knowledge Base article CTX129580. For that approach you have to format the csv file as shown below:

There are alternate formats that will work, also. See the Knowledge Base article for more details. Any errors are displayed on screen, which is why if you are loading thousands of machines/users, I would use the script so you have a separate log file to review.

Getting the desktops and users into a Catalog is easy. The hard part is knowing which users should be assigned to which desktops. If your organization keeps track of this, you are way ahead of the game. In some of the organizations I have worked with recently, we were able to get this from an SCCM report. SCCM has a report called “User device affinity associations per collection,” which attempts to figure out, based on logons over the last seven days, who the user of each desktop is. This has worked pretty well, but it’s not perfect. One of the deployments had only 10,000 assignments for 17,000 desktops.

If you allow it in your organization, you could do a similar thing with PowerShell scripts using Get-Winevent. The script would look through the event log on each desktop for event id 4624 with type 2 logins (interactive) whose LogonProcessName is “User32.” The fastest way I found to run this is using a “-filterXpath” query as shown below:

Please note the space after the “User32.” It took me a while to find that. You would want to run this against a list of all the desktops that you are missing assignments for and figure out how you want to handle when multiple users have logged on. I have created a script using this technique that can be used to connect to each desktop and capture logons. The script has not been tested yet in production environments and is not supported by Citrix. See the script documentation for warnings and please test well before using. You can download the script here. If you give the script a try, I would love to hear how it worked for you or if you had problems with it. Please post results in the comments below so I can make it better if it needs work.

User Assignment

There is more to know about user assignments that may be important for how you want to handle them. If you do not configure a “Desktop Assignment Rule” in your Delivery Group, then there will be no automatic assignment from users logging on locally to the desktop. Then the assignment you make with a script, or manually, will be the only assignment made. If you do use a Desktop Assignment Rule, you can restrict assignments to just one or more Active Directory groups or allow everyone with access to the Delivery Group to be assigned. If a user meets the criteria and logs on locally to the desktop after the Remote PC Access VDA is installed, they will be assigned to the desktop.

By default, all users who logon locally and pass the assignment rule will be assigned. This, of course, can cause issues for the work from home model because the first user to open a session will be the only one that can use that computer until they log off. Other assigned users will see an error like this:

However, if there is no assignment rule created, then there will be no auto-assignments which can be useful. The assignment you make in Studio directly or via script will be the only assignment made.

Another useful thing to know is that for on-premises deployments, multiple user assignments can be disabled. This would allow for the use of local assignments for local logons. But only the first user to logon will be assigned. See the Citrix Knowledge Base article CTX137805 for details.

Installation of the VDA

Another aspect of the Remote PC Access deployment that can be challenging is installing the Remote PC Access Virtual Delivery Agent on all the desktops. Unlike installing the VDA on an image where you only have to do it once, the installation for Remote PC Access has to happen many times. The installation, in this case, is normally performed by package installation managers like Microsoft’s System Center Configuration Manager.

One thing that we found is that the installation was much more successful when the prerequisites are installed first, then the VDA. It also worked more reliably when there was a reboot added after each prerequisite was installed. Lastly, we have seen that installations on Windows 10 have been more reliable than Windows 7. This may be due to the fact that the prerequisites are normally already installed.

These are the prerequisites for the two latest LTSR VDA versions.

1912 VDA

7.15 VDA

This article has detailed directions for deploying the VDA with a package manager like SCCM.

Key Takeaways

The ability to deploy Remote PC Access has benefited many customers during the COVID-19 crisis, where all IT organizations were presented with demanding new remote access requirements over night. Remote PC Access provides instant capacity for organizations that may not have extra capacity in the data center and it allows for secure access through Citrix ADC gateways or the Citrix Gateway service without requiring a complex-to-setup, network-based, VPN solution. That does not mean deploying any remote access technology is simple, but I hope that by providing a better understanding of how Remote PC Access works and what we have learned about how it can be deployed, our customers will have an easier time deploying it to their users that are now working from home.

This software / sample code is provided to you “AS IS” with no representations, warranties or conditions of any kind. You may use, modify and distribute it at your own risk. CITRIX DISCLAIMS ALL WARRANTIES WHATSOEVER, EXPRESS, IMPLIED, WRITTEN, ORAL OR STATUTORY, INCLUDING WITHOUT LIMITATION WARRANTIES OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE, TITLE AND NONINFRINGEMENT. Without limiting the generality of the foregoing, you acknowledge and agree that (a) the software / sample code may exhibit errors, design flaws or other problems, possibly resulting in loss of data or damage to property; (b) it may not be possible to make the software / sample code fully functional; and (c) Citrix may, without notice or liability to you, cease to make available the current version and/or any future versions of the software / sample code. In no event should the software / code be used to support of ultra-hazardous activities, including but not limited to life support or blasting activities. NEITHER CITRIX NOR ITS AFFILIATES OR AGENTS WILL BE LIABLE, UNDER BREACH OF CONTRACT OR ANY OTHER THEORY OF LIABILITY, FOR ANY DAMAGES WHATSOEVER ARISING FROM USE OF THE SOFTWARE / SAMPLE CODE, INCLUDING WITHOUT LIMITATION DIRECT, SPECIAL, INCIDENTAL, PUNITIVE, CONSEQUENTIAL OR OTHER DAMAGES, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGES. Although the copyright in the software / code belongs to Citrix, any distribution of the code should include only your own standard copyright attribution, and not that of Citrix. You agree to indemnify and defend Citrix against any and all claims arising from your use, modification or distribution of the code.

Exit mobile version