PMC 3.0, Start Guide

PMC 3.0, Start Guide

Overview

This document is an extraction from the release notes of PMC 3.1.2. 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 version that you download and are planning to deploy. 

You can always click anywhere on the table contents to jump faster to a section you're interested in.

Product Release Notes: NComputing PMC, Version 3.1.2

Product

NComputing PMC Endpoint Manager

Version 

3.1.2

Supported virtual machine environments

  1. VMware ESXi 6.7.0 and 7.0
  2. Citrix Xen Server 7.4.0
  3. Microsoft Hyper-V Manager Version 10.0.19041.1
  4. Microsoft Azure Cloud
  5. PMC Endpoint Manager has been tested and confirmed to work with the above mentioned versions of supported hypervisors, but it will work with other versions of those hypervisors too. 

Supported NComputing access devices

  1. RX300 with firmware version 3.2.7 or newer
  2. RX-RDP with firmware version 1.1.3 or newer
  3. RX-RDP+ with firmware version 1.10.10 or newer
  4. RX420(RDP) with firmware version 1.2.3 or newer
  5. RX440(RDP) with any firmware
  6. EX500 with any firmware version
  7. LEAFOS(X86) version 2.7.0 or newer
  8. LEAFOS(PI4) version 2.4.5 or newer
This document contains important information. Please read the entire document to ensure that your deployment process goes smoothly.

About the Product

NComputing PMC is an endpoint management system designed and developed to remotely manage NComputing access devices.

Key Product Features

  1. Ability to manage devices located in local- and wide-area networks, devices located behind firewalls and NAT-routers, including devices of work-from- home users.
  2. Ability to edit configuration of selected devices and to push configurations to multiple devices (through device profiles).
  3. Ability to securely shadow all manage devices’ screens.
  4. Ability to request and collect troubleshooting information from managed devices.
  5. Ability to schedule device firmware updates.
  6. Readiness to support future device families, models, and configuration versions by uploading configuration definition files.
  7. Hosting files (firmware, certificates, wallpapers) for managed devices.
  8. Deployment as virtual appliance compatible with industry-standard hypervisors.
  9. Easy to use web-based user interface, accessible from any network location.
  10. Dashboard view with auto-refreshing summary information.
  11. Detailed event logging with filtering capability.
  12. Export functions for PMC data contents.

PMC Licensing Information

PMC is NComputing's endpoint management software for RX300, RX300+ RX-RDP, RX- RDP+, RX420(RDP), RX440(RDP) and LEAF OS (including EX500) devices. Number of available PMC licenses depends on managed device model and associated AMP (Annual Maintenance Program) status:
  1. Each RX-RDP, RX-RDP+, RX420(RDP), RX440(RDP), EX500 and LEAFOS(x86) device comes with a perpetual license for the PMC software and first-year complimentary software maintenance update (AMP for RX-RDP, RX-RDP+, RX420(RDP), RX440(RDP) and LEAFOS(x86)). After the expiration of the first- year complimentary AMP for RX-RDP, RX-RDP+, RX420(RDP), RX440(RDP) or LEAFOS(x86), the RX-RDP, RX-RDP+, RX420(RDP), RX440(RDP), EX500 or LEAFOS(x86) device can only receive firmware updates from PMC. AMP for RX-RDP, RX-RDP+, RX420(RDP), RX440(RDP) and LEAFOS(x86) licenses must be then purchased and allocated to each RX-RDP, RX-RDP+, RX420(RDP), RX44(RDP), EX500, and/or LEAFOS(x86) device to allow PMC to push the firmware updates.
  2. The RX300 and RX300+ devices require a separate purchase of AMP for vSpace Pro to receive the PMC software license for that device.
  3. Once PMC is registered to NComputing Management Portal, it will auto- detect the PMC licensing allowance for RX300, RX300+, RX-RDP, RX-RDP+, RX420(RDP), RX440(RDP), EX500, and LEAFOS(x86) devices that have been connected to PMC.

General Information and Installation Instructions

