Managing Protect With Multiple Administrators

Version 3

    Purpose


    In some environments, there may be multiple administrators tasked with overseeing patch management. When using multiple administrators with Protect- understanding how this works and the best practices for such a configuration can help this process run more smoothly. This document explains how Protect handles multiple administrators and shares some best practices for using Protect with multiple admins.

     

    Description

     

    How Shavlik Protect Manages Multiple Administrators

     

    Shavlik Protect contains a number of built-in checks to guard against simultaneous and conflicting commands from different administrators. For example:

    • The program will not allow duplicate group names or template names
    • The program will not allow simultaneous updates to any groups, templates, distribution servers, or agent policies by different administrators. If this situation should occur the second administrator will receive a warning message similar to the following:

         "Another user has updated the Machine Group named 'Sample Machine Group' since you opened it. Reload 'Sample Machine Group' to see their changes."

    another_user.jpg

    • Only one console will be authorized to use the Database Maintenance tool. If an administrator at another console wants to perform maintenance on the database, that administrator must take ownership of that task before the program will allow the administrator to continue.
      • Note: The 'Take Ownership' button is only displayed if you have two or more consoles that share one database. If your organization uses multiple Shavlik Protect consoles that share the same database, only one console will be authorized to use the Database Maintenance tool. If an administrator at another console wants to perform maintenance on the database, that administrator must take ownership of the task before the program will allow the administrator to continue. Any existing maintenance tasks will be allowed to complete before ownership is transferred to another administrator.

     

    Best Practices When Using Multiple Administrators


    Recommendations

    • You should upgrade your hardware platform by increasing the number of processors and the amount of installed memory on the console machine. This will increase performance in those instances when two or more administrators are logged on at the same time and performing tasks.
      • Minimum suggested hardware requirements for two administrators: 2 processor cores and 4 GB RAM
      • For a high performance system, use 16 processor cores and 32 GB RAM
      • For each additional administrator, add 1 processor core and 1 GB RAM
    • When two administrators log on to the same console they must use different accounts. The same account can be used only when logging on to different consoles.
    • If you edit a group that is typically used by another administrator you should notify that person about the change.
    • Each administrator should create their own credentials and assign them to machines.
    • Each administrator should define default credentials that are the same as their logon credentials. This will eliminate problems that may occur if the administrator forgets to assign machine credentials.

     

    Potential Issues When Using Multiple Administrators

    Usage Issues

    You must take a few common sense precautions when using multiple administrators.  Even though Shavlik Protect contains a number of built-in safety checks, it cannot guard against all possibilities. The program may act in unpredictable ways if the following occur:

    •   If two administrators try to scan the same machine group or ESXi Hypervisor at the same time.

    The machines will be scanned twice, causing potential performance issues. In addition, there may be administrative rights errors due to the multiple connections.

    •   If two or more administrators try to deploy patches or bulletins to the same machine at the same time.

    The most likely result is that one deployment task will succeed and the other will fail. But because the deployment that succeeds will likely perform a restart of the target machines, the machines may be in an unknown state when the other deployment fails.

    Credential Issue

    When you create credentials and assign them to machines, those credentials belong to your administrator account. If a different administrator (Administrator B) logs on and uses Shavlik Protect, they will not have access to the machine credentials you provided. The second administrator must provide their own machine credentials.One of the ways this can be confusing is if Administrator B fails to provide their own machine credentials and tries to schedule a patch deployment from a scan that was performed by Administrator A. The deployment can be successfully scheduled if default credentials are available, but the actual patch deployment will likely fail because the patch deployment requires machine credentials -- credentials that were provided by Administrator A but that are not available to Administrator B.Recommendations:

    • Each administrator should create their own credentials and assign them to machines
    • Each administrator should define default credentials that are the same as their logon credentials. This will eliminate some of the problems that may occur if the administrator forgets to assign machine credentials.


    Virtual Inventory Consideration

    Unlike machine groups (which can be viewed by all administrators), vCenter Servers and ESXi Hypervisors can only be viewed by the administrator that added them to Shavlik Protect. If two different administrators want to manage the same vCenter Server or ESXi Hypervisors, both administrators must add the item to the Virtual Inventory list.

     

    Additional Information

     

    How Credentials work in Protect

     

    Affected Products

     

    Shavlik Protect 9.x