PRODUCT RELEASE NOTES:
NCOMPUTING PMC ENDPOINT MANAGER, VERSIONS 4.2.1

Product: NComputing PMC Endpoint Manager

Version: 4.2.1

Supported virtualization environments:  

• VMware ESXi 6.7.0, 7.0.3, 8.0.1
• Citrix XenServer 7.4
• Citrix Hypervisor 8.2 CU1
• Microsoft Hyper-V Manager Version 10.0.19041.1
• Microsoft Azure Cloud

PMC Endpoint Manager has been tested and confirmed to work with the above-mentioned versions of supported hypervisors, but it will also work with other versions of those hypervisors, as well as with other hypervisors. 

Supported NComputing access devices:

• L400 with all firmware versions
• RX300 with firmware version 3.2.7 or newer
• RX-RDP with firmware version 1.1.3 or newer
• RX-RDP+ with firmware version 1.10.10 or newer
• RX420(RDP) with firmware version 1.2.3 or newer
• RX440(RDP) with all firmware versions
• RX520, R540, RX580 with all firmware versions
• EX500, EX500W, EX500S with all firmware versions
• LEAFOS(X86) version 2.7.0 or newer
• LEAFOS(PI4) version 2.4.5 or newer
• Legacy LEAF OS versions 2.0.11 to 2.2.18

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:

• 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.
• Ability to edit configuration of selected devices and to push configurations to multiple devices (through device profiles).
• Ability to securely shadow all managed devices’ screens.
• Ability to request and collect troubleshooting information from managed devices. 
• Ability to schedule device firmware updates.
• Readiness to support future device models and configuration versions by uploading configuration definition files.
• Ability to host files (firmware, certificates, wallpapers, etc.) for managed devices.
• Role-based control of PMC users access permissions.
• Deployment as virtual appliance compatible with industry-standard hypervisors and Microsoft Azure Cloud.
• Ability to work in environments with and without Internet connectivity.
• 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.
• Export functions for PMC data contents.
• Localized user interface.

ABOUT THIS RELEASE:

PMC Endpoint Manager 4.2.1 (also referred to as 4.2 in this document) is a major product release which replaces the 4.1.1 and earlier versions. This release contains new features, functionality improvements, security patches, and fixes for bugs affecting earlier versions.

NEW PRODUCT FEATURES IN THIS RELEASE:

• Support for the Microsoft Identity Platform (Entra ID) as an external Authentication System for PMC users.
• Ability to add external users to PMC local user groups.
• Support for TOTP-based Multifactor Authentication (MFA). 
• Option to temporarily lock down user accounts after repeated failed authentication attempts.
• Integration with external notification systems to send critical system event alerts. Enhanced tasks scheduling subsystem.
• GUI-based tools for SSL certificate management.
• Added support for RX520 device models.

Please refer to the More about new product features section for more information.

PRODUCT IMPROVEMENTS IN THIS RELEASE:

• Enhanced System Summary information in PMC Dashboard.
• More detailed Volumes and Storage Space information in PMC Dashboard.
• Auto-expanding the file systems after increasing storage volume size in the hypervisor’s console.
• Effective Configuration view with expand/collapse functionality.
• Enhanced Audit Events subsystem with advanced event filtering.
• Roles and Permissions UI enhancements, including the ability to copy Roles and filter Roles / Permissions list.
• Redesigned backup and restore subsystem. 
• PMC virtual appliance OS updated to Debian 12.
• System components updated to the latest Debian 12 versions.
• Support for the latest configuration versions of NComputing access devices and LEAF OS.

ISSUES FIXED IN THIS RELEASE:

• PMC-2453 – Resolved an issue where “Rename" and "Remove" tasks were unnecessarily available for the "Auto-created subnets" Subnet Group.
• PMC-2478 – Fixed an incorrect error message when viewing the effective configuration of disabled profiles.
• PMC-2476, PMC-2452 – Applied security patches to the PMC appliance base OS and software components. 

PMC LICENSING INFORMATION:

PMC is NComputing’s endpoint management software for L400, RX300, RX-RDP, RX-RDP+, RX420(RDP), RX440(RDP), RX520, RX540, RX580, LEAF OS (including EX500/EX500W/EX500S), and RX420(vSpace) devices. Number of available PMC licenses depends on managed device model and associated AMP (Annual Maintenance Program) status:

• Each RX-RDP, RX-RDP+, RX420(RDP), RX440(RDP), RX520, RX540, RX580, and LEAF OS device (including LEAF OS preinstalled on EX500/EX500W/EX500S devices), comes with a perpetual license for the PMC software and first-year complimentary software maintenance update (aka AMP) license. The RX-RDP, RX-RDP+, RX420(RDP), RX440(RDP), RX520, RX540, RX580, EX500/EX500W/EX500S, or LEAF OS devices with expired AMP will only initiate firmware updates when requested by PMC. Local firmware update attempts will fail on devices with expired AMP. AMP for RX-RDP, RX-RDP+, RX420(RDP), RX440(RDP), and LEAFOS(X86) licenses must be purchased and allocated to RX-RDP, RX-RDP+, RX420(RDP), RX44(RDP), RX520, RX540, RX580, EX500/EX500W/EX500S, and/or LEAF OS devices to allow PMC-initiated firmware updates after the expiration of the fist-year complimentary AMP.
• The L400, RX300 and RX420(vSpace) devices require a separate purchase of AMP for vSpace Pro to receive the PMC software license for that device.
• Once PMC is registered to NComputing Management Portal in online mode, it will auto-detect the PMC licensing allowance for L400, RX300, RX-RDP, RX-RDP+, RX420(RDP), RX440(RDP), RX520, RX540, RX580, EX500, EX500W, EX500S, LEAF OS, and RX420(vSpace) devices that have been connected to PMC. 
• In offline mode, a manual refresh of PMC license will be necessary to determine the device allowance.

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 is opened for the first time. 
• 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.
• The built-in local 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.
• 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. This can be done with the ‘passwd’ command from the Linux shell.
• 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. 
• Following methods are available to allow the managed device to automatically discover the URL of PMC Endpoint Manager:

• DHCP option 207: 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.
• NComputing Management Portal: the devices contact the Management Portal to obtain the PMC URL which is linked there with the LEAF OS license key used for device activation. The PMC URL can also be specified for the device group the device belongs to.
• 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).

The order in which the discovery methods are tried is following: (1) DHCP, (2) NComputing Management Portal, and (3) DNS. Once one method returned an address or URL, no other methods will be tried. The devices will keep trying to use the first successfully discovered PMC address even if the actual PMC connection through the discovered address/URL will be unsuccessful. 

• 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 back to devices the 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 IN AZURE CLOUD:

Since version 3.0.1, PMC Endpoint Manager can be deployed to Azure Cloud. 

When deploying PMC to Azure Cloud, it’s advisable to put the PMC VM into dedicated Resource Group. A new Resource Group can be created in the Create virtual machine step. The already created PMC virtual machine can also be moved to the dedicated Resource Group later.

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 

