PMC Version 4, Start Guide

PMC Version 4, Start Guide

Overview

This document based on the release notes of PMC 4.1.1. It covers everything you need to know, in-depth, regarding installation and deployment of PMC.
It is always recommended that you use the current release notes of every PMC version that you download and are planning to deploy. 
This writing contains important information. Please read the entire document to ensure that your deployment process goes smoothly. You can always click anywhere on the table contents to jump faster to a section you're interested in.

Name and Version

NComputing PMC Endpoint Manager
Version 4.1.1

Supported virtual machine environments

  1. VMware ESXi 6.7.0, 7.0.3, 8.0.1
  2. Citrix Xen Server 7.4
  3. Citrix Hypervisor 8.2 CU1
  4. Microsoft Hyper-V Manager Version 10.0.19041.1
  5. Microsoft Azure Cloud
Info
PMC Endpoint Manager has been tested and confirmed to work with the above mentioned versions of supported hypervisors, but it will work with other versions of those hypervisors, as well as with other hypervisors. 

Supported NComputing access devices

  1. L400 with all firmware versions
  2. RX300 with firmware version 3.2.7 or newer
  3. RX-RDP with firmware version 1.1.3 or newer
  4. RX-RDP+ with firmware version 1.10.10 or newer
  5. RX420(RDP) with firmware version 1.2.3 or newer
  6. RX440(RDP) with all firmware versions
  7. EX500 with all firmware versions
  8. LEAFOS(X86) version 2.7.0 or newer
  9. LEAFOS(PI4) version 2.4.5 or newer
  10. Legacy LEAF OS versions 2.0.11 to 2.2.18


About the Product

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


Key Product Features

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


About Release 4.1.1

PMC Endpoint Manager 4.1.1 is a major product release which replaces the 4.0.2 and earlier versions. This release contains new features, improvements, and fixes for bugs affecting earlier versions.

New Product Features

  1. Role-based access control for PMC users.
  2. Ability to define IP address whitelists for PMC users and managed devices.
  3. Ability to define web session policies for PMC users.
  4. Concept of external Authentication Systems.
Please refer to the "More about new product features" section for more information.


Product Improvements

  1. All device profile management tasks moved to device groups.
  2. ‘Logout everywhere’ option in web-based user interface.
  3. Improved information about the required PMC version displayed when trying to upload an incompatible PCU file.
  4. Support for latest configuration versions of NComputing access devices and LEAF OS.

Issues Fixed

  1. PMC-2343 – Inability to update PMC after rolling back a previous update.
  2. PMC-2331 – Screen shadowing passwords are visible.
  3. PMC-2281 – Issues with starting PMC services (displaying the ‘PMC is not ready yet’ message in the GUI) after updating from version 2.9, 3.0, or 3.1, caused by incorrect conversion of old license data, if the license version property was erased due to a bug in the older PMC versions.
  4. PMC-2274 – Issues with restoring PMC 3.x or 4.0 backups if the backup contains audit events related to failed logon attempts of Active Directory users. This problem can also cause the never-ending ‘PMC is not ready yet’ message after performing an in-place update.
  5. PMC-2261 – Issues with delivering files and/or creating new PMC backups, if PMC contains files that were restored from an older backup.
  6. PMC-2254 – File list filtering by file type does not work.
  7. PMC-2249 – Local application names are not displayed in Configuration Editor for RX420(RDP) configuration version 18.
  8. PMC-2248 – In Configuration Editor for LEAF OS v.21 or later, the Application ID does not get checked, which allows creation of multiple apps with the same ID.

