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.

You can find information about the supported platform for TrueSight Server Automation on BMC Support Central, under Product Availability and Compatibility.

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

See the ports and protocols list.

You can find the build number for the various releases (base version, SPs, and patches) in Preparing-for-a-Windows-upgrade-using-the-unified-product-installer or Preparing-for-a-Linux-or-UNIX-upgrade-using-the-unified-product-installer.

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.

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.

You can find information about the supported upgrade paths for TrueSight Server Automation in the Upgrading-using-individual-component-installers section of the online technical documentation (in the Preparing-for-a-Windows-upgrade-using-the-unified-product-installer or Preparing-for-a-Linux-or-UNIX-upgrade-using-the-unified-product-installer topics).

You can find deployment architecture recommendations in the following Planning section: Deployment-use-cases

See Upgrading-custom-configuration-objects.

%temp% directory

• https://msdn.microsoft.com/en-us/library/windows/desktop/aa376931(v=vs.85).aspx
• https://johnkoerner.com/install/windows-installer-error-codes/

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

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.

No. There won’t be any issue in communication between 2 components which are using different versions of redistributable. 

Use the following process:

1. 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.
2. Remove the "nouser" line from the users file.
3. 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.

See the following Knowledge Article for information on this issue:
Knowledge Article ID: 000022404

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.

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.

The following table provides information about the directories on the file server and their contents:

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.

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.

You can specify a schedule for any Job to ensure that it is executed every x hours.

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.

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.

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.

See Minimum-permissions-for-patching.

You can use any of the following utilities:

• Swagger
• postman
• curl

BMC does not advocate the use of any specific utility.

Every API except POST:/v1/sessions requires the following header to be set:

After the session ID is acquired, you can use it for other APIs.

Example: (with curl)

1. 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"
                      }
               }
   }

2. 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="

After you authorize the Swagger with the session ID, you can change the role and authorize if the user has that role.

• 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"}

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

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

1. Create a post request.
2. Populate the request body with a JSON object named session containing a valid user name and password.

3. POST : /api/v1/sessions (try out)
   Request body : 

   {
   "user_name": "BLAdmin",
   "password": "XXXXXXXX",
   "role_name": "BLAdmins",
   "authentication_type": "SRP"
   }
4. Execute the request and use the session ID from the response.
5. Authorize the Swagger.

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

Create an NSH Type 1 script with blpowershell command and use the required option as mentioned in To manage PowerShell configurations.

Create an NSH Type 1 script with blpowershell -resetoption command and execute the script against the server whose PowerShell configuration needs to be reset.

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,

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:

For more information about overriding options at runtime, see Overriding the PowerShell options at runtime.

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.

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:

On Windows: INSTALL_DIR\RSCD\rscd.logOn UNIX: INSTALL_DIR/[NSH|RSCD]/log/rscd.log

<INSTALLDIR>\Transactions\log\bldeploy-xxxx.log

For detailed instructions on analyzing the Trace.txt file, see How to analyze Trace.txt generated by a Windows Patch Analysis Job (user contribution).

1. 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#

2. 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"
   }
3. Execute the request and use the session ID from the response.
4. Authorize Swagger.

For more information, see Trying-out-the-REST-APIs.