Citrix Virtual Apps and Desktops

Remote PC Access

Note:

You can manage your Citrix Virtual Apps and Desktops deployment using two management consoles: Web Studio (web-based) and Citrix Studio (Windows-based). This article covers only Web Studio. For information about Citrix Studio, see the equivalent article in Citrix Virtual Apps and Desktops 7 2212 or earlier.

Remote PC Access is a feature of Citrix Virtual Apps and Desktops that enables organizations to easily allow their employees to access corporate resources remotely in a secure manner. The Citrix platform makes this secure access possible by giving users access to their physical office PCs. If users can access their office PCs, they can access all the applications, data, and resources they need to do their work. Remote PC Access eliminates the need to introduce and provide other tools to accommodate teleworking. For example, virtual desktops or applications and their associated infrastructure.

Remote PC Access uses the same Citrix Virtual Apps and Desktops components that deliver virtual desktops and applications. As a result, the requirements and process of deploying and configuring Remote PC Access are the same as those required for deploying Citrix Virtual Apps and Desktops for the delivery of virtual resources. This uniformity provides a consistent and unified administrative experience. Users receive the best user experience by using Citrix HDX to deliver their office PC session.

The feature consists of a machine catalog of type Remote PC Access that provides this functionality:

  • Ability to add machines by specifying OUs. This ability facilitates the addition of PCs in bulk.
  • Automatic user assignment based on the user that logs into the office Windows PC. We support single user and multiple users assignments. By default, we automatically assign multiple users to the next unassigned machine. To restrict automatic assignment to a single user, sign in to Web Studio, go to Settings and turn off the Enable automatic assignment of multiple users for Remote PC Access setting.

Citrix Virtual Apps and Desktops can accommodate more use cases for physical PCs by using other types of machine catalogs. These use cases include:

  • Physical Linux PCs
  • Pooled physical PCs (that is, randomly assigned, not dedicated)

Notes:

For details on the supported OS versions, see the system requirements for the VDA for single-session OS and Linux VDA.

For on-premises deployments, Remote PC Access is valid only for Citrix Virtual Apps and Desktops Advanced or Premium licenses. Sessions consume licenses in the same way as other Citrix Virtual Desktops sessions. For Citrix Cloud, Remote PC Access is valid for Citrix DaaS (formerly Citrix Virtual Apps and Desktops service) and Workspace Premium Plus.

Considerations

While all the technical requirements and considerations that apply to Citrix Virtual Apps and Desktops in general also apply to Remote PC Access, some might be more relevant or exclusive to the physical PC use case.

Important:

Windows 11 physical systems (and some running Windows 10) include virtualization-based security features that result in the VDA software’s incorrectly detecting them as virtual machines. To mitigate this issue, you have the following options:

  • Use the “/physicalmachine” option along with the “/remotepc” option as part of the VDA command-line installation

  • Add the following registry value after the VDA is installed if the aforementioned option was not used HKEY_LOCAL_MACHINE\SOFTWARE\Citrix\PortICA

    • Name: ForceEnableRemotePC
    • Type: DWORD
    • Data: 1

Deployment considerations

While planning the deployment of Remote PC Access, make a few general decisions.

  • You can add Remote PC Access to an existing Citrix Virtual Apps and Desktops deployment. Before choosing this option, consider the following:
    • Are the current Delivery Controllers or Cloud Connectors appropriately sized to support the additional load associated with the Remote PC Access VDAs?
    • Are the on-premises site databases and database servers appropriately sized to support the additional load associated with the Remote PC Access VDAs?
    • Will the existing VDAs and the new Remote PC Access VDAs exceed the number of maximum supported VDAs per site?
  • You must deploy the VDA to office PCs through an automated process. The following are the available options:
  • Review the Remote PC Access security considerations.

Note:

When designing Remote PC Access, you must consider the number of physical monitors connected to the GPU on the remote PC and currently configured/operating. Even if the monitor is not used in the Citrix session, but is detected by the GPU, the monitor’s presence is counted towards the maximum supported monitor limit by the GPU.

