Using 1 Single Authorisation file across multiple instances of TEM?

(imported topic written by NicholasAu)

Hi Guys,

I need to deploy 2 separate instance of TEM on a production and non-production environment where each environment has a different number of endpoint nodes to manage during normal operation. Let’s say production environment has x endpoints and non-production environment has y endpoints.

However when DR happens, the production endpoints (x) will be managed by the non-production TEM instance. Hence the non-production TEM instance will be managing (x + y ) endpoints

During the setup, should i generate only 1 LicenseAuthorization.BESLicenseAuthorization which covers both (x + y) endpoints and distribute the same license.pvk and license.crt to these 2 separate TEM instance? Or i should generate 2 separate LicenseAuthorization.BESLicenseAuthorization, one for each environment.

Hope to hear advice from you guys.

Thanks a lot.

(imported comment written by Tim.Rice)

You should look into using DSA.

You then have two (or more?) ‘fail over’ servers. As long as they are both on line, they replicated database information on a scheduled basis and both have the same Masthead.

Short Description …

  • You have a Primary and a Secondary TEM Server. The two servers replicate their SQL database instances on a scheduled basis (configured/managed by the IEM/TEM/BigFix Admin tool).
  • Clients can report to either server (meaning the servers can be geographically distributed, but they still need a good network connection to allow the replication).
  • Relays should be configured to use Primary and Secondary for their reports.
  • If the Primary ever fails, Relays will switch to the Secondary server to report client information.
  • Any Console’s open and connected to the Primary server would need to be closed and reopened and connected to the Secondary server until the Primary comes back on line.
  • The Servers will replicate DB diff’s so the entire database doesn’t have to be sent each time.

I run this configuration supporting ~35k endpoints located in 200+ physical locations served by WAN connections. My ‘Dev/Test’ environment is actually a different Serial Number and Masthead (configured identical to the production system) created on the License Management web page. We don’t want the two to ever mix. I have created and use custom copies of the ‘Change Masthead’ tasks so that I can move ‘test/dev’ endpoints between the two Environments if we need to test client upgrades or functions prior to major TEM upgrades. We keep ‘test/dev’ systems for our major systems where we usually test OS/Software patches.

(imported comment written by NicholasAu)

Hi Tim

Thanks for your reply. I am trying to reaffirm the understanding. Please correct me if i am wrong.

My env is smiliar to your Dev/test environment as during normal operating times, the prod and non-prod clients are managed separately.

  1. I need to use a different serial number and masthead for both prod and non-prod environment. This means i need to generate 2 LicenseAuthorization.BESLicenseAuthorization. One for each environment.

  2. Make use of “maesthead switch” task to move the endpoints between the two environments.

The network bandwidth between the two environment is too small. It may not be feasible to do the database replication via network. I may need to explore the traditional database backup and restore as if it is a migration to a new server.

Does this sound ok?

(imported comment written by Tim.Rice)

To better explain my environment …

The TEM Production environment consists of separate physical servers for Primary & Secondary. These are housed in different data centers on campus, with high speed network links. The Production Primary and Secondary databases replicate with each other. Other component servers are virtualized, things like SUA & SCM

The TEM Test/Dev consists of all virtualized servers for Primary, Secondary, SUA, SCM, etc. The Test/Dev Primary and Test/Dev Secondary SQL databases replicate.

The purpose of my Test/Dev environment is ONLY to test updates to TEM itself. The only replication of databases that occurs is between the Primary and Secondary servers for each environment. I do NOT replicate the TEM Production environment into the TEM Test/Dev database.

My Test/Dev TEM system is not used to manage anything other than itself under normal operations. When we are preparing to test a new major version of TEM, I need to validate that the new client isn’t going to conflict in any way with existing line of business production software, so I work with a few of our major Application owners (internal staff) to migrate several of the line of business Test/Dev application systems over to the TEM Test/Dev instance, upgrade the Test/Dev TEM environment making sure that the clients update properly and work with the Application owners to ensure that the line of business Test/Dev systems are still functioning properly. Once the TEM validation/testing is done and the Production TEM environment is upgraded, the various line of business application Test/Dev servers are migrated back to the Production TEM system, and their information is purged out of the TEM Test/Dev system.

The line of business application Test/Dev systems are normally left in the Production TEM system because their Application Owners need to validate OS and Vendor patches on a regular basis, and the Production TEM system is used to perform the installation of those patches in their Test/Dev and later in their Production environments. I don’t update TEM anywhere near as frequently.

Gotta love ITIL!

(imported comment written by NicholasAu)

Hi Tim,

You’ve mentioned:

Once the TEM validation/testing is done and the Production TEM environment is upgraded, the various line of business application Test/Dev servers are migrated back to the Production TEM system, and their information is purged out of the TEM Test/Dev system.

Is the migration done via masthead switch task? How do we ensure the production TEM system has the latest information about the Test/Dev Server after the testing etc? Is there some kind of data extraction and import from Test/Dev TEM into Production TEM?

How is the information purged out of the TEM Test/Dev system? Is it done via TEM remove Utility?

Thanks for your advice!