PMC Licensing Information

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

  1. Each RX-RDP, RX-RDP+, RX420(RDP), RX440(RDP), EX500 and LEAF OS device comes with a perpetual license for the PMC software and first-year complimentary software maintenance update. After the expiration of the first-year complimentary AMP for RX-RDP, RX-RDP+, RX420(RDP), RX440(RDP) or LEAF OS, the RX-RDP, RX-RDP+, RX420(RDP), RX440(RDP), EX500 or LEAF OS device can only receive firmware updates from PMC. AMP for RX-RDP, RX-RDP+, RX420(RDP), RX440(RDP) and LEAFOS(x86) licenses must be then purchased and allocated to each RX-RDP, RX-RDP+, RX420(RDP), RX44(RDP), EX500, and/or LEAF OS device to allow PMC to push the firmware updates.
  2. 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.
  3. Once PMC is registered to NComputing Management Portal in online mode, it will auto-detect the PMC licensing allowance for L400, RX300, RX-RDP, RXRDP+, RX420(RDP), RX440(RDP), EX500, 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:
  1. 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.
  2. 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.
  3. 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.
  4. 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.
  5. 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.
  6. 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.
  7. 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.
  8. 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.
  9. 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.
  10. To automate the PMC server discovery, the DHCP option 207 can be used. This DHCP option should provide a string value containing the URL in form of ‘https://<PMC_address>’, where <PMC_address> must be replaced with the proper host name or IP address of the PMC virtual appliance.
  11. LEAFOS(X86) 2.9.20 and newer versions support additional PMC server discovery methods:
    1. NComputing Management Portal: the devices will contact the Management Portal to obtain the PMC URL linked there with the LEAFOS license key used for device activation.
    2. DNS: the devices will try to use the ‘https://pmc’ URL to connect to the ‘pmc’ host in current DNS domain (obtained from DHCP or configured statically).
  12. The Management-Portal-based method is specific to LEAF OS devices; however, the support for DNS-based method will be successively added to new firmware of other device models.
    The order in which the discovery methods are tried is following: (1) DHCP, (2) NComputing Management Portal (on LEAFOS only), 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.
  13. 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.
  14. 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 response 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 to 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:

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 11 (the base OS of PMC), the system services installed by the incompatible packages 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:
  1. In the search bar at the top of Azure Portal page, enter ‘Policy’ to find the Policy service and open it.
  2. From the Policy task list on the left, select Authoring > Definitions.
  3. In the toolbar at the top of the page, click the + Policy definition button to create a new Azure Policy.

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

  7. Under Policy Rule, paste the following JSON data:


    {

    "mode": "All",

    "policyRule": {

    "if": {

    "allOf": [

    {

    "field": "type",

    "equals": "Microsoft.Compute/virtualMachines/extensions"

    },

    {

    "field": "Microsoft.Compute/virtualMachines/extensions/type",

    "in": "[parameters('notAllowedExtensions')]"

    }

    ]

    },

    "then": {

    "effect": "deny"

    }

    },

    "parameters": {

    "notAllowedExtensions": {

    "type": "Array",

    "metadata": {

    "description": "The list of extensions that will be denied. Example:

    CustomScriptForLinux, VMAccessForLinux etc.",

    "displayName": "Denied extension"

    }

    }

    }

    }

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


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

  1. From the Policy task list on the left, select Authoring > Assignments.
  2. In the toolbar at the top of the page, click the Assign policy button to create a new Policy Assignment.
  3. 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.
NotesNote: 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.
  1. 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.
  2. 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:

    ["MDE.Linux", "OmsAgentForLinux"]


  1. Click the Review + create button at the bottom of the page.
  2. 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.1.1 supports updates from PMC 3.0.x, 3.1.x, 3.2.x, and 4.0.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 3.x or 4.0 to 4.1.1 (on-prem deployments) 

Please follow the below procedure to perform an in-place update of PMC appliance deployed on-prem:
  1. (Optional but recommended) Using the dedicated management tool of your hypervisor, create a snapshot of your PMC appliance virtual machine. Alternatively, from PMC GUI, create and save outside of PMC a system backup. This is to protect your current PMC against the unlikely case of in- place update failure.
  2. In PMC GUI, under Administration > System Updates, click the [Browse] button to locate the .UPD file containing the PMC 4.1.1 update package. Press the [Apply] button to start the upload process.
Notes
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.
  1. 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.
  2. PMC appliance will be rebooted at the end of the process to apply the changes.

