What is ThinManager? Central thin client management in a plant: content, redundancy, licensing, network

ThinManager is Rockwell Automation software for managing a plant's thin clients and other terminals from one place. It runs on a computer or server. When a device boots, it connects to the ThinManager Server and downloads its firmware, its configuration and the content assigned to it (TM-UM001L, pp. 26–28). The simplest use, per the manual, is a Windows application deployed from a Remote Desktop Server to a ThinManager-ready device. ThinManager can also deliver cameras, VNC screens, workstations, browser containers and FactoryTalk Optix. This article follows the user manual TM-UM001L-EN-P (ThinManager 14.2, 07/2026).

What ThinManager does

The manual calls ThinManager a content delivery system: from a source to a device where the user works with it (p. 28). In the typical architecture, the Remote Desktop Server runs the HMI sessions that talk to the PLCs (p. 29); the terminal displays the result (p. 781).

"ThinServer" is the configuration database, running as a Windows service; devices get firmware and configuration from it. "ThinManager" is the interface used to configure it. A computer running both is a ThinManager Server (p. 781).

Setup order: "Remote Desktop Server Wizard", "Display Client Wizard", "Terminal Configuration Wizard", then link the hardware to the Terminal (p. 24).

Content types

• Remote Desktop Services: a full desktop, or one application with AppLink (pp. 151, 174–175). Two or more Display Clients on one Terminal is MultiSession (p. 295).
• Containers: Docker-based, running on the thin client (since 12.1) or on a server (since 12.0). Only Linux containers can run on a thin client, because the firmware is Linux-based (pp. 102–103). Images include chrome, FactoryTalk System Status, ViewPoint and optix app (p. 104).
• Optix Container (since 14.1): runs a FactoryTalk Optix application exported from Optix Studio directly on a thin client. Each Terminal needs its own Optix entitlement key. When the manual was written, Optix 1.6 supported only online entitlements for Docker deployments; without Internet it runs in a 2-hour demo mode (pp. 110–111). See also FactoryTalk View SE vs ME vs Optix.
• Cameras and VNC: IP or USB cameras through a Camera Display Client; VNC shadow of, for example, a PanelView Plus, default port 5900 (pp. 137, 146, 148, 193).
• Workstation and Terminal Shadow: RDP brings a PC's session to a thin client, for applications that cannot run on Remote Desktop Services; Terminal Shadow shows another thin client's screen (pp. 217, 228–229).

MultiMonitor uses thin clients with several video ports; since 11.1 the number of monitors depends on those ports. Monitors can form one desktop ("spanned"), separate desktops ("screened") or a mix (p. 736). Virtual Screens divide one physical monitor into overlays, giving MultiMonitor functionality on a single screen (p. 245).

Location Services adds location to delivery: a Location, with or without a fixed Terminal, is resolved manually or by QR code, Bluetooth beacon, Wi-Fi, GPS or NFC (p. 30). Resolver actions are Shadow, Transfer, Forced Transfer and Clone (p. 780). With the TMC apps on Windows, iOS and Android devices, ThinManager manages the content but not the underlying operating system; some x86 tablets that ThinManager boots wirelessly are the exception (p. 379).

Redundancy

The manual recommends Failover in every system; each server needs the same applications in the same locations and the same Windows accounts (pp. 188–189).

The ThinManager Server can be a pair. Full Redundancy gives an administrative console on both servers. Mirrored Redundancy gives it only on the primary; the secondary is view-only but Terminals can boot from it. With Stand-Alone, running Terminals keep running if the server goes offline, but a Terminal that reboots waits until the server is back (p. 54). Mirrored licences must use Automatic Synchronization (p. 58). For the wider SCADA picture, see SCADA server redundancy.

Licensing, as the manual describes it

There are two modes, chosen under "Install > License Mode": ThinManager Master License and FactoryTalk Activations (p. 53).

• Master License: Product Licenses (let Terminals connect and set their features) are added to a Master License on the ThinManager licensing site, activated with the Installation ID, and the Activated License File is applied in ThinManager (pp. 53, 61). You need enough Product Licenses for each Terminal (p. 18). V-FLEX licences are flexible volume licences (p. 54).
• FactoryTalk Activations: through FactoryTalk Activation Manager, which can be a central licence server rather than the ThinManager server (pp. 18, 63).
• Standard product licences are available with redundancy; Enterprise server licences include Full Redundancy (p. 54).
• Microsoft side: a Remote Desktop Licensing Server and an RDS CAL for each thin client, plus a normal CAL for the servers (pp. 17, 73).

Security

The manual has three user types (p. 66):

1. Windows Users log in to the Remote Desktop Server and belong to the Remote Desktop Users group. Each Terminal or Location should have its own account, with only the rights its applications need. Never use a Domain Administrator for auto-login.
2. ThinManager Security Group Users are Windows group members with rights in the ThinManager console. By default only Windows Administrators can connect; six groups have predefined privileges (pp. 709–710).
3. ThinManager Users receive Display Clients at a thin client through an Access Group, formerly TermSecure (pp. 66, 781).

Also: the database is AES-encrypted with its own password since 11.2, and backups cannot be recovered if the password is lost (pp. 18, 24). Since 14.1, TLS certificates live in the Microsoft Certificate Store, with warnings 60, 30 and 10 days before expiry (p. 70). Firmware from 13.2.0 is signed for Secure Boot (p. 371). Replacing a thin client can require a ThinManager password or a Windows account (p. 699). For network zoning, see IEC 62443 zones and conduits.

Compared with a full PC at every machine

The manual does not compare costs and has no PC comparison. It does state these points about thin clients:

Where PCs stay, WinTMC lets ThinManager manage their RDP connections and adds Failover and Instant Failover (p. 371), but ThinManager modules do not apply; drivers go into the PC's own Windows (p. 379).

What a plant should prepare

1. Remote Desktop Servers: Windows Server with the Remote Desktop Services role, a Remote Desktop Licensing Server and RDS CALs; one Windows account per Terminal in Remote Desktop Users; applications installed in Install Mode, e.g. change user /install (pp. 17, 73).
2. ThinManager Server: 64-bit only since version 13 (p. 17); database password, backups and licence mode (pp. 18–20, 53); a second server if you need redundancy (p. 54).
3. Network: open the listed ports in all firewalls, e.g. UDP/67 for the PXE Server, UDP/69 for TFTP, UDP/4011 when DHCP runs on the ThinManager server or for UEFI boot, UDP/4900 for TFTP firmware download (HTTPS, on the port set on the HTTPS Server Settings page, is the default firmware delivery, p. 723), TCP/2031 for configuration, TCP/3389 for RDP, TCP/5900 for shadow (pp. 24–25). See also FactoryTalk and Logix firewall ports.
4. VLANs and PXE: only one PXE server per network; a separate VLAN for each ThinManager Server pair that answers PXE is recommended (p. 25).
5. IP addressing: ThinManager-ready thin clients use static IP or DHCP. ThinManager-compatible thin clients lack the ThinManager BIOS, boot by PXE and need DHCP. On the plant DHCP server, Option 066 is the ThinManager Server IP and Option 067 is acpboot.bin (p. 26). The PXE Server has four modes, under "Manage > PXE Server" (pp. 354–355). A duplicate static IP stops the firmware download (p. 351).
6. Server containers, if used: Windows Server 2019 with Internet; no offline installation (pp. 120–121).

Engineering support for an existing HMI/SCADA system: SCADA and historian.