Frequently Asked Questions (FAQs)

Server Automation enables you to automate the Lifecycle of both physical and virtual servers and enforce best practices across all servers. You can use it to automate best practice processes by sequencing Fixlets, Tasks, and Baselines across multiple endpoints. Server Automation also provides hypervisor capabilities, enabling you to do things like create virtual machines.

• Use Server Automation to automate a multi-tier application deployment. See the demo video for more details.
• Use Server Automation to automate the deployment of Oracle Database 11g. See the demo video for more details.

Example

You can use Server Automation to automate IT processes that otherwise involve a lot of manual and error-prone work. For example, you can use Server Automation to patch systems like web servers in an orderly sequence. You could create an Automation Plan to fully automate the patching of systems such as a cluster of web servers, without any loss of service.

To implement this to run in separate stages, known as steps, you would simply create two steps in your Automation Plan and add this same baseline to each step. To run the Automation Plan, click Take Action.

Then, when you are specifying the targets for each step, you would specify different targets for step 1 and step 2.

You would specify some of the web servers as targets for step 1, and the remaining web servers as targets for step 2. This would ensure that while step 1 is running and patching some of the web servers, the web servers you specified as targets in step 2 remain up and running and providing service to your websites. Then when step 1 has completed, the web servers patched as part of step 1 are back up and running and powering your website, and then step 2 will begin and will take down the web servers specified as part of step 2. Then when step 2 has completed, the patching has completed and all web servers are back up and running and powering your web sites.

For complete installation instructions for Server Automation, click here.

There can be limitations when managing step actions with non-master operators.

In BigFix Server Automation, plan execution and control actions (such as stop, resume, and monitoring step actions) are tightly bound to the operator used to configure the REST API. If a different type of operator attempts to control the plan (for example, to stop a step action), the operation may fail or be disabled due to internal session privilege enforcement. This behavior applies across all Plan Engine versions and is based on the current design of Server Automation and Plan Engine.

This issue has no functional impact and you can correct it by clicking Refresh on the console.

In some rare cases, a failure step might run for Fixlet steps that are showing a Fixed status in the Automation Plan Action Status dashboard.

1. Check that the keystore file generated at Server Automation plan engine startup, called peKeyStore.jks, exists in the C:\Program Files (x86)\BigFix Enterprise\BES Server\Applications\PlanEngine directory.
2. If it does, rename it, for example peKeyStore.jks.old.
3. Restart the plan engine:
   1. Rename the file C:\Program Files (x86)\BigFix Enterprise\BES Server\Applications\Config\PlanEngine.xml file. For example, you could rename it to C:\Program Files (x86)\BigFix Enterprise\BES Server\Applications\Config\PlanEngine.xml.draft
   2. Wait 30 seconds (or if you have Task Manager open, you should see the automation plan engine Java process end.)
   3. Rename the file back again to C:\Program Files (x86)\BigFix Enterprise\BES Server\Applications\Config\PlanEngine.xml

1. Disable the server plugin from starting the plan engine by renaming the configuration file:

   $>mv/var/opt/BESServer/Applications/Config/PlanEngine.xml
   $>mv/var/opt/BESServer/Applications/Config/PlanEngine.xml.stop

2. Start the plan engine manually so any errors can be noted:

   $> cd /var/opt/BESServer/Applications/PlanEngine
   $> . ./bin/planengine.sh start

3. The plan engine does not start properly, and missing shared objects are reported in the shell window. Make a note of these.
4. Use yum to determine what lib(s) are missing, based on the missing reported shared objects:

   $> yum whatprovides <shared object name>

   Note: The most common missing shared object noted to date is libgcc_s.so.1.
5. Use yum to install the appropriate version of the associated providing library:

   $> yum install <library name>

   Note: The most common missing shared library noted to date is libgcc.i686.
6. Retry running the plan engine again; this time there should be no errors and the Automation Plan Engine should remain running:

   $> cd /var/opt/BESServer/Applications/PlanEngine
   $> . ./bin/planengine.sh start

7. After you have confirmed that the engine is running correctly, stop the engine by pressing Ctrl+C in the shell window.
8. Restore the server plugin configuration file back to its original name (to restore automatic startup of the engine):

   $>mv/var/opt/BESServer/Applications/Config/PlanEngine.xml.stop
   $>mv/var/opt/BESServer/Applications/Config/PlanEngine.xml

9. Finally, tail the engine console log file to ensure the automatically started engine is functioning correctly and no errors are reported:

   $> tail -100f /var/opt/BESServer/Applications/Logs/pe_console.log

You must then start the BES Server Plugin Service and try the installation of the Automation Plan Engine again.

2012-12-06 06:59:27,604 INFO [main] (cli.PlanEngineLauncher:172) :: IZNENG109I Starting the Automation Plan Engine ...
2012-12-06 06:59:33,038 INFO [PlanEngine] (util.AccessChecker:96) :: IZNENG0135I The Platform API cannot be reached. Ensure that the Username and the Password are correct.
2012-12-06 06:59:33,041 INFO [PlanEngine] (util.AccessChecker:102) :: IZNENG140E There is a API error in the calling Script: {0}. {1}
2012-12-06 06:59:33,043 INFO [PlanEngine] (cli.PlanEngineLauncher:153) :: IZNENG094I The received command is : "quit"
2012-12-06 06:59:33,044 INFO [PlanEngine] (cli.PlanEngineLauncher:184) :: IZNENG113I Shutting down the Automation Plan Engine ...

2012-08-23 13:15:20,235 INFO [main] (cli.PlanEngineLauncher:255) :: IZNENG025I \
Plan Engine (build number 0.49) starting in JVM with PID (4508) ...
2012-08-23 13:15:20,235 INFO [main] (cli.PlanEngineLauncher:259) :: IZNENG026I \
Plan Engine CLI initializing ...
2012-08-23 13:15:20,235 INFO [main] (cli.PlanEngineLauncher:130) :: IZNENG001I \
Received command: "start"

Also, for upgrading the Automation Plan Engine from single node to multi-node, refer to Migrating from Automation Plan Engine (Single node to Multinode) or vice-versa in our product documentation.

1. The Automation Plan Engine begins processing the Automation Plan action.
2. The Automation Plan Engine opens a step action.
3. The Automation Plan Engine processes the step action on the endpoints that you specify.
4. If the step action is successful, the Automation Plan Engine stops the step action and proceeds to the next step action.
5. If the status for a step action is Failure and the step has no failure step, the Automation Plan action is stopped.
6. If the Automation Plan contains a failure step for the failed step action, the Automation Plan Engine runs the failure step before the Automation Plan action is stopped.
7. If the prior step action is successful, the Automation Plan Engine opens the next step action and begins processing it.

If you stop an Automation Plan step action without first stopping the Automation Plan action, the Automation Plan Engine continues to process the Automation Plan action, generating new step actions as it does so.

• The Automation Plan Engine fails to communicate with Web Reports.
• The Web Reports Service might be disabled.
• Web Reports user credentials fail or become invalid.
• BigFix console user credentials fail or become invalid.

1. Note the ID of the Automation Plan that you want to export. The ID is displayed in the ID column for the Automation Plan in the Automation Plans panel.
2. Go to the All Content domain and click Fixlets and Tasks. Enter the ID of the Automation Plan that you want to export.
3. Click Export, specify a file name and location, and click Save.

1. Install the BigFix Client on the computer that will be imaged. After installation, the BigFix Client will register with the BigFix Server and will write certain registry keys and files to the hard drive after registration. You must remove these registry keys and files.
2. Stop the BigFix Client in the Windows services dialog.
3. Remove the registry values RegCount, ReportSequenceNumber, and ComputerID (if they exist) at HKEY_LOCAL_MACHINE\SOFTWARE\BigFix\EnterpriseClient\GlobalOptions.
4. Delete the __BESData folder in the BigFix Client installation folder (default is C:\Program Files\BigFix Enterprise\BES Client).

1. Install the BigFix client on the computer to be imaged. After installation, the BigFix client registers with the BigFix server.
2. Stop the BigFix client by entering the following command: # /etc/init.d/besclient stop.
3. Edit the file besclient.config and delete the three lines beginning with ReportSequenceNumber, ComputerId, and RegCount.
4. The default location of the besclient.config file is /var/opt/BESClient/besclient.config.
5. Delete the __BESData folder. The default location for this folder is /var/opt/BESClient/__BESData.

The Server Automation Virtualization management extender supports up to five concurrent virtualization requests. However, because of this issue where processes compete to complete the command, the concurrency can be reduced to between one and five processes.

The above scenario is valid when using the Management Extender, but the issue is solved to a greater extent when one uses the Plugin Portal.