Upgrading “in-place” from PMC 3.x or 4.0.0 to 4.1.1 (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, where only 2 GB are available by default.
Due to the incompatibility of some of the Microsoft packages installed by the extensions with Debian 11 Linux (the base OS of PMC), the system services installed by the incompatible packages 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 3.x or 4.0.0 to 4.1.1.

Notes
Note: The below steps are not necessary if they were already executed when upgrading an older version to 4.0.2.
  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:
    1. 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).
    2. In the toolbar at the top of the page, click the ->Move button, and select Move to another resource group option.
    3. On the Move resources / Source + target page, select the target (or create a new) Resource Group and click Next. 
    4. On the Move resources / Resources to move page, confirm that the necessary resources are selected and, once the validation completes, click Next.
    5. 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.
  2. 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.
  3. 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).
  4. 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.1.1 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.
  5. (Optional but recommended) To allow reverting the changes which will be done in next steps, create a Restore Point of your current PMC VM:
    1. In the Azure Portal, open the PMC VM overview page.
    2. From the task list on the left, select Backup + disaster recovery > Restore point.
    3. Create a Restore Point, which will include all Disks of PMC VM.
  6. Increase the size of the overlay volume filesystem:
    1. In the Azure Portal, open the PMC VM overview page.
    2. From the VM task list on the left, select Settings > Disks.
    3. 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.
    4. Open the properties of this disk by clicking its name.
    5. From the Disk task list on the left, select Settings > Size + Performance.
    6. Specify Custom disk size of at least 5 GB and select a Performance tier.

    7. Click the Save button to update the disk.
    8. 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.

    9. 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

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

  8. 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:
  1. In Azure Portal, open the PMC VM overview page.
  2. From the VM task list on the left, select Settings > Extensions +
    applications.

  3. 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:
  1. In PMC GUI, under Administration > System Updates, click the [Browse] button to locate the .UPD file containing the PMC 4.1.1 update package. Press the [Apply] button to start the upload process.

    NotesNote: 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.1.1 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 to version 4.1.1. This method can also be used to migrate PMC between different types of hypervisors, where an in-place update is not an option.
  1. Logon to your existing PMC appliance as a user belonging to a user group with administrative permissions.
  2. Under Administration > Backup and Restore, click the [Start backup] button to create a PMC backup.
  3. Go to Administration > Files and click the name of the newly created backup file to download it.
  4. Shut the old PMC appliance down.
  5. Deploy a new PMC Endpoint Manager 4.1.1 appliance by following the instructions from the previous section.
  6. Go to PMC 4.1.1 TUI and configure the same static IP address as the one used previously on the backed-up and shut down old PMC appliance.
  7. Login as the ‘pmcadmin’ user to PMC 4.1.1.
  8. Under Administration > Files, select System backup as file type, click the [Browse] button to select the downloaded backup file. Then click the [Upload file] button.
  9. Under Administration > Backup and Restore, in the Restore from a backup file panel, select the uploaded backup file.
  10. When restoring a backup, you can opt to restore the licensing data.
    1. With the Restore licensing data option not selected, PMC 4.1.1 will have to be reactivated after restoring the backup. You may need to manually disconnect your currently activated PMC 4.1.1 instance through your account in Management Portal (under My PMC Installations > My PMC Servers), before reactivating the PMC 4.1.1 appliance after restoring the backup.
    2. With the Restore licensing data option selected, PMC 4.1.1 will reuse the licensing data from the backed-up PMC appliance and reactivation will not be necessary.
  11. 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.
  12. 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.1.1 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.

Notes
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 the Management Portal. Continuing to use both appliances will make one of the appliances out of sync with the Management Portal, causing the licensing grace period to begin on the desynchronized appliance. Disconnecting it from the Management Portal and reactivating will be necessary to restore 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 tthe original PMC appliance. This may happen due to possible virtual Ethernet iinterface 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.1.1

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 introduces 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:
  1. User accounts, which define the PMC users. Users can be members of user groups.
  2. User groups, which define groups of PMC users with the same responsibility. 
    User groups can have roles assigned.
  3. Roles, which define the users’ functions in organization. Roles consist of selected permissions and can be assigned to user groups.
  4. 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.
  5. 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 be automatically become members of the PMC user group.

