1 of 1 people found this helpful
The method you are using will result in the selected user or user group being assigned to one system. If you want to assign a user or group to all encrypted systems, then you need to use the Group Users screen. Go to menu>data protection>endpoint encryption users>group users. Any user or group you select here, will be assigned to all systems in that part of the system tree. If you want those users to have access to all systems, simply do this at the My Organization level of the tree (the root).
Are you saying that instead of asking users to login to a system so they get "cached", I can do everything from within a group? Would this group be "pushed" to all laptops with EEPC6.1? Another problem is that from research it seems that 6.1 has a limitation of recommended 350users with max of 500 users per device. At the moment we have 731 users on v 18.104.22.168 and this would be an issue with 6.1
Comments are appreciated
1 of 1 people found this helpful
The limit on users is defined by the Preboot Filesystem size, which defaults to 20MB but is confirgurable in EEAdmin. Also, if you are a password-only customer (i.e. you don't use smartcards) it would be worth changing your LDAP sync task to remove the "certificate" field so that user's certs are not synced across.....these certs take up quite a lot of space and if you are password only you don't need them.
Where do you see it stated that the product can handle a max of 500 users per device?
dwebb, thanks for your prompt reply
I attended a McAfee webinar this week (lost the first 45min). Will attend another on Monday 13 Jun
How many users can be accommodated by the default PBFS size?
Approximately 350 users. (speaker menitoned that 500 could be squeezed in)
How much space will a single user occupy in the PBFS?
Approximately 8-10 KB.
Can I change the default size of the PBFS?
Yes. This is a Server policy setting.
What is included in the PBFS?
The PBFS contains all of the necessary information to provide the user with the ability to authenticate. This includes but is not limited to:
- The files necessary for the Pre-Boot Environment
- Language files for all supported client languages
- Fonts to display characters from all supported languages
- The theme assigned to the client
- The users assigned to the client
1 of 1 people found this helpful
Ok, so what the speaker probably meant was that 500 could be squeezed into the default PBFS size.
I would recommend that you up the PBFS size to 30MB, remove the certificate sync from the sync task and then test with your 700 users. It should be fine (note that if you see sluggish behaviour at login, it will be because a lot of syncing of the 700 users is occuring which locks the PBFS preventing the login from hapenning. Login and then retry login an hour or so later and the problem should have gone once the users have all synced across.
dwebb, thanks again.....
when you saying sluggish behaviour at login, do you mean the whole boot process or just from CTRL+ALT+DEL screen?
Slightly diverting from original post, I am curious about sluggishness because I have been trying to troubleshoot a slow login problem on our network and have not thought about safeboot. Came across this thread: https://community.mcafee.com/thread/32300 post #4 "....BUT it won't let a third party GINA start until all drivers are done, because there may be some dependencies, etc..." (We use Novell). Have been using Xperf to diagnose it.
It maybe a good ideia, as we are migrating, to just have users sync'ed via "add local domain users" rather the bloating a group.
Hope someone can come up with some comments/suggestions
Just from Ctrlaltdel screen......the system will activate after the first batch of users is received, so when it gets back to login prompt it may be syncing further users down to preboot, meaning that the credential provider is blocked from accessing the PBFS temporarily, meaning that login can appear to take a little while. Once all users are synced, the sluggishness disappears.
More generally, we have seen certain third party services fail to start properly, preventing the EEPC service from starting up until Windows times out the offending third party service. This can result in a delay at login. Windows will timeout the service after around 80 seocnds, so if you are seeing such a delay it could be that a service (not EEPC) is failing to start properly, meaning that all subsequent services are blocked from starting. Check this out in the system logs and look for errors starting services.
Yes. You don't have to ask users to login to Windows once and get cached. That would only be a requirement if you were relying purely on our "add local domain users" feature. This is one of three ways to assign users to systems.
- Use add local domain users to detect cached users during activation, This eliminates the need for the admin to assign individual users to their systems. Yay for automation!
- Add users or groups of users to invidual systems. This is done in ePO from the Encryption Users screen. You just click on a system, then choose actions>endpoint encryption>add user.
- Add users or groups of users to ALL systems or GROUPS of systems (instead of individual systems like in option 2). This is most useful for groups of administrators who need access to all systems. This is also done in the Encryption Users screen, but you have to go into the "Group Users" tab. Anyone you select in the group users tab will be assigned to all systems in whichever part of the system tree you have selected. If you want them assigned to all systems, just make sure the My Organization part of the system tree is selected.
Most customers will use a combination of option 1 and 3. They use 1 to assign end users to systems, and they'll use 3 to assign administrative or support users to systems.
The only tricky use case is the case of brand new systems. Since they don't have any cached users, it is difficult to use option 1. But for that, we recommend simply using two policies and switching them after the system gets some cached users. You can see the process here: https://community.mcafee.com/blogs/danlarson/2009/11/25/eepc-v6-best-practice-te mporarily-enable-automatic-booting-on-new-installs
You can fit 731 users in the pre-boot environment, no problem. But there is a right way and a wrong way to do it.
As dwebb says...
- Go to your LDAP sync task and clear the 4th field (just delete the text in it)
- Also go to the User Based Policy and either disable self-recovery or delete any of the questions that you don't use (especially the ones for languages that you don't support)
- In the configuration screen, increase the size of the PBFS to 30MB (just for some padding)
- You may also want to consider increasing your ASCI interval. The default is 60 minutes, but I'd bump it up to 180 minutes while you are initially implementing this.
The reason that support and some others in McAfee recommend assigning smaller numbers of users to systems is for scalability. If a customer with 100,000 laptops assigned 5,000 users to every system, their ePO server would probably start smoking. It is just a lot of calculations to process lots of users on lots of systems all day long. ePO can do it, but it will suck a lot of resources. Since you are only talking about 731 users, I'd bet that you have less than 1,000 systems. So assigning 700+ users in that environment is not a problem - as long as you follow the advice above.
For your use case, you should just go in the encryption users screen and leverage the Group Users features. Pull your AD group that has your 731 users and assign it to the My Organization level of the system tree. Then I'd disable the add local domain users option in the system settings policy since you no longer need it.