14
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.
