Product: NComputing PMC
Version: 2.5.0
Supported virtual machine environments:
PMC has been tested and confirmed to work with the above-mentioned versions of supported hypervisors, but it will work with other versions of these hypervisors too.
Supported NComputing access devices:
This document contains important information. Please read the entire document to ensure that your deployment process goes smoothly.
NComputing PMC is a device management system designed and developed to remotely manage NComputing access devices. PMC Device Management provides simple and powerful device management for RX300, RX-RDP, RX420(RDP) and LEAF OS thin clients. PMC does NOT support RX-HDX nor RX420(HDX) (Citrix) thin clients.
Number of available PMC licenses depends on managed device model and associated AMP (Annual Maintenance Program) status:
Following are the important points to consider before and during PMC installation:
Below is some general information about how PMC works:
- Each device managed by PMC must belong to a Subnet. Subnets will be identified by Subnet IP address, Subnet Mask and device’s Visible IP Address. Subnets exist in Subnet Groups. When a device from a not yet known Subnet connects to PMC, then PMC creates the Subnet automatically and puts it into the ‘Auto-created Subnets’ Subnet Group.
- Subnet Groups can be created manually and the Subnets can be moved between Subnet Groups.
- Subnets can be created manually too, even before the first device from the Subnet will connect to PMC.
- A Visible IP Address and Visible IP Address Mask can be specified when creating a Subnet. The Visible IP Address can be used to differentiate NAT-ed Subnets using the same local IP addressing.
- PMC allows assigning device profiles at several different levels: Organization, Subnet Groups, Subnets, Name Scopes, Asset Tag-based Groups, Manual Groups.
- Profiles for different device families/models and different configuration versions of the same model can be assigned at all levels.
- Profiles do not need to contain all device settings. Only the necessary subset of settings can be defined in each profile.
- When a device model using particular configuration version connects to PMC, PMC merges settings from all profiles matching the configuration version used by the device, to create the effective configuration. Effective configuration will be sent to the device.
- Settings merging (to create the effective configuration) happens in the above mentioned order: first the settings from appropriate (matching device's family/model/version) Organization's profile will be taken, then from the Subnet Group (which reflects a site or geographical location) the device belongs to, then from the Subnet, and so on. Settings from profiles assigned at Organization level are the most global (as all connected devices belong to Organization group), thus things like branding (desktop wallpaper) or CA certificates (for 802.1x network connections) should be contained there.
- If same settings are defined in profiles assigned at different levels, then the settings from profiles assigned at more specific (lower) level overwrite settings from more general (higher) level, e.g. settings defined in a profile assigned to a Subnet Group overwrite settings from profile assigned at Organization level (if same settings but with different values exist in both profiles). Settings from a profile assigned to Subnet overwrite settings from profiles assigned to Subnet Group and Organization, and so on, up to Manual Groups.
- PMC assigns devices to Name Scopes (inside Subnet) by parsing device name and matching it with device name pattern defined for the Name Scope.
- PMC assigns device to Asset Tag-based Groups by checking the value of the Asset Tag reported by the device.
- Devices (inside Subnet) can be manually assigned to Manual Groups.
- Name Scopes, Asset Tag-based Groups, and Manual Groups can be used when some specific settings need to be provided to a specific groups of devices (e.g. belonging to organization's department, building floor, room, etc.).
- Device saves locally the configuration received from PMC. This configuration will remain active even if the device will lose PMC connectivity.
- If devices belonging the same department in Organization's structure exist in different locations (Subnet Groups) then the same profiles with department-specific settings can be assigned to Name Scopes, Asset Tag-based, or Manual Groups created under different Subnets.
Please follow the below procedure to update an older PMC version to version 2.5.0:
Depending on whether the reactivation will be necessary or not, you will be redirected to PMC 2.5.0 activation page or to logon page, after restoring the backup. All devices, device settings, profiles, local user accounts, local user groups, uploaded files, and server settings will be restored. When restoring a backup of PMC 2.0.0, 2.0.1 or 2.0.6 also virtual appliance’s network settings, all Subnet Groups, Subnets, Name Scopes, Asset Tag-based groups, and Manual Groups, as well as device profile assignments to those groups will be restored.
Note: When a backup of a PMC appliance was created with the intention to be restored together with the licensing data on a newer PMC version, then the original (backed-up) appliance should be shut down and never used again. This is to keep consistency of the access tokens contained in the backup and restored on the new PMC appliance. Continuing to use both appliances will make one of the appliances out of sync with the Management Portal, causing the licensing grace period to begin on the desynchronized appliance. Disconnecting it from the Management Portal and reactivating will be necessary to restore the normal operation.
Note: Restoring a backup of a PMC appliance which had a static IP address, on a PMC appliance which currently has a different IP address (static or DHCP), will result with the web-based user interface losing the connection with PMC. To continue working with PMC after restoring such backup, the web-based user interface will have to be reopened through a new URL based on the restored static IP address.
Note: When restoring in PMC running on a new hypervisor a backup of PMC deployed to a different hypervisor, e.g. when restoring on PMC running on VMware ESXi a backup of PMC deployed to Hyper-V, the restore procedure may not correctly restore the static IP address of the original PMC appliance. This may happen due to possible virtual Ethernet interface names difference between the hypervisors. Please confirm in the Text-based User Interface that PMC has configured the expected static IP address, after restoring the backup. Set the correct static IP address manually, when necessary.
PMC 2.5.0 brings following new major product features:
LDAP-based PMC users authentication
PMC 2.5.0 can leverage an LDAP server to authenticate the PMC users. An Active Directory domain controller can be used as the LDAP server and act as the repository of user accounts and groups. Following parameters must be configured under Administration > LDAP Settings to enable LDAP authentication in PMC 2.5.0:
Enable LDAP authentication – this checkbox must be selected.
Server type – only Microsoft AD is currently selectable.
Server URL – the URL of the LDAP server. Unencrypted (ldap://…) and encrypted (ldaps://…) LDAP connections are supported. If incomplete URL will be specified, PMC will automatically extend it by prepending the protocol prefix and appending protocol specific TCP port number. For the ‘ldap’ protocol (which is the default) the TCP port 389 will be used. For the ‘ldaps’ protocol (which must be specified manually) the TCP 636 port will be used. If a non-standard port should be used for the communication with the LDAP server, the port number should be entered manually. E.g. to securely connect to an AD forest’s Global Catalog server, the ‘ldaps’ protocol will have to be used with manually specified port 3269.
Domain name – the name of the Active Directory domain. It will be appended to the username specified on the logon page when performing LDAP binds to authenticate the user.
CA certificate – an uploaded Certification Authority certificate can be selected here. It will be used for verification of the LDAP server certificate, when a secure LDAP (ldaps://…) Server URL will be specified.
Ignore certificate subject – this option allows using the ‘ldaps’ protocol for connections to LDAP servers presenting certificates with Subject’s canonical name not matching server’s FQDN.
LDAP search base DN – this must be the distinguished name (DN) of a container (Organizational Unit, not a users group!) containing all user and user group objects, which will be used by PMC. All LDAP searches will start at this point and go deeper into the directory structure. In simplest case, this can be the distinguished name of the root of the Active Directory tree (however, this is only advisable for small directories).
PMC users group DN – this must be the distinguished name of a users group containing the accounts of all PMC users (full admins and helpdesk users). All logging in PMC users must be members of this group for the authentication to succeed.
Advanced user lookup settings – the advanced user lookup settings are preconfigured with values appropriate for typical Active Directory deployments.
LDAP-based PMC users authorization
Making the PMC users members of the LDAP users group identifiable by the PMC users group DN parameter allows the authentication of the users, but does not grant any permissions to them. In PMC 2.5.0, the LDAP user can be authorized to access parts of the device infrastructure with full admin (read/write) or helpdesk (read-only) permissions. The authorization is based on users’ membership in LDAP user groups determined by the Full Admin group DN and Helpdesk (read-only) group DN specified at different device grouping levels (Organization, Subnet Group, Subnet).
The authorization settings for the whole Organization are configurable under Administration > LDAP Settings, as well as through the Manage user authorization task, available in the Summary panel after selecting the top-most Organization node in the device groups tree.
The Manage users authorizations task, available in each group’s Summary panel, can be used to enter the distinguished names of the LDAP user groups to authorize the users with full admin or helpdesk permissions at Subnet Group and Subnet levels.
Following users authorization rules apply:
- Users authorized with specific permissions (full admin or helpdesk) for a device grouping level (Organization, Subnet Group or Subnet), are also authorized with the same permissions to manage all underlying device grouping levels.
- Users authorized with any permissions for a device grouping level, are also authorized with helpdesk (read-only) permissions allowing them to see all parent grouping levels.
- User will have no access to (will not even be able to see) the device groups the user is not authorized for.
- Users authorized with full admin permissions at the Organization level will have the same permissions as the built-in local ‘pmcadmin’ user.
In geographically dispersed environments, this functionality allows nominating regional administrators and helpdesk users and allowing them to manage and/or see only eligible parts of the infrastructure with the devices managed by PMC.
Tools for automatic and manual device profiles upgrades
PMC, when composing the effective configuration which will be sent to the managed device, strictly controls the versions of the device configurations used during this process. If multiple profiles for different device families, models and configuration versions are assigned to the device groups, making a hierarchy of groups containing the managed device, then only the profiles matching the managed device family, model and configuration version will be merged together when composing the effective configuration. NComputing continuously develops the device firmware to bring new valuable device features. As these new features often require specific settings, the new firmware versions containing new product features usually introduce new versions of device configuration. Although the new device configuration versions usually contain incremental extensions to older versions, some obsolete settings can be removed too. The strict control of the device configuration versions ensures completeness and consistency of the configuration settings delivered by PMC to managed devices. Thanks to that approach, the managed devices will never receive from PMC incomplete configurations nor receive configurations with parameters not existing in the specification of device’s current configuration version.
When an Organization was using some devices for a while, profiles for the then-current configuration version of the devices were likely created in PMC. If at some time the Organization decided to upgrade (all or some) devices to a newer firmware version which introduced new product features and thus also a new configuration version, the existing profiles will be no more used for composing the effective settings for the upgraded devices. This is because of the configuration version mismatch between the existing profiles and upgraded device firmware. With no profiles existing for devices’ current configuration version the effective configuration composed by PMC will be empty. Such configuration will not affect any device settings.
To avoid the necessity to manually create new profiles for devices’ new configuration version, PMC 2.5.0 offers tools which can greatly simplify or even fully automate the upgrade process.
Following functionalities are available:
- Automatic profiles upgrades after uploading schema files with definitions of new device configuration versions.
When multiple upgrade paths exist, e.g. in case when existing profiles for multiple older configuration versions can be upgraded, the administrator will be able to select which profiles and to which configuration version should be upgraded. The upgraded profiles can be automatically assigned to the same device groups, where the original (old) profiles were assigned.
- Manual profiles upgrades after uploading schema files.
The upgrades can be performed with the Upgrade task of the Device Profiles list.
- Automatic profiles upgrades when restoring a backup containing profiles created for older configuration versions.
In this case the profiles will be automatically upgraded to the latest available configuration version only. The upgraded profiles can be optionally assigned to the same device groups where the original profiles were assigned.
- Automatic upgrades of configuration edited directly on specific devices.
When the device configuration was edited in the past directly on a device when the device was using some older configuration version, then PMC will automatically upgrade the edited configuration to device’s current configuration version when the device will report a newer configuration version during check-in.
Device reboot and shutdown schedulers
PMC 2.5.0 allows scheduling device reboots and shutdowns. The schedules can be defined with the Reboot and Shutdown tasks of the Devices lists. As the scheduled events will be defined using the time zone of PMC Management Server, the proper Time zone needs to be set for the PMC appliance under Administration > System Settings. Because the Reboot and Shutdown actions will be initiated by PMC (at the scheduled time PMC will send to the devices appropriate commands), the devices must be in online state to be able to execute the actions.
Workaround: The below steps must be followed to update the RX300 3.1.3 firmware to a newer version:
systemctl stop firewalld
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:
systemctl start firewalld
Note: This issue was specific to RX300 device with firmware version 3.2.7 or older. Newer RX300 firmware versions correct this issue automatically during firmware update. NComputing strongly recommends updating all devices to latest available firmware version before starting to manage them from PMC.
Note: This is a problem on the Management Portal side which will be fixed there.
Workaround: For the time being please use other browsers for accessing PMC, like Google Chrome or Mozilla Firefox.