Following are the important points to consider before and during PMC installation:
  2. 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.
  3. 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.
  4. 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.
  5. 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.
  6. 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.
  7. In the next step after activation, PMC will ask the user to select tagged Subnets handling mode
    Refer to following sections of this document for more information about tagged Subnets handling.)
  8. The built-in PMC user account for accessing the web-based user interface with administrative privileges is pmcadmin. The password is pmcadmin too. NComputing, for security reasons, suggests changing this password to an own one.
  9. The built-in Linux user account allowing privileged access to the shell of the underlying Linux operating system is root, with pmcadmin password. NComputing, for security reasons, suggests changing this password to an own one.
  10. 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 as the ‘Use following PMC address’ parameter.
  11. 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.
  12. LEAFOS(X86) 2.9.20 and newer versions support additional PMC server discovery methods:
    1. NComputing Management Portal: the devices will contact the Management Portal to obtain the PMC URL linked there with the LEAFOS license key used for device activation.
    2. DNS: the devices will try to use the ‘https://pmc’ URL to connect to the ‘pmc’ host in current DNS domain (obtained from DHCP or configured statically).
  13. The Portal-based method is specific to LEAFOS devices; however, the support for DNS-based method will be subsequently added to new RX-series firmware. The order in which the discovery methods are tried is following: (1) DHCP, (2) NComputing Management Portal, and (3) DNS. Once one method returned and address or URL, no other methods will be tried. This will be the case even if the connection through the discovered address/URL was unsuccessful.
  14. 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.
  15. 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.

PMC Deployment to Azure Cloud

PMC Endpoint Manager 3.0.1 (and newer versions) can be deployed to Azure Cloud. Please refer to following Knowledge Base article for the information where to find and how to install PMC from Azure Marketplace: https://support.ncomputing.com/portal/en/kb/articles/ncomputing-using-pmc-on-microsoft-azure-marketplace

PMC Update Information

PMC Endpoint Manager 3.1.2 supports updates from PMC 2.9.x, 3.0.x and 3.1.0. Updates from older versions can succeed but have not been tested by NComputing and thus are not officially supported.

Upgrading from PMC 2.9x to 3.1.2

Please follow the below procedure to update an older supported PMC version to version 3.0.0:
  1. Logon to your existing PMC appliance as a user belonging to a user group with administrative permissions.
  2. Under Administration > Backup and Restore, click the [Start backup] button to create a PMC backup.
  3. Go to Administration > Files and click the name of the newly created backup file to download it.
  4. Shut the old PMC appliance down.
  5. Deploy a new PMC Endpoint Manager 3.1.2 appliance by following the instructions from the previous section.
  6. Go to PMC 3.1.2 TUI and configure the same static IP address as the one used previously on the backed-up and shut down old PMC appliance.
  7. Login as the ‘pmcadmin’ user to PMC 3.1.2.
  8. 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.
  9. Under Administration > Backup and Restore, in the Restore from a backup file panel, select the uploaded backup file.
  10. When restoring a backup you can opt to restore the licensing data.
    1. With the Restore licensing data option deselected, PMC 3.1.2 will have to be-reactivated after restoring the backup. You may need to manually disconnect your currently activated PMC 3.1.2 instance through your account in Management Portal (under My PMC Installations > My PMC Servers), before reactivating the PMC 3.1.2 appliance after restoring the backup.
    2. With the Restore licensing data option selected, PMC 3.1.2 will re- use the licensing data from the backed-up PMC appliance and the reactivation will not be necessary.
    3. 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.
    4. Click the [Start restore] button.

    Depending on whether the reactivation will be necessary or not, after restoring the backup, you will be redirected to PMC 3.1.2 activation page or to the logon page. All devices, device settings, profiles, local user accounts, local user groups, uploaded files, and server settings will be restored. 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: Please take into account the ‘PMC backup/restore considerations with extended support for tagged Subnets’ from next sections of this document below.

    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 with the access tokens maintained by the Management Portal. 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 a backup of PMC deployed to a different hypervisor, e.g. when restoring on a new PMC currently 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 mismatch 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.

    Upgrading "in-place" from PMC 3.0.x or 3.1.0 to 3.1.2

    PMC 3.0.0 introduced the ability to perform in-place updates of PMC appliances, without the necessity to create and restore system backups.
    Please follow the below procedure to perform an in-place PMC update:
    1. (Optional, but recommended) Using the dedicated management tool of your hypervisor, create a snapshot of your PMC appliance virtual machine. Alternatively, from PMC GUI, create and save outside of PMC a system backup. This is to secure your current PMC against the unlikely case of in-place update failure.
    2. Under Administration > System Updates, click the [Browse] button to locate the .UPD file containing the PMC 3.1.2 update package. Press the [Apply] button to start the upload process. 
      Note: Separate PMC update packages are available for on-prem and Azure Cloud deployments. Please make sure you have obtained the appropriate update package. An attempt to update PMC with incorrect update package will fail.
    3. The upload, extracting and verification of the update package will take a moment. Once the ‘Ready for update’ message appears, press the [Apply update] button to continue, or [No] to stop the process. PMC functionality will be blocked until the update is completed.
    4. PMC appliance will be rebooted at the end of the process to apply the changes.
    The in-place update will preserve all contents of PMC database (devices, subnets, subnet groups, profiles, local user accounts, etc.), the system settings (including the operation mode), network settings and the licensing information.

