PMC 2.5 Quick Start Guide

PMC 2.5 Quick Start Guide

Product Release Notes:
NComputing PMC, Version 2.5.0

Product: NComputing PMC

Version: 2.5.0

Supported virtual machine environments:  

  • VMware ESXi 6.7
  • Citrix XenServer 7.4.0
  • Microsoft Hyper-V Manager Version 10.0.17763.1

PMC has been tested and confirmed to work with the above-mentioned versions of supported hypervisors, but it will work with other versions of these hypervisors too. 

Supported NComputing access devices:

  • RX300 with firmware version 3.2.7 or newer
  • RX-RDP with firmware version 1.1.3 or newer
  • RX420(RDP) with firmware version 1.2.3 or newer
  • Repurposed PCs with LEAF OS 2.0.11

This document contains important information. Please read the entire document to ensure that your deployment process goes smoothly.

About the Product:

NComputing PMC is a device management system designed and developed to remotely manage NComputing access devices. PMC Device Management provides simple and powerful device management for RX300, RX-RDP, RX420(RDP) and LEAF OS thin clients. PMC does NOT support RX-HDX nor RX420(HDX) (Citrix) thin clients.

Key Product Features:

  • Ability to manage devices located in local- and wide-area networks, including devices located behind firewalls and NAT-routers.
  • Ability to edit configuration of selected devices and to push configurations to multiple devices (through device profiles).
  • LDAP-based PMC users authentication and authorization.
  • Tools for automatic and manual device profiles upgrades.
  • Ability to schedule device firmware updates.
  • Ability to schedule device reboots and shutdowns.
  • Readiness to support future device families, models, and configuration versions.
  • Hosting files (firmware, certificates, wallpapers) for managed devices.
  • Deployment as virtual appliance, compatible with industry-standard hypervisors.
  • Easy to use web-based user interface, accessible from any network location.
  • Dashboard view with auto-refreshing summary information.
  • Detailed event logging with filtering capability.

PMC Licensing Information:

Number of available PMC licenses depends on managed device model and associated AMP (Annual Maintenance Program) status:

  • Each RX-RDP and RX420(RDP) device comes with a perpetual license for the PMC software and first-year complimentary software maintenance update (AMP for RX-RDP and RX420(RDP)). After the expiration of the first-year complimentary AMP for RX-RDP or RX420(RDP), the RX-RDP or RX420(RDP) device can only receive firmware updates from PMC. Furthermore, extended AMP for RX-RDP and RX420(RDP) licenses must be purchased and allocated to each RX-RDP and/or RX420(RDP) device to allow PMC to push firmware update.
  • The RX300 device requires a separate purchase of either AMP for vSpace Pro  or AMP for VERDE VDI to receive the PMC software license for that device.
  • Once PMC is registered to NComputing Management Portal, it will auto-detect the PMC licensing allowance for RX300, RX-RDP and RX420(RDP) devices that have been connected to PMC.

General Information and Installation Instructions:

