• 3 replies
  • Latest Post - ‏2014-04-08T13:05:52Z by Tim.Rice
1 Post

Pinned topic Licensing Virtual Workstations

‏2014-03-26T15:00:54Z |

We are thinking of deploying some virtual workstations (Window 7) in our VMWare environment.   Do these virtual workstations need a IEM "client" license, or would they be covered by the license of IEM assigned to the ESX host that supports the virtual environments (servers plus these new virtual workstations)?

  • jgstew
    56 Posts

    Re: Licensing Virtual Workstations



    I don't know for certain, particularly as it may be different on a case by case basis depending on your contract, but in general I believe you need a client license per virtual client.



  • WeylanWang
    5 Posts

    Re: Licensing Virtual Workstations



    TEM requires an agent on the machine be able to manage the computer regardless of if the agent is virtual or not.

    So if you wish to mange the computer you will have to install an agent on it and it will be considered to use up a TEM license.

    If you want to manage the HOST, that also requires a license on the HOST OS machine.

    An example:

    If you have

    VM server RH OS

    5 GUEST windows 7 machines.

    And you wish to manage all of them.  You will use up 6 license to manage all of them.


  • Tim.Rice
    40 Posts

    Re: Licensing Virtual Workstations


    We are beginning to look at Virtual Desktop technology where I work.  (DISCLAIMER : I have not been directly involved with the Virtual Desktop project yet, I just have to deal with the 'Ghost Machines' that our current implementation is leaving in IEM).

    From what I can tell there are two options.

    1. Leave the BESClient service active in the Master/Gold Image.
    2. Disable the BESClient service in the Master Image.

    If you go with Option 1, every time a Virtual Desktop (VD) is spun up, it will register as a Unique machine in IEM (a new Computer ID), and each new VD will have to process all of the MasterAction site information to evaluate all the Fixlets/Tasks/Open Actions.  Depending on the scale of your environment, this could be substantial. All this effort, and unless the VD persists between session, the information, plus any patches/updates/changes applied will be lost when the VD is torn down at the end of the virtual session.  If a VD with the same name is spun up again later, it will appear as a duplicate system because it will have a unique internal IEM Computer ID.

    If you go with Option 2, the VD sessions don't show up as individual machines in the Console.  The BESClient would only be started in the "Master Image" when you needed to make changes to it, then before recommitting it as the Master Image again, you would disable the BESClient service.

    Currently, our VD Team is leaving the BESClient active in the Master Image, and only a few VD's for VIP's are persistent.  The rest are destroyed when the session is closed.  It's manageable for me at this time because I clean duplicate machines out of the database every night, but because I wait to Purge the data from the database for 6 months, there is a huge volume of 'junk' in the database resulting from the constant spin up of "New Computers" in IEM.  I've dropped a bug in the ear of the VD Team, but our ISO may override my desires because they want 'active visibility' into the VD environment.

    If you go with Option 1, be sure to remove duplicates and purge data on a regular basis.

    If you go with Option 2, you don't have the ability to manage the VD sessions dynamically, but your database should remain sane.

    As with the rest of life ... trade offs!