The baseline is one of
the most important component in the IEM and it contains the collation Fixlets
and Task. In another word the baseline is group of the Fixlets and Task which
we need to deploy in the group of or single servers.
The following are best practices a console
operator should follow when creating and using baselines and taking baseline
actions:
SIZE: Limit the number of components per baseline to a maximum of
anywhere between 75 and 150 components. There is no hard maximum number of
components that a baseline can contain. However, a baseline which is too large
can take a very long time for the client to evaluate and process based on the
number and types of components being added to the baseline and the size of the
component relevance clauses. If this happens, this could tie up the client for
several hours to a couple of days and in the meantime block the endpoint from
being able to process further actions or send reports. There is no exact way of
determining how many components your baselines can contain before client
performance suffers, so start within the recommended range and move up from
there; testing the to see if the clients can take larger baselines and still
perform well.
SITES: Create baselines in custom sites to keep the total size of the
master actionsite low. Doing this helps to prevent the client from spending all
of its time processing the master actionsite (which takes priority for the
purpose of processing administrative types of actions in the deployment).
Ensure that the endpoints for which you want the baseline to be evaluated on
are subscribed to the custom site which contains the baseline.
OPERATORS: When taking actions on the baselines, take them as a
non-master console operator. This will also help to keep the total size of the
master actionsite low.
PATCHING BASELINES: When creating patching baselines, the
following are recommended to reduce the potential for problems occurring:
READ the Description in each Fixlet before deciding that you
want to add it to a baseline and deploy it. The Descriptions contain important
notes, requirements, and potential problems that may arise when deploying the
update. It is important to be aware of these before adding them as components
to a baseline or taking action.
DO NOT blindly select all Fixlets or even all patching Fixlets
and just add them to a baseline. Sometimes there can be a temptation to filter
in all relevant Fixlets, add them to a baseline, and take action to all
endpoints. Doing this can cause serious problems in your deployment and
enterprise.
DO NOT add components that are for administering your deployment
in baselines that are for patching. For example, do not include a Fixlet from
the BES Support site used to upgrade the IEM client in a baseline with patching
Fixlets from the Patching for Windows (English) site. Keep deployment
administration types of actions separate from OS patching actions.
DO NOT add service pack level patch Fixlets as components to your
baselines. Deploy service pack level patches as separate actions. Service pack
level upgrades are too large and expensive to be placed in a baseline along
with other updates. Service level updates may also supersede other updates and
so you may want to upgrade the endpoints OS to the latest service pack level,
confirm continued functionality on the endpoint, and then deploy the balance of
any relevant patching Fixlet update.
DO NOT add patch Fixlets to baselines in which the name of it
contains CORRUPT PATCH.
DO NOT add patch Fixlets to baselines in which the name if it
contains (Superseded).
DO NOT add patch Fixlets to baselines which require the download
to be manually cached.
DO go through each patch Fixlet component when you are
editing the baseline to ensure you have selected an action for the component.
Most Fixlets have a default action "Action1 (Default)" which is set
for the component. Check to see if there is only that one default action. If it
does only have one, leave it on that the default action: