This topic provides information that supplements the TrueSight Server Automation documentation. It contains the following sections:
When is the end of support for my version of TrueSight Server Automation? Is my version supported? (Should I be thinking about upgrading?)
For supported version information, see the following BMC Support Support page:
http://webapps.bmc.com/support/faces/az/prodallversions.jsp?seqid=164625
Note that as of June 26, 2012, version 7.x releases are no longer supported.
Where can I find information about the platforms currently supported for TrueSight Server Automation product versions?
You can find information about the supported platform for TrueSight Server Automation on BMC Support Central, under Product Availability and Compatibility.
Where is the Knowledge Base?
The BMC Knowledge Base (which includes answers for common problems with TrueSight Server Automation) is located at https://bmcsites.force.com/casemgmt/sc_CoveoSearch#q=BMC%20Server%20Automation&t=KB&sort=relevancy
What ports and protocols does TrueSight Server Automation require?
Where can I find the build number for a release?
Where can I find information about the integration of TrueSight Server Automation with BMC ProactiveNet?
See the following documentation resources:
- For information about enabling the retrieval of change information from BMC BladeLogic Server Automation for Probable Cause Analysis (PCA), see the chapter about integrating with TrueSight Server Automation in the BMC ProactiveNet User Guide.
- For information about transferring data to BMC PATROL and BMC ProactiveNet regarding the status, availability, and performance of hosts and servers managed by TrueSight Server Automation, see the online documentation for BMC PATROL for TrueSight Server Automation and BMC ProactiveNet Automation Server Monitoring.
Where can I find information about the third party software versions included with TrueSight Server Automation?
You can find information about the included software versions in the Third-party software section of the Minimum software requirements topic and in the Browsing-discovered-software-applications topic.
Installation and upgrade questions
What are the Supported upgrade paths for TrueSight Server Automation?
Where can I find deployment architecture recommendations for implementing TrueSight Server Automation?
You can find deployment architecture recommendations in the following Planning section: Deployment-use-cases
What do I do if I just upgraded and am getting errors in Jobs that reference Custom/Server Objects?
Where are the Microsoft Visual C++ 2015 Redistributable installation log files located?
How do I find the description of Microsoft Visual C++ 2015 Redistributable related errors reported in log files?
How to debug the failures reported during psexec commands ?
Check the debug level rscd.log file on the Psexec server.
You can also try to convert the blpsexec command from rscd.log to native psexec command and try to execute it on psexec server from Administrative command prompt (cmd.exe started as “Run as Administrator”).
blpsexec command: blpsexec -s winserv.bmc.com -u Administrator -p TNEKNUDRFET -h cmd /c hostname
psexec command: psexec \\winserv.bmc.com -u Administrator -p password_of_Administrator_user -h cmd /c hostname
What will happen if Microsoft Visual C++ 2017 redistributable is already installed on a server?
Internal version of Visual C++ 2015 and 2017 is same (i.e. 14.0). So when we try to install VC++ 2015 redistributable it detects that newer version is already installed on the server, so installation is skipped.
As Visual C++ 2017 is binary compatible with 2015, our product will still work with Visual C++ 2017 redistributable.
Will 8.9.2 Application server (that uses Microsoft Visual C++ 2015) have any backword compatibility issues with older Agents (which uses Microsoft Visual C++ 2005 redistributable)?
No. There won’t be any issue in communication between 2 components which are using different versions of redistributable.
I'm having trouble with an RSCD agent. How do I open up the permissions temporarily?
Use the following process:
- Start by looking at the rscd.log. Who are your requests currently mapping to? If it is someone who does not exist in your users or users.local file, consider adding a temporary definition for them.
- Remove the "nouser" line from the users file.
- Change the contents of the exports file so that it contains a single line: "* rw,user=root" or "* rw,user=Administrator" (or the name of your local admin account).
Once you have finished troubleshooting, make sure to restore the original configuration.
How do I configure NSH/ZSH command history to persist across sessions?
See the following Knowledge Article for information on this issue:
Knowledge Article ID: 000022404
Where can I find "how to" information for specific user scenarios?
You can find a list of user contributed tutorial information in the BMC-Contributor-topics topic.
In addition, the taking the reins article on Communities includes additional videos and "how to" information.
Are videos available that help to explain how to accomplish specific user tasks?
See the PDFs-and-videos topic for a list of all videos.
In addition, the taking the reins article on Communities includes additional videos and "how to" information.
What are the directories on the file server used for?
The following table provides information about the directories on the file server and their contents:
| |
---|
| |
| |
| |
| Bldeploy xml file for blpackages |
| BladeLogic-related dashboard report |
| |
| Files that are used for Audit jobs |
| |
| The bldeploy.xml file imported after you log in as a BLAdmin |
| Installers and scripts, such as Notepad ++, deployable msi, and RSCD installer |
| Installers of Application Server, PXE, RSCD, and TrueSight Server Automation console |
| Patch analysis related Jason files and catalog-related files |
| NSH scripts (chef and puppet packager and DB_FS_Cleanup) |
| Windows patch data in the zip format |
| Empty (used for storing temporary files) |
How do I make sure my catalog does not get any new patches?
If the catalog is in Online mode, updating the catalog obtains any new patches or modifies existing patches that have changed. To prevent new patches from being downloaded, do not run the Catalog Update Job until you need new patches in the catalog.
If the catalog is in Offline mode, then to prevent new patches from being downloaded, you must ensure:
- The source location has not been updated by re-running the downloader
- The metadata file(s), if applicable, in the depot have not been changed since the last run
If you ensure the preceding items, running a Catalog Update Job does not add any new patch metadata or modify existing patch metadata.
How do I make sure that my patching job remediates servers on execution?
While creating the Patching Job, from the Deploy Job options menu within the Remediation Options panel, select the Execute job now option. The same options are available while creating a remediation job from the Analysis results.
How do I make sure that I run analysis every x hours?
You can specify a schedule for any Job to ensure that it is executed every x hours.
How do I ensure that my catalog contains only attributes that meet "my" criteria?
You must create a custom property on an appropriate depot object. For example, to set certain criteria on a Windows Hotfix object, by selecting Property Dictionary View > Built-in Property Classes > Hotfix, you can add a new property. You can then create a new smart group using an appropriate condition to include this new property.
How do I know which filters are missing from my Windows catalog to cover all products installed on all my targets that have been added to my patching job?
The job log of the Patching Job displays a warning message that indicates the filters that must be added so that all products on all targets that are part of the Patching Job are analyzed in the next run of the Patching Job. A sample warning message is shown below.
WarningSep 8, 2010 6:15:54 PMPatches belonging to following filters were found missing during analysis:
Skype, English
Adobe, English
Windows Media Player, English
Microsoft Office, English
Microsoft Office 2007, English
SQL Server 2005, English
Flash, English
Microsoft Office 2003, English
.Net Framework, English
Microsoft Windows XP, English
Please update your catalog with these filters to avoid any vulnerabilities
How do I get more details about the Deploy Job that was executed when I installed patches on my targets?
You can use the drop-down list in the Deploy Job options settings to get the desired information about the execution of that Deploy Job. For example, if you select the All Information option within Logging level, subsequent execution of the Deploy Job provides you with all information about the Deploy Job execution.
What are the minimum permissions required for a patching job?
How can I test the REST APIs?
You can use any of the following utilities:
BMC does not advocate the use of any specific utility.
Every API except POST:/v1/sessions requires the following header to be set:
| |
---|
| This header is deprecated. Use the Authorization Header instead that includes the session ID that is returned by the POST:/v1/sessions API. |
| |
| <valid_TrueSight Server Automation_role_name> for switch role functionality, |
After the session ID is acquired, you can use it for other APIs.
Example: (with curl)
Create a session (login).
curl -X POST "https://clm-pun-t188mh:9843/bsa-rest/v1/sessions" -H "accept: application/json"
-H "Content-Type: application/json" -d "{ \"user_name\": \"BLAdmin\", \"password\": \"XXXXXX\",
\"role_name\": \"BLAdmins\", \"authentication_type\": \"SRP\"}"
Response :
{ "session_id": "56df274d-2aeb-4229-b603-ae29e31b1e3f.eNoLDgoAAAHwAPY=",
"roles": [ "BLAdmins" ],
"expiration_time": "2019-01-11T17:58:48.137+0000",
"default_role": "BLAdmins",
"_links": {
"self": {
"href": "https://clm-pun-t188mh:9843/bsa-rest/v1/sessions"
}
}
}
Use the session ID that is obtained from the previous step for the subsequent API calls.
For example, to get a list of all servers, call the GET:/v1/servers API as follows:
curl -X GET "https://clm-pun-t188mh:9843/bsa-rest/v1/servers" -H "accept: application/json"
-H "Authorization: Bearer 56df274d-2aeb-4229-b603-ae29e31b1e3f.eNoLDgoAAAHwAPY="
How can I change the Swagger role?
After you authorize the Swagger with the session ID, you can change the role and authorize if the user has that role.
How to use RSSO authentication?
- Use the following blasadmin parameters to enable Remedy Single Sign-On authentication:
- IsEnable – To enable or disable the Remedy Single Sign-On authentication. For example, set RemedySsoAuth IsEnabled true
- RemedySsoServerUrl – To set the Remedy Single Sign-On Server URL to serve a REST API request. For example, set RemedySsoAuth RemedySsoServerUrl https://clm-pun-014841:8443/rsso/
- TrustStorePassword – To set the truststore password for Remedy Single Sign-On server certificate validation. For example, set RemedySsoAuth TrustStorePassword password
- TrustStoreType – To set the truststore type use for Remedy Single Sign-On server certificate validation. For example, set RemedySsoAuth TrustStoreType JKS
- TrustStorePathname – To set the keystore path for Remedy Single Sign-On server certificate validation. For example, set RemedySsoAuth TrustStorePathname C:\BSA_Source\test.j
- If you already has a Remedy Single Sign-On token, make sure that the Remedy Single Sign-On authentication is configured in TrueSight Server Automation, and copy the token in the Authorization Header (Bearer <token_ID>) as a part of any REST API call. You can skip login using POST:/sessions API
If you need to generate the Remedy Single Sign-On token, use the following Remedy Single Sign-On REST API URL:
http://<rsso_server_hostname>:8080/rsso/api/v1.0/token
Method:POST
content-type application/json; charset=utf-8
Request body :
{
"username":"testuser",
"password":"password",
"realm":"*"
}
output :
{"rsso_token":"_46fcfeba-c846-4593-918c-2ecf04f6327d"}
Where the log files are located?
The REST API log file location is present on the Application Server. The log file is located at <TSSA_INSTALLATION_DIR>\NSH\br\restapi_<deployment_name>.log
- (Windows) C:\Program Files\BMC Software\BladeLogic\NSH\br\restapi_default.log
- (Linux) cd /opt/bmc/bladelogic/NSH/br/restapi_default.log
How to change the log settings
- Logging configuration file is logback.xml where user can make settings according to his requirements
- You can find this file in the <InstallationPath>BladeLogic\NSH\br\deployments\<config_deployment>\tomcat\webapps\rest\WEB-INF\classes\logback.xml
You can use the logback.xml file to do the following:
1. Change the scan time of the file.
2. Change the rolling file size encoded with <maxFileSize>20MB</maxFileSize> tags.
3. Change the logging level of the loggers to read specific logs as required.
4. Change minimum and maximum file backup size encoded with <minIndex>1</minIndex><maxIndex>5</maxIndex> tags.
- Logs can be read from restapi_<config_deployment>.txt, which is located at <InstallationPath>\BladeLogic\NSH\br\
Logging Levels are ordered as follows: TRACE < DEBUG < INFO < WARN < ERROR.
By default, logging level is set to INFO, which indicates that you can see only the following types of messages: ERROR, WARN, and INFO messages
To see DEBUG and TRACE messages you need to change the level accordingly. For example:-
<!-- Setting loggers -->
<logger name="com.bmc.bladelogic.rest" level="INFO">
<appender-ref ref="DeploymentSiftingAppender" />
</logger>
<logger name="com.bmc.bladelogic.rest.configuration.LoggingFilter" level="INFO"/>
<logger name="com.bmc.bladelogic.rest.controllers" level="INFO" />
<logger name="com.bmc.bladelogic.rest.service" level="INFO" />
<logger name="com.bmc.bladelogic.rest.BSARestInterceptor" level="INFO" />
<logger name="com.bmc.bladelogic.rest.service.RestPatchCatalogService" level="INFO"/>
--<logger name="com.bmc.bladelogic.rest" level="INFO">--> Root level of REST API Logging, changing this will affect all implemented logs under this.
--<logger name="com.bmc.bladelogic.rest.configuration.LoggingFilter" level="INFO"/>----> Logs the Request Url, Request Method, Response Status in INFO and request and response body in DEBUG. Other logging levels are not implemented here.
--<logger name="com.bmc.bladelogic.rest.controllers" level="INFO" />Logs various messages under this with all levels.
--<logger name="com.bmc.bladelogic.rest.service" level="INFO" />Logs various messages under this with all levels.
How to acquire a session?
- Create a post request.
- Populate the request body with a JSON object named session containing a valid user name and password.
POST : /api/v1/sessions (try out)
Request body :
{
"user_name": "BLAdmin",
"password": "XXXXXXXX",
"role_name": "BLAdmins",
"authentication_type": "SRP"
}
- Execute the request and use the session ID from the response.
- Authorize the Swagger.
What error codes are generated?
- 200 (OK)
It indicates that the REST API successfully carried out whatever action the client requested. - 400 (Bad Request)
400 is the generic client-side error status, used when no other 4xx error code is appropriate. Errors can be like malformed request syntax, invalid request message parameters, or deceptive request routing, and so on. - 401 (Unauthorized)
A 401 error response indicates that the client tried to operate on a protected resource without providing the proper authorization. - 403 (Forbidden)
A 403 error response indicates that the client’s request is formed correctly, but the REST API refuses to honor it. For example, the user does not have the necessary permissions for the resource. - 404 (Not Found)
The 404 error status code indicates that the REST API can’t map the client’s URI to a resource but may be available in the future. Subsequent requests by the client are permissible. - 500 (Internal Server Error)
500 is the generic REST API error response.
How do I change the default blpowershell configuration values in blpowershell.cnf file?
Create an NSH Type 1 script with blpowershell command and use the required option as mentioned in To manage PowerShell configurations.
How do I reset the PowerShell configurations to default values?
Create an NSH Type 1 script with blpowershell -resetoption command and execute the script against the server whose PowerShell configuration needs to be reset.
How do I configure the blpowershell.cnf file if the PowerShell is installed in a non-default location (for example, C:\Powershell\bin\pwsh.exe) and is not present in the PATH environment variable?
You must have PS_DIR=C:\Powershell\bin and PS_CMD=pwsh.exe in the blpowershell.cnf file. Create an NSH Type 1 script with blpowershell command and use the required option as mentioned in To manage PowerShell configurations. For example,
blpowershell -setoption "PS_DIR" "C:\Powershell\bin"
blpowershell -setoption "PS_CMD" "pwsh.exe"
I have installed PowerShell in a non-default location (for example, C:\Powershell\bin\pwsh.exe) and is not mentioned in the PATH environment variable. How do I use this PowerShell at runtime?
Additional runtime options are provided to override the configured PowerShell values in blpowershell.cnf. You need to pass the following additional runtime argument when executing the PowerShell script:
-blpsusedir "C:\Powershell\bin"
-blpsusecmd "pwsh.exe"
For more information about overriding options at runtime, see Overriding the PowerShell options at runtime.
PowerShell script returns an error message, but TrueSight Server Automation reports it as Success. Why is this behaviour?
After the PowerShell script is executed, TrueSight Server Automation decides Success/Failure based on the exit code of PowerShell command. You can try executing the same PowerShell script manually on the target server from the command prompt and check the exit status (%errorlevel% or $?). It was observed that the PowerShell version before version 5 returns Success message even if the script execution fails.
How can I determine where TrueSight Server Automation is installed?
On UNIX, look in /etc/lib/rsc/HOME or /usr/lib/rsc/HOME. If that file does not exist, you are running a local or self-contained installation, and will need to derive the installation location from running processes. For example:
Linux:
ls -la /proc/`ps -ef | grep rscw | grep -v grep | awk '{print $2}'` | grep exe | awk '{print $11}'
Solaris:
pargs -l `ps -ef | grep rscd | head -1 | awk '{print $2}'`
Where are the RSCD Agent logs located?
On Windows: INSTALL_DIR\RSCD\rscd.logOn UNIX: INSTALL_DIR/[NSH|RSCD]/log/rscd.log
Where is the transaction or bldeploy log?
<INSTALLDIR>\Transactions\log\bldeploy-xxxx.log
How do I analyze the *Trace.txt* file that is generated by a Windows Patch Analysis Job?
For a list of frequently asked questions for Agent troubleshooting, see Frequently asked questions for agent troubleshooting.
Top Knowledge Articles from BMC Customer Support
BMC Communites maintains a list of the top 10 Knowledge Articles (KAs) as recommended by the Customer Support team for BMC BladeLogic Server Automation.The KAs are selected by a combination of both the collective experience of the team and other quantitative factors, with the goal of sharing the most relevant and useful information in a easy to consume format.See Top 10 Knowledge Articles for BladeLogic Server Automation on BMC Communities for the list.
Walkthrough topics introduce you to a key BMC BladeLogic Server Automation use case (for example, compliance), and provide step by step, cookbook-style examples that demonstrate a specific aspect of that use case.
Click here to see a list of the topics in this space that are walkthroughs.
| |
---|
Getting started with automation | |
| |
| |
| |
| |
| |
| |
| |
| |
The following BMC sites provide information outside of the TrueSight Server Automation documentation that you might find helpful:
What are the steps to use Swagger?
- Open a web browser and create a URL to host Swagger.
https://<APPSERVER_HOST>:<PORT_NUMBER>/rest/swagger-ui.html#
Example: https://localhost:9843/rest/swagger-ui.html# Create a session using the POST session's API.
POST : /api/v1/sessions (try out)
Request body :
{
"user_name": "BLAdmin",
"password": "XXXXXXXX",
"role_name": "BLAdmins",
"authentication_type": "SRP"
}
- Execute the request and use the session ID from the response.
- Authorize Swagger.
For more information, see Trying-out-the-REST-APIs.