This content has been marked as final. Show 25 replies
Sorry, haven't seen the issue before - but a few thoughts.
Are the machines in a controlled or an uncontrolled group? If controlled, if you look at the properties of the group, do the groups with the removed users still exist? If uncontrolled, check the group and the individual computer object. Peek at the computer auditing log as well (on the server), maybe there are some hints in there. Have you confirmed the users are still a part of the groups that are assigned to the computer?
Are these groups created by synching with Active Directory? If so, are you maybe starting to hit a limit on the number of users allowed as part of your license? I'm not sure what happens when you hit or pass the limit, but could be worth a look.
And finally, I think that only 2,000 users can be assigned to a single machine, are you surpassing the limit by assigning any of these groups to the computers?
Sorry I can't be more helpful, but these are the things I'd probably check first.
which product version? do you have a client log you can post?
You may also want to check to see if the users are being deleted and recreated in SB. Depending on how your LDAP/AD connector is configured, a "moved" user in LDAP/AD could be considered by the SB Connector to be a "delete" for one and a "create" for another. Like Active Directory, recreating a user of the same name does not give it the same database entry, so it would lose any associations it had (as they are done by object ID).
Now that is interesting. Counting up, we have 1994 users assigned to this machine group so we should be OK. Can you cite a reference for this limit?
Thanks for the help
We're on Build 5420. I have got a couple of client logs but they're about 1000 lines each which is a bit long for posting.
This would imply that changes were being made in AD. That would require somebody to be actually maintaining AD.... :rolleyes:
In any event, these users haven't been moved around in AD. And even if they had, that wouldn't explain why they only get removed on one ore two machines as opposed to all of them :)
Hi Mike - I have the 5500 build documentation in front of me and can't find a reference to the limit, but it's been give to me each time I've had McAfee on-site and in conferences I've been to where McAfee has presented. Now that was all back when I was looking at an older build (about 2 versions old), but there's nothing in the release notes that say the limit has been removed. Perhaps one of the two McAfee reps can point out where it is in the documentation.
Furthermore, the reason for the limit, I'm told, is that the size of the SbFS has a max size, so for all I know the 2,000 user limit is a soft limit based on what else is in the File System - maybe (pure guess) if you put other themes in there, or extra token readers or something it would take up the room needed for those extra 6 users (2000-1994).
Technically, there isn't a limit baked into the software that states "no more than 2k users can be assigned" - but do keep in mind that the safeboot filesystem (sbfs) file is only 20mB of size, which stores all these users, including filegroups such as themes and what not in it also..
Hence, the problem would be that the sbfs is full, which would result in users not being able to sync or get any updates etc etc..
And yes, this can be expanded but it's generally not a good idea to do so :)
Anyhow -- if you have actually assigned this many users to all machines, my guess would be that a large number of machines actually have the same set of users assigned to it?
If so, keep in mind that if a clientmachine gets the signal to sync, it will access the database and lock the item it comes across upon that moment.
Now, looking at machine #2 in your env - which holds the same number of users - will also start to sync, and come across one of the users within the database which can not be accessed as it's locked by machine #1 - the effect could be that it either thinks its gone or corrupt, and might toss it away due to that..
Now imagine having this in an environment with 1500 machines syncing at around the same time, with all the same users ;-)
I've seen this before, resulting in such issues.
My suggestions would be the following;
- Reduce the number of users assigned to machines to the mandatory users only (individual > groups)
- Make sure all machines do not sync at around the same time
- Use a random boot sync delay to spread the load
- Make sure no other stuff is locking the safeboot database (sbdata), such as a virusscanner or backuptool during syncs
- Try not to use the ad connector at times when many syncs are going on to avoid conflicts
Hope it helps.
Would the OP be able to use the SBFS viewer that came in the TOOLS pack to see how much of the 20mb was being used? I haven't used it in quite a while and don't have access to it now, I don't recall if it showed just files or if it showed sizes as well.