MailBag Friday (#2)

Every Friday, we dedicate this space to sharing Technical Support emails we have recently received.  Our hope is that this weekly feature will help to educate other ThinManager users and provide them with answers to questions they may have about licenses, installation, integration, deployment, upgrades, maintenance, and daily operation.  Great Technical Support is an essential part of any software product, and we are constantly striving to make your environment as productive and efficient as possible.


We are looking to roll out more thin clients at our plants.  One thing we are wanting to do is give Plant Area leaders the ability configure users through Wonderware InTouch.  Is there a way to set a TermSecure user’s RFID   Card number   via the TermMon ActiveX Control ?
Harry N.


There are only two ways to associate a card with a TermSecure user.
1) You can set up a terminal with a card reader and ThinManager running (as a administrator). Have all the cards and scan them one at a time and associate the card with a pre-created TermSecure user.
Or you can scan a card and create the user on the spot. I think a replacement is quicker.
2) Get each card and record the user and the card number. Go into each TermSecure user configuration and add the badge number to the Card/Badge Information page.



Recently at one of our sites, they noticed some odd behavior and we would like to know if this was the result of a known issue (they are currently at v4.0 SP3).

They have DeltaV Operate sessions for both their production and test environments available. One day they received complaints that users were connecting to the wrong sessions. Upon investigation, they found that users were connecting to TDVNPADELTAV01 even though they were requesting a DeltaVOperate display client (not a DeltaVOperate_Test client, which are restricted to significantly fewer termsecure users) . They double-checked that TDVNPADELTAV01 was not assigned as a DeltaVOperate display client, and eventually went as far as removing and adding the server and cycling the ThinManager service on both servers (they have failover). Since that time, all behavior appears to be normal.

Any thoughts on why this occurred? I have been assured that there were no deliberate configuration changes made by the site administrators, however, could that change be made accidentally? I also could not find anything of note in the event logs.

Any insight you could provide would be helpful.

Thanks and Regards,

Brad B.

No, this isn’t a known bug.  Are they using DNS? If so maybe the tables pointed to the wrong server for a while.
We do have the ability to send an email when a configuration changes and the ability to backup the configuration automatically.
See Event Selection Page and E-Mail or Windows Message Recipients Page in the for emailing configuration changes.
This is for TM6 but it is unchanged from TM4.
See about automatically backing up the configuration.

I’m designing a network topology where it will include some wireless devices. My provider is asking me about the bandwidth consumed by Thinmanager. I’m clear about using 100MB speed… but I’m not sure about how much consumes each Thin client…

Could you give me an approach for this data?

Jean C.

The bandwidth consumed by a RDP session depends greatly on what you’re running on it.  Higher resolution, color depth, and complexity will cause more bandwidth to be consumed.

A typical 64k color session will use between 20-30kbps and simple programs could use as little as 5kbps.  A 32M color session running an HMI or PowerPoint presentation will use between 50-150kbps.  Keep in mind, this is per session, not per client.


Tom Jordan

Marketing Lead for ThinManager - A Rockwell Automation Technology