We will have hundreds of console users. Each console operator will be responsible only for their site's systems. Using the latest version 9 release, 9.0.777, what is the easiest way to do this. I'm thinking of creating a special site only to hold groupsthat target each site and then use a combination of sites and roles. Also would like to use the LDAP groups option so that operators are automatically created and assigned the correct rights the first time they log in. So I guess I'm asking, what's the best way to use groups, roles, sites and LDAP groups to do this and make it as easy as possible for us. Maybe an example would spell this out better? Key for us is we want to make sure no console operator has the ability to add more systems to their purview unless they automatically fall into the groups we create. Hence why I want to create these special groups in an area that are not accessable by anyone except the main IEM admins. Thanks in advance!
Pinned topic Best way to delegate rights to large amount of console operators
mcalvi91 27000402M974 Posts
MMcGough 2700045QWK4 PostsACCEPTED ANSWER
Re: Best way to delegate rights to large amount of console operators2013-09-25T21:47:52Z in response to jfschafer
There are a few moving parts to consider. It sounds like you are on the right path. Here is what I would recommend, keeping in mind I don't know what all your organizations requirements are:
Custom Sites: Create a custom site for each of the locations or different groups. The easiest way to do this would be to create those sites by division of duties. The Europe administrators manage the Europe site and the Europe computers are subscribed to the Europe site. The Australia administrators manage the Australia site and the Australia computers are subscribed to the Australia site.
Operators: Each operator will need site permissions to the custom site(s) that are in scope for them. They will also need permissions to manage the machines in those sites. You can do this with or without roles. Roles add an extra layer, but they are nice when you have many operators with the same permissions to the same sites and the same machines. Meaning you would need separate roles to divide duties between sites if that is what you intend.
Endpoints: Each endpoint needs to be subscribed to the site containing the content you want the operators to deploy. You can set site subscriptions based on AD membership or any other relevance expression that you would like to use (IP subnet, registry branding, etc). If you use AD membership you will need to tweak a few things to get a system join the group right away. I believe AD polling is every 12 hours by default, for example.
You can use group membership for the site subscriptions, but then you'll have to wait for a system to join an automatic group before it picks up the site subscription. No problems with that, but keep in mind it does add an extra hoop for the endpoint to jump through, it does also mean you only have to manage subscriptions in one place. This product is very flexible. For every choice there is a cost and a benefit; you'll have to test and find out what fits your org best.
Finally, if you plan to allow the operators to deploy content that exists in external sites (Solaris Patches or Updates to Windows Applications, Software Usage Analysis, Tivoli Remote Control), you will have to account for that in some way. You can subscribe the computers to those external sites and then allow your operators to read that content. You can have your operators copy that content into the custom sites - operators will still need to be able to read those sites. Or you can have the main IEM Administrators perform those duties - either copy content or subscribe computers to the external sites and manage the actions for that content.Updated on 2013-09-25T21:51:58Z at 2013-09-25T21:51:58Z by MMcGough
martinc 060001Y10723 PostsACCEPTED ANSWER
Re: Best way to delegate rights to large amount of console operators2013-09-25T22:17:50Z in response to MMcGough
As said above (or below depending on where you are reading this), there are many factors that make this hard to give a solution. The one recommended by MMcGough for sure works.
Another option to consider would be to create the computer groups and assign the computers to those groups based on some property. The use of the AD groups would be one if you have them organized in AD. You could look at subnets if you have that info available. Possibly host names if you have a naming convention for the locations, departments, etc. Then assign the groups to the role(s) and the operator to the role(s)
You could then assign the groups to the sites or you could just assign all systems to the sites and the operator will only see the systems that they have access to based on the roles.
One possible issue if you create the custom sites and assign the specific operator/role to the various sites is that you could end up with some duplication. What I mean by this is that you could have a software package built for MS Office (as an example) that would need to be available to all sites. You would then have to copy that fixlet to the various sites. It could be the exact same fixlet, so it is not a big deal, but if you need to change it, then you need to do it in all sites. If you create many sites, all systems still have to evaluate the relevance to all the sites, so if you only have a couple sites, this is not a big issue, but if you have a 100, then it could cause delays.
As said previously, this is a very flexible tool and there is no real right answer without first knowing your environment.
Gulf Breeze Software Partners
Re: Best way to delegate rights to large amount of console operators2013-10-25T06:32:47Z in response to martinc
Just wanted to update everyone following this thread. I ended up doing a combination of the excellent advice you gave above. After looking at the pros and cons of the various methods, of course. Here's what I've found. Since we have over 2000 "site locations", each having their own IT, I initially thought, heck, I'll just make each location their own site, have a special area where only I control the main groups, subscribe those groups to the right site, then use roles along with LDAP groups that give rights to those admins to their site and auto create console accounts. On paper that sounds wonderful, until you add 20-30 sites and realize every person that logs into the console now has to load every single site you've created (even if they're not subscribed to all of them). So in the end to avoid the dreaded (1/2122 sites loading) status when opening the console, which would probably take an hour, even on good hardware, I decided to use groups and roles for sites that don't really really need to create their own custom content (most sites I hope) and sites/groups and roles for those that do. Thats really the only way to do it, although some sites are probably going to be upset as I would like to give everyone the ability to create content but not have everyone see each others content (that would be way to cluttered). I think limiting who can create content is the only way based on how IEM is made today.
Although if the console didn't take so dang long to open with 2000 sites, I would have definatley used sites for all. As far as custom content goes, we are going to train console users or force them to go through an enterprise team to build content so we can ensure it goes at either a site level or a higher level for all to benefit. No reason 500 site's should make an office deployment package when we could just make 1 for all to use : )
In the end, this brings up some things about highly distributed environments with lots of IT people responsible for their own sites. IEM is pretty tough to deploy if you don't architect it right or assume you're going to give 1000 IT people in your organization access to the console, because IEM is not made for heavy amounts of console users. It's built assuming you have a very centralized operation of IT management. You definately don't want 2000 console operators, because that's exactly what we would need. So we have to really think hard about who we give console access and who we give just web reporting.
I would love to see some improvements I'd be eager to see in the capability of the console to handle more concurrent operators. For example, web-based console or individual "web apps" that are specific to certain duties (ie software package creation and deployment, patching, creating groups, modifying groups etc). All individual tasks via a web app tied to appropriate API's. Also, it would be REALLY REALLY nice to see web report roles tied to the same roles in the IEM console so you don't have to re-create roles in Web Reports and then manually link the same accounts you've already done in the console to give 1000's of users access to the duplicate 1000 web reports roles you had to create from scratch.
Thanks all for you great advice. It really helped!