More About Recent New PMC Product Features

Firmware updates leveraging the update source specified in device configuration:

When scheduling a firmware update, PMC administrator can select one of the following firmware source options:
  1. ‘Let the devices use the configured firmware update source and method’ – this is the new option introduced in PMC 3.1.0. When the device receives from PMC a firmware update command with that option selected, the device will try to perform the firmware update using the method and source, which it has configured under the Support settings. The Support > Firmware Update settings are now configurable with PMC. This allows updating the devices working in different locations from different firmware sources. Large firmware update file transfers through WAN links can be avoided thanks to that option. Especially the method based on the FTP/HTTP URL is useful with that option, as it allows using web or FTP servers in device locations to deliver the firmware updates locally. It’s up to the IT department to setup the necessary web or FTP server, to upload the firmware update files there, and to determine the necessary URLs. 
    Note: If this new type of firmware update will be scheduled to happen ‘now’ and the firmware update source has been configured with PMC just before that (a minute or less), it can happen, that both commands will be delivered to the target device(s) at the same time. In such case, devices running firmware released prior to December 2022 can start the firmware update before applying the configuration change containing the firmware update source information. To avoid such situation, it’s advisable to wait some time (a minute or two) after applying the configuration change and before scheduling the firmware update. This is to ensure, that the device will complete the configuration changes before beginning with the firmware update.
  2. ‘Let PMC provide the firmware image files to devices’ – this is the option which was always used by PMC prior to version 3.1.0 and is still the default one in PMC 3.1.0. PMC acts as the central source of firmware update files for all devices when this option is selected.

Customization of lists presentation

The ‘Gearwheel’ icon   has been added in the upper-right corner of all lists to allow opening the list customization dialog. The list columns can be displayed, hidden, and moved according to PMC user’s preferences.

New PMC system update mechanisms

PMC Endpoint Manager versions up to 2.9 required deployment of virtual appliance containing the new PMC version and then restore of a backup created on an older version to perform system update, which was inconvenient, time consuming and error prone. PMC Endpoint Manager 3.0 introduced a new structure of internal filesystems, which allows quick and easy in-place updates of appliance software. No deployment of new appliance nor restore of older version backup will be necessary in the future. Subsequent PMC versions will be provided as full image (for new deployments) and as a system update package (to update existing PMC 3.x deployments).

Send message feature

A new task, Send message, has been added to Devices list. It allows the PMC user to send text messages to selected devices.

The messages will pop-up on device screens. The information about the PMC user who sent the message as well as the date and time when the message was sent will be displayed to device user.

Support for ‘Raise Hand’ requests

PMC Endpoint Manager 3.0.1 supports the ‘Raise Hand’ requests, which can be sent by the managed devices. Such requests will be sent when the device user will press the Shift-Ctrl-F2 key combination. Upon receiving the ‘Raise Hand’ request, PMC will display a notification and put a timestamp information into the newly introduced  ‘Raise Hand’ time column of Devices list.



This will allow the PMC administrator or helpdesk agent to quickly identify the devices whose users need assistance and used the Raise Hand feature to indicate that. The Raised hand time column allows sorting and filtering to even quicker find the devices. The new Clear raise hand task of the Devices list allows clearing the raised hand timestamps for selected (or all) devices.

Ability to export the contents of all PMC lists

All PMC lists can be exported in Excel (XLSX), comma-separated (CSV), PDF and HTML formats. Filtered and unfiltered lists can be exported. In the case when the Devices list display is limited due to licensing issues, the list of unlicensed devices can be exported to determine which devices (not shown on the list in PMC UI) are actually causing the issue.

Ability to manage lost devices (mark selected devices as ‘lost’ or ‘found’)

