We recently received some changes to the license types of some of our CA PPM users. There are a couple hundred changes that need to be made (some Full licenses becoming Restricted, some accounts being deleted outright, etc...). Can these be batch made via XOG, or would this have to be done individually?
My second question is more complicated. License types are dictated by a specific right (i.e. if a user with a View Only license was granted an single specific Administrative right, their license would automatically expand to a Full, correct?). Changing a users license type from a Full to Restricted (or Restricted to View Only) will also strip them of those access rights, correct? To put in plainly, what are the exact steps that need to take place to change a license type?
I would assume that when you say that you "received some changes", that you have some direction from management to reduce your license count and exert some controls over the number and type of licenses in use. In general, the kind of license that a user consumes is determined by access rights, and access rights can be maintained in bulk via XOG. The official count of licenses used is determined entirely by the kind of accesses used by Active users in your Production environment. You could have a million users in a sandbox environment, but it is only the Active users in Production that are looked at for accounting purposes. And, of course, while you cannot "delete an account", you can deactivate it. Also, to be clear, you cannot directly change a license type in a user record - you must change the access rights that the user has in order to affect the kind of license that he/she consumes. The license portlets in Administration show who has which types of license, and the access rights of each user, so that will be the view to refer to for stripping the access rights to a more manageable number.
You will need to be keenly aware that some Full licenses are determined by certain inherent rights that are built into the application and cannot be modified - most notably Investment managers - like Project and Portfolio managers - and Resource Managers. You will see these access rights in the license view portlet with a designation of (auto). If you have individuals who are designated as a Resource Manager or a Project (or portfolio, or Application or other Investment) manager who do not normally maintain data in Clarity, you will need to either remove them from that field or be prepared to accept that they will consume a Full license. There are various strategies for doing so, but that is a topic far larger than this note will accommodate.
You are absolutely correct that granting even a single access right to edit data in Administration, or even in a single project will elevate that user to a Full license user. You will need to be very clear about who, exactly, will need to have edit rights and Admin access if you need to make wholesale reductions in your license usage. In that regard, you will also need to be very judicious in the granting of Instance rights to projects and resources, as that is often a back-door way that license counts are inflated. The best means of control is through the creation of appropriate Security Groups (simpler is better, fewer are better), and the assignment of personnel to those groups based on the actual functions that they need to perform. That will also make the administration of security (and licenses) easier, and make your security auditors happier.
If you have a large number of users and a lot of overlapping rights for many of them, it will likely take several iterations of clean-up to get a handle on it.
The (very) basic steps for this initiative are:
1. Review with the relevant stakeholders the current user roles and the kinds of access that each role requires to perform their duties. Everyone will need to be aware that the objective of this exercise is to reduce license costs, and they need to be prepared to justify any access for a role that requires a Full license...and even in some cases, a Restricted license.
2. Create Security Groups that are consistent with the duties for the roles. You do not need a group for every role - developers, testers and analysts might all be in a single Basic Access group with very limited access rights.
3. XOG out the Security Groups and add users to the correct groups, and remove users from groups that they should not be in. XOG the group resource data back in...as a note: you might need a Gel Script to delete users from a group, a tech person will know that better than I do.
4. If you have a large number of users with instance rights that need to be removed, you will need to update those records, and that can be done with either a script or XOG.
Do all of the above first in a sandbox environment and test thoroughly.
If the number of changes to your security group structure (not the resource assignments), you may want to consider creating new security groups and deactivating the old ones. That will allow easier recovery in the event that something critical was overlooked in the set-up and testing. After a couple of months, you can them delete the old deactivated groups.
If you have other questions, you can correspond with me directly.
There are not that many things to add to John's post.
One thing I find useful is using a tool that will directly give you required licence. That is much smoother than working with the license information portlets only.
The image is for an older version and from an old Community webcast. With such a tool you can easily see if there is a difference between global and instance/OBS rights regarding the required license. Further the tool can create the major part of the xml file or all of it for the group.
The challenge with inactivating resources is that they are not included in many of the reports either. SO If you inactivate a resource to reduce the license count you remove the related actuals from the reports as well.
Another thing is the participants and collaboration manager which are not within the rights management. So If an active user has been one of those and all the rights are stripped the user will still show up consuming a license in the license portlets, because participant and collaboration are not displayed in the rights in Administration, but still counted when considering license requirements.
Hi William - Did one of the responses help answer your question? If so please mark as Correct Answer. Thanks!