PMC 4.1.1 has following user roles built-in:

  1. 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, performing licensing-related tasks, creating and restoring PMC backups, uploading definitions of new device configurations (.PCU files), etc.
  2. 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.
  3. 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.

Notes
Note: When updating from older 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. 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:
  1. 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.
  2. 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 way to authenticate remote users was by enabling LDAP authentication. PMC 4.1.1 introduces the concept of external authentication systems, with the LDAP/AD being the first (and the only) one supported by PMC 4.1.1. Future PMC versions will add support for other external authentication systems.
When updating to 4.1.1 from an older PMC version with LDAP/AD authentication enabled, an external authentication system with the type set to ‘Microsoft Active Directory’ will be added automatically. It’s 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.

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 introduces the concept of external Authentication System, where Microsoft Active Directory is the first supported one. Authentication Systems can be defined on the Administration > Authentication Systems page.

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

Following parameters must be configured:
Server type – select Microsoft Active Directory.
Enable – select the checkbox to enable the system.
Display name – specify 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 tthe 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.

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 be 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 tthe 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.
IP access rules for user group members can be configured when editing properties of a user group.

Notes
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:
  1. Never terminate
  2. Terminate when the same user logs on
  3. 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.


Prior to PMC 4.1.1, there was the dedicated Device Profiles page 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, 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.
In 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 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.

More About Product Features Introduced in Earlier PMC Versions 

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.

Notes
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.

Notes
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:
  1. New devices have been connected, for which PMC does not yet have the AMP information and thus cannot determine their manageability or updateability,
  2. New AMP licenses have been purchased and are available in NComputing Management Portal to extend the number of manageable “vSpace” devices,
  3. 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.
Notes
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:
  1. 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.
  2. 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.
  3. 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:
  1. ‘Let the devices use the configured firmware update source and method’ – this is the new option introduced in PMC 3.1.0. When the device receives from PMC a firmware update command with that option selected, the device will try to perform the firmware update using the method and source, which it has configured under the Support settings. The Support > Firmware Update settings are now configurable with PMC. This allows updating the devices working in different locations from different firmware sources. 
    Large firmware update file transfers through WAN links can be avoided thanks to that option. 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.

    Notes
    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.


  2. ‘Let PMC provide the firmware image files to devices’ – this is the option which was always used by PMC prior to version 3.1.0 and is still the default one in PMC 3.1.0. PMC acts as the central source of firmware update files for all devices when this option is selected.

Customization of lists presentation

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

New PMC system update mechanisms

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

Send message feature

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

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

Support for ‘Raise Hand’ requests

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



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

Ability to export the contents of all PMC lists

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

Ability to mark selected devices as ‘lost’ or ‘found’

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

Ability to revoke LEAFOS licenses

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

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

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

Example: 

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

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

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

Subnet Tag values are case insensitive.

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

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

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

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

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

PMC backup/restore considerations with extended support for tagged Subnets

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

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

Support for device screen shadowing

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

Support for passcode-based device onboarding

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

PMC appliance troubleshooting information collector

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

Requesting troubleshooting information from managed devices

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

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

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

Event notifications

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

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

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:
  1. Automatic profiles upgrades after uploading schema files with definitions of new device configuration versions.
  2. When multiple upgrade paths exist, e.g. in case when existing profiles for multiple older configuration versions can be upgraded, the administrator will be able to select which profiles and to which configuration version should be upgraded. The upgraded profiles can be automatically assigned to the same device groups, where the original (old) profiles were assigned.
  3. Manual profiles upgrades after uploading schema files. The upgrades can be performed with the Upgrade task of the Device Profiles list.
  4. Automatic profiles upgrades when restoring a backup containing profiles created for older configuration versions.
    In this case the profiles will be automatically upgraded to the latest available configuration version only. The upgraded profiles can be optionally assigned to the same device groups where the original profiles were assigned.
  5. Automatic upgrades of configurations edited directly on specific devices. When the device configuration was edited in the past directly on a device when the device was using some older configuration version, then PMC will automatically upgrade the edited configuration to device’s current configuration version when the device will report a newer configuration version during check-in.

Device reboot and shutdown schedulers

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

