Of course, during setup this approach isn’t viable at all. But as soon as the OM12 Management Group is functional (that is two OM12 Management Servers are in place and the related SQL databases), there isn’t a good reason anymore to use them to run the OM12 Console from.
Why you ask? Good question. There are multiple reasons:
- The OM12 Console consumes RAM
As the matter of a fact, the OM12 Console might become RAM hungry. Especially when you’re creating new Views, User Roles, Run As Accounts/Profiles, importing/configuring Management Packs and so on. - The OM12 Management Servers require the resources themselves
In any given Management Group, the OM12 Management Servers have a lot of work to perform. More over with the ‘good old’ RMS gone and having distributed the RMS specific workloads among ALL OM12 Management Servers. So why ‘eat’ it away with running the OM12 Console on those servers? And belief me, when YOU start doing it, you’re colleagues are bound to follow soon ((S)He does it as well, so why shouldn’t I?). And before you know it every OM12 Management Server has locally two running OM12 Console sessions running… - The OM12 Console creates PER user a cache file
This cache file might grow overtime to several hundreds of MBs, especially when you have opened all the different Views available in the OM12 Console. This will consume a lot of disk space and create an additional burden. - Let’s talk about security and the lack of auditing…
Now with OM12 the local group BUILTIN\Administrators have SCOM administrator access to the OM12 Management Group. Basically meaning when some one logs on to a OM12 Management Server many times they’re member of that local group, granting them admin access to your OM12 environment. Normally you don’t want situations like these, since the more people can do within any given product without the proper required knowledge, the bigger the changes are something is bound to go wrong. And with an almost lack of any auditing mechanism in OM12 (), changes are you’ll never find out who wrecked what in OM12…
Okay! You’ve got me convinced. So now what? Install the OM12 Console on every system the OM12 administrators and end users touch?
No, that’s also a scenario you shouldn’t use. Simply because it becomes hard to manage it when an update for the OM12 Console comes out (on an average basis 4 times per year at least when looking at the release schedule of the Update Roll Up packages).
Instead it’s far more better to use a Windows server dedicated for managing your IT environment. Servers like these run Terminal Servers in user mode, so the server allows more than two concurrent sessions and are called stepping stone servers or management servers (not to be confused with OM12 Management Servers). Servers like these run a plethora of other ICT management applications as well like management tooling for the Virtual Infrastructure, network management tooling, SAN tooling, etc etc.
With a trick the cache file for the OM12 Console is to be redirected to another logical drive, offloading the drive running the server OS. And when an update of the OM12 Console comes out, it’s easily pushed to this server and you’re done. Compared to keep inventory who has the OM12 Console installed, and make sure they all get the proper update, this is a walk in the park.
When this special server is properly provisioned (enough RAM, CPU and disk space) you’ll benefit from it. Even more so when the ICT management applications are used while running a regular end user account (so NOT an account with domain admin permissions!) and the terminal server is fully configured, including the permissions which decide what user account is allowed to run what ICT management applications.
Now you’re in total control of your OM12 environment. Of course, keep the installation files of the OM12 Console on a location which is also protected, preventing rogue installations of it.
No comments:
Post a Comment