Microsoft Defender for Cloud considerations

Based on the reports from customers using PMC Endpoint Manager in Azure Cloud, we have noticed that enabling the Microsoft Defender for Cloud option for the Azure Subscription covering the PMC virtual machine can cause serious problems with PMC appliances. The problems arise because the Microsoft Azure Linux Agent (waagent) software component running in PMC virtual machines in Azure Cloud attempts to install certain VM extensions when the Microsoft Defender for Cloud option is enabled. Due to the incompatibility of some of the Microsoft packages installed by the extensions with Debian Linux (the base OS of PMC), the system services installed by the incompatible packages may write massive amounts of messages to system journal, unnecessarily consuming the storage space. A shortage of storage space can lead to serious system problems. To avoid the potential issues caused by Microsoft Defender for Cloud installation, we advise to create and assign an Azure Policy, which will prevent the Defender installation. 

Follow the below steps to create the Azure Policy:

• In the search bar at the top of Azure Portal page, enter ‘Policy’ to find the Policy service and open it.
• From the Policy task list on the left, select Authoring > Definitions.
• In the toolbar at the top of the page, click the  Policy definition button to create a new Azure Policy.

• Under Definition location, select an Azure Subscription which covers your PMC VM.
• Enter some Name for the new Policy (e.g., Prevent Defender extensions installation).
• Under Category, select the Use existing radio-button and select the Compute category.

• Under Policy Rule, paste the following JSON data:

If some JSON data was already there, replace it with the above.

• Click Save to create the new Policy definition.

The created Azure Policy needs to be assigned to the Resource Group containing your PMC virtual machine:

• From the Policy task list on the left, select Authoring > Assignments.
• In the toolbar at the top of the page, click the Assign policy button to create a new Policy Assignment.
• On the Assign policy page, on the Basics tab, under Scope, select your Azure subscription and the Resource Group dedicated for your PMC virtual machines as the Scope for the Policy assignment.

Note: When you omit the Resource Group selection, the Policy will be applied to all ‘Compute’ resources in your Azure Subscription and will prevent the Microsoft Defender for Cloud installation on all virtual machines covered by the subscription, not only on PMC virtual machines.

• On the Assign policy page, go to the Basics tab. Under Basics, select the Policy definition created a moment ago. The Assignment name will be set to selected policy definition name. Select Enabled as Policy enforcement.
• On the Assign policy page, on the Parameters tab, paste the below JSON array (including the square brackets) as the value of the Denied extension parameter:

• Click the Review + create button at the bottom of the page.
• Click the Create button at the bottom of the page to create the Policy Assignment.

When you switch the view to the Resource Group dedicated to PMC virtual machines, the Policy Definition and the Policy Assignment should appear after selecting Settings > Policies from the Resource Group task list on the left-hand side of the page. 

PMC UPDATE INFORMATION:

PMC Endpoint Manager 4.2.1 supports updates from PMC 4.0.x and 4.1.x. Updates from older versions can succeed but have not been tested by NComputing and thus are not officially supported.

Since version 3.0.0, PMC Endpoint Manager supports “in-place” updates of PMC appliances, without the necessity to create and restore system backups. An in-place update will preserve all contents of PMC database (devices, subnets, subnet groups, profiles, local user accounts, etc.), the system settings (including the check-in operation mode), network settings and the licensing information. 

Due to the specifics of the bugfixes included in the PMC 4.0.2 maintenance release (which are also contained in this 4.1.1 release), the in-place update procedures are different for PMC appliances deployed on-premises and for PMC appliances deployed to Microsoft Azure Cloud (where some additional preparation steps are necessary prior to the in-place update).

Upgrading “in-place” from PMC 4.0 or 4.1 to 4.2 (on-prem deployments)

Please follow the below procedure to perform an in-place update of PMC appliance deployed on-prem:

• (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 protect your current PMC against the unlikely case of in-place update failure.
• In PMC GUI, under Administration > System Updates, click the [Browse] button to locate the .UPD file containing the PMC 4.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 update package for on-prem deployments. An attempt to update PMC with incorrect update package will fail.

• The upload, extraction, 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.
• PMC appliance will be rebooted at the end of the process to apply the changes.

Upgrading “in-place” from PMC 4.0 or 4.1 to 4.2 (deployments in Azure Cloud)

Based on the reports from customers using PMC in Azure Cloud, we have noticed that enabling the Microsoft Defender for Cloud option for the Azure Subscription covering the PMC virtual machine can cause serious problems with PMC appliances. The problems arise because the Microsoft Azure Linux Agent (waagent) software component running in PMC virtual machines in Azure Cloud attempts to install certain VM extensions when the Microsoft Defender for Cloud option is enabled. The extensions occupy several hundred megabytes of storage space on one of PMC storage volumes. Due to the incompatibility of some of the Microsoft packages installed by the extensions with Debian Linux (the base OS of PMC), the system services installed by the incompatible packages may write massive amounts of messages to system journal, quickly consuming the remaining storage space. A shortage of storage space can lead to serious system problems.

Following preparation steps are necessary on Azure-hosted PMC VMs prior to in-place upgrade from version 4.0.0 to 4.2.

Note: The below steps are not necessary if they were already executed when upgrading an older version to 4.0.2 or 4.1.1 (e.g., 3.x to 4.0.2 or 4.0.0 to 4.1.1).

• If PMC VM was not deployed to a dedicated Resource Group, it is advisable to move the VM into a Resource Group dedicated to PMC appliance resources. To move the PMC to a dedicated Resource Group:

• In the Azure Portal, open the current Resource Group of the PMC appliance and select the resources belonging to your current PMC appliance (at least the Virtual Machine and the four Disks).
• In the toolbar at the top of the page, click the  Move button, and select Move to another resource group option.
• On the Move resources / Source + target page, select the target (or create a new) Resource Group and click Next.
• On the Move resources / Resources to move page, confirm that the necessary resources are selected and, once the validation completes, click Next.
• On the Move resources / Review page, select the checkbox to confirm you understand the consequences of the move operation and click the Move button to start the process.

• Connect to the PMC VM with SSH or open the Serial Console (Azure Portal > PMC VM > Help options > Serial console) and logon to the admin user account which was created during PMC VM deployment.
• In the Linux shell of the PMC admin user, execute the ‘sudo journalctl --vacuum-size=100M’ command to clean-up the system journal (only leaving 100 MB of the events data, if the size was bigger).
• Execute the ‘sudo du -ah /var/log/ | grep -v "/var/log/journal" | sort -h -r | head -n 11 | tail -n 10’ command to find the top ten largest files (excluding system journal files) in the /var/log directory. Its output will be similar to the following:
  
  

pmcadmin@PMC-4:~$ sudo du -ah /var/log/ | grep -v "/var/log/journal" | sort -h -r | head -n 11 | tail -n 10

108M    /var/log/syslog

48M     /var/log/messages

520K    /var/log/daemon.log

169K    /var/log/dpkg.log

140K    /var/log/cloud-init.log

62K     /var/log/bootstrap.log

52K     /var/log/kern.log

48K     /var/log/auth.log

32K     /var/log/faillog

32K     /var/log/btmp

On PMC appliances which have been running for several months, especially if Azure Defender for Cloud components have been installed, there might be log files with sizes of several hundred megabytes. To truncate such files, execute the following command on each of them (replace <log_file_name> with actual log file name):

echo | sudo tee /var/log/<log_file_name>

• In the Linux shell of the PMC admin user, execute the ‘df -h’ command to determine the storage device of the 2 GB overlay volume. Its output will be like the following:
  
  

pmcadmin@PMC-4:~$ df -h

Filesystem      Size  Used Avail Use% Mounted on

udev            1.9G     0  1.9G   0% /dev

tmpfs           392M  672K  392M   1% /run

/dev/sdb1       7.8G  957M  6.5G  13% /run/live/medium

/dev/loop0      914M  914M     0 100% /run/live/rootfs/filesystem.squashfs

/dev/sdc        2.0G  231M  1.6G  13% /run/live/overlay

overlay         2.0G  231M  1.6G  13% /

tmpfs           2.0G     0  2.0G   0% /dev/shm

tmpfs           5.0M     0  5.0M   0% /run/lock

/dev/sde         32G   60K   30G   1% /media/pmc-data

/dev/sdd        7.8G   75M  7.3G   1% /media/pmc-services

/dev/sda1       7.8G   24K  7.4G   1% /mnt

In the above example, the 2 GB overlay volume (mounted on /run/live/overlay) resides on the /dev/sdc device. Write this information down for further use. The filesystem from the overlay volume stores the changes made to the underlying root filesystem (which is read-only). PMC 4.2 appliances newly deployed to Azure cloud will have the overlay volume size already set to 5 GB. Since increasing the overlay volume size cannot be done from within the VM during the in-place update process, the volume size will need to be manually increased before beginning the in-place update.

• (Optional but recommended) To allow reverting the changes which will be done in next steps, create a Restore Point of your current PMC VM:

• In the Azure Portal, open the PMC VM overview page.
• From the task list on the left, select Backup + disaster recovery > Restore point.
• Create a Restore Point, which will include all Disks of PMC VM.

• Increase the size of the overlay volume filesystem:

• In the Azure Portal, open the PMC VM overview page.
• From the VM task list on the left, select Settings > Disks.
• Under Data disks, locate the one which has the 2 GB size. It should be the LUN 0 one. 

This disk is the /dev/sdc device from the above example and is mounted on /run/live/overlay.

• Open the properties of this disk by clicking its name.
• From the Disk task list on the left, select Settings > Size + performance.
• Specify Custom disk size of at least 5 GB and select a Performance tier.

• Click the Save button to update the disk.
• In the Linux shell of the PMC admin user, execute the following command to extend the filesystem on the disk: ‘sudo resize2fs /dev/sdc’. /dev/sdc is the disk device storing the overlay volume (mounted on /run/live/overlay), as determined in previous steps. If needed, change the /dev/sdc disk device path to a path appropriate for your system. Command output should be like the following: 

pmcadmin@PMC-4:~$ sudo resize2fs /dev/sdc

resize2fs 1.46.2 (28-Feb-2021)

Filesystem at /dev/sdc is mounted on /run/live/overlay; on-line resizing required

old_desc_blocks = 1, new_desc_blocks = 1

The filesystem on /dev/sdc is now 1310720 (4k) blocks long.

• Execute the ‘df -h’ command again to confirm that the filesystem from the overlay volume has been really resized:

pmcadmin@PMC-4:~$ df -h

Filesystem     Size  Used Avail Use% Mounted on

udev           1.9G     0  1.9G   0% /dev

tmpfs          392M  680K  392M   1% /run

/dev/sdb1      7.8G  957M  6.5G  13% /run/live/medium

/dev/loop0     914M  914M     0 100% /run/live/rootfs/filesystem.squashfs

/dev/sdc       4.9G  945M  3.7G  20% /run/live/overlay

overlay        4.9G  945M  3.7G  20% /

tmpfs          2.0G     0  2.0G   0% /dev/shm

tmpfs          5.0M     0  5.0M   0% /run/lock

/dev/sde        32G   60K   30G   1% /media/pmc-data

/dev/sdd       7.8G   75M  7.3G   1% /media/pmc-services

/dev/sda1      7.8G   24K  7.4G   1% /mnt

• Create an Azure Policy to prevent the deployment of problematic Azure Defender for Cloud packages. To create the Policy, follow the instructions from the Microsoft Defender for Cloud considerations section above.
• The created Azure Policy needs to be assigned to the Resource Group containing the PMC VM. To assign the Policy, follow the instructions from the further part of the Microsoft Defender for Cloud considerations section above.

The Defined Policy and the Assignment should prevent the installation of unwanted Microsoft Defender for Cloud extensions, which overconsume the storage space on the overlay volume and flood the system journal. However, if the extensions have already been installed, they will need to be uninstalled manually. 

To uninstall the Microsoft Defender for Cloud extensions:

• In Azure Portal, open the PMC VM overview page.
• From the VM task list on the left, select Settings > Extensions + applications.

• If the MDE.Linux and OmsAgentForLinux extensions are listed, click the name of each one. Click the Uninstall button located at the top of the panel that appears on the right-hand side to uninstall the extension. After uninstallation, the Azure Policy defined and assigned in the previous steps will prevent the reinstallation of these extensions.

After completing the above preparation steps, please follow the procedure below to perform an in-place update of the PMC appliance deployed to Microsoft Azure Cloud:

• In PMC GUI, under Administration > System Updates, click the [Browse] button to locate the .UPD file containing the PMC 4.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 update package for deployments in Azure Cloud. An attempt to update PMC with incorrect update package will fail.

• The upload, extraction, 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.
• PMC appliance will be rebooted at the end of the process to apply the changes.

Migrating from PMC 2.9.x (or newer versions) to 4.2 by restoring a backup

Even though it has not been thoroughly tested by NComputing and thus is not officially supported, the below procedure can be followed to try updating PMC versions 2.9.x (or 3.x) to version 4.2. This method can also be used to migrate PMC between different types of hypervisors, where an in-place update is not an option.

• 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 Endpoint Manager 4.2 appliance by following the instructions from the previous section.
• Go to PMC 4.2 TUI and configure the same static IP address as the one used previously on the backed-up and shut down old PMC appliance.
• Login as the ‘pmcadmin’ user to PMC 4.2.
• 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, you can opt to restore the licensing data. 

• With the Restore licensing data option not selected, PMC 4.2 will have to be reactivated after restoring the backup. You may need to manually disconnect your currently activated PMC 4.2 instance through your account in Management Portal (under My PMC Installations > My PMC Servers), before reactivating the PMC 4.2 appliance after restoring the backup.
• With the Restore licensing data option selected, PMC 4.2 will re-use the licensing data from the backed-up PMC appliance and 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, after restoring the backup, you will be redirected to PMC 4.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.

Important notes: 

Please take into account the ‘PMC backup/restore considerations with extended support for tagged Subnets’ from next sections of this document below.

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 NComputing 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 normal operation.

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 assigned by 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.

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.

MORE ABOUT NEW PRODUCT FEATURES INTRODUCED IN PMC 4.2.1

Using Microsoft Entra ID as an external Authentication System for PMC users

PMC Endpoint Manager 4.2 introduces the support for Microsoft Identity Platform (Entra ID) as yet another external Authentication System. PMC users can now benefit from modern authentication and identity validation technologies, such as passwordless authentication and conditional access.

In order to use Microsoft Entra ID as an external Authentication System for PMC users, the PMC Endpoint Manager must first be registered as an application under Azure tenant’s Entra ID. This can be done on the Microsoft Entra ID > App registrations page of Azure Portal. When registering the application, select the following:

• Account type – Accounts in this organization (single tenant).
• Platform – Single-page application (SPA).
• Redirect URI – The URL to which the browser is redirected after successful user authentication. This must be the PMC Login URL, for example: https://pmc.company.local/pmc/login/.
  
  

While redirects to URLs containing IP addresses may also work, the best practice is to use a fully qualified domain name (FQDN). Depending on whether PMC’s web-based interface is accessed from the internal network or the public Internet, ensure that the internal or public IP address of PMC is properly registered in the organization’s internal and/or public DNS. The DNS should resolve the FQDN used in the Redirect URL to the appropriate internal or public IP address.

The registered application needs to get the following delegated Microsoft Graph API permissions granted:

• User.Read
• profile

To allow seamless (without any consent requests) user authentication in the PMC application, the above listed permissions must have admin consent granted for the user accounts in the tenant organization. The permissions can be added, and the admin consent can be granted in the Azure Portal under Microsoft Entra ID > App registrations > {Name of defined PMC application} > API permissions page:

Configuring Microsoft Entra ID as an external Authentication System

PMC Authentication Systems can be defined in PMC on the Administration > Authentication page. To define Microsoft Entra ID as an Authentication System, use the Create task in the Authentication Systems panel.

The following parameters must be configured:

Server type – selection of the Authentication System type (Microsoft Entra ID).

Display name – the name that will be presented to the users to identify the Authentication System (e.g., on the logon page).

Enable – checkbox to enable the Authentication System.

Use global MFA settings – select this checkbox to additionally enforce the PMC’s own Multifactor Authentication for the users of the Authentication System. In the case of Entra ID, it’s better to use Entra ID’s own MFA, instead of PMC’s MFA.

Tenant ID – the identifier of Entra ID tenant. It can be found in the Azure Portal under Microsoft Entra ID > Overview page.

PMC users group ID – the identifier of the Entra ID user group containing all users allowed to login to PMC. All PMC users originating from Entra ID must be members of this group. Just a successful Entra ID authentication alone is not enough to allow access to PMC.

Client ID – the identifier of the PMC application registered in the Entra ID tenant. This can be found in the Azure Portal under Microsoft Entra ID > App registrations > {Name of defined PMC application} > Overview page. 

Configuring authorization for Entra ID users

Successful authentication of Entra ID users does not automatically grant any permissions to them. To grant some permissions, the Entra ID user group(s) the users belong to must be matched with some local PMC group(s), which in turn can have some user roles assigned. This can be achieved by creating a membership rule. This task is available in the Group Membership Rules panel of the user group edit page under Administration > User Management > User Groups > Edit.

For Entra ID, a membership rule contains an identified (Object ID) of an Entra ID user group. Members of this Entra ID user group will automatically become members of the PMC user group and will be authorized to perform the administrative tasks granted by the permissions enabled in the definitions of the Roles assigned to the user group.

Directly adding external users to local PMC user groups

Besides using the Membership Rules to automatically make users belonging to certain user groups in external Authentication Systems members of local PMC user groups, starting with PMC version 4.2, it is also possible to directly assign such users to local PMC user groups. To do so, follow the procedure below:

• Set up the external Authentication System.
• Let the external user(s) authenticate in PMC. Upon the first logon, the users will not yet have any permissions, so only the Dashboard will be presented to them. This will allow PMC to collect the necessary information about the user accounts as well.
• Under Administration > User Management > User Groups, select the User Group you want to assign the external users members to and execute the Manage users task. The authenticated but not yet authorized user accounts will be listed. 
• Select the user accounts you want to add to the local user group and click the [Save] button.

Since that moment, the selected external users will become authorized to perform the administrative tasks granted by the permissions enabled in the definitions of the Roles assigned to the user group.

Support for Multifactor Authentication (MFA)

Since version 4.2, the Multifactor Authentication (MFA) can be enabled as an additional security measure for PMC user accounts. MFA is a functionality that works in conjunction with and complements the Authentication Systems supported by PMC. The MFA implementation in PMC leverages the Time-Based One-Time Password (TOTP) algorithm defined in the RFC 6238 document. With MFA enabled, PMC will enforce the applicable users to configure an authenticator app (e.g., Microsoft Authenticator or Google Authenticator) by scanning a QR code from the logon screen on the first logon attempt. On subsequent logon attempts, with the MFA already configured for a user account, the user will be prompted to provide a one-time password from the authenticator app to be able to successfully log on. 

The MFA settings are configurable in the MFA Settings panel of the Administration > Authentication page. The ‘Manage MFA settings’ permission is required to perform the MFA-related tasks in PMC. Once enabled globally, local PMC user accounts will be required to configure and use MFA. For user accounts originating from external Authentication Systems (Active Directory or Entra ID), the MFA is optional and can be disabled by deselecting the Use global MFA settings checkbox in the Authentication System’s settings. This is especially advisable for Authentication Systems (like Entra ID) that offer their own MFA mechanisms. 

MFA recovery codes can be optionally enabled for MFA-enforced users. Such codes allow logging on in case of authenticator app unavailability. 

Each user can generate their own MFA recovery codes in the User Preferences dialog. This dialog can be opened by clicking the user name in the upper-right corner of the PMC web-based user interface and by selecting the Preferences option. In the same User Preferences dialog, each user can also erase their own MFA configuration. This will force the user to repeat the authenticator app setup on the next logon.

PMC users with the ‘Manage MFA settings’ permission granted will be able to centrally remove configurations and recovery codes for all PMC users. Corresponding tasks are available in the MFA Setting panel of the Administration > Authentication page.

Option to temporarily lock down user accounts after a number of failed authentication attempts

User lockdown can be enabled in the User Lockdown Settings panel of the Administration > Authentication page. With this feature enabled, once the number of sequentially failed authentication attempts for a particular user exceeds the selected value during the selected time interval, the user account will be locked for the selected time. Successful authentication resets the counter. 

The global User Lockdown functionality applies to local PMC user accounts and is optional for the external Authentication Systems.

Users with ‘Manage user lockdown settings’ permission can unlock the locked user accounts by executing the Unlock task on user accounts selected in the Users panel of the Administration > User Management page.

Concept of external Notification Systems

PMC Endpoint Manager 4.2 introduces the concept of external Notification Systems. Notification Systems can be used to deliver information about significant events taking place in PMC. They consist of Monitors, which continuously check certain PMC system conditions, and Notification Channels, which are responsible for delivering the information to defined recipients. Monitors act as notification sources for the channels.

System Monitors available in PMC 4.2 are:

• Device offline time
• Device user raised hand
• Failed user authentications
• Licensing issues
• Percent of offline devices
• Volume space

Some of the Monitors can be configured to periodically resend the notifications when the triggering condition is continuously met. If resending is disabled (resending interval is set to zero), PMC only sends notifications when new (or previously resolved) problems occur.

Some Monitors can be configured to aggregate the events which happened during selectable time period and to only send summary notifications. With disabled aggregation, the Monitor will immediately send the notification on each new event.

PMC 4.2 provides two channels for notifications delivery: SMTP and Web hook. SMTP channel allows sending the notifications via e-mails. The Web hook  channels make use of web APIs to deliver the notifications. For both channels, a Name must be specified and the Notification sources (Monitors) providing information about system events must be selected. Both channels can be independently enabled or disabled.

Settings specific to the SMTP notification channel are:

• Retry failed messages – In case of inability to send the e-mail message, the attempt will be repeated. 
• Retry attempts – Number of resending attempts before giving up.
• Retry interval – Amount of time between e-mail resending attempts.
• Sender e-mail – E-mail address the notification will be sent from.
• Subject prefix – The prefix, to be prepended to notification-specific e-mail subject.
• Host – Address of the SMTP host.
• Connection security – Selection of the SMTP connection encryption method. Possible selections are: None, SSL/TLS, SARTTLS
• Port – SMTP service port. It should be: 25 for None selected as Connection security, 465 for SSL/TLS, and 587 for STARTTLS.
• Authentication method – Selection of the authentication method required by the SMTP host: No authentication or Normal password.
• User name – User name for Normal password authentication method.
• Password – User password for Normal password authentication method.
• Connection timeout – Amount of time PMC will wait when trying to connect to SMTP host.
• Read timeout - Amount of time PMC will wait for a response from SMTP host. 
• Allow PMC user to subscribe to this channel – When selected, the PMC users, on their Preferences page, will have the option to subscribe to this notification channel and provide own e-mail recipient addresses. 
• Default recipients – List of e-mail addresses PMC will send the notifications to, even if no user subscribed to the channel.

Settings specific to the Web hook notification channel are:

• Request method – The HTTP method to be used when making the API calls: GET, PUT, or POST.
• Base URL – The base URL of the web API service.
• Show advanced settings – When enabled, the advanced request settings will be displayed. 
• Request headers – This advanced setting allows defining additional HTTP headers, which will be sent with the API requests. This might be especially useful when using PUT or POST request methods with custom request bodies. The "Content-Type" header can be overwritten then with a value appropriate for the custom request body.
• Connection timeout – Amount of time PMC will wait when trying to connect to the HTTP host providing the web API service.
• Read timeout – Amount of time PMC will wait for a response from the HTTP host providing the web API service.

Web hook channels require some source-specific settings. These are:

• Context path – URL path, which will be appended to the Base URL when making the API call. Variables (see below) can be used in context paths. Context paths must be set for all sources when the GET request method is selected.
• Split aggregated messages – This option is only meaningful when using the GET method, where the notification data gets appended to the API URL as a query string. When selected, the messages provided by Monitors configured to aggregate the events will be split and sent to the API service in multiple requests.
• Use custom request body template – This option is only meaningful when using PUT or POST request methods. By default, the notification data will be sent as a JSON object created from a built-in template. With a custom body template, the data can also be sent in different format. Variables can be used in custom body templates.

Variables can be used when defining context paths and when creating custom request body templates. They have the form of ${variableName}. ${variableName} will be replaced with the actual value of the named variable when sending the API request. Names of variables available for each notification data source can be listed in the Edit source-specific settings dialog boxes. Some variables (especially the ones containing specific event details) only become available when the Split aggregated messages option is enabled.

SSL certificate settings

All connections to PMC Endpoint Manager are encrypted with the TLS protocol. This regards the connections from managed devices, as well as web browser connections of PMC users. TLS relies on SSL certificates to allow clients (managed devices or web browser) verify the authenticity of PMC hosts. 

The SSL certificates used by the TLS listener of PMC are configurable in the dedicated panel on the Administration > System Settings page. 

PMC allows choosing between:

• Built-in certificate
• Certificate (and private key) generated by PMC and signed by external Certification Authority
• Certificate and private key generated outside of PMC and signed by external Certification Authority

Certificates which are ready to use and can be selected in the Current certificate combo-box are marked with the Ready to use label. Certificates marked as Not configured require further action to become usable. Each certificate type has a dedicated “accordion item” (expandable/collapsable element) in the PMC SSL Certificate Settings panel allowing the execution of the tasks necessary to configure the certificate.

Using PMC to generate the private key and the signing request

To prepare a certificate (and private key) generated by PMC:

• Expand the Certificate generated by PMC settings item.
• Execute the Create new signing request task.
• In New certificate signing request dialog select the private key algorithm and key size, and provide the certificate subject properties. PMC automatically takes the fully qualified domain name from the PMC URL opened in web browser and proposes it as the Common Name (CN) and DNS-based Subject Alternative Name (SAN) for the requested certificate. A different Common Name and more Subject Alternative Names can be specified, if needed. Other certificate subject properties are optional.
• Click the [Create] button to start the private key and certificate signing request creation process.
• Execute the Download CSR file task to download the certificate signing request (CSR) file.
• Send the CSR file to the Certification Authority of your choice for verification and signing.
• Once you have the signed certificate back from the Certification Authority (the file should be in Base64-encoded X.509, aka PEM, format), execute the Upload signed certificate task. If the uploaded signed certificate will match the private key created and stored on the PMC appliance during certificate signing request creation, the certificate will become ready to use.

You can then select the signed certificate in the Current certificate combo-box.

If you need to cancel the pending certificate signing request (e.g., when a request with different properties is required), execute the Cancel pending request task.

If you need to remove from PMC the private key and the signed certificate, select another certificate in the Current certificate combo-box and then execute the Reset action.

Uploading the private key and certificate created externally

To upload to PMC a certificate signed by external Certification Authority, with the private key generated outside of PMC:

• Expand the Certificate and private key uploaded to PMC settings item.
• Execute the Upload new certificate and private key task.
• The Select certificate and private key dialog box allows uploading the certificate and private key stored in two separate files (both should be in PEM format) or uploading the certificate and the private key stored in single PKCS#12 (.pfx or .p12) file. 
• If the private key is encrypted, provide the private key password.
• Click the [Continue] button to upload the files. If the uploaded signed certificate and the private key will match with each other, the certificate will become ready to use.

You can then select the uploaded certificate in the Current certificate combo-box.

If you need to remove from PMC the uploaded private key and certificate, select another certificate in the Current certificate combo-box and then execute the Reset action.

Enhanced Tasks scheduling subsystem

Since version 4.2, the tasks scheduled and executed by PMC can be viewed and managed in a more transparent way. This regards one-time tasks (e.g., firmware updates) as well as repeating tasks, like scheduled device reboots or shutdowns, or tasks executed by Notification Systems.

List of all currently scheduled tasks, including tasks scheduled for all devices, is available on the Administration > Scheduled Tasks page. The permission required to manage the scheduled tasks is ‘Manage tasks’. The built-in PMC super user role grants this permission. The corresponding read-only permission is ‘View tasks’. 

Each task can have one of following states:

• Active – The task will be executed at scheduled time.
• Completed – The one-time task has been completed.
• Suspended – The task is “on hold” and will not be executed at the scheduled time. 
• Canceled – The task has been canceled and will not be executed anymore.

Following operations can be performed on scheduled tasks:

• Suspend – This operation can only be performed on active tasks targeted to devices. Suspended tasks will not be executed at the scheduled time, but will remain on the task list (the schedule is not removed).
• Resume – This operation can only be performed on suspended tasks. After resuming, the tasks will be executed according to their existing schedule.
• Cancel – Removes the task schedule for the selected target (which must be a device) so the task will no longer be executed.
• View history – Displays the task execution history for the selected target, with detailed status for each task execution attempt.
• Scheduler settings – Allows the configuration of how long the execution history of completed, canceled, and active tasks will be kept and the configuration of maximum number of remembered execution records per task.

List of scheduled tasks can be sorted and filtered by most columns. To only display tasks for a specific target, use the Filter option of the Target column and enter a string characterizing the target. This is especially useful when looking for the execution history or current schedule of tasks related to devices.

List of tasks specific to selected device can also be accessed from the Devices list, by clicking the floating “eye” icon ( ), which opens the device details view. List of active tasks will be displayed at the bottom of the dialog box. The view more link opens the Scheduled Tasks page, with the task list filtered to only display the tasks targeted to the selected device.

MORE ABOUT PRODUCT FEATURES INTRODUCED IN EARLIER PMC VERSIONS

Role-base access control (RBAC) for PMC users

Prior to version 4.1.1, only two levels of user privileges were available in PMC Endpoint Manager: full-admin (with read-write permissions and with the ability to perform all administrative actions) and help-desk (read-only permissions, with limited access to administrative actions). The control over the permissions for local PMC users was only possible by making or not making the users members of a user group with “Administrative group” flag set. Users not belonging to any such group only had read-only permissions. For local PMC user accounts the differentiation between full-admin read-write privileges and read-only privileges was only possible at the whole organization level. For LDAP (Active Directory) users, for the whole organization, as well as for Subnet Groups and Subnets, it was possible to separately specify Distinguished Names of Active Directory user groups containing users with full-admin and help-desk only privileges.

PMC 4.1.1 introduced role-based access control (RBAC) to make the control over user permissions to execute administrative actions much more granular. Not only the LDAP/Active Directory users can benefit from the role-based access control, but also the local PMC users.

The role-based access control mechanism makes use of following elements: 

• User accounts, which define the PMC users. Users can be members of user groups. 
• User groups, which define groups of PMC users with the same responsibility. User groups can have roles assigned.
• Roles, which define the users’ functions in organization. Roles consist of selected permissions and can be assigned to user groups.
• Permissions, which allow (when granted through a role) or disallow (when not granted) executing specific administrative actions. Permissions can be selected when defining a user role.
• Group membership rules, which allow automatic assignment to user groups the users whose identity was confirmed by an external Authentication System (e.g., Microsoft Active Directory). Group membership rules are a property of a user group. For Active Directory, a membership rule contains a distinguished name of an Active Directory user group. Members of this AD user group will automatically become members of the PMC user group.

PMC 4.1.1 and newer versions have following user roles built-in:

• PMC super user – Members of user groups with this role assigned will have all possible permissions. This role grants the same permissions as the membership in an “Administrative group” in PMC versions prior to 4.1.1. This not only includes the device management tasks, but also the administrative actions like managing global PMC settings, updating PMC, performing licensing-related tasks, creating and restoring PMC backups, uploading definitions of new device configurations (.PCU files), etc.
• Device administrator – This role grants permissions necessary to perform typical device management tasks, like creating device profiles, editing configurations, shadowing devices, rebooting or shutting down devices, managing files, etc.
• Helpdesk agent – This role grants permissions to device management tasks which do not alter device configurations.

Custom roles can be defined and assigned to user groups to grant special sets of permissions.

Note: When updating from pre-4.1 PMC versions, the local user groups which had the “Administrative group” flag set (e.g., ‘pmcadmins’), will automatically get the ‘PMC super user’ role assigned in PMC 4.1.1 (or newer). However, the groups which prior to update did not have this flag set, will not get any roles assigned, especially they will not have the ‘Helpdesk agent’ role assigned. If necessary, the assignment of the ‘Helpdesk agent’ role (or of some custom role) will have to be done manually by a user with appropriate permissions.

The user accounts, roles, and user groups (including the membership rules) can be configured on the consolidated Administration > User Management page.

Using RBAC to configure authorization of PMC users

The authorization to perform specific administrative actions results from the permissions, which have been granted to the PMC user groups the given user belongs to. The authorization is configurable with the Manage assigned user groups task, which is available in the Summary panels of the whole Organization, each Subnet Group and each Subnet. Members of the assigned user groups will be authorized to perform on the device group the administrative actions resulting from the permissions granted to the user groups. The Show user permissions task located in the same place can be used to display the effective permissions for each authorized PMC user. Only permissions related to device management will displayed. 

Following user authorization rules apply:

• Users authorized with specific permissions for specific device grouping level (Organization, Subnet Group, or Subnet), are also authorized with the same permissions to manage all underlying device grouping levels.
• Users will have no access to (will not even be able to see) any device groups the user is not authorized for.

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

Concept of external Authentication Systems

Before PMC 4.1.1, the only possibility to authenticate remote users was to enable LDAP authentication. PMC 4.1.1 introduced the concept of external Authentication Systems, with the LDAP/AD being the first (and the only) one supported by PMC 4.1.1.

Using Active Directory as external Authentication System for PMC users

Since PMC Endpoint Manager version 2.5.0 it is possible to use LDAP servers 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. PMC Endpoint Manager 4.1.1 introduced the concept of external Authentication Systems, where Microsoft Active Directory was the fist supported one. Authentication Systems can be defined on the Administration > Authentication page. 

To define a new Authentication System, use the Create task.

Following parameters must be configured:

Server type – selection of the Authentication System type (e.g., Microsoft Active Directory).

Enable – the checkbox to enable the Authentication System.

Display name – the name which will be presented to the users to identify the Authentication System (e.g., on the logon page).

Server URL – the URL of the Active Directory domain controller acting as the LDAP server. Unencrypted (ldap://…) and encrypted (ldaps://…) LDAP connections are supported. If an 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 to verify 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.

User lookup base DN – this must be the distinguished name (DN) of an Organizational Unit, not a user 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 user group containing the accounts of all PMC users. All signing-in PMC users must be members of this group for the Active Directory authentication to succeed. 

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

Active Directory configuration when updating a PMC instance which had LDAP/AD authentication enabled

When updating to 4.1.1 (or to a newer version) from an older PMC version (2.5.0 or newer) with LDAP/AD authentication enabled, an external authentication system with the type set to ‘Microsoft Active Directory’ will be added automatically. Its configuration will be taken from the LDAP configuration of the original version. Based on the Distinguished Names of the user groups which in the original version were authorized as full-administrator or helpdesk, the new user groups will be created with group membership rules configured with appropriate LDAP/AD Distinguished Names. The created user groups will get the PMC super user or Helpdesk agent roles assigned, depending on the authorization configuration in original version. The created user groups will also be assigned to the device groups (Organization, Subnet Group, or Subnet) where the Distinguished Names were originally specified in Manage User Authorization dialog. 

Configuring authorization for Active Directory users

Successful authentication of Active Directory users does not yet grant any permissions to them. To grant some permissions, the Active Directory group(s) the users belong to must be matched with some local PMC group(s), which in turn can have some user roles assigned. This can be achieved by creating a membership rule. This task is available in the Group Membership Rules panel of the user group edit page.

For Active Directory, a membership rule contains a distinguished name of an Active Directory user group. Members of this AD user group will automatically become members of the PMC user group.

Ability to define IP address whitelists for PMC users and managed devices

To enhance the security of PMC, since version 4.1.1, it is possible to define whitelists of IP addresses for PMC users and managed devices. Only user or device connections originating from whitelisted addresses will be accepted. 

IP address whitelists consist of IP rules in form of Subnet CIDR or IP address range. E.g., 10.200.57.0/24, 10.200.52.0-10.200.59.0, 107.15.144.36/32. The last example, which is a CIDR with 32-bit network mask, defines a subnet consisting of single IP address, effectively limiting the access to the 107.15.144.36 IP address only. Alternatively, a range with the same start and end address can be use to also limit the rule to just a single IP address.

To enable the IP whitelist feature, the Enable IP access rules switch needs to be turned on in the IP Access Restrictions panel on the Administration > System Settings page.

IP access rules for devices can be configured on the dedicated panel on the Administration > System settings page.

Note: When determining device’s eligibility to connect to PMC, PMC checks whether the Visible IP address of the device is allowed by any of the defined IP access rules.

IP access rules for user group members can be configured when editing properties of a user group.

Note: If the IP whitelist has been improperly defined, effectively preventing access for all PMC users, then the main Enable IP access rules switch can be turned off in the Text-based User Interface (TUI).

Ability to define web session policies for PMC users

The ability to define web session policies is yet another security feature introduced in PMC 4.1.1. The web session policy defines the behavior of existing user sessions when the same or another user logs on from another web browser. The available web policy selections are:

• Never terminate
• Terminate when the same user logs on
• Terminate when any other group member logs on

The web session policies are properties of user groups and can be selected when editing the groups.

New location of tasks related to Device Profiles

Prior to PMC 4.1.1, the dedicated Device Profiles page was accessible from the side menu. This has been removed in PMC 4.1.1 and all task related to the management of Device Profiles have been moved to Device Profiles panels in the device groups. New profiles can be now directly created in the target device groups and there is no need to assign the Device Profiles anymore. 

New profiles, which will be created in PMC 4.1.1 or newer versions, are not enabled by default. Configurations of not yet enabled profiles can be edited and saved, but the device settings from such profiles will not be included in the calculation of effective configurations. Only after enabling the profile, the device settings will go to the effective configurations. 

PMC Endpoint Manager versions up to 4.0.2 allowed creation of multiple unassigned profiles for the same device family, device model, and configuration version. Since 4.1.1, with the new location of the device profile tasks, it is not possible anymore, as each created profile will be immediately assigned to the device group, where the profile was created. When upgrading from previous PMC versions, the profiles which existed but were not assigned to any device group, will be converted to profile files and made available on the Administration > Files page. The new Import configuration profile task allows importing the profile from a file. Export configuration task can be used to save the selected profile as a file. This allows reusing the profile in some other device group or even in other PMC instance.

Localization of the PMC web-based user interface

The web-based user interface of PMC Endpoint Manager is now available in following languages: English, German, French, Spanish, Portuguese, Chinese (traditional and simplified), Korean, and Japanese. The user interface language can be selected on the logon screen. After logon, the language can be changed under User Preferences.

The User Preferences settings can be accessed through the menu, which appears after clicking the PMC username in the upper-right corner of PMC GUI.

Note: The Text-based User Interface (TUI) of PMC virtual appliance, accessible through the dedicated management tool of your hypervisor, is and will remain only available in the English language.

Offline mode – ability to activate and use PMC in environments without Internet access.

The offline activation mode is an option for customers whose PMC appliances are connected to restricted networks and cannot get in direct touch with NComputing Management Portal. When activating the PMC appliance or refreshing the licensing information in offline mode, the same information which PMC normally (in online mode) sends over the Internet will be exchanged in form of request and license files. 

Note: The offline activation option is not enabled by default for customer accounts in NComputing Management Portal. To enable the offline option, please get in touch with NComputing Technical Support or with your NComputing Sales Representative before proceeding.

PMC activation in offline mode

To activate PMC in offline mode, proceed as following:

1. After deploying a new PMC appliance, on the main activation page, click the Switch to offline activation link at the bottom of the page.
2. On the offline PMC activation page, enter a name for the new PMC appliance and click the [Download request file] button.
3. After downloading the offline activation request file from PMC, copy the file to a computer with unrestricted Internet access and logon to NComputing Management Portal (https://manage.ncomputing.com).
4. In NComputing Management Portal, go to My PMC Installations, open the Offline Licensing page, and upload the request file there to create and download a PMC license file.
5. Move back to the PMC GUI and click the Upload the license file to complete the offline activation process link at the bottom of the offline activation page.
6. On the license file upload page, click the [Browse] button to select the PMC license file downloaded from NComputing Management Portal.
7. Select the checkbox to confirm that you accept the NComputing End-User License Agreement and click the [Upload license file] button.
8. If the license file downloaded from the Management Portal matches the request file created in step 2., PMC appliance will be activated, and the offline activation process will be completed.

Note: If you generated a new offline activation request file after downloading the license file from the Management Portal, you will have to repeat the procedure starting at step 4.

PMC license refresh in offline mode

In online mode, PMC contacts the NComputing Management Portal every day and automatically refreshes the license information. Manual license refresh is only necessary when the PMC administrator wants to accelerate the process after connecting new devices (for which PMC does not yet have the AMP information) or after purchasing or renewing the AMP licenses.

As in offline mode such automatic license refresh process cannot take place, the manual offline refresh will be usually necessary when:

• new devices have been connected, for which PMC does not yet have the AMP information and thus cannot determine their manageability or updateability,
• new AMP licenses have been purchased and are available in NComputing Management Portal to extend the number of manageable “vSpace” devices,
• new AMP licenses have been purchased and are available in NComputing Management Portal to extend the number of updatable “LEAF OS” and “RDP” devices.

To perform a PMC license refresh in offline mode, proceed as following:

1. In PMC GUI, go to Administration > Licensing page and click the [Download license update request file] button.
2. After downloading the license update request file from PMC, copy the file to a computer with unrestricted Internet access and logon to NComputing Management Portal (https://manage.ncomputing.com).
3. In NComputing Management Portal, go to My PMC Installations, open the Offline Licensing page, and upload the request file there to create and download a PMC license file.
4. Move back to the PMC Administration > Licensing page.
5. Click the [Browse] button to select the PMC license file downloaded from NComputing Management Portal.
6. Click the [Upload license update file] button to complete the process.

Note: If you generated a new offline license update request file after downloading the license file from the Management Portal, you will have to repeat the procedure starting at step 3.

Offline activation/licensing mode limitations

In offline mode, some limitations apply to following product features:

• Revoking LEAF OS licenses – the selected LEAF OS devices (if online) will immediately receive from PMC the requests to invalidate their licenses, but the NComputing Management Portal will only receive the invalidation requests upon next PMC license refresh, which is a manual process in offline mode.
• Marking devices as lost - the selected devices (if online) will immediately receive from PMC the requests to reset the configurations to factory defaults, LEAF OS devices will additionally receive the requests to invalidate their licenses, but the NComputing Management Portal will only receive the corresponding requests upon next PMC license refresh, which is a manual process in offline mode.
• Marking devices as found - as the devices previously marked as lost can only be unlocked by the Management Portal, unlocking the devices (marking them as found) will be impossible in offline environments. To mark the devices as found, not only an update of PMC license will be necessary, but the devices will also have to be connected to a network with Internet connectivity. 

As in offline mode the PMC license refresh requires manual creation of license update request file and upload of that file into Management Portal, it is advisable to perform the license refresh as soon as possible. Otherwise, if the devices with invalidated licenses or the devices marked as lost will be moved to a network with Internet connectivity, the Management Portal, based on the outdated information it will still have, will re-send to the devices the previous licenses, or will unlock the lost devices.

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:

• ‘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. The method based on the FTP/HTTP URL is especially useful with that option, as it allows using web or FTP servers in device locations to deliver the firmware updates locally. It is up to the IT department to set up 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 a situation, it is 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 the firmware update.

• ‘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.x 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 introduced the support for the ‘Raise Hand’ requests, which can be sent by the managed devices. Such requests will be sent when the device user presses the Shift-Ctrl-F2 key combination. Upon receiving the ‘Raise Hand’ request, PMC will display a notification and put timestamp information into the newly introduced Raised 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 use the Raise Hand feature to indicate that. The Raised hand time column allows sorting and filtering to find the devices even quicker. 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 Devices list in PMC GUI) are causing the issue.

Ability to 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 in the ‘lost’ information being sent for the selected devices to NComputing Management Portal. For LEAF OS 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 is 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 LEAF OS licenses

For LEAF OS devices which are no longer 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 LEAF OS devices.

Basic support for tagged Subnets (introduced in PMC 2.6.1)

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 from 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 PMC 2.7.0)

PMC 2.6.1 introduced support for ‘tagged Subnets’. For devices reporting a non-empty Subnet Tag value, 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:

• ‘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. 
• ‘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 device 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 a 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”:

• 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.
• Backups of PMC 2.6.1 will be fully restored.
• Backups of PMC 2.7.0 (or newer) deployed in “standard mode” will be fully restored.
• Backups of PMC 2.7.0 (or newer) deployed in “IP-neutral mode” will be partially restored. This means that:

• PMC appliance and system settings will be restored,
• Devices list will be restored,
• Subnet Groups will be restored,
• untagged Subnets will be restored (with contained Names Scopes, Asset Tag-based groups, and Manual Groups),
• tagged Subnets will be re-created based on Subnet Tag values and device addresses. They will be put into a special Subnet Group.
• 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 newer) deployed in “IP-neutral mode”:

• Backups of PMC 2.5.1 will be partially restored. This means that:

• PMC appliance and system settings will be restored,
• Devices list will be restored,
• Subnet Groups will be restored,
• untagged Subnets will be restored (with contained Names Scopes, Asset Tag-based groups, and Manual Groups),
• tagged Subnets will be re-created based on Subnet Tag values only. They will be put into a special Subnet Group.
• Device Profiles will be restored and assigned to the original groups whenever possible. If impossible, they will remain unassigned.

• Backups of PMC 2.6.1 will be partially restored (as above).
• Backups of PMC 2.7.0 (or newer) deployed in “standard mode” will be partially restored (as above).
• 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 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 RX440(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 only temporarily disabling the H.264 support, for the duration of the troubleshooting session, and re-enable it then for 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 resolve product issues. The troubleshooting information can be collected in:

• PMC web-based GUI, under Administration > Troubleshooting,
• 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 are 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. Administrators can download the logs in such cases. 

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

PMC keeps up to five 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 username 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.

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 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:

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

When multiple upgrade paths exist, e.g., in case 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 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: 

• When new (not yet registered) devices connect to PMC for the first time, PMC may not yet have the AMP information associated with the managed devices. If PMC has been activated in online mode, 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. If PMC has been activated in offline mode, a manual refresh of the PMC license information will be necessary to register the devices with the Management Portal and to display them on the unrestricted lists. Refer to the ‘PMC license refresh in offline mode’ section of this document for more information.
• 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 on system boot-up.
  Workaround: Rebooting the PMC virtual appliance after changing the IP address in the TUI resolves the issue. The Base URL can also 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 current PMC versions.

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://192.168.2.10: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.

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: https://192.168.2.10).

• 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 the latest available firmware version before starting to manage them from PMC.

• Internet Explorer is not supported as a web browser for accessing the web-based PMC GUI.
• 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.

www.ncomputing.com

© Copyright 2025 NComputing Global, Inc. All rights reserved. NComputing is the property of NComputing Global, Inc. Other trademarks and trade names are the property of their respective owners. Specifications are subject to change without notice. Performance may vary, depending on the configuration of the shared computer.