Known Issues and workarounds: 

  1. When new (not yet registered) devices 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.
  2. After changing in the TUI the IP address of PMC appliance’s network interface, the Base URL (under Administration > System Settings in PMC’s web-based user interface) will still contain the old IP address. This happens because the PMC Management Server component only adjusts the Base URL to match the current IP address on system boot-up.
  3. Workaround: Rebooting the PMC virtual appliance after changing the IP address in the TUI resolves the issue. The Base URL can 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.
  4. Firmware updates fail on RX300 devices running the 3.1.3 firmware. This issue happens because the RX300 3.1.3 firmware was not yet ready for firmware downloads through the HTTPS protocol, which is the default communication protocol used by current PMC versions.
    Workaround: The below steps must be followed to update the RX300 3.1.3 firmware to a newer version:
    1. Connect with an SSH client (e.g. PuTTY) to the IP address of the PMC appliance and logon as the 'root' user with 'pmcadmin' password.
    2. Invoke the following command to stop the network firewall on PMC appliance: systemctl stop firewalld
    3. In PMC’s web-based user interface, under Administration > System Settings, change the Base URL of this PMC server in your network' to use the HTTP protocol and port 8080, like: http://:8080/ Double click the URL to edit it. Use the real IP address of the PMC appliance instead of 192.168.2.10 from the above example.
  5. After this change PMC will create the firmware download URLs using the modified Base URL. This will allow the devices running the 3.1.3 firmware to successfully download and update the firmware. 
    To revert the changes after completing firmware updates on all devices do the following:
    1. Invoke the following command to start the network firewall again: systemctl start firewalld
    2. Revert the Base URL setting to its original value (containing the HTTPS protocol and no port number, like: https://192.168.2.10).
  6. 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.
  7. Workaround: If the managed device displays in its local GUI the Audio output priority list with the Audio item spelled with uppercase ‘A’ then resetting the device to factory defaults should resolve the issue. To reset the device to factory defaults, do the following:
    1. With the device GUI visible on the screen press [Ctrl]-[Win]-[F12] to open the ‘rx-terminal’ window.
    2. Invoke the ‘reset-to-factory’ command.
AlertNote: This issue was specific to RX300 device with firmware version 3.2.7 or older. Newer RX300 firmware versions correct this issue automatically during firmware update. NComputing strongly recommends updating all devices to latest available firmware version before starting to manage them from PMC.
  1. Internet Explorer is not supported as a web browser for accessing the web- based PMC GUI.
  2. PMC-697 – Unexpected error while importing PCM appliance into XenServer. 
AlertNote: 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.

© Copyright 2024 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.

​
​

Article Number: 848
Revision Date: 04/2025



    • Related Articles

    • Getting started with RX-HDX and get latest firmware updates

      IMPORTANT NOTE: As of July 1, 2020, NComputing has formed a new partnership with Stratodesk, making the official Stratodesk branded OS and management center available on NComputing devices. Enterprises and organizations using NComputing thin client ...

    • Where can I find the LEAF OS user configuration guide?

      There are multiple guides available for LEAF OS configurations: Getting Started: LEAF OS for Citrix Guide (supported from LEAF OS version 3.7.4 or higher) https://ncomputing.box.com/shared/static/uvo2gec2hqr8q11ebinoipcyfw0t4ygh.pdf Getting Started: ...

    • VERDE 8.3.4.n Installation Guide

      Scope The following installation guide is applicable to VERDE versions 8.3.4.0 and 8.3.4.1. It is expected that the person executing this installer has a working knowledge of Linux commands. Overview The Verde installer (VI) is a bash script with the ...

    • Getting started guide: LEAF OS for Citrix desktop virtualization

      This LEAF OS Getting Started Guide summarizes important configurations to get your organization started with Citrix desktop virtualization with LEAF OS (version 3.7.4 or higher): ...

    • Legacy L-series User Manual

      "Classic Versions" like vSpace 6 will be permanently discontinued after June 30th, 2020.   Please upgrade promptly to our latest platform  vSpace Pro.  If you are using version 6 because of terminals that are not compatible with vSpace Pro 11 or ...