Group Sizes - McAfee ENDPOINT ENCRYPTION ENTERPRISE - BEST PRACTICES GUIDE Manual

LifeTime=86400
The time (in seconds) for which the index will be used before it is automatically re‐created if somebody logs on
to the database. The default is 30 minutes but is never recommended. A value of zero means that it never
expires automatically, and the value of 86400 means one day.
A value of zero gives you full control but this setting needs a separate process to recreate the index. This could
be a simple batch file that runs overnight ‐ removes the index files and forces a recreate. This can sometimes
produce the best result and performance.
Recreation of the index files will take performance. It will cause the logon to be delayed for quite some time
dependant on database size and performance, and can cause issues if the creation of systems occurs during
this rebuild time. Therefore, depending on the size of the database, it is recommended this process is set to
run very early in the morning. For example, remove name* files in SBDATA 00000001 and 00000002 folders
especially through a script early morning 2 A.M. Following that, run an admin logon using the command line
tool (SBADMCL) and perform a command such as getcounts through script to rebuild the cache early, before
the systems synchronize.
You can use a batch files for this, one example is called RecreateCache.bat. Examples of scripts are in the
optional EEPC Tools download, or, available from your McAfee representative.
[Attribs]
SingleFile=No
If this is set to Yes, the attributes for objects will be placed into a single file instead of each one having their
own file. Not generally used although it simplifies and speeds up backup, this will make the database twice as
slow!
AutoConvert=No
If this is set to Yes and SingleFile is also set to Yes, then attributes are automatically converted to a single file
when the object is opened for writing. Otherwise, only new objects will have their attributes in a single file.
NOTE: Attributes are not converted until they are opened for writing. Again, this can produce fewer files per
object to aid backups but is slightly less resilient to failure.
[Tracking]
ObjectChanges=No
Object change tracking for the backup tool might decrease the performance of the database by about 100%
thus it is not recommended to use this in big environments.
Group sizes
The size of a user group or systems group should not be too big. A user group of 5000 can take 20 seconds or
more to open even on a fast server. We recommend keeping the size under 2000. Optimally 1000 or less will
work well in many cases for faster access to groups on any server.
Also assigning large group of users directly to a client can have performance implications (network/server
performance, slow client boot up and sync times and installation processes) so smaller groups are better.
Users can be assigned individually too. The fewer users assigned the better from a security perspective. See
User Objects – General Performance Tips section later.
14