PMC Endpoint Manager 2.9.0 can be used to mark selected devices as ‘lost’ (e.g. stolen). This action will result with the ‘lost’ information being sent for the selected devices to NComputing Management Portal. For LEAFOS devices, the device license will additionally be revoked. The devices marked as ‘lost’ (if still connected to PMC) will receive the request to reset the configuration to factory defaults, lock the UI and block the operability. The ‘lost’ devices will stop communicating with PMC and will become offline. When a device will be found, it can be unlocked from the PMC interface. However, PMC will only send this information to NComputing Management Portal. Devices marked as ‘lost’ will have to be rebooted and will need Internet connectivity to directly contact the Management Portal to receive the ‘found’ information, get unlocked and restore the normal operation.

Ability to revoke LEAFOS licenses

For LEAFOS devices which are no more in use, it is possible to revoke the licenses (which effectively de-activates the device and resets them to factory defaults). The revoked licenses return to the license pool associated with the license key originally used for device activation and can be re-used to activate other LEAFOS devices.

Basic support for tagged Subnets (introduced in PMC 2.6.1 and higher versions)

Up to PMC 2.5.1, when a device with a Visible IP Address different than Ethernet or Wi-Fi IP address was checking-in to PMC, PMC was assigning the device to a Subnet which was configured to consider the Visible IP address. When devices are connecting to PMC through the Internet form NATed Subnets, PMC recognizes the public IP address of the Subnet as Visible IP Address of the connecting devices. As most Internet Service Providers by default do not assign to customers static public IP addresses, PMC (versions up to 2.5.1) was creating for the connected devices new Subnets, whenever the public/visible IP address was changing. As these new Subnets were created in the ‘Auto-created Subnets’ Subnet Group, additional manual actions were necessary to move the newly created Subnets to appropriate Subnet Groups, where necessary device profiles were assigned. To eliminate that inconvenience, PMC 2.6.1 introduces support for ‘tagged Subnets’. When a device, in check-in data, reports to PMC a non-empty Subnet Tag value, PMC will ignore the Visible IP Address, but instead will consider the Subnet Tag value, when assigning the device to a Subnet. This allows management of devices located in separate Subnets, even if the Subnets are using the same IP addressing schemes (e.g. 192.168.1.0/24). The Subnets will be differentiated by the Subnet Tag values reported by the devices. Device profiles dedicated to those different Subnets can be reliably assigned that way.

Example: 

In the above example, even though the networks in two branch offices, Office A and Office B, use the same addressing scheme (192.168.1.0/24), even though the devices from both branch offices are connecting to PMC over the Internet with unpredictable public IP addresses, as the managed devices have different (and branch-office-specific) Subnet Tags configured, PMC puts them into separate Subnets. Device Profiles appropriate for each branch office can be assigned to those Subnets. The unpredictable Visible IP addresses of the devices are not taken into consideration when determining the Subnet affiliation of the devices.

When a device reports a Subnet Tag value in the check-in data, but no Subnet with the reported Subnet Tag value exists yet, PMC will create a new tagged Subnet with the reported Subnet Tag value.

Tagged Subnets can also be predefined by PMC administrator. The Consider Subnet Tag and Consider visible IP address options are mutually exclusive.

Subnet Tag values are case insensitive.

Extended support for tagged Subnets (introduced in 2.7.0 and higher versions)

PMC 2.6.1 introduced support for ‘tagged Subnets’. For devices reporting a non- empty Subnet Tag values, PMC 2.6.1 was ignoring the Visible IP address when assigning the devices to Subnets, but the Ethernet or Wi-Fi addresses were still considered. Please refer to the ‘Support for tagged Subnets’ section below for more information.

PMC 2.7.0 (and newer versions) handle the devices reporting empty Subnet Tag values in exactly same way as 2.6.1 (the Ethernet/Wi-Fi and Visible IP addresses are the factors considered by PMC when determining device’s Subnet affiliation), but to better fit the work-from-home scenarios PMC 2.7.0 further extended the support for ‘tagged Subnets’.

The way how PMC 2.7.0 (and newer versions) handle the devices reporting non- empty Subnet Tags depends on PMC’s operation mode, which must be selected after PMC activation. Two options are available:
  2. 'Use network addressing when assigning devices with a Subnet Tag value’ – this selects the “standard mode”, where PMC 2.7.0 (and newer versions) handle the tagged Subnets in the same way as PMC 2.6.1.
  3. ‘Only use device Subnet Tag value when assigning devices to groups’ – this selects the “IP-neutral mode”, where PMC 2.7.0 (and newer versions) completely ignore the addressing information when assigning devices reporting non-empty Subnet Tag values to Subnets. The Subnet Tag value becomes the only determinator. This allows assigning to a single Subnet devices originating from locations using different addressing schemes. Work- from-home scenarios are the best example of such situation, as the home users can connect from home networks with addresses like 192.168.0.0/24, 192.168.1.0/24, 10.0.0.0/24, etc. with unpredictable Visible (public) IP addresses, however from device management perspective having such devices automatically grouped together is still desirable. The “IP-neutral mode” allows that through the Subnet Tags.
