ThinManager® is a powerful platform designed to simplify the
way productivity content is delivered, and devices are managed
within manufacturing environments. Learn how ThinManager can revolutionize everything from the plant floor to the control room, change the way you view mobility in those areas, and deliver and manage The Connected Enterprise today. In addition, this session will reveal what to look for in the 10.0 release due out later this year.
Script:
What is ThinManager? It is a software platform designed for the plant floor that provides centralized content delivery and device management.
The first part of this statement is about Content Delivery. We will discuss the different types of Content Sources that ThinManager supports in the next slide.
The second part is about Device Management. ThinManager can manage thin clients, zero clients, mobile devices (tablets and smartphones), as well as PCs. ThinManager can manage all of these different device types in exactly the same way. You will use the same Terminal Configuration Wizard in ThinManager regardless of the device type.
You are going to manage all of this environment centrally using ThinManager.
ThinManager is a key component to delivering and managing the Connected Enterprise.
Script:
Some of the more common Content Types are represented in the 1st panel on the left.
The 1st five bullet points are examples of Windows-based content types.
It is important to note that ThinManager is an agnostic platform, so any Windows based content can be delivered.
The most common way that Windows based content is delivered with ThinManager is using Microsoft’s Remote Desktop Services (formerly called Terminal Services). It is not the only way, but the most common way.
Often times, it is assumed that ThinManager requires, or is dependent on Remote Desktop Services, but that is not the case.
With that said, while it is not required, since ThinManager is often deployed with Remote Desktop Services, you will typically find ThinManager installed on a Remote Desktop Server.
What is a Remote Desktop Server? This is a Windows Server based operating system (like Server 2008/2012/2016) that has the Remote Desktop Services role installed and configured. With this role installed, the server can then host multiple, independent Remote Desktop sessions from devices like thin clients, tablets, etc.
So, instead of installing FactoryTalk View SE on a number of PCs throughout the facility, you could instead install the FactoryTalk View SE Client on a Remote Desktop Server and use ThinManager to launch and distribute multiple instances of it.
In addition to Windows-based content, ThinManager supports IP or USB Cameras. ThinManager can tap into the camera’s video stream and deliver it to a device managed by ThinManager.
ThinManager also supports Terminal Shadowing. Shadowing is the ability to see a terminal remotely. Shadowing is supported through the ThinManager Admin Console, so you can see and remotely control any terminal managed by ThinManager centrally. We also extend this concept so terminals can shadow other terminals – this is called Terminal to Terminal shadowing. A single terminal can be shadowed by several other terminals. The shadowed sessions can be remotely controllable or view only.
Lastly, ThinManager can now connect to VNC Servers as sources of content. This will enable shadowing of the PanelView Plus, and plug it into all of the unique ways that ThinManager can assign and deliver content.
So, what are the ways in which ThinManager can deliver the content of the Connected Enterprise?
ThinManager can assign and deliver content in 3 ways – By Device, By User and By Location.
By Device:
Every device managed in ThinManager will have a unique Terminal Profile.
The Terminal Profile is linked to the device based on the device’s MAC address.
The Terminal Profile defines the device’s default content and its other characteristics (i.e.: if it needs a touchscreen driver, is it permitted to be shadowed, etc.)
It is very common to assign FactoryTalk View SE as the default content for a device so it is automatically delivered when the device boots up.
By User:
In addition, content can be assigned to a user or a user group.
In this way, when a user logs in at any terminal managed by ThinManager, that user’s assigned content will be delivered (i.e.: a Maintenance user may receive an instance of Logix Designer, or maybe the Work Order System Client, etc.)
By Location:
Location is the foundation of ThinManager’s mobility initiative, called Relevance.
It allows content to be assigned and delivered to a mobile device based on its physical location.
As an example, a QR Code could be placed on a PLC panel. When a Maintenance user scans the QR Code, Logix Designer could be delivered to their mobile device with the correct ACD file opened up automatically.
As another example, maybe you permit a user to access the FactoryTalk View SE Client from their mobile device, but you want to physically limit where they can access it from. With Relevance, you can geo-fence content in based on the mobile device’s location (using Bluetooth Beacons, GPS, Access Points, etc.)
==========
SHORT SCRIPT:
ThinManager can easily deliver all kinds of content that your workforce needs to do their jobs. ThinManager securely delivers that content to any combination of device, user or location. This graphic shows examples of content, device, user and location.
Thin client networks are inherently more secure than traditional PC networks but ThinManager increases security even further by employing powerful user authentication techniques and the ability to designate specific locations for content delivery within your facility.
ThinManager is a Content Delivery and Device Management Platform.
Content Sources can be created and managed centrally.
Each device managed by ThinManager is assigned a unique terminal profile within ThinManager.
A device can be a thin/zero client, mobile device, or PC and each are managed in exactly the same way within ThinManager.
Content can be assigned and delivered by any combination of Device, User, and Location.
Script:
So, to summarize, ThinManager’s #1 Objective is to Safely and Securely Deliver Content to any combination of Device, User and Location.
It is important to note that none of the content delivered is ever hosted on the device itself. The device is merely a window into the content that is being hosted somewhere else.
In the case of a mobile device, if it is removed from the facility, no Intellectual Property will be on the device.
In addition to Remote Desktop Servers, Virtual Desktops (VDI) can be delivered using ThinManager. It doesn’t matter if your Windows content types are physical or virtual. If they are virtualized, ThinManager works with all hypervisors – VMWare, Hyper-V, Citrix, etc.
The content types introduced in the previous slide can be simultaneously delivered to a terminal and aggregated, creating composite applications from disparate sources.
ThinManager offers some very unique ways to visualize the different content types – Tiling and Virtual Screening, for example (shown in a later slide).
ThinManager’s flexible content delivery paradigm enables the delivery of content to the right device and the right person in the right location.
Script:
Traditionally, Windows based applications were hosted on PCs in manufacturing areas.
Quite often, these PCs ran dedicated applications like FactoryTalk View SE, restricting access to the Windows desktop.
In general, a Windows desktop experience is not required, and sometimes not desired – especially on the Plant Floor or in the Control Room.
This environment requires management of support of many operating systems, many times each at different version and service pack levels.
In addition to the locally installed OS, the applications required must be managed at each PC, and anti-virus must be deployed and managed as well.
These PCs are generally not industrial, so they tend to have moving parts like hard drives, fans, and commercial grade power supplies that are all prone to failure.
Replacement of a PC, even with well managed external images, will typically take hours, resulting in costly downtime.
Lastly, the PCs are more susceptible to virus infection because their USB ports are used with flash drives.
Script:
A ThinManager solution looks more like this – where PCs are generally replaced by thin clients. Any of the Windows based applications are then hosted centrally – typically on a Remote Desktop Server.
This architecture dramatically reduces the number of operating systems that need to be maintained – whether they are physical or virtual.
It also increases security at the endpoint, because nothing is stored on the actual ThinManager managed thin client. And USB ports on these devices are disabled by default for everything except keyboards and mice.
Adding ThinManager to this deployment provides an added layer of management that brings some very unique, plant-floor centric capabilities to the table.
As a side note – PCs can be retained and managed in a ThinManager deployment as well.
ThinManager offers a Windows based application called WinTMC that will essentially emulate a ThinManager thin client from a Windows OS. This is sometimes utilized if there are some applications that must continue to run locally, while additional remote content is managed from ThinManager.
Alternatively, some PCs can be PXE booted (PXE is an Intel standard = Preboot Execution Environment = a way to deliver firmware/operating systems over the network at boot time), where the PC would be booted from the ThinManager firmware, as opposed to its locally installed OS.
Script:
Here we have a centralized Remote Desktop Server with ThinManager installed on it.
The server has the client applications on it that we would like to distribute using ThinManager.
As previously mentioned, ThinManager does not require or depend on Remote Desktop Services, but it is most commonly deployed with Remote Desktop Services.
Script:
The VersaView 5200 pictured here does not have a locally installed OS (could be described as a zero client in fact).
When the VersaView 5200 is connected to a network with ThinManager present, it will receive the ThinManager firmware right when it boots up. The firmware is approximately 13MB in size, and on today’s networks, it is delivered and installed within seconds.
Since the VersaView 5200 is ThinManager Ready, it can be assigned a Static IP address, or use DHCP.
Value: No operating system stored on the device makes that device much easier to manage. Fewer operating systems to maintain and support.
Script:
Once the firmware is delivered, the VersaView 5200 will request its Terminal Profile from ThinManager.
If this is the 1st time the device is booted, ThinManager will most likely not have a Terminal Profile assigned to the MAC address of this new device. Therefore, a list of available Terminal Profiles will be made available from which to select.
Once assigned, ThinManager creates a marriage between the Terminal Profile assigned and the MAC address of the new device. Each subsequent bootup will not require assignment, as ThinManager will automatically recognize it.
If the terminal is replaced, all that is required is the correct assignment of the Terminal Profile of the failed/replaced terminal. The new terminal will essentially assume the outgoing terminal’s identity and even reconnect to its content sources, which were not disrupted during this process.
Value: The terminal profile is created and managed centrally. No configuration done at the terminal itself. This makes terminal replacement very easy – simply assign the correct profile to the replacement device. No re-building of client operating systems. This leads to enormous downtime savings.
Script:
Once the Terminal Profile is delivered, the associated content will be delivered to the terminal.
In this example, an instance of the FactoryTalk View SE Client is delivered to the terminal.
Content (called Display Clients in ThinManager) can also be assigned and delivered by User or by Location.
In addition to Display Clients, you can also configure other characteristics of the terminal within the Terminal Profile:
Terminal schedules can be defined if the terminal only needs to be available on certain days or during certain times of the day.
The shadowing behavior can be set (i.e.: Enabled, Disabled, Ask, Warn).
Modules (drivers) can be assigned to enable external device connection like touchscreens and/or badge readers, etc.
ThinManager includes a number of other Modules that provide additional functionality to the terminal.
Value: ThinManager terminals are significantly more secure than the PCs that they replace. No local OS to secure, and no Windows desktop to protect.
Script:
Failover is defined as having multiple sources available for your content.
In the example above, a second Remote Desktop Server is added that can also host the FactoryTalk View SE Client.
If the Primary goes down, the terminal will automatically failover to the Secondary Remote Desktop Server.
Redundancy, on the other hand, is having 2 installs of ThinManager whose configurations are automatically synchronized.
The main role of the ThinServer service is to deliver the Terminal Firmware and Terminal Profile.
Once a terminal is booted and connected to its Content Sources, the ThinServer service could be shut down, and the terminals would continue to run.
However, if the ThinServer became unavailable AND you attempted to boot up a terminal, it would not be able to boot because it would have no source from which to receive its firmware and profile.
For this reason, many users opt for ThinManager Redundancy.
There are 2 types of Redundancy available: Mirrored and Full. Both provide 2 separate installations of ThinManager whose configurations are automatically synchronized. Mirrored is a lower cost alternative that has a restriction. Namely, one of the ThinManager installations is designated as the Primary and it is from this and only this install that you can make changes to the ThinManager configuration. Full Redundancy does not have this restriction (i.e.: you can make ThinManager configuration changes from either installation – Primary or Secondary).
Value: Failover reduces downtime and improves the maintainability of the system. Content servers can be taken offline for patching, etc. without affecting production. Redundancy also reduces downtime by providing a secondary source for booting thin clients.
Script:
ThinManager’s ability to aggregate multiple content sources using MultiSession is one of its most powerful and popular features.
Any time more than one Content Type (Called Display Clients) is assigned and delivered, it is called MultiSession.
Multiple Display Clients can be visualized simultaneously using Tiling Mode.
ThinManager supports up to 25 tiles in a 5x5 grid on a single display.
Tiling is optional – if it is not used, then there really is no limit to how much content could be delivered to a terminal.
Remember that the majority of the processing required is not occurring at the terminal.
Clicking on a tile will bring that tile full screen enabling interaction.
There are a number of configurable ways to switch between Display Clients and to/from Tiling mode.
The 2 SE Client instances are Remote Desktop Services Display Clients.
The 1 SE Client instance is a Workstation Display Client.
The 1 PanelView Plus Shadow is a VNC Display Client.
Value: Multisession and Tiling really result in increased productivity by providing consolidated views of all of the content required by an end user, allowing them to maintain a pulse on the production system.
Script:
Because of ThinManager’s strength of bringing multiple content types together, it is often necessary to spread the content out across multiple physical displays.
ThinManager supports up to 5 physical displays connected to a single terminal.
MultiMonitor is often deployed in Control Room environments, where multiple PCs, keyboards and mice make it challenging to support and maintain.
As an example, 3 five monitor thin clients could be used to drive 15 displays, and management is reduced to maintaining 3 terminal profiles in ThinManager.
ThinManager also includes a module (which are like drivers), called the Shared Keyboard and Mouse module. that could be applied to the 3 terminals that would enable a single keyboard and mouse to control all 3 terminals and hence all 15 displays.
Content (called Display Clients within ThinManager) can be assigned to each display by default (tiling is still supported), but it can also be configured to moveable by the user of the terminal so the Display Clients can be moved from one display to another.
This behavior is completely controllable, so the ThinManager administrator can configure which Display Clients are moveable versus not.
Similarly, a display can be configured to either be protected, so that it cannot receive additional Display Clients, or not.
Value: MultiMonitor and Virtual Screening really simplifies Control Rom deployments, greatly simplifying the management and maintenance of the computing resources required in those environments. Numerous Control Room PCs can be replaced by thin clients all managed by a few terminal profiles in ThinManager.
Script:
Virtual Screening is the evolution of MultiMonitor in ThinManager.
Instead of investing in multiple physical displays, end users may choose to invest in bigger, 4K displays.
4K = 3840x2160 in resolution (basically a 2x2 grid of 1920x1080 HD displays)
A thin client with graphics support for 4K would be required to drive a 4K display.
Content can overlap as well.
Value: MultiMonitor and Virtual Screening really simplifies Control Rom deployments, greatly simplifying the management and maintenance of the computing resources required in those environments. Numerous Control Room PCs can be replaced by thin clients all managed by a few terminal profiles in ThinManager.
Script:
User Based Content delivery is 2nd way in which content can be delivered.
Relevance Users (formerly known as TermSecure) provides the ability to assign and deliver content based a user or a user’s role.
A User’s credentials can reside in ThinManager or linked to an Active Directory account (much like Windows Linked Users in the FactoryTalk Directory).
ThinManager supports RFIDeas badge readers and Crossmatch fingerprint scanners, each of which can be associated with a Relevance User.
ThinManager can also store a Relevance User’s password, or even rotate it automatically on a pre-defined schedule.
Value: User Based Content delivery increases both Security and Productivity. Multi-factor authentication (badge plus password, or fingerprint plus password) results in a more secure environment, where a user receives only their designated content. Users can have their specific content delivered to them at any terminal managed by ThinManager. No need to run back to PCs for the content they need.
Script:
Unlike a ThinManager thin client, the ThinManager firmware is not compatible with most mobile devices, which have their own OS (iOS, Android and Windows).
Instead of delivering the ThinManager firmware to these devices, a ThinManager Client (TMC) application can be used.
iTMC = iOS, aTMC = Android, WinTMC = Windows.
Each of these apps emulates a ThinManager thin client and can therefore be managed centrally from ThinManager.
Similar to a thin client, each mobile device will require a unique Terminal Profile in ThinManager.
Relevance User based content can be delivered to the mobile device (just like a thin client).
Most importantly, Location based content can be delivered.
Defining a Location in ThinManager is accomplished by assigning the desired content to it as well as assigning a Location Resolver.
A Location Resolver basically tells ThinManager to which Location the mobile device has resolved. Permissions can also be assigned to the Location Resolver (i.e.: only Maintenance users can scan the QR Code on the PLC Panel and receive Logix Designer).
ThinManager supports 4 Location Resolvers currently:
QR Codes – these can be printed out using a number of free web based utilities.
Bluetooth Beacons – think of these as proximity sensors for your mobile devices. They have a maximum range of 50 meters and can be purchased in battery or USB powered options. Beacons are often used to geo-fence content so a user cannot leave a certain area/zone with the delivered content.
WiFi Access Points – ThinManager can detect which Access Point a mobile device is connected to and based on this connection either enable or disable access to content.
GPS – for outdoor applications, GPS can be used to define a location.
Mobile devices can also interact with thin clients in some very unique ways:
Content delivered to a thin client can be transferred/redirected to a mobile device.
Content delivered to a thin client can be shadowed by a mobile device.
Content delivered to a thin client can be cloned and delivered to a mobile device.
Value: Delivering location based content will also greatly improve productivity and reduce downtime by quickly delivering location based content to a user’s mobile device to help them more quickly assess equipment status and take corrective action.
Script:
From the original release of ThinManager, its primary value proposition has revolved around Lower Total Cost of Ownership.
Productivity is increased on the administrative side by simplifying content delivery and device management.
Productivity is also increased on the end user side by delivering the right content to the right user at the right location.
Visualization to the process is improved by delivering disparate content sources together and providing unique ways to visualize the sources simultaneously, maintaining and monitoring the pulse of the process at all times.
Security is dramatically increased because the content delivered is not actually hosted or stored on the device to which it is delivered.
In addition, the content can be delivered based on user role and/or user location.
Maintenance and downtime costs are also decreased with ThinManager because get out of the PC refresh cycle (generally every 2-3 years), and when terminals do fail, they can be replaced in under 2 minutes by anyone.
Script:
ThinManager Managed Thin Clients offer a lower total cost of ownership when compared to PC deployments, often times paying for themselves the 1st time a PC failure is avoided in downtime savings.
Thin Clients, especially industrial grade terminals, are less likely to fail because they have no moving parts – no hard drives or fans.
When a ThinManager Thin Client does fail, it can be replaced by virtually anyone – as none of the configuration is done at the terminal. Simply connect the replacement terminal and assign the Terminal Profile for the failed terminal.
Thin Clients are smaller and require less power to operate and cool. Some energy companies actually offer rebates for thin client deployments.
Thin Clients are inherently more secure than PCs – they often have no local storage, eliminate the Windows desktop and the USB ports are disabled for all things except keyboards and mice by default).
With ThinManager, disparate content types can easily be delivered to virtually any device.
Script:
The VersaView 5200 industrial grade thin client from Rockwell Automation will be available to customers around May of 2017.
It will initially be available with a Single Core Intel Atom processor with 2GB of RAM. Expect a Quad Core option to be released later in the year.
It offers a very wide operating temperature range from -20 to 60 degrees Celcius.
It will be powered by 24VDC power – unlike competing products that offer only an external power supply that is prone to failure.
Dual HD Displays are supported (DisplayPort and VGA).
Dual 1Gbit/s Ethernet ports are included.
ThinManager can be configured for Automatic Failover between these ports using the Redundant Ethernet Module (both ports look as 1 IP and MAC address externally).
Alternatively, these 2 ports can participate on 2 separate subnets/VLANs using the Second Ethernet Module in ThinManager. This is often used for IP cameras on separate VLANs.
It will be ThinManager Ready, which means that it will have the ThinManager BIOS Extension Image embedded inside of it, so out of the box it will be ThinManager-aware.
ThinManager also supports commercially available terminals, like Dell Wyse, HP, etc. Since these terminals do not have the ThinManager BIOS Extension image embedded within them, PXE is used to deliver the ThinManager firmware to them. As long as they are x86 based terminals, the chances are pretty good that ThinManager will work with them.
A complete list of Supported Hardware can be found at http://www.thinmanager.com/kb/index.php/Supported_Hardware.
Script:
In addition to box thin client, Rockwell Automation will be releasing the VersaView 5200 Panel Thin Client, July 2017.
This unit will be available in 4 sizes – 12.1, 15.6, 18.5 and 21.5, each of which will have an integrated VersaView 5200 bolted to the back.
The temperature range is not quite as broad as the box thin client at 0 to 50 degrees Celcius, due to the addition of the touch panel.
While the display itself supports Multi-Touch, ThinManager does not currently support Multi-Touch in its touchscreen drivers.
Similar to the box thin client, these units will be ThinManager Ready.
Script:
Unlike the VersaView 5200, the hardware listed on this page is not ThinManager Ready. None of it has any special ThinManager BIOS, etc. – however each can be used in some way with ThinManager, which is why they are listed here.
The devices with a check in the PXE column can be booted with the ThinManager firmware using the PXE standard from Intel. This generally requires that PXE be enabled in the BIOS and moved to the top of the boot order. Once this is done and ThinManager is configured to be a PXE Server, the device can be booted with the same firmware that a ThinManager Ready terminal would receive, and can therefore be managed just like a ThinManager Ready terminal.
So instead of booting from the locally installed OS, the PXE terminals would be booted from ThinManager.
The devices with a check in the Touch – USB or Touch – Serial indicate that they have touchscreens that will work with ThinManager. We expect that the 6176< and 6186M will be compatible, just need to verify that with formal testing in our office.
The devices with a check in the VNC column indicate that ThinManager can connect to them via VNC and essentially shadow them. Unlike, the PXE devices, we cannot manage the VNC devices (we are not able to boot them from the ThinManager firmware).
The PanelView 5000 is expected to include VNC Support in its release that will coincide with v31 – but this is subject to change.
Script:
ThinManager has been on the market for over 17 years, and almost exclusively been deployed in manufacturing environments.
ThinManager has very much been designed with the plant floor in mind leading to a very OT-centric solution.
Often times the most difficult thing involved with ThinManager deployments is configuring Microsoft’s Remote Desktop Services. The rest of ThinManager is intuitive and simple to pick up.
ThinManager is the only solution that manages server content as well as the client itself, resulting in zero configuration required at the thin client.
Alternative solutions like Citrix and VMWare Horizon View are IT-centric solutions that require significantly more complex architectures and are much more dependent on the IT organization to deploy and support.
While these solutions have had success in the front office, they are simply not designed for the plant floor. Their strengths are not aligned with the needs of the plant floor.
St
How is it Licensed?
ThinManager is licensed based on 3 factors:
Terminal Connection License
Redundancy
Platform Maintenance
The Terminal Connection License is defined by how many terminals/devices are concurrently connected to ThinManager. These are sold in 5, 10 and 25 packs (which are additive) as well as an Enterprise Server license that provides Unlimited Terminal Connections.
Redundancy provides a pair of ThinManager installations that are automatically synchronized. Either installation can deliver firmware and terminal profiles.
Platform Maintenance is equivalent to TechConnect. In exchange for annual fee, the end user receives the latest version of ThinManager, Live Tech Support and trade-in value for their license towards an Enterprise Server license.
Redundancy is having 2 ThinManager installations that are automatically synchronized -> either of which can deliver firmware and profiles to the terminals managed by ThinManager.
None
Mirrored – provides a pair of ThinManager installs which are automatically synchronized, but there is a restriction - changes to the ThinManager configuration can only be made from the Primary ThinManager installation
Full – similar to Mirrored except there is no restriction – ThinManager configuration changes can be made from either ThinManager installation
Platform Maintenance (PM) is ThinManager’s form of TechConnect. This is an annual fee that provides the latest release of ThinManager, access to live tech support, and credit towards upgrades in the future.
There are 3 special licenses available:
Muni Pack – offered only in 25 terminal connection counts and for municipalities only – can split the terminal connection count across multiple sites. Can be purchased with No Redundancy or Full Redundancy only.
Enterprise Server – provides an unlimited number of terminal connections on a single owned network. Includes Full Redundancy and 1st Year of Platform Maintenance. Restriction: Cannot be used on networks that are public, leased or non-company owned.
FLEX (100, 250, 500) – provides a terminal count limit, but can be installed on as many networks as needed. RESTRICTION: Can only be utilized within a single Business Unit of a company.
Script:
When deploying ThinManager with Remote Desktop Services, RDSCALs are required.
There are two types of RDSCALs – Per User and Per Device.
When configuring the RD Licensing Server (normally on the Remote Desktop Server), you must select whether it will use Per User or Per Device RDSCALs.
Generally Per Device is better suited for ThinManager deployments. Each device/terminal managed by ThinManager would require a Per Device RDSCAL.
Even if you are delivering multiple sessions to a terminal using MultiSession, only 1 Per Device RDSCAL would be required.
Per User RDSCALs would make sense if you had more devices than users, which is generally not the case with ThinManager deployments.
FactoryTalk licensing must also be considered when deploying ThinManager. Generally, each instance of the FactoryTalk View SE Client requires a FactoryTalk View SE Client license. Similarly, for Logix Designer, etc.
In the example where we deliver multiple instances of the FactoryTalk View SE Client to a single terminal (i.e.: via Tiling Mode or Virtual Screening), each instance would require a FactoryTalk View SE Client.
While we are investigating ways of improving this commercially in the future, you are encouraged to speak with a Rockwell Sales representative to discuss FactoryTalk Client licensing with your ThinManager deployments.
As an aside, you could deliver a single Desktop session to a ThinManager terminal and launch multiple instances of the FactoryTalk View SE Client *within* that single session and only consume a single FactoryTalk View SE Client license. But you would lose the Tiling and Virtual Screening abilities of ThinManager which rely on session-based content.