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.

The following list shows some common causes for this issue:

• Review the Application Server log and look for a Java stack trace; this usually indicates the issue.
• A few common things can cause problems with the Application Server start up:
  • The File Server RSCD Agent is not licensed (for pre-8.2 versions).
  • ACLs were pushed to the File Server agent.
    • Add a 'System:System  rw,map=<root|Administrator>' to the users.local on the File Server agent.

In this case, you need to synchronize the bladelogic.keystore across all Application Servers.

See To synchronize keystore files of multiple Application Servers for more information.

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

You can find recommendations for sizing Application Servers in Sizing Application Servers.

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.

In addition, the taking the reins article on Communities includes additional videos and "how to" information.

The following table provides information about the file server directories 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.

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

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.

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,

blpowershell -setoption "PS_DIR" "C:\Powershell\bin"

blpowershell -setoption "PS_CMD" "pwsh.exe"

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.

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:

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}'`