The operation mode is only selectable after PMC activation and cannot be changed later. This is because with the same inventory of devices in the database, the PMC Management Server needs to maintain different layout of Subnets.

Please refer to following NComputing Knowledge Base article for more information about the extended support for tagged Subnets introduced in PMC 2.7.0: https://support.ncomputing.com/portal/en/kb/articles/how-to-use-subnet-tags-to-assign-devices-to-groups-in-pmc

PMC backup/restore considerations with extended support for tagged Subnets

Due to the different layouts of Subnets the PMC Management Server needs to maintain depending on the selected PMC operation mode (“standard” vs. “IP- neutral”), the following needs to be considered when restoring PMC backups:

In PMC 2.7.0 (or newer) deployed in “standard mode”:
  2. Backups of PMC 2.5.1 will be fully restored. “Fully restored” means that all PMC appliance and system settings, Devices, Device Groups (Subnet Groups, Subnets, Name Scopes, Asset Tag-based groups, Manual Groups), Profiles, Profiles-to-Groups assignments, Files and Audit Events will be fully restored from the backup.
  3. Backups of PMC 2.6.1 will be fully restored.
  4. Backups of PMC 2.7.0 (or newer) deployed in “standard mode” will be fully restored.
  5. Backups of PMC 2.7.0 (or newer) deployed in “IP-neutral mode” will be partially restored. This means that:
    2. PMC appliance and system settings will be restored,
    3. Devices list will be restored,
    4. Subnet Groups will be restored, 
    5. Untagged Subnets will be restored (with contained Names Scopes,
    6. Asset Tag-based groups and Manual Groups),
    7. Tagged Subnets will be re-created based on Subnet Tag values and device addresses. They will be put into a special Subnet Group.
    8. Device Profiles will be restored and assigned to the original groups whenever possible. If impossible, they will remain unassigned.
In PMC 2.7.0 or 2.9.0 deployed in “IP-neutral mode”:
  1. Backups of PMC 2.5.1 will be partially restored. This means that:
    2. PMC appliance and system settings will be restored
    3. Devices list will be restored
    4. Subnet Groups will be restored
    5. Untagged Subnets will be restored (with contained Names Scopes, Asset Tag-based groups and Manual Groups)
    6. Tagged Subnets will be re-created based on Subnet Tag values and device addresses. They will be put into a special Subnet Group.
    7. Device Profiles will be restored and assigned to the original groups whenever possible. If impossible, they will remain unassigned.
  2. Backups of PMC 2.6.1 will be partially restored (as above).
  3. Backups of PMC 2.7.0 (or newer) deployed in “standard mode” will be partially restored (as above).
  4. Backups of PMC 2.7.1 (or newer) deployed in “IP-neutral mode” will be fully restored.

Support for device screen shadowing

The software components allowing device screen shadowing from PMC act as yet another VNC viewer application. The VNC screen shadowing feature needs to be enabled on the managed devices for the PMC screen shadowing feature to work.
Note: The Raspberry Pi-based devices (RX300, RX-RDP, RX420(RDP) and RX-RDP+) can use the hardware-based H.264 decoder to accelerate the video decoding in RDP, AVD and Windows 365 sessions. The output of that hardware H.264 decoder is inaccessible for the VNC server and thus the shadowing of the device only shows a black screen. To allow shadowing of RDP, AVD and Windows 365 sessions, the H.264 support needs to be disabled. It can be done by specifying following custom parameters:
• For the RDP sessions on RX420(RDP) and RX44(RDP) devices: /noh264
• For the RDP session on RX300, RX-RDP and RX-RDP+ devices: /novcast
• For the AVD (and Windows 365) sessions: h.264 support=b:false
Screen shadowing of devices running RDP or AVD sessions will be possible then, however the session performance can be slightly degraded. We recommend to only temporarily disable the H.264 support, for the duration of the troubleshooting session, and to re-enable it then for the normal operation.

Support for passcode-based device onboarding