Machine catalog considerations

The type of machine catalog required depends on the use case:

  • Remote PC Access machine catalog
    • Windows dedicated PCs
    • Windows dedicated multi-user PCs. This use case applies to physical office PCs that multiple users can access remotely in different shifts.
    • Pooled Windows PCs. This use case applies to physical PCs that multiple random users can access, such as computer labs.
  • Single-session OS machine catalog
    • Static - Dedicated Linux PCs
    • Random - Pooled Linux PCs

Once you identify the type of machine catalog, consider the following:

  • A machine can be assigned to only one machine catalog at a time.
  • To facilitate delegated administration, consider creating machine catalogs based on geographic location, department, or any other grouping that eases delegating administration of each catalog to the appropriate administrators.
  • When choosing the OUs in which the machine accounts reside, select lower-level OUs for greater granularity. If such granularity is not required, you can choose higher-level OUs. For example, in the case of Bank/Officers/Tellers, select Tellers for greater granularity. Otherwise, you can select Officers or Bank based on the requirement.
  • Moving or deleting OUs after being assigned to a Remote PC Access machine catalog affects VDA associations and causes issues with future assignments. Therefore, make sure to plan accordingly so that OU assignment updates for machine catalogs are accounted for in the Active Directory change plan.
  • If it is not easy to choose OUs to add machines to the machine catalog because of the OU structure, you don’t have to select any OUs. You can use PowerShell to add machines to the catalog afterward. User auto-assignments continue to work if the desktop assignment is configured correctly in the Delivery Group. A sample script to add machines to the machine catalog along with user assignments is available in GitHub.
  • Integrated Wake on LAN is available only with the Remote PC Access type machine catalog.

Linux VDA considerations

These considerations are specific to the Linux VDA:

  • Use the Linux VDA on physical machines only in non-3D mode. Due to limitations on NVIDIA’s driver, the local screen of the PC cannot be blacked out and displays the activities of the session when HDX 3D mode is enabled. Showing this screen is a security risk.

  • Use machine catalogs of type single-session OS for physical Linux machines.

  • Automatic user assignment is not available for Linux machines.

  • If users are already logged on to their PCs locally, attempts to launch the PCs from StoreFront fail.

  • Power saving options are not available for Linux machines.

Technical requirements and considerations

This section contains the technical requirements and considerations for physical PCs.

  • The following are not supported:
    • KVM switches or other components that can disconnect a session.
    • Hybrid PCs, including All-in-One and NVIDIA Optimus laptops and PCs.
    • Dual boot machines.
  • Connect the keyboard and mouse directly to the PC. Connecting to the monitor or other components that can be turned off or disconnected, can make these peripherals unavailable. If you must connect the input devices to components such as monitors, do not turn those components off.
  • The PCs must be joined to an Active Directory Domain Services domain.
  • Secure Boot is supported on Windows 10 and Windows 11 only.
  • The PC must have an active network connection. A wired connection is preferred for greater reliability and bandwidth.
  • If using Wi-Fi, do the following:
    1. Set the power settings to leave the wireless adapter turned on.
    2. Configure the wireless adapter and network profile to allow automatic connection to the wireless network before the user logs on. Otherwise, the VDA does not register until the user logs on. The PC isn’t available for remote access until a user has logged on.
    3. Ensure that the Delivery Controllers or Cloud Connectors can be reached from the Wi-Fi network.
  • You can use Remote PC Access on laptop computers. Ensure that the laptop is connected to a power source instead of running on the battery. Configure the laptop power options to match the options of a desktop PC. For example:
    1. Disable the hibernate feature.
    2. Disable the sleep feature.
    3. Set the close lid action to Do Nothing.
    4. Set the “press the power button” action to Shut Down.
    5. Disable video card and NIC energy-saving features.
  • Remote PC Access is supported on Surface Pro devices with Windows 10. Follow the same guidelines for laptops mentioned previously.
  • If using a docking station, you can undock and redock laptops. When you undock the laptop, the VDA reregisters with the Delivery Controllers or Cloud Connectors over Wi-Fi. However, when you redock the laptop, the VDA doesn’t switch to use the wired connection unless you disconnect the wireless adapter. Some devices provide built-in functionality to disconnect the wireless adapter upon establishing a wired connection. The other devices require custom solutions or third-party utilities to disconnect the wireless adapter. Review the Wi-Fi considerations mentioned previously.

    Do the following to enable docking and undocking for Remote PC Access devices:

    1. In the Start menu, select Settings > System > Power & Sleep, and set Sleep to Never.
    2. Under the Device Manager > Network adapters > Ethernet adapter go to Power Management and clear Allow the computer to turn off this device to save power. Ensure that Allow this device to wake the computer is checked.
  • Multiple users with access to the same office PC see the same icon in Citrix Workspace. When a user logs on to Citrix Workspace, that resource appears as unavailable if already in use by another user.
  • Install the Citrix Workspace app on each client device (for example, a home PC) that accesses the office PC.

