To assign a key to a Group or Sub-Group rather than to individual systems or users follow these steps:
1. From the ePO console, click Menu | Data Protection | FRP Keys
2. Click the check box next to the key you wish to assign and click Actions | Key Assignments | Assign to Systems
3. Select the Group or Sub-Group you wish to assign the key to (If you wan to assign to all systems select My Organization)
Note: Do not select any individual systems
4. Click OK
5. Open Menu | Automation | Server Tasks
6. Run the FRP: Process Key Assignments task
7. After the task has been completed, the client must perform an ASCI to pull the key down. Normally you will just wait until the next ASCI interval. If you want to test on a few systems, a Collect and Send Props on the client or Agent Wakeup Call will perform an ASCI immediately
Note: Do not try and send a wakeup to your entire environment, it won't break anything but it will timeout before most of the systems receive the wakeup call
will that permantly assign the key to new systems that check into ePO or will that only apply to the systems that are in ePO when i do it? can keys be assigned Tag based? i thought i remember being able to do that in the 4.x version, but i don't see that functionality in the 5.x version
This is permanent and new system will also receive the key as well as system currently in the system tree.
There is no method to assign the key via tag as there was with 4.x. This is because the grant keys policy is no longer used. Because there is no policy for key assignments, Policy Assignment Rules cannot be used for tag based assignments.
This was replaced with a different mechanism for key assignments to prioritize and make key assignment for users easier. As such, with FRP 5.x I don't really prefer assigning keys to the systems like I outlined above but rather if I require a key assignment to all systems, I assign the key to the Domain Users AD Group using the Authentication Type: OS Authentication. While this isn't the best solution in every situation, this adds additional security as there must be a domain user logged into the system for the keys to be active thus if a local account is used, the keys will not be available and the encrypted data is inaccessible.
understood. i was using the domain user way, but they have a strange issue with ldap syncs failing because the domain is a part of a forest and they have been having ongoing issues with ldap. they are only using one key that they want to every system so until they can fix/figure out the ldap issues, the my org assignment is the fix. thank you for your help.