When the Require passcode for device onboarding option will be activated under Administration > System Settings, then newly connecting devices will prompt the users to provide the onboarding passcode. Only if the user will provide correct onboarding passcode the device will successfully check-in and will be added to PMC’s database. This is a one-time process only. Already onboarded devices will never prompt users for any onboarding passcodes.

PMC appliance troubleshooting information collector

PMC troubleshooting files contain numerous Linux system logs, application logs and configuration files, which can greatly help NComputing developers resolving product issues. The troubleshooting information can be collected in:
  1. PMC web-based GUI, under Administration > Troubleshooting,
  2. PMC TUI, option 4. – Collect troubleshooting information.

Requesting troubleshooting information from managed devices

The ‘First aid kit’  floating icon of the Devices list allows requesting from the device the troubleshooting logs.
After collecting, the device uploads the archived logs to PMC. This process can take a while (even a few minutes, especially when network tests will be executed). The same ‘First aid kit’ icon in the Flags column of the Devices list indicates that the device has uploaded the troubleshooting logs to PMC. Administrator can download the logs in such case.

Troubleshooting logs collected from all devices are available on the Administration > Files page.

PMC keeps up to 5 troubleshooting log archives uploaded by each managed device.

Event notifications

Whenever an event related to devices, device groups, profiles, licenses, files, or user accounts happens, PMC 2.6.1 can display a pop-up notification and also automatically refresh the affected GUI elements. Each PMC user can configure own preferences regarding which events should cause what actions.

The User Preferences settings can be accessed through the menu, which appears after clicking the PMC user name in the upper-right corner of PMC GUI.
In case of user-initiated events, only other logged on PMC users (not the user who initiated the event) will receive the notifications.

LDAP-based PMC users authentication

PMC 2.5.0 and newer versions 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:
  1. Enable LDAP authentication – this checkbox must be selected.
  2. Server type – only Microsoft AD is currently selectable.
  3. 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.
  4. 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.
  5. CA certificate – an uploaded Certification Authority certificate can be selected here. It will be used to verify the LDAP server certificate, when a secure LDAP (ldaps://...) Server URL will be specified.
  6. 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.
  7. 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).
  8. 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.
  9. 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. Since 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 node (Organization) in the device groups tree.

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

Following users authorization rules apply:
  1. 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.
  2. 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.
  3. Users will have no access to (will not even be able to see) any device groups the user is not authorized for.
  4. 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 configurations. 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 offers tools which greatly simplify or even fully automate the upgrade process.

Following functionalities are available:
  1. Automatic profiles upgrades after uploading schema files with definitions of new device configuration versions.
  2. 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.
  3. Manual profiles upgrades after uploading schema files. The upgrades can be performed with the Upgrade task of the Device Profiles list.
  4. 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.
  5. Automatic upgrades of configurations 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 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: 

  1. 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.
  2. 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.
  3. 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.
  4. 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.
  5. Workaround: The below steps must be followed to update the RX300 3.1.3 firmware to a newer version:
    1. 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.
    2. Invoke the following command to stop the network firewall on PMC appliance: systemctl stop firewalld
    3. 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 192.168.2.10 from the above example.
  6. 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:
    1. Invoke the following command to start the network firewall again: systemctl start firewalld
    2. Revert the Base URL setting to its original value (containing the HTTPS protocol and no port number, like: https://192.168.2.10).
  7. 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.
  8. 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:
    1. With the device GUI visible on the screen press [Ctrl]-[Win]-[F12] to open the ‘rx-terminal’ window.
    2. 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.
  1. Internet Explorer is not supported as a web browser for accessing the web- based PMC GUI.
  2. PMC-697 – Unexpected error while importing PCM appliance into XenServer. 
Note: This message can be safely ignored.

Contacting Technical Support and Additional Resources

Visit the NComputing Knowledge Base at http://kb.ncomputing.com/ for more information, guides, and walkthroughs.
To request Technical Support, please visit the NComputing Support page at http://www.ncomputing.com/support/overview.

Disclaimer

Information contained in this document may have been obtained from internal testing or from a third party. This information is for informational purposes only. Information may be changed or updated without notice. NComputing reserves the right to make improvements and/or changes in the products, programs and/or specifications described herein anytime without notice.

All NComputing software is subject to NComputing intellectual property rights and may be used only in conjunction with Genuine NComputing hardware and in accordance with the NComputing End User Licensing Agreement and Terms of Use.