Configuration sequence

This section contains an overview of how to configure Remote PC Access when using the Remote PC Access type machine catalog. For information on how to create other types of machine catalogs, see the Create machine catalogs.

  1. On-premises site only - To use the integrated Wake on LAN feature, configure the prerequisites outlined in Wake on LAN.

  2. If a new Citrix Virtual Apps and Desktops site was created for Remote PC Access:

    1. Select the Remote PC Access Site type.
    2. On the Power Management page, choose to enable or disable power management for the default Remote PC Access machine catalog. You can change this setting later by editing the machine catalog properties. For details on configuring Wake on LAN, see Wake on LAN.
    3. Complete the information on the Users and Machine Accounts pages.

    Completing these steps creates a machine catalog named Remote PC Access Machines and a Delivery Group named Remote PC Access Desktops.

  3. If adding to an existing Citrix Virtual Apps and Desktops site:

    1. Create a machine catalog of type Remote PC Access (Operating System page of the wizard). For details on how to create a machine catalog, see Create machine catalogs. Make sure to assign the correct OU so that the target PCs are made available for use with Remote PC Access.
    2. Create a Delivery Group to provide users access to the PCs in the machine catalog. For details on how to create a Delivery Group, see Create Delivery Groups. Make sure to assign the Delivery Group to an Active Directory group that contains the users that require access to their PCs.
  4. Deploy the VDA to the office PCs.

    • We recommend using the single-session OS core VDA installer (VDAWorkstationCoreSetup.exe).
    • You can also use the single-session full VDA installer (VDAWorkstationSetup.exe) with the /remotepc/physicalmachine option, which achieves the same outcome as using the core VDA installer.

      Note:

      For RemotePC installation, use /physicalmachine argument with /remotepc for VDA to behave as expected in certain user scenarios.

    • Consider enabling Windows Remote Assistance to allow help desk teams to provide remote support through Citrix Director. To do so, use the /enable_remote_assistance option. For details, see Install using the command line.
    • To be able to see logon duration information in Director, you must use the single-session full VDA installer and include the Citrix User Profile Management WMI Plugin component. Include this component by using the /includeadditional option. For details, see Install using the command line.
    • For information about deploying the VDA using SCCM, see Install VDAs using SCCM.
    • For information about deploying the VDA through deployment scripts, see Install VDAs using scripts.

    After you successfully complete steps 2–4, users are automatically assigned to their own machines when they log in locally on the PCs.

  5. Instruct users to download and install Citrix Workspace app on each client device that they use to access the office PC remotely. Citrix Workspace app is available from https://www.citrix.com/downloads/ or the application stores for supported mobile devices.

Features managed through the registry

Caution:

Editing the registry incorrectly can cause serious problems that might require you to reinstall your operating system. Citrix cannot guarantee that problems resulting from the incorrect use of Registry Editor can be solved. Use Registry Editor at your own risk. Be sure to back up the registry before you edit it.

Disable multiple user auto-assignments

On each Delivery Controller, add the following registry setting:

HKEY_LOCAL_MACHINE\Software\Citrix\DesktopServer

  • Name: AllowMultipleRemotePCAssignments
  • Type: DWORD
  • Data: 0

Sleep mode (minimum version 7.16)

To allow a Remote PC Access machine to go into a sleep state, add this registry setting on the VDA, and then restart the machine. After the restart, the operating system power saving settings are respected. The machine goes into sleep mode after the preconfigured idle timer passes. After the machine wakes up, it reregisters with the Delivery Controller.

HKEY_LOCAL_MACHINE\SOFTWARE\Citrix\PortICA

  • Name: DisableRemotePCSleepPreventer
  • Type: DWORD
  • Data: 1

Session management

By default, a remote user’s session is automatically disconnected when a local user initiates a session on that machine (by pressing CTRL+ATL+DEL). To prevent this automatic action, add the following registry entry on the office PC, and then restart the machine.

HKEY_LOCAL_MACHINE\SOFTWARE\Citrix\PortICA\RemotePC

  • Name: SasNotification
  • Type: DWORD
  • Data: 1

By default, the remote user has preference over the local user when the connection message is not acknowledged within the timeout period. To configure the behavior, use this setting:

HKEY_LOCAL_MACHINE\SOFTWARE\Citrix\PortICA\RemotePC

  • Name: RpcaMode
  • Type: DWORD
  • Data:
    • 1 - The remote user always has preference if he or she does not respond to the messaging UI in the specified timeout period. This behavior is the default if this setting is not configured.
    • 2 - The local user has preference.

The timeout for enforcing the Remote PC Access mode is 30 seconds by default. You can configure this timeout but do not set it lower than 30 seconds. To configure the timeout, use this registry setting:

HKLM\SOFTWARE\Citrix\PortICA\RemotePC

  • Name: RpcaTimeout
  • Type: DWORD
  • Data: number of seconds for timeout in decimal values

When a user wants to forcibly get the console access: The local user can press Ctrl+Alt+Del twice in a gap of 10 seconds to get local control over a remote session and force a disconnect event.

After the registry change and machine restart, if a local user presses Ctrl+Alt+Del to log on to that PC while it is in use by a remote user, the remote user receives a prompt. The prompt asks whether to allow or deny the local user’s connection. Allowing the connection disconnects the remote user’s session.

Session management logging

Remote PC Access now has logging capabilities that log when someone tries to access a PC with an active ICA session. This allows you to monitor your environment for unwanted or unexpected activity and be able to audit such events if you need to investigate any incidents.

Events are logged using Windows Event Viewer and are in Applications and Services > Citrix > HostCore > ICA Service > Admin.

There are three distinct events that are logged when using Remote PC Access.

Ctrl+Alt+Del event

This event appears when the local user presses Ctrl+Alt+Del on the console keyboard with an active remote session.

Event details

  • Log name: Application and Services
  • Event ID: 43, 44, 45
  • Source: ICA Service

Event ID 43

This event ID appears when the SasNotification registry value does not exist or when the SasNotification registry value is 0.

  • Message:

             Ctrl+Alt+Del has been pressed on the endpoint.
             The session management behavior is set to automatically disconnect the remote session.
    

Event ID 44

This event ID appears when the SasNotification registry value is 1 and the RpcaMode registry value is 1 or the RpcaMode registry value does not exist.

  • Message:

             Ctrl+Alt+Del has been pressed on the endpoint.
             The session management behavior is set to notify the remote user. The user preference is set to remote user.
    

Event ID 45

This event ID appears when the SasNotification registry value is 1 and the RpcaMode registry value is 2.

  • Message:

             Ctrl+Alt+Del has been pressed on the endpoint.
             The session management behavior is set to notify the remote user.
             The user preference is set to local user.
    

