This document is an extraction from the release notes of PMC 3.0. It covers everything you need to know, in-depth, regarding installation and deployment of PMC. It is always recommended that you use the current release notes of every PMC version that you download and are planning to deploy.
You can always click anywhere on the table contents to jump faster to a section you're interested in.
NComputing PMC is an endpoint management system designed and developed to remotely manage NComputing access devices.
PMC Endpoint Manager 3.0.0 is a major Tech Preview* release which replaces the 2.9.x and earlier versions. This release contains new features, improvements and fixes for bugs affecting earlier versions.
Following are the important points to consider before and during PMC installation:
PMC Endpoint Manager 3.0.0 supports updates from PMC 2.7.0 and 2.9.x. Updates from older versions can succeed but have not been tested by NComputing and thus are not officially supported.
Please follow the below procedure to update an older supported PMC version to version 3.0.0:
Depending on whether the reactivation will be necessary or not, after restoring the backup, you will be redirected to PMC 3.0.0 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.
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.0 has 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.0 deployments). The details how to perform the PMC system update will be provided in the Release Notes for the next PMC version.
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.
PMC Endpoint Manager 3.0.0 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 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 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.
More About Product Features Introduced in Earlier PMC Versions
Ability to export the contents of all PMC lists
All PMC lists can be exported in Excel (XLSX), comma-separated (CSV), PDF and HTML formats. Filtered and unfiltered lists can be exported. In the case when the Devices list display is limited due to licensing issues, the list of unlicensed devices can be exported to determine which devices (not shown on the list in PMC UI) are actually causing the issue.
Ability to manage lost devices (mark selected devices as ‘lost’ or ‘found’)
PMC Endpoint Manager 2.9.0 can be used to mark selected devices as ‘lost’ (e.g. stolen). This action will result with the ‘lost’ information being sent for the selected devices to NComputing Management Portal. For LEAFOS devices, the device license will additionally be revoked. The devices marked as ‘lost’ (if still connected to PMC) will receive the request to reset the configuration to factory defaults, lock the UI and block the operability. The ‘lost’ devices will stop communicating with PMC and will become offline. When a device will be found, it can be unlocked from the PMC interface. However, PMC will only send this information to NComputing Management Portal. Devices marked as ‘lost’ will have to be rebooted and will need Internet connectivity to directly contact the Management Portal to receive the ‘found’ information, get unlocked and restore the normal operation.
Ability to revoke LEAFOS licenses
For LEAFOS devices which are no more in use, it is possible to revoke the licenses (which effectively de-activates the device and resets them to factory defaults). The revoked licenses return to the license pool associated with the license key originally used for device activation and can be re-used to activate other LEAFOS devices.
Basic support for tagged Subnets (introduced in PMC 2.6.1)
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.
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)
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 2.9.0 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 2.9.0 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 2.9.0 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 2.9.0 completely ignore the addressing information when assigning devices reporting non-empty Subnet Tag values to Subnet. The Subnet Tag value becomes the only determinator. This allows assigning to 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 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, but 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.
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 2.9.0 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 2.9.0 deployed in “standard mode” will be fully restored.
- Backups of PMC 2.7.0 or 2.9.0 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 2.9.0 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 2.9.0 deployed in “standard mode” will be partially restored (as above).
- Backups of PMC 2.7.1 or 2.9.0 deployed in “IP-neutral mode” will be fully restored.
Support for device screen shadowing
The software components allowing device screen shadowing from PMC act as yet another VNC viewer application. The VNC screen shadowing feature needs to be enabled on the managed devices for the PMC screen shadowing feature to work.
Note: The Raspberry Pi-based devices (RX300, RX-RDP, RX420(RDP) and RX-RDP+) can use the hardware-based H.264 decoder to accelerate the video decoding in RDP, AVD and Windows 365 sessions. The output of that hardware H.264 decoder is inaccessible for the VNC server and thus the shadowing of the device only shows a black screen. To allow shadowing on 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: /noh264
• 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:
- 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 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.
Whenever an event related to devices, device groups, profiles, licenses, files, or user accounts happens, PMC 2.6.1 can display a pop-up notification and also automatically refresh the affected GUI elements. Each PMC user can configure own preferences regarding which events should cause what actions.
The User Preferences settings can be accessed through the menu, which appears after clicking the PMC user name in the upper-right corner of PMC GUI.
In case of user-initiated events, only other logged on PMC users (not the user who initiated the event) will receive the notifications.
LDAP-based PMC users authentication
PMC 2.5.0 and newer versions can leverage an LDAP server to authenticate the PMC users. An Active Directory domain controller can be used as the LDAP server and act as the repository of user accounts and groups.
Following parameters must be configured under Administration > LDAP Settings to enable LDAP authentication:
- Enable LDAP authentication – this checkbox must be selected.
- Server type – only Microsoft AD is currently selectable.
- Server URL – the URL of the LDAP server. Unencrypted (ldap://...) and encrypted (ldaps://...) LDAP connections are supported. If incomplete URL will be specified, PMC will automatically extend it by prepending the protocol prefix and appending protocol specific TCP port number. For the ‘ldap’ protocol (which is the default) the TCP port 389 will be used. For the ‘ldaps’ protocol (which must be specified manually) the TCP 636 port will be used. If a non-standard port should be used for the communication with the LDAP server, the port number should be entered manually. E.g. to securely connect to an AD forest’s Global Catalog server, the ‘ldaps’ protocol will have to be used with manually specified port 3269.
- Domain name – the name of the Active Directory domain. It will be appended to the username specified on the logon page when performing LDAP binds to authenticate the user.
- CA certificate – an uploaded Certification Authority certificate can be selected here. It will be used 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.
- LDAP search base DN – this must be the distinguished name (DN) of a container (Organizational Unit, not a users group!) containing all user and user group objects, which will be used by PMC. All LDAP searches will start at this point and go deeper into the directory structure. In simplest case, this can be the distinguished name of the root of the Active Directory tree (however, this is only advisable for small directories).
- PMC users group DN – this must be the distinguished name of a users group containing the accounts of all PMC users (full admins and helpdesk users). All logging in PMC users must be members of this group for the authentication to succeed.
- Advanced user lookup settings – the advanced user lookup settings are preconfigured with values appropriate for typical Active Directory deployments.
LDAP-based PMC users authorization
Making the PMC users members of the LDAP users group identifiable by the PMC users group DN parameter allows the authentication of the users, but does not grant any permissions to them. Since PMC 2.5.0, the LDAP user can be authorized to access parts of the device infrastructure with full admin (read/write) or helpdesk (read-only) permissions. The authorization is based on users’ membership in LDAP user groups determined by the Full Admin group DN and Helpdesk (read-only) group DN specified at different device grouping levels (Organization, Subnet Group, Subnet).
The authorization settings for the whole Organization are configurable under Administration > LDAP Settings, as well as through the Manage user authorization task, available in the Summary panel after selecting the top-most node (Organization) in the device groups tree.
The Manage users authorizations task, available in each group’s Summary panel, can be used for specifying the distinguished names of the LDAP user groups, whose members will be authorized with full admin or helpdesk permissions at Subnet Group and Subnet levels.
Following users authorization rules apply:
- Users authorized with specific permissions (full admin or helpdesk) for a device grouping level (Organization, Subnet Group or Subnet), are also authorized with the same permissions to manage all underlying device grouping levels.
- Users authorized with any permissions for a device grouping level, are also authorized with helpdesk (read-only) permissions allowing them to see all parent grouping levels.
- Users will have no access to (will not even be able to see) any device groups the user is not authorized for.
- Users authorized with full admin permissions at the Organization level will have the same permissions as the built-in local ‘pmcadmin’ user.
In geographically dispersed environments, this functionality allows nominating regional administrators and helpdesk users and allowing them to manage and/or see only eligible parts of the infrastructure with the devices managed by PMC.
PMC, when composing the effective configuration which will be sent to the managed device, strictly controls the versions of the device configurations used during this process. If multiple profiles for different device families, models and configuration versions are assigned to the device groups, making a hierarchy of groups containing the managed device, then only the profiles matching the managed device family, model and configuration version will be merged together when composing the effective configuration. NComputing continuously develops the device firmware to bring new valuable device features. As these new features often require specific settings, the new firmware versions containing new product features usually introduce new versions of device configurations. Although the new device configuration versions usually contain incremental extensions to older versions, some obsolete settings can be removed too. The strict control of the device configuration versions ensures completeness and consistency of the configuration settings delivered by PMC to managed devices. Thanks to that approach, the managed devices will never receive from PMC incomplete configurations nor receive configurations with parameters not existing in the specification of device’s current configuration version.
When an Organization was using some devices for a while, profiles for the then- current configuration version of the devices were likely created in PMC. If at some time the Organization decided to upgrade (all or some) devices to a newer firmware version which introduced new product features and thus also a new configuration version, the existing profiles will be no more used for composing the effective settings for the upgraded devices. This is because of the configuration version mismatch between the existing profiles and upgraded device firmware. With no profiles existing for devices’ current configuration version, the effective configuration composed by PMC will be empty. Such configuration will not affect any device settings.
To avoid the necessity to manually create new profiles for devices’ new configuration version, PMC offers tools which greatly simplify or even fully automate the upgrade process.
Following functionalities are available:
- Automatic profiles upgrades after uploading schema files with definitions of new device configuration versions.
- When multiple upgrade paths exist, e.g. in case when existing profiles for multiple older configuration versions can be upgraded, the administrator will be able to select which profiles and to which configuration version should be upgraded. The upgraded profiles can be automatically assigned to the same device groups, where the original (old) profiles were assigned.
- Manual profiles upgrades after uploading schema files. The upgrades can be performed with the Upgrade task of the Device Profiles list.
- Automatic profiles upgrades when restoring a backup containing profiles created for older configuration versions. In this case the profiles will be automatically upgraded to the latest available configuration version only. The upgraded profiles can be optionally assigned to the same device groups where the original profiles were assigned.
- Automatic upgrades of 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 will connect to PMC for the first time PMC may not yet have the AMP information associated with the managed devices. Clicking the [Refresh] button under Administration > Licensing in PMC’s web-based user interface will force PMC to report to Management Portal serial numbers of all connected devices. Management Portal will register the new devices and return to PMC the associated licensing information. This will allow PMC to display the devices on the lists.
- After changing in the TUI the IP address of PMC appliance’s network interface the Base URL (under Administration > System Settings in PMC’s web-based user interface) will still contain the old IP address. This happens because the PMC Management Server component only adjusts the Base URL to match the current IP address at system boot-up.
- Workaround: Rebooting the PMC virtual appliance after changing the IP address in the TUI resolves the issue. The Base URL can be changed directly on the Administration > System Settings page of PMC web-based interface too. In this case PMC appliance reboot will not be necessary.
- Firmware updates fail on RX300 devices running the 3.1.3 firmware. This issue happens because the RX300 3.1.3 firmware was not yet ready for firmware downloads through the HTTPS protocol, which is the default communication protocol used by PMC.
- Workaround: The below steps must be followed to update the RX300 3.1.3 firmware to a newer version:
- Connect with an SSH client (e.g. PuTTY) to the IP address of the PMC appliance and logon as the 'root' user with 'pmcadmin' password.
- Invoke the following command to stop the network firewall on PMC appliance: systemctl stop firewalld
- In PMC’s web-based user interface, under Administration > System Settings, change the Base URL of this PMC server in your network' to use the HTTP protocol and port 8080, like: http://:8080/ Double click the URL to edit it. Use the real IP address of the PMC appliance instead of 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.