Hi folks - We recently had our professional services rep come and install our product and get us on our merry way. All went well and Excellent service. However, they did mention that it would be a best practice to NOT check the checkbox to add all domain users and instead, to add each user manually. Unfortunately I dont recall the reason.
Does anyone know anything about this or have any opinions or thoughts on this?
Everything I read seems to point toward checking the box - and on a major rollout it is becoming a real PITA to add each user manually.
What to you all think?
Thanks in advance.
it does not add "all" domain users - only those with local cached profiles? I would check it - that's what it's for.
Simon, we tried to use it, because it makes sense, but the end result was in 6.0.x it just didnt work.
We found that if this was on, then we would never kick off encryption.
In addition, every call to support they made sure that we had this off in the policies.
I think that it was to assure that there was not duplication of user tokens, from being added through this way and also having a group assigned.
In the documentation for 6.1 it says to make sure that it is on. We have not tried it yet, we have some other issues to work through before. Once those are worked thorugh, we will give it a shot, we want this feature to work.
Wyodoc1, your issue was most likely caused by communication problems inherent in the 6.0.x architecture. These problems are now fixed in v6.1 and "add local domain users" is working great now. I would encourage you to upgrade to v6.1.
we have 6.1 and tried add the domain group "domain users" bad ideal we have 30K users and this killed our db. Did the add local domain users check and that works great.
Glennjbrown, this is a great observation. I think many customers may be tempted to assign all domain users to all systems, but it causes two problems. First, the pre-boot file system is a finite size (I think 20MB by default), we simply cannot fit 30K users in that space on the disk. I think the max we can support, even if you increase the PBFS file size, is around 5,000. This is a lot, compared to our competition, but definitely not big enough to contain all users for most enterprises. The second problem is sync time. On each ASCI, we have to process some of the users (sometimes all of them). If each endpoint is processing thousands of users, then ePO has to work very hard to return the necessary information. This results in high concurrency on the ePO server and long sync times for the clients. It works, but it requires a very fast server and at the end of the day the benefit is very minor. You don't need to assign every user from the domain, you just need to assign the users who actually use the system. That's why the add local domain users feature is so popular.
Just to clarify the following statement
If each endpoint is processing thousands of users, then ePO has to work very hard to return the necessary information. This results in high concurrency on the ePO server and long sync times for the clients.
The processing will be done on the AgentHandlers, which in turn will be communicating with the SQL database.
Indeed. Each time a user changes their password, this needs to be synced to all the machines in your estate, causing not just significant server load but also high network traffic. If you use smartcards, the problem is further worsened by the need to sync down certificate data which just makes the data that much larger.
To clarify Simon's point, the ALDU function only adds in domain users who have logged into the client machine at least once in the past. It does not add all domain users.