Remote session disconnect event

This event appears when the remote session has been disconnected for various reasons.

Event details

  • Log name: Application and Services
  • Event ID: 46, 47, 48
  • Source: ICA Service

Event ID 46

This event ID appears when the remote session has been disconnected and when the SasNotification registry value does not exist or the SasNotification registry value is 0.

  • Message:

             The remote session for <remoteUserName> has been disconnected.
    

Event ID 47

This event ID appears when the remote user agrees to disconnect the session and when the SasNotification registry value is 1 and the RpcaMode registry value is 1 or the RpcaMode registry value is 2 or the RpcaMode registry value does not exist.

  • Message:

             The remote session for <remoteUserName> has been disconnected because the user accepted the request to disconnect the session.
    

Event ID 48

This event ID appears when the remote user does not decline the disconnect request within the specific timeout period and when the SasNotification registry value is 1 and the RpcaMode registry value is 2.

  • Message:

             The remote session for <remoteUserName> has been disconnected because the user did not decline the disconnection request within the configured timeout period (<timeout period>).
    

Ctrl+Alt+Del pressed twice event

This event appears when Ctrl+Alt+Del is pressed twice within 10 seconds.

Event details

  • Log name: Application and Services
  • Event ID: 49
  • Source: ICA Service

Event ID 49

This event ID appears when Ctrl+Alt+Del is pressed twice within 10 seconds.

  • Message:

             The remote session for <remoteUserName> has been forcibly disconnected.
    

Wake on LAN

Remote PC Access supports Wake on LAN, which gives users the ability to turn on physical PCs remotely. This feature enables users to keep their office PCs turned off when not in use to save energy costs. It also enables remote access when a machine has been turned off inadvertently.

With the Wake on LAN feature, the magic packets are sent directly from the VDA running on the PC to the subnet in which the PC resides when instructed by the delivery controller. This allows the feature to work without dependencies on extra infrastructure components or third-party solutions for delivery of magic packets.

The Wake on LAN feature differs from the legacy SCCM-based Wake on LAN feature. For information on the SCCM-based Wake on LAN, see Wake on LAN – SCCM-integrated.

System requirements

The following are the system requirements for using the Wake on LAN feature:

  • Control plane:
    • Citrix DaaS
    • Citrix Virtual Apps and Desktops 2009 or later
  • Physical PCs:
    • VDA version 2009 or later
    • Windows 10 or Windows 11. For supportability details, see the VDA system requirements.
    • Wake on LAN enabled in BIOS/UEFI
    • Wake on LAN enabled in network adapter’s properties within Windows configuration

Configure Wake on LAN

If you are using Citrix Virtual Apps and Desktops on-premises, the configuration of integrated Wake on LAN is only supported using PowerShell.

To configure Wake on LAN:

  1. Create the Remote PC Access machine catalog if you do not have one already.
  2. Create the Wake on LAN host connection if you do not have one already.

    Note:

    To use the Wake on LAN feature, if you have a host connection of the “Microsoft Configuration Manager Wake on LAN” type, create a new host connection.

  3. Retrieve the Wake on LAN host connection’s unique identifier.
  4. Associate the Wake on LAN host connection with a machine catalog.

To create the Wake on LAN host connection:

# Load Citrix SnapIns
Add-PSSnapIn -Name "*citrix*"

# Provide the name of the Wake on LAN host connection
[string]$connectionName = "Remote PC Access Wake on LAN"

# Create the hypervisor connection
$hypHc = New-Item -Path xdhyp:\Connections `
                -Name $connectionName `
                -HypervisorAddress "N/A" `
                -UserName "woluser" `
                -Password "wolpwd" `
                -ConnectionType Custom `
                -PluginId VdaWOLMachineManagerFactory `
                -CustomProperties "<CustomProperties></CustomProperties>" `
                -Persist

$bhc = New-BrokerHypervisorConnection -HypHypervisorConnectionUid $hypHc.HypervisorConnectionUid

# Wait for the connection to be ready before trying to use it
while (-not $bhc.IsReady)
{
    Start-Sleep -s 5
    $bhc = Get-BrokerHypervisorConnection -HypHypervisorConnectionUid $hypHc.HypervisorConnectionUid
}
<!--NeedCopy-->

When the host connection is ready, run the following commands to retrieve the host connection’s unique identifier:

$bhc = Get-BrokerHypervisorConnection -Name "<WoL Connection Name>"
$hypUid = $bhc.Uid
<!--NeedCopy-->

After you retrieve the connection’s unique identifier, run the following commands to associate the connection with the Remote PC Access machine catalog:

Get-BrokerCatalog -Name "<Catalog Name>" | Set-BrokerCatalog -RemotePCHypervisorConnectionUid $hypUid
<!--NeedCopy-->

Design considerations

When you are planning to use Wake on LAN with Remote PC Access, consider the following:

  • Multiple machine catalogs can use the same Wake on LAN host connection.
  • For a PC to wake up another PC, both PCs must be in the same subnet and use the same Wake on LAN host connection. It does not matter if the PCs are in the same or different machine catalogs.
  • Host connections are assigned to specific zones. If your deployment contains more than one zone, you need a Wake on LAN host connection in each zone. The same applies to machine catalogs.
  • Magic packets are broadcasted using the global broadcast address 255.255.255.255. Ensure that the address is not blocked.
  • There must be at least one PC turned on in the subnet - for every Wake on LAN connection - to be able to wake up machines in that subnet.

Operational considerations

The following are considerations for using the Wake on LAN feature:

  • The VDA must register at least once before the PC can be woken up using the integrated Wake on LAN feature.
  • Wake on LAN can only be used to wake up PCs. It does not support other power actions, such as restart or shut down.
  • After the Wake on LAN connection is created, it is visible in Web Studio. However, editing its properties within Web Studio is not supported if using Citrix Virtual Apps and Desktops on-premises.
  • Magic packets are sent in one of the two ways:
    1. When a user tries to launch a session to their PC and the VDA is unregistered
    2. When an administrator manually sends a power on command from Web Studio or PowerShell
  • Because the delivery controller is unaware of a PC’s power state, Web Studio displays Not Supported under power state. The delivery controller uses the VDA registration state to determine whether a PC is on or off.

Wake on LAN – SCCM-integrated

SCCM-integrated Wake on LAN is an alternative Wake on LAN option for Remote PC Access that is only available with on-premises Citrix Virtual Apps and Desktops.

System requirements

The following are the system requirements for using the SCCM-integrated Wake on LAN feature:

  • Citrix Virtual Apps and Desktops 1912 or later
  • Physical PCs:
    • VDA version 1912 or later
    • Windows 10. For supportability details, see the VDA system requirements.
    • Wake on LAN enabled in BIOS/UEFI
    • Wake on LAN enabled in network adapter’s properties within Windows configuration
  • System Center Configuration Manager (SCCM) 2012 R2 or later

Configure SCCM-integrated Wake on LAN

Complete the following prerequisites:

  1. Configure SCCM 2012 R2, 2016, or 2019 within the organization. Then deploy the SCCM client to all Remote PC Access machines, allowing time for the scheduled SCCM inventory cycle to run, or force one manually, if necessary.
  2. For Wake Proxy support, enable the option in SCCM. For each subnet in the organization that contains PCs that use the Remote PC Access Wake on LAN feature, ensure that three or more machines can serve as sentinel machines.
  3. For magic packet support, configure network routers and firewalls to allow magic packets to be sent, using either a subnet-directed broadcast or unicast.
  4. Configure Wake on LAN in each PC’s BIOS/UEFI settings.
  5. Deploy the VDA to the physical PCs if you haven’t done it already.

After you address the prerequisites, complete the following steps to allow the Delivery Controller to communicate with SCCM:

  1. Create a host connection for SCCM. For more information, see Connections and resources.
    • Select Microsoft Configuration Manager Wake on LAN as the connection type.
    • The credentials entered must have access to the collections in the scope and must have the Remote Tools Operator role.
  2. Select the connection in Web Studio, then select Edit Connection, and click Advanced.
  3. Select the appropriate option for handling Wake on LAN:
    • If you are using Wake-up proxy, select the first option: Microsoft System Center Configuration Manager Wake-up proxy.
    • If you are using magic packets, select the second option: Wake on LAN packets transmitted by the Delivery Controller.
      • Select the appropriate transmission method: subnet-directed boradcasts or unicast.

After you create the host connection, associate the connection with a Remote PC Access catalog:

  • If you are creating a new Remote PC Access catalog, in the Operating System page of the catalog creation wizard, select Remote PC Access as the catalog type and choose the appropriate connection from the drop-down list.
  • To add Wake on LAN to an existing Remote PC Access catalog:
    1. Go to the Machine Catalogs node in Web Studio, select the machine catalog, and then select Edit Machine Catalog.
    2. Select the Power Management tab and choose Yes to enable power management for the machine catalog.
    3. Select the appropriate connection from the drop-down list and click OK.

Troubleshoot

Monitor blanking not working

If the Windows PC’s local monitor is not blank while there is an active HDX session (the local monitor displays what’s happening in the session) it is likely due to issues with the GPU vendor’s driver. To resolve the issue, give the Citrix Indirect Display driver (IDD) higher priority than the graphic card’s vendor driver by setting the following registry value:

HKEY_LOCAL_MACHINE\SOFTWARE\Citrix\Graphics\AdapterMerits

  • Name: CitrixIDD
  • Type: DWORD
  • Data: 3

For more details about display adapter priorities and monitor creation, see the Knowledge Center article CTX237608.

Session disconnects when you select Ctrl+Alt+Del on the machine that has session management notification enabled

The session management notification controlled by the SasNotification registry value only works when Remote PC Access mode is enabled on the VDA. If the physical PC has the Hyper-V role or any virtualization-based security features enabled, the PC reports as a virtual machine. If the VDA detects that it is running on a virtual machine, it automatically disables Remote PC Access mode. To enable Remote PC Access mode, add the following registry value:

HKEY_LOCAL_MACHINE\SOFTWARE\Citrix\PortICA

  • Name: ForceEnableRemotePC
  • Type: DWORD
  • Data: 1

Restart the PC for the setting to take effect.

Diagnostic information

Diagnostic information about Remote PC Access is written to the Windows Application Event log. Informational messages are not throttled. Error messages are throttled by discarding duplicate messages.

  • 3300 (informational): Machine added to catalog
  • 3301 (informational): Machine added to delivery group
  • 3302 (informational): Machine assigned to user
  • 3303 (error): Exception

Power management

If power management for Remote PC Access is enabled, subnet-directed broadcasts might fail to start machines that are on a different subnet from the Controller. If you need power management across subnets using subnet-directed broadcasts, and AMT support is not available, try the Wake-up proxy or Unicast method. Ensure those settings are enabled in the advanced properties for the power management connection.

The active remote session records the local touchscreen input

When the VDA enables Remote PC Access mode, the machine ignores the local touchscreen input during an active session. If the physical PC has the Hyper-V role or any virtualization-based security features enabled, the PC reports as a virtual machine. If the VDA detects that it is running on a virtual machine, it automatically disables Remote PC Access mode. To enable Remote PC Access mode, add the following registry setting:

HKEY_LOCAL_MACHINE\SOFTWARE\Citrix\PortICA

  • Name: ForceEnableRemotePC
  • Type: DWORD
  • Data: 1

Restart the PC for the setting to take effect.

More resources

The following are other resources for Remote PC Access: