The ITAM Review

News, reviews and resources for worldwide ITAM, SAM and Licensing professionals.

Process of the Month – Platform Identity Process

4382167569_5fcff8bb12_z

Switching off Servers and seeing who complains first/loudest is not recommended!

We are not yet at that stage with inventory systems where they can tell us what classification or type of server a particular machine is.  Development, Test, Academic, Training or Evaluation installations of software should be isolated to devices dedicated to those roles.  Throw into the mix the concept of High Availability and Failover/clustering etc. and the landscape can look pretty tawdry when it comes to deciding what you are happy to pay for, and what you are happy to argue about with a software vendor.

My top tip in this sphere is where possible, try and leverage your naming convention – if a machine name states that the device is Dev (or has the Dev annotation somewhere in its Machine Name) then you know that it is a Development device, and so software that appears from one inventory sweep to the next isn’t as high on your investigation list as it might have been before.

Platform Identity Process

Primary Objective

  1. To classify server devices appropriate to their role in the company; aiding the definition of software classification wherever possible.

Secondary Objective

  1. To review the worth of server roles to the business and so understand whether or not they should stay in their current configuration/role, or be re-allocated or even disposed of.

Assumption

  1. N/A

Function Step Overview

1.10 This is a straightforward activity – the Inventory Manager is required to capture the inventory of all devices in scope.
1.20 The Inventory Manager is then required to filter devices based upon their server capabilities and roles.  Higher end SAM suites can offer such a capability by taking the serial number of a device and comparing that to manufacturer’s lists of devices – some massaging may be required here, you may have desktop servers performing fairly critical services that could be missed purely because a SAM suite hasn’t classified that as a server.
1.30 The HAM Manager is required to take the list of servers, and start to categorise the role(s) those servers play.  Clearly, the first time this process is run the amount of time dedicated to such a task might be better handled by splitting it up amongst a team.  Providing that team have a decent knowledge of the server roles, then this isn’t a problem.  However, I also suspect that the HAM Manager may be seeing devices on this list for the first time that he/she is not aware of.
1.40 Having gone through the classifying of server roles by the HAM Manager, he and the Sam Manager and wherever possible the server owners (i.e. those folks who called for the server to be deployed in the first place)  sit down and review the server roles and assess whether they are still needed.  From here, two list are created:  Servers to be retained and Servers to be removed.
1.50 For those Servers to be retained, the CMDB is updated – highlighting what the role of the Server is, and the date of last review.  For those servers that are to be removed, the process splits out into two options – The Hardware Disposal Process (if the physical device has reached its end of life) and the Software Removal Process (if the server in question is Virtual, and needs to be removed via Systems Management means).  Equally, it could be that a decision has been taken to recycle the software on a hardware device, so an AND/OR switch is offered to exit the process.

Service/software dependencies:  Do not throw caution to the wind and arbitrarily switch or delete servers – I would always investigate dependencies of the services the server provides – is a particular server part of a wider distributed deployment of software?  Or perhaps there is a legal/regulatory requirement for a server to be sat their apparently doing nothing? Always address the business case, and consider the wider context.

Switching off Servers and seeing who complains first/loudest is not recommended!

Other Process of the Month Articles:

Upcoming Process of the Month Articles:

  • Software Request Process
  • Software Removal Process
  • Process Review Process

Image Credit

The process kit by Rory Canavan is available from SAMcharter.com

email

About Rory Canavan

With a technical background in business and systems analysis, Rory has a wide range of first-hand experience advising numerous companies and organisations on the best practices and principles pertaining to software asset management.

This experience has been gained in both military and civil organisations, including the Royal Navy, Compaq, HP, the Federation Against Software Theft (FAST) and several software vendors

2 Comments

  1. Other techniques to help classify and assign a Status to a server (where the naming convention is not helpful)are:

    Check IP address, it’s common for product and pre-production to be in different segments

    Check backup policy, all production systems are backed up and you usually have an owner assigned (charged)

    Server Banner or login screen. Not always reliable but some sys admins will splash the server status on the login screen

    Password management & security groups: This again can give you a record to cross check.

    At the end of the day you’ll need a variety of sources and a policy to identify an maintain this information is indeed invaluable

  2. Rory Canavan says:

    As ever, very helpful real-world guidance from Piaras. These are the kind of tips and tricks I would expect to see fleshed out from a template and weaved into supporting documentation to ensure the accuracy of any findings.

Leave a Comment