Trigger baseline from client side

Customizations
1

Hi, is there any CLI or script using which we can trigger the baseline installation from the client side ?
Requirement is to install all baseline for newly built servers [Windows], if yes, then I can have a batch file or powershell script to trigger the baseline installations and reboot servers from client side itself. If other alternate methods are tested, please advice.

regards
Rahamath

2

It depends on how you wrote the Relevance for the Baseline(s).

A newly installed BES Client will begin processing all of the Open Actions as soon as it gets them from the Main Server or it’s Relay.

If your Baselines all have Open Actions, then eventually the client will process them (assuming they are Relevant to the new system).

By default, the BES Client doesn’t provide any way for you to “manually” kick off an Action (Baseline, Fixlet, Task or otherwise).

The Action must …

  1. Be in a site that the Endpoint is Subscribed to. Under normal circumstances, the Client will not receive Action files from sites it is NOT subscribed to, but there are conditions that it can happen, and the client will refuse to process the Action if it, or the source Content, are from a site the BES Client is not yet subscribed to.
  2. The client must Evaluate all of the Relevance clause as TRUE. Any FALSE result will cause the client to determine that the Action is not Relevant to the Action in question.
  3. Depending on how the Action is created, specifically the Reapply this action Option, the BES Client will only process a Relevant Action one time.
  4. The Action must not be “Expired”.

If your Baselines have Open Actions, and the BES Clients in question are subscribed to the sites that hold the Actions, then eventually the BES Client should process them.

3

Hi

We’ve asked this question to multiple persons in IBM, but with no luck. There is no way that the client can start an action by triggering the CLIENT API or something else. You do have some work arounds that you can play with. You can put an extra relevance in your baseline that checks for a custom registry/textfile/folder/… I don’t know what your exact use case is, but you can create this registry/textfile/folder/ on the machine whenever you need a baseline to execute. Remember to put the baseline on reapply when it becomes relevant.

Hope this helps.

4

It is part of a security model that the client can’t initiate actions. It could however accept an offer or like you have mentioned it could rely on some other object in the OS existing, but this is still following the security model that an action is created on the authority of a console operator.

2 Likes
5

It sounds like the original post is really solved by an open policy action that is dynamically targeted to either all machines or just the new ones, or similar mechanism.

This is really the way to dynamically trigger an action (or baseline action) from the client side.

You could have something that only triggers if a file DOES exists, and deletes it at the end, or something that only triggers if a file DOES NOT exist, and creates it at the end. A file is just one example, it could just as easily be a client setting, or registry setting, or similar.

One example of why you would want to do this is to trigger something like the client gathering new content based upon something else happening in the system in the case where UDP notifications are not working and you don’t want to wait for command polling to happen.

It is important to understand that the client can continue to process policy actions and existing actions without the root server or relays, as long as they don’t require downloads that are only available from the root server/relays.

6

Automation against newly created machines does work and can work well if the proper setup is done. Some key elements include:

Have one or multiple unique attributes/conventions for the machines being created. Think subnets, computer names, models, location, brand, etc.

Create a dynamic group using a relevance expression that accurately identifies the unique attributes/conventions.

Create a custom site for your staging content. Add scripts and packages into this site.

Create a policy action to subscribe to this site that uses the same relevance. This way machines automatically get the correct content.

Create another policy action with the same relevance that targets the dynamic group you previously created. This policy action could be a single task/fixlet or a whole baseline of items.

For different types of machines, just vary the criteria to different unique attributes.

Optionally chain policy actions to have new machines step through a sequence of baselines.

Optionally do your domain joins automatically. Using an encrypted password, you can leverage a dynamically built Netdom script that can correctly place your new machine into the right domain and OU of your choosing.