Following are the important points to consider before and during PMC installation:

  • After uploading the PMC virtual appliance to a hypervisor, care must be taken to ensure that the virtual Ethernet interface is connected to a virtual network which is bridged with the hypervisor’s physical network interface. This network interface must be accessible by the managed devices. Connecting the PMC virtual appliance to hypervisor’s NAT-network or host-only network will prevent the managed devices from connecting to PMC.
  • After being uploaded to a hypervisor and started for the first time, the PMC virtual appliance will try to obtain an IP address from a DHCP server. NComputing strongly recommends assigning a static IP address (or at least creating a DHCP reservation) for the PMC appliance. This is to ensure that PMC will always appear in the network with the same IP address. PMC virtual appliance automatically starts a TUI (text-based user interface) on its virtual console (which is accessible through hypervisor’s administration interface). TUI allows the configuration of PMC virtual appliance’s network interfaces.
  • PMC’s web-based user interface can be accessed from any up-to-date web browser through the ‘https://<PMC_address>/pmc’ URL, where <PMC_address> must be replaced with the proper address of the PMC virtual appliance, as shown in the TUI.
  • The PMC component delivering the web-based user interface is preconfigured with a self-signed SSL certificate. An exception for the PMC URL should be created in the web browser used for accessing PMC’s web-based interface.
  • PMC virtual appliance must be activated with the NComputing Management Portal before it will be used for managing any devices. The activation page will appear when the web-based user interface will be opened for the first time. 
  • The built-in PMC user account with administrative privileges is ‘pmcadmin’. The password is ‘pmcadmin’ too. NComputing, for security reasons, suggests changing this password to an own one.
  • The built-in Linux user account allowing privileged access to the shell of the underlying CentOS operating system is ‘root’, with ‘pmcadmin’ password. NComputing, for security reasons, suggests changing this password to an own one.
  • The devices, to become manageable, must obtain the address of the PMC appliance (the URL of the PMC Management Server) to connect to. The  address/URL can be specified manually in the Management section of device Setup GUI. The ‘Use following PMC address’ parameter allows that.
  • To automate the PMC server discovery, the DHCP option 207 can be used. This DHCP option should provide a string value containing the URL in form of ‘https://<PMC_address>’, where <PMC_address> must be replaced with the proper host name or IP address of the PMC virtual appliance.
  • As HTTPS protocol will be used by the devices for communication with PMC the TCP 443 port must be opened on all firewalls located between the managed devices and the PMC appliance.
  • The managed devices repeatedly send to PMC small portions of information – so called heartbeats. This happens every 30 seconds. Heartbeats allow PMC to keep track of devices which are online and also give the devices the information about PMC availability. In responses to heartbeats, PMC sends to devices requests to execute management actions. Because of this approach the devices may react with some delay (up to 30 seconds) to management actions performed in PMC.

How PMC Works?

Below is some general information about how PMC works:

  1. Each device managed by PMC must belong to a Subnet. Subnets will be identified by Subnet IP address, Subnet Mask and device’s Visible IP Address. Subnets exist in Subnet Groups. When a device from a not yet known Subnet connects to PMC, then PMC creates the Subnet automatically and puts it into the ‘Auto-created Subnets’ Subnet Group. 
  2. Subnet Groups can be created manually and the Subnets can be moved between Subnet Groups. 
  3. Subnets can be created manually too, even before the first device from the Subnet will connect to PMC. 
  4. A Visible IP Address and Visible IP Address Mask can be specified when creating a Subnet. The Visible IP Address can be used to differentiate NAT-ed Subnets using the same local IP addressing.
  5. PMC allows assigning device profiles at several different levels: Organization, Subnet Groups, Subnets, Name Scopes, Asset Tag-based Groups, Manual Groups. 
  6. Profiles for different device families/models and different configuration versions of the same model can be assigned at all levels.
  7. Profiles do not need to contain all device settings. Only the necessary subset of settings can be defined in each profile.
  8. When a device model using particular configuration version connects to PMC, PMC merges settings from all profiles matching the configuration version used by the device, to create the effective configuration. Effective configuration will be sent to the device. 
  9. Settings merging (to create the effective configuration) happens in the above mentioned order: first the settings from appropriate (matching device's family/model/version) Organization's profile will be taken, then from the Subnet Group (which reflects a site or geographical location) the device belongs to, then from the Subnet, and so on. Settings from profiles assigned at Organization level are the most global (as all connected devices belong to Organization group), thus things like branding (desktop wallpaper) or CA certificates (for 802.1x network connections) should be contained there. 
  10. If same settings are defined in profiles assigned at different levels, then the settings from profiles assigned at more specific (lower) level overwrite settings from more general (higher) level, e.g. settings defined in a profile assigned to a Subnet Group overwrite settings from profile assigned at Organization level (if same settings but with different values exist in both profiles). Settings from a profile assigned to Subnet overwrite settings from profiles assigned to Subnet Group and Organization, and so on, up to Manual Groups.
  11. PMC assigns devices to Name Scopes (inside Subnet) by parsing device name and matching it with device name pattern defined for the Name Scope.
  12. PMC assigns device to Asset Tag-based Groups by checking the value of the Asset Tag reported by the device.
  13. Devices (inside Subnet) can be manually assigned to Manual Groups. 
  14. Name Scopes, Asset Tag-based Groups, and Manual Groups can be used when some specific settings need to be provided to a specific groups of devices (e.g. belonging to organization's department, building floor, room, etc.).
  15. Device saves locally the configuration received from PMC. This configuration will remain active even if the device will lose PMC connectivity.
  16. If devices belonging the same department in Organization's structure exist in different locations (Subnet Groups) then the same profiles with department-specific settings can be assigned to Name Scopes, Asset Tag-based, or Manual Groups created under different Subnets.

PMC Update Information:

Please follow the below procedure to update an older PMC version to version 2.5.0:

  • Logon to your existing PMC appliance as a user belonging to a user group with administrative permissions.
  • Under Administration > Backup and Restore click the [Start backup] button to create a PMC backup.
  • Go to Administration > Files and click the name of the newly created backup file to download it.
  • Shut the old PMC appliance down.
  • Deploy a new PMC 2.5.0 appliance by following the instructions from the previous section.
  • Look into PMC 2.5.0 TUI to determine its IP address, provided by a DHCP server. If there is no DHCP server in PMC’s subnet, configure the same static IP address as the one previously used on the backed-up and shut down old PMC appliance.
  • Login as the ‘pmcadmin’ user to PMC 2.5.0.
  • Under Administration > Files select System backup as file type, click the [Browse] button to select the downloaded backup file. Then click the [Upload file] button.
  • Under Administration > Backup and Restore, in the Restore from a backup file panel, select the uploaded backup file. 
  • When restoring a backup of PMC 2.0.0, 2.0.1 or 2.0.6, you can opt to restore the licensing data, however, if you have been experiencing the PMC-1142 issue on PMC 2.0.0 (Grace Period started because the last attempt to reach the Management Portal was unsuccessful), then please do not select this option
  • With the Restore licensing data option deselected, PMC 2.5.0 will have to be-reactivated after restoring the backup. You may need to manually disconnect your currently activated PMC 2.5.0 instance through your account in Management Portal (under My PMC Installations > My PMC Servers), before reactivating the PMC 2.5.0 appliance, after a backup was restored.
  • With the Restore licensing data option selected, PMC 2.5.0 will re-use the licensing data from the backed-up PMC 2.0.0, 2.0.1 or 2.0.6 appliance and the reactivation will not be necessary.
  • PMC can upgrade the device profiles contained in the restored backup and assign the upgraded profiles to the same device groups where the existing profiles were assigned. The Automatically upgrade applicable device profiles checkbox can be selected to perform automatic upgrade of all profiles for which configuration upgrade paths exist. 
  • Click the [Start restore] button.

Depending on whether the reactivation will be necessary or not, you will be redirected to PMC 2.5.0 activation page or to logon page, after restoring the backup. All devices, device settings, profiles, local user accounts, local user groups, uploaded files, and server settings will be restored. When restoring a backup of PMC 2.0.0, 2.0.1 or 2.0.6 also virtual appliance’s network settings, all Subnet Groups, Subnets, Name Scopes, Asset Tag-based groups, and Manual Groups, as well as device profile assignments to those groups will be restored.

Note: When a backup of a PMC appliance was created with the intention to be restored together with the licensing data on a newer PMC version, then the original (backed-up) appliance should be shut down and never used again. This is to keep consistency of the access tokens contained in the backup and restored on the new PMC appliance. Continuing to use both appliances will make one of the appliances out of sync with the Management Portal, causing the licensing grace period to begin on the desynchronized appliance. Disconnecting it from the Management Portal and reactivating will be necessary to restore the normal operation.

Note: Restoring a backup of a PMC appliance which had a static IP address, on a PMC appliance which currently has a different IP address (static or DHCP), will result with the web-based user interface losing the connection with PMC. To continue working with PMC after restoring such backup, the web-based user interface will have to be reopened through a new URL based on the restored static IP address.

Note: When restoring in PMC running on a new hypervisor a backup of PMC deployed to a different hypervisor, e.g. when restoring on PMC running on VMware ESXi a backup of PMC deployed to Hyper-V, the restore procedure may not correctly restore the static IP address of the original PMC appliance. This may happen due to possible virtual Ethernet interface names difference between the hypervisors. Please confirm in the Text-based User Interface that PMC has configured the expected static IP address, after restoring the backup. Set the correct static IP address manually, when necessary.

More about the new features of PMC 2.5.0:

PMC 2.5.0 brings following new major product features:

LDAP-based PMC users authentication

PMC 2.5.0 can leverage an LDAP server to authenticate the PMC users. An Active Directory domain controller can be used as the LDAP server and act as the repository of user accounts and groups. Following parameters must be configured under Administration > LDAP Settings to enable LDAP authentication in PMC 2.5.0:

Enable LDAP authentication – this checkbox must be selected.

Server type – only Microsoft AD is currently selectable.

Server URL – the URL of the LDAP server. Unencrypted (ldap://…) and encrypted (ldaps://…) LDAP connections are supported. If incomplete URL will be specified, PMC will automatically extend it by prepending the protocol prefix and appending protocol specific TCP port number. For the ‘ldap’ protocol (which is the default) the TCP port 389 will be used. For the ‘ldaps’ protocol (which must be specified manually) the TCP 636 port will be used. If a non-standard port should be used for the communication with the LDAP server, the port number should be entered manually. E.g. to securely connect to an AD forest’s Global Catalog server, the ‘ldaps’ protocol will have to be used with manually specified port 3269.

Domain name – the name of the Active Directory domain. It will be appended to the username specified on the logon page when performing LDAP binds to authenticate the user.

CA certificate – an uploaded Certification Authority certificate can be selected here. It will be used for verification of the LDAP server certificate, when a secure LDAP (ldaps://…) Server URL will be specified.

Ignore certificate subject – this option allows using the ‘ldaps’ protocol  for connections to LDAP servers presenting certificates with Subject’s canonical name not matching server’s FQDN.

LDAP search base DN – this must be the distinguished name (DN) of a container (Organizational Unit, not a users group!) containing all user and user group objects, which will be used by PMC. All LDAP searches will start at this point and go deeper into the directory structure. In simplest case, this can be the distinguished name of the root of the Active Directory tree (however, this is only advisable for small directories).

PMC users group DN – this must be the distinguished name of a users group containing the accounts of all PMC users (full admins and helpdesk users). All logging in PMC users must be members of this group for the authentication to succeed. 

Advanced user lookup settings – the advanced user lookup settings are preconfigured with values appropriate for typical Active Directory deployments.

LDAP-based PMC users authorization

Making the PMC users members of the LDAP users group identifiable by the PMC users group DN parameter allows the authentication of the users, but does not grant any permissions to them. In PMC 2.5.0, the LDAP user can be authorized to access parts of the device infrastructure with full admin (read/write) or helpdesk (read-only) permissions. The authorization is based on users’ membership in LDAP user groups determined by the Full Admin group DN and Helpdesk (read-only) group DN specified at different device grouping levels (Organization, Subnet Group, Subnet). 

The authorization settings for the whole Organization are configurable under Administration > LDAP Settings, as well as through the Manage user authorization task, available in the Summary panel after selecting the top-most Organization node in the device groups tree.

The Manage users authorizations task, available in each group’s Summary panel, can be used to enter the distinguished names of the LDAP user groups to authorize the users with full admin or helpdesk permissions at Subnet Group and Subnet levels.

Following users authorization rules apply:

  • Users authorized with specific permissions (full admin or helpdesk) for a device grouping level (Organization, Subnet Group or Subnet), are also authorized with the same permissions to manage all underlying device grouping levels.
  • Users authorized with any permissions for a device grouping level, are also authorized with helpdesk (read-only) permissions allowing them to see all parent grouping levels.
  • User will have no access to (will not even be able to see) the device groups the user is not authorized for.
  • Users authorized with full admin permissions at the Organization level will have the same permissions as the built-in local ‘pmcadmin’ user. 

In geographically dispersed environments, this functionality allows nominating regional administrators and helpdesk users and allowing them to manage and/or see only eligible parts of the infrastructure with the devices managed by PMC.

Tools for automatic and manual device profiles upgrades

PMC, when composing the effective configuration which will be sent to the managed device, strictly controls the versions of the device configurations used during this process. If multiple profiles for different device families, models and configuration versions are assigned to the device groups, making a hierarchy of groups containing the managed device, then only the profiles matching the managed device family, model and configuration version will be merged together when composing the effective configuration. NComputing continuously develops the device firmware to bring new valuable device features. As these new features often require specific settings, the new firmware versions containing new product features usually introduce new versions of device configuration. Although the new device configuration versions usually contain incremental extensions to older versions, some obsolete settings can be removed too. The strict control of the device configuration versions ensures completeness and consistency of the configuration settings delivered by PMC to managed devices. Thanks to that approach, the managed devices will never receive from PMC incomplete configurations nor receive configurations with parameters not existing in the specification of device’s current configuration version.

When an Organization was using some devices for a while, profiles for the then-current configuration version of the devices were likely created in PMC. If at some time the Organization decided to upgrade (all or some) devices to a newer firmware version which introduced new product features and thus also a new configuration version, the existing profiles will be no more used for composing the effective settings for the upgraded devices. This is because of the configuration version mismatch between the existing profiles and upgraded device firmware. With no profiles existing for devices’ current configuration version the effective configuration composed by PMC will be empty. Such configuration will not affect any device settings. 

To avoid the necessity to manually create new profiles for devices’ new configuration version, PMC 2.5.0 offers tools which can greatly simplify or even fully automate the upgrade process.

Following functionalities are available:

  • Automatic profiles upgrades after uploading schema files with definitions of new device configuration versions. 

When multiple upgrade paths exist, e.g. in case when existing profiles for multiple older configuration versions can be upgraded, the administrator will be able to select which profiles and to which configuration version should be upgraded. The upgraded profiles can be automatically assigned to the same device groups, where the original (old) profiles were assigned.

  • Manual profiles upgrades after uploading schema files. 

The upgrades can be performed with the Upgrade task of the Device Profiles list. 

  • Automatic profiles upgrades when restoring a backup containing profiles created for older configuration versions.

In this case the profiles will be automatically upgraded to the latest available configuration version only. The upgraded profiles can be optionally assigned to the same device groups where the original profiles were assigned. 

  • Automatic upgrades of configuration edited directly on specific devices. 

When the device configuration was edited in the past directly on a device when the device was using some older configuration version, then PMC will automatically upgrade the edited configuration to device’s current configuration version when the device will report a newer configuration version during check-in.

Device reboot and shutdown schedulers

PMC 2.5.0 allows scheduling device reboots and shutdowns. The schedules can be defined with the Reboot and Shutdown tasks of the Devices lists. As the scheduled events will be defined using the time zone of PMC Management Server, the proper Time zone needs to be set for the PMC appliance under Administration > System Settings. Because the Reboot and Shutdown actions will be initiated by PMC (at the scheduled time PMC will send to the devices appropriate commands), the devices must be in online state to be able to execute the actions.

Known Issues and workarounds: 

  • When new (not yet registered) devices will connect to PMC for the first time PMC may not yet have the AMP information associated with the managed devices. Clicking the [Refresh] button under Administration > Licensing in PMC’s web-based user interface will force PMC to report to Management Portal serial numbers of all connected devices. Management Portal will register the new devices and return to PMC the associated licensing information. This will allow PMC to display the devices on the lists.
  • After changing in the TUI the IP address of PMC appliance’s network interface the Base URL (under Administration > System Settings in PMC’s web-based user interface) will still contain the old IP address. This happens because the PMC Management Server component only adjusts the Base URL to match the current IP address at system boot-up.
    Workaround: Rebooting the PMC virtual appliance after changing the IP address in the TUI resolves the issue. The Base URL can be changed directly on the Administration > System Settings page of PMC web-based interface too. In this case PMC appliance reboot will not be necessary.
  • Firmware updates fail on RX300 devices running the 3.1.3 firmware. 
    This issue happens because the RX300 3.1.3 firmware was not yet ready for firmware downloads through the HTTPS protocol, which is the default communication protocol used by PMC.

Workaround: The below steps must be followed to update the RX300 3.1.3 firmware to a newer version:

  • Connect with an SSH client (e.g. PuTTY) to the IP address of the PMC appliance and logon as the 'root' user with 'pmcadmin' password.
  • Invoke the following command to stop the network firewall on PMC appliance:

systemctl stop firewalld

  • In PMC’s web-based user interface, under Administration > System Settings, change the Base URL of this PMC server in your network' to use the HTTP protocol and port 8080, like: http://:8080/ Double click the URL to edit it. Use the real IP address of the PMC appliance instead of from the above example.

After this change PMC will create the firmware download URLs using the modified Base URL. This will allow the devices running the 3.1.3 firmware to successfully download and update the firmware.

To revert the changes after completing firmware updates on all devices do the following:

  • Invoke the following command to start the network firewall again:

systemctl start firewalld

  • Revert the Base URL setting to its original value (containing the HTTPS protocol and no port number, like:
  • With RX300 firmware version 3.2.7 or older, an attempt to save edited device configuration for Audio output priority or to store device configuration as a profile can fail with ‘Validation of device configuration has failed’ error message.
    Workaround: If the managed device displays in its local GUI the Audio output priority list with the Audio item spelled with uppercase ‘A’ then resetting the device to factory defaults should resolve the issue. To reset the device to factory defaults, do the following:
  • With the device GUI visible on the screen press [Ctrl]-[Win]-[F12] to open the ‘rx-terminal’ window.
  • Invoke the ‘reset-to-factory’ command.

Note: This issue was specific to RX300 device with firmware version 3.2.7 or older. Newer RX300 firmware versions correct this issue automatically during firmware update. NComputing strongly recommends updating all devices to latest available firmware version before starting to manage them from PMC.

  • PMC-1201 – Re-activating PMC appliance with new PMC Instance Name does not update the instance name on Management Portal & device Licensing Status page.

Note: This is a problem on the Management Portal side which will be fixed there.

  • PMC-1150 – Display issues in Microsoft Edge and Internet Explorer browser

Workaround: For the time being please use other browsers for accessing PMC, like Google Chrome or Mozilla Firefox.

  • PMC-1127 – There is no way to remove device from PMC if it is listed under ‘LIMITED’ due to license restrictions.
  • PMC-697 – Unexpected error while importing PCM appliance into XenServer.
    Note: This message can be safely ignored.

    • Related Articles

    • PMC 3.0, Start Guide

      Overview This document is an extraction from the release notes of PMC 3.0. It covers everything you need to know, in-depth, regarding installation and deployment of PMC. It is always recommended that you use the current release notes of every PMC ...
    • Where can I find the LEAF OS user configuration guide?

      There are multiple guides available for LEAF OS configurations: Getting Started: LEAF OS for Citrix Guide (supported from LEAF OS version 3.7.4 or higher) Getting Started: ...
    • NComputing Citrix Ready Workspace Hub User Guide

      The latest Citrix Ready Workspace Hub user guide can be found here:
    • RX300, RX-RDP, RX420(RDP) and LEAF OS User Configuration Guide

      There are multiple guides available for LEAF OS configurations: Getting Started: LEAF OS for Microsoft AVD & Windows 365 Cloud PC RX-RDP, RX420(RDP), RX300 and LEAF OS user ...
    • PMC: Invalid Credentials upon login to dashboard.

      Once you setup the Virtual Appliance, you will be asked for credentials to access the dashboard.  If you enter your Management Portal credentials, these will not be accepted and you will receive a message in red "credentials for user [your email] are ...