Skip navigation

When EUEM components are deployed, they are communicating with each other in different ways. Let’s refer to the basic architecture of a simple deployment of EUEM.




Let’s review each component roles


  • The Cloud Probe is the capture engine. It is capturing TCP/IP packets and is building objects (HTTP( and HTTPS request and response pairs) and extracts whatever data it is configured to. When objects are captured, they are sent to the Real User Collector.


  • The Real User Collector buffers those objects (several Cloud Probes may send data to one collector) for the Analyzer to consume (one or several Analyzers may get data from one Collector).


  • The Real User Analyzer retrieves data from one or more Real User Collectors and performs most of the processing.



All the communications between EUEM components occur on a secure channel using HTTPS. The same goes for managing EUEM by accessing its web interface.


The Collector and the Analyzer have their own built-in SSL certificates. When deployed a self-signed SSL certificate is generated for each component. Given that the authentication between each EUEM components is done via user accounts, there is no two-way SSL authentication as in other TrueSight Operations Management products.


Replacing a SSL certificate on any EUEM component does not impact the entire deployment and without causing any disruption in the way the product works. This means that one can use a signed certificate on an Analyzer and still use the self-signed certificate on the Collector without breaking the flow between the components. This also means that one does not have to change anything on the TrueSight Presentation Server for the Analyzer & TSPS integration or on the App Visibility Portal server when the App Visibility integration is configured.


As long as the configured SSL certificate is a valid and signed one, there is no problem!


The steps below are for the Real User Analyzer but the same procedure applies to the Real User Collector. Since there is no web UI for Cloud Probe, there is no SSL certificate on Cloud Probe to change.


EUEM is a Java application running on a Tomcat server.  Replacing the SSL certificate is very simple. The steps are

  1. Get a signed SSL certificate from a Certificate Authority and the original SSL private Key.
  2. Bundle them in a Java keystore format.
  3. Configure EUEM to use this keystore instead of the default one created at installation time.


Important notice: It is your responsibility to provide the Java keystore file. BMC is not responsible and will not provide help in generating it.


Configuring the Analyzer to use your keystore file

  1. Copy your keystore file to the Real User Analyzer server.
  2. Make a copy of the following file as a backup.
    1. $EUEM_HOME/analyzer/apache-tomcat/conf/server.xml
  3. Edit the server.xml file
  4. Look for the following lines. The first line is a pointer to the full pathname of your keystore file. The second line specifies the password (*) to that keystore.
    1. keystoreFile="${truesight.home}/conf/platform/security/keystore/java/keystore"
    2. keystorePass="tsPwDSt0r3"
  5. Restart the Real User Analyzer at your convenience to have the changes take effect.


If you have the Real User Collector deployed on the same system you have to repeat the steps as its SSL certificate configuration is separate.



(*) About storing the keystore password in clear text in the server.xml file. This is a constraint from the Tomcat design itself. This is best and fully described in the official Apache Tomcat FAQ.


You are probably wondering….what happens to my AppVis data? Where does it go?  Does it get backed up?  How can I recover if I have a system failure?


These are all really good questions.


All of your data from the TEA Agents, .Net Agents and Java Agents are stored on the App Visibility Portal / Collector.  These components are not backed up automatically. You must do this manually and on a regular basis.  This is the only way that you will be able to restore the data if something happens to these components.


It is also important to note that you should backup the App Visibility Portal / Collector if you are doing an upgrade to the Truesight Presentation Server (TSPS).  It does not matter that you are not "touching" the Portal/Collector. The Portal/Collector databases are dependent on the Truesight Presentation Server and if something happens to that component during an upgrade, it will affect your data on the Portal/Collector.


If your Portal and Collector are on different systems, then you will need to make sure that both databases are backed up simultaneously. Otherwise, the data will become out of sync.


Below are links to our documentation that will explain how to backup and restore the different versions of the Portal / Collector.


  1. 10.5:


  1. 10.7


  1. 11.0


One of the greatest challenges users face today is defining what is a problem versus what is normal behavior. Synthetic Metric Rules (SMRs) were introduced in TrueSight Synthetic 10.7. They are used to define how synthetic transactions are monitored. This powerful functionality allows users to create rules that are more granular than ever before. SMRs significantly change the user experience and monitoring capability provided with the synthetic monitoring solution.


As you know, Events break down into Rules (defining what is a problem versus normal behavior) and Conditions (what to do when a particular problem is detected). In TrueSight, it is primarily TSIM that handles Conditions (e.g. integration with Remedy to open tickets when a problem is detected). SMRs fall into the first category (event notification when there is a problem). SMRs are all about how granularly the user can define what is a problem versus what is normal behavior. In TrueSight Synthetic 10.5 and earlier, users had to rely on SLA metrics to define Rules. These SLA metrics are only aggregated over a 5-minute interval. The 5-minute interval is extremely limiting. Say, for example, you have a specific URL Checker script that pings a web page once per minute. Let's say there are 5 executions in a 5-minute interval. If those 5 executions take 1.1, 1.2, 1.1, 1.2, and 5 seconds respectively and you set the threshold to 2 seconds and 20%, the SLA would fire if any one transaction takes more than 2 seconds to complete. With SMRs you have very fine-grained control. You can create a rule that says 2 consecutive transactions must be over 2 seconds which provides a more accurate rule and thus fewer false-positive alerts resulting in earlier detection of the problem.


With TS Synthetic 10.7 and 11.0 we provide Synthetic Metric Rules and superior data visualization. This includes metric rules for monitoring of metrics of synthetic executions:


  • Synthetic Metric Rules
  • Synthetic Health view
  • Synthetic Health Analysis view
  • Synthetic metric reports view


Below are some screenshots and hyperlinks to the online documentation to give you a sneak peek and guide you through the world of SMRs:


1) On the Synthetic Metric Rules page you can define and manage these rules and the criteria for generating events and issue notifications.


Managing Synthetic Metric Rules



2) Synthetic Health view


Investigating application issues reported by synthetic health events - BMC TrueSight App Visibility Manager 11.0



3) Synthetic Health Analysis view


Analyzing Synthetic Health Details



4) Synthetic Health Reports


Viewing Synthetic Health Reports


This video will show you how to create a custom table view in TrueSight Presentation Server 10.7 to determine where your synthetic events came from at a quick glance.



SLA Thresholds

To ensure that you meet your obligations for user satisfaction, you can set up thresholds and notifications to alert you about performance and availability events.


The following short video shows you how to configure SLA thresholds for automatically discovered applications or an application with end-user monitoring.

Don't rely on density to learn about performance problems.

Want to learn more?

Want to watch more?

You can find more how-to videos on YouTube in the TrueSight Operations Management | How-To Videos playlist.

Please comment to let us know what else you would like to know about SLA thresholds.


Are you searching Google and BMC Communities for a solution, but could not find one?


Are you searching the BMC Support Knowledge Base and getting too many results for products you are not using?


Are you spending time having to unselect/select various products in the list?


Would you like to search the BMC Support Knowledge Base and only see results for just the TrueSight App Visibility Manager, BMC Real End User Experience Monitoring (Virtual and Software), Synthetic, PATROL for Application Management, or TMART products?


If the answer to any of the above is YES then you need to use a pre-filtered URL to just search for that particular product.  Also these pre-filtered URLs will contain additional KAs/solutions that are not available on Google and BMC Communities.  See the following steps to use these pre-filtered URLs to find solution to the problem or question:


Step 1) In a web browser, log into the BMC Support Central web site (Support Central - BMC Software)


Note: You must log into the BMC Support Central web site prior to using the pre-filtered URLs.


Step 2) Select one of the desired pre-filtered URLs in the table below and enter it into the same web browser in Step 1


BMC Products
Pre-filtered URLS

TrueSight App Visibility Manager Server


BMC Application Diagnostics


TrueSight App Visibility Agent


BMC TrueSight App Visibility Agent


BMC Application Management Suite

BMC Real End User Experience Monitoring and Analytics



BMC Real End User Experience Monitoring



BMC Real End User Experience Monitoring - Virtual Edition
BMC Real End User Experience Monitoring - Software Edition
Borland Silk Performer Synthetic Transaction Monitoring
Borland Silk Test for TrueSight Synthetic Monitor

PATROL for Application Management



BMC PATROL for Application Management


Step 3) Enter the desired text into the search field to find KAs/solutions


When the App Visibility Agent for .NET is running then there should be two .dll files attached to the IIS worker process (w3wp.exe) within IIS.  To verify that these .dll files are bounded to the IIS worker process, perform the following steps:


Step 1) Download the Process Explorer utility at the following location:


and copy it to the server with the App Visibility Agent for .NET.


Step 2) Start the Process Explorer and click View -> Show Lower Pane


Step 3) Click View -> Lower Pane Window -> DLLs


Step 4) Look for the IIS worker process name called w3wp.exe and see if it is running.



An Internet Information Services (IIS) worker process is a windows process (w3wp.exe) which runs Web applications, and is responsible for handling requests sent to a Web Server for a specific application pool.  See for more information.  This w3wp.exe process only appears in Task Manager if any of the web sites is being accessed by web browsers. It is not a service at all.  So you can start w3wp.exe by going to the IIS home page like http://<IIS_hostname_here>.


Step 5) If w3wp.exe is present then click w3wp.exe and see if the following two .dll files in the lower pane that belongs to "BMC Software, Inc." are present:





See screen shot below:




If either one of these .dll files are not present then stop the App Visibility Agent for .NET and IIS (or stop the application pool or pools instead of IIS).  Then start the App Visibility Agent for .NET first and then start IIS (or start the application pool or pools).  Perform the above steps again to verify if the two .dll files are present.


If the ClrProfInstrumProbe.dll file is only missing then the App Visibility Agents for .NET will not able to find/map web applications on IIS.  We need to confirm if the worker process (w3wp.exe) has the correct value for the COR_PROFILER environment variable.  Below are the steps to check the COR_PROFILER environment variable:


Step 1) On the server with the App Visibility Agent for .NET, start the Process Explorer utility


Step 2) Look for the worker process (w3wp.exe)


Step 3) Right click on the w3wp.exe process and select Properties


Step 4) Click on the Environment tab and look for the following two environment variables:





The value for COR_ENABLE_PROFILING should be 1.

The value for COR_PROFILER should be {FF51CB90-1C9F-4b50-BA41-D48BDE9823B0}.


If the value for the COR_PROFILER environment variable is not {FF51CB90-1C9F-4b50-BA41-D48BDE9823B0} then it means that another APM monitoring program is interfering with the App Visibility Agent for .NET and that other product needs to be uninstalled.


If you were using the Application Management KM with older versions of TrueSight Synthetic Monitor, and you have upgraded to TrueSight Synthetic Monitor 10.7, then you will want to start using the new Synthetic Metric Rules. Below is a link to our documentation that explains how to move from Monitoring Policies to Synthetic Metric Rules:


And below here is a video that will demonstrate how to do the conversion:


TrueSight Operations Management 10.7 was released on March 28, 2017. This means App Visibility Manager product upgrades are now available.  Please refer to for all the details on upgrading your App Visibility Manager products.


For customers running older versions of our software, namely BMC Transaction Management Application Response Time (TMART) and BMC Real End User Experience Monitoring 2.7.02 we have AMIGO programs to assist you with the migration to 10.7.00.


The Assisted MIGration Offering (AMIGO) programs are designed to assist you with the migration from an older version of a product to a newer version when there are major changes that will affect your migration. They are provided to all customers as part of your support coverage.


Are you postponing a migration from BMC Transaction Management Application Response Time (TMART) to Borland Silk Performer for TrueSight Operations Management 17.5.00 (TS-Synthetic) because of time, learning curve concerns or risk issues?  The TS-Synthetic Assisted MIGration Operations (AMIGO) program is designed specifically to help you migrate quickly, easily and safely. Please follow the link below to our knowledge article to get started:


There is a major architecture change when you migrate from BMC Real End User Experience Monitoring - Virtual Edition 2.7.02 to BMC Real End User Experience Monitoring - Software Edition 10.7.00. Don't get caught off guard by the changes and be prepared with the BMC Real End User Experience Monitoring Software Edition AMIGO program. Please follow the link below to our knowledge article to get started:


Please contact BMC Technical Support ( if you need any more information on this.


NOTE:  This is post contains a sample script.  BMC Support cannot assist in coding or debugging custom scripts


Project Attributes allows a user to edit parameters through an Execution Plan without editing the Silk Performer script directly.


A good case for this scenario would be a script that uses a username and password on a system where the password changes every few months.  If you have your script configured to use Project Attributes, then you can change the password via the Execution Plan instead of modifying the script.


Below is a step by step example of how we can do this:


1.  Open Silk Performer

2.  Choose Project - Project Attributes

3.  In the name field give the attribute a name (e.g password)

4.  In the Type field choose 'password' from the drop-down list.

5.  In the Value field enter a password you wish to use in your script.

Project Attributes.png

6.  You can now add code to your script that will pick up this attribute.  Below is some sample code:



    TINIT            : begin;

    UserPassTest             : 1;



  sUser   : string;

  sPass   : string;


// Transactions Section



  transaction TINIT


    AttributeGetString("ProjectAttributeUsername", sUser_variable);

    AttributeGetString("ProjectAttributePassword", sPass_variable);

  end TINIT;


  transaction UserPassTest







  end UserPassTest;


You can then use the variable "sPass_variable" anywhere that it is required in your script. Remember that if you use "sPass_variable" in a form (in the dclform section of the script) then it must be a global variable.


NOTE: Project attributes are case sensitive


After you have imported your script into TSPS, you can edit the Execution Plan and see your new editable settings.  If you followed the example above, then you should see something similar to the screen shot below:

Execution Plan.png

When the Execution Plan is deployed out to the TEA Agent, it will be passed the parameters from the above fields.  If you want to change the username or password that the Execution Plan is using, then you simply need to come back to the Execution Plan settings and change these values.


Trending in Support: TrueSight Silk Performer and TM ART, need to re-init Browser-Driven monitors.


I have had a few cases lately involving Web browser-driven (AJAX) monitors. The monitors run fine in Silk Performer but after several runs in TrueSight under a TEAAgent the monitor has problems. There are a few manifestations:


- growing memory usage of the TEAAgent or perfBrowserHost_x86.exe as though there is a memory leak.


- growing thread usage of the TEAAgent or perfBrowserHost_x86.ex as though there is a thread leak.


- growing number of HTTP connections to the web application being monitored.


- the TEAAgent crashes


- the TEAAgent quits responding


- the TEAAgent quits feeding results to TrueSight


- the monitor or the TEAagent reports time outs


- the monitor reports BrowserEngine: 29 - UI element not found


- the monitor reports other BrowserEngine: 29 errors


The gist of the problem is that the browser doing the monitoring needs to re-initialize in order to free up resources from previous runs.  A resolution is given in this article:


The most common resolution that I have seen is to put a BrowserStop in the script where it will execute right before the monitor ends. Of course, if your script has "if" statements or loops or such it may be difficult to find the best place to put the BrowserStop in order to make sure it executes with every run of the monitor. But I do see a lot of browser-driven monitor scripts that contain no "if" statements or loop and so placing the BrowserStop at the end of the script works fine.


Another option would be to try a different type of monitor.  Silk Performer 15.0 introduced a new type of monitor called Web (Async). 




Since it handles some asynchronous web traffic it may work for some web applications that you thought needed a Web browser-driven (AJAX) monitor. Here is a video introducing this type of monitor:


Since this type of monitor was introduced in Silk Performer 15 it is, of course, not available to TM ART.


EUEM makes extensive use of filters. These are used in the following manners to name a few:


1) To include or exclude subsets of your traffic data with regards to what gets processed by EUEM

2) To control what gets included into the data for specific Watchpoints

3) To control where to apply rules.


While one could write filters completely from scratch, the Filter Expression Builder makes the work far easier by allowing you to make selections from dropdown boxes to unlock the full power of the filter expressions. Filters can be quite generic, using a single condition or very specific relying on a series of conditions to be met. With regards to Watchpoints, a complex, multi-condition filter can be handled either by a single complex filter or by several independent filters where one can control whether all or any of the filters must be met for traffic data in question to be included or the rule in question to be acted upon.


Single filter rule:


Multiple filter rules:


Next, we can focus on how breaking up a URI into its components allows us to capture multiple matches by leveraging the various string operators and how to use them most efficiently. For matters of simplicity, we are going to focus on strings and the parts of the URI.


A URI such as: can be broken down as follows:


URI Host = (This is the name of the application in question)


URI Stem = /wonder/access_form.aspx (This is the name and path to the specific resource in question)


Query Parameters = ?q1=test&q2=blue (Query parameters are a way to pass information in the URI call that may affect the details of the resource that is returned)


By focusing on say just the URI Host, we can grab all of the traffic related to the application in question. If we instead focus only on the URI stem, we can grab data related to a specific resource that may exist on multiple applications that we might be monitoring.


Because the paths to the location might not be the same from application to application, that's where the string operators come in. We'll start with the simplest of these operators:


  • Is equal to (=) This means that the part in question in the traffic must exactly match what is in the filter
  • Starts With This means that the part in question in the traffic must start with the same characters defined in the filter
  • Ends With This means that the part in question in the traffic must end with the same characters defined in the filter
  • Contains This means that the part in question in the traffic must contain the string defined in the filter
  • Is in comma-seperated list means that the string in the traffic must match one of the strings in the comma-separated list defined in the filter.


For example if one application has the access_form.aspx resource here in one application: /wonder/access_form.aspx and here in another application: /glue/membership/access_form.aspx we could capture this same resource in both applications using (url.stem_string endswith "access_form.aspx" ignorecase).


In the same way, if we wanted to focus only on the web servers for our multiple applications, we could use something like ( startswith "www").


The operator that requires the least amount of resources is the Is equal to operator because the comparison is very straightforward. The string for the part in question either is or is not what is defined in the filter. For operators like Contains, EUEM must search through the part in question.


Sometimes we might want to match more than one condition, hence the Grouping & Chaining Operators: AND, OR & NOT


AND is used when multiple conditions must exist simultaneously in the traffic. OR is for when at least one of the conditions in question must be true. For example, a single request can only be addressed to a single URI Host, so if we are looking for traffic to either Application A, B or C, this is where the OR operator is used. NOT is used to exclude traffic where the string in question is seen.


When creating a complex filter expression with more than one condition, we can choose to add the new conditions to the expression using: AND, OR, AND NOT, OR NOT.


Lastly, we can create filter expressions where say the URI Host must be one of three choices while at the same time, the URI Stem must match a specific string condition. In order to make this happen, the conditions and arguments must be grouped. For this example, the filter expression might look like this:


(( is "")  OR  ( is "")  OR  ( is ""))  AND  (url.stem_string endswith "qualities.html" ignorecase)


The additional brackets make it clear where the choice is and where the conditions (or groups of conditions) must both be true.


Creating efficient filters means reducing repetition and fully leveraging the string operators in question. By creating efficient filters, we free up resources to handle more traffic volume.


Please feel free to rate this blog or leave us any questions or comments as we are always looking to improve our documentation.


To see more blogs like this, see:

TrueSight App Visibility Manager


In this blog, we will cover how to ensure that DNS Is properly configured for End User Experience Management (EUEM) so that calls to external services can be correctly routed.


Workstations and other client devices get their DNS server and IP settings automatically through DHCP when joined to a network, but servers which are accessed by many devices need to have fixed addresses, and hence, static IP configuration.  Because these networking settings are entered manually, there is no call made out to get these parameters from DHCP. As such, the IP addresses for services such as DNS and NTP must also be entered manually.


On Linux systems, the DNS servers that the system uses for name resolution are defined in the /etc/resolv.conf file. Each nameserver line in the resolv.conf file defines a DNS server.  The entries are prioritized by the order they are found in the file, so the primary DNS server would be the first line, the secondary would be the second, tertiary third and so on. At the bottom of the file, we have a search line which is used to complete fully qualified domain names if only the host name is given. For example, if I have “search” and I pinged “docs” , the system would assume that I am referring to “”.


For example:


nameserver <IP_of_primary_DNS_server>

nameserver <IP_of_secondary_DNS_server>

nameserver <IP_of_tertiary_DNS_server>




Lastly, the DNS servers defined by the resolv.conf file must be identified by IP and not name for the simple fact the system won’t know how to handle domain names until after it knows how to reach the DNS servers.


Please feel free to rate this blog or leave us any questions or comments as we are always looking to improve our documentation.


To see more blogs like this, see:

TrueSight App Visibility Manager 


You can use the SLA to change the status of your applications in the TSPS console and you can also use the AM KM with TrueSight Infrastructure Management (TSIM) to alert if an event threshold is breached n times in a series.


The SLA is used in TSPS to update the application status.  However, the SLA can only see the most recent 5 minute results window and cannot see anything that happened in the history of the application.  So if there is a failed result in the 5 minute period that could cause the SLA to trigger an event, then it will set application status to the appropriate value.


You may also have your AM KM set to trigger an event if an event threshold is breached n times in a series.  In this scenario, if an event is triggered, it will occur after n times. 


Please remember that the SLA and AM KM are 2 separate items and report on the data in different manners.


Below are a few use cases to demonstrate how the SLA and AM KM work (Please note that I am only discussing critical notifications in these use cases and not minor):


AM KM is configured to alert if there is a failure 2 times in a row

The Execution Plan runs once every 5 minutes and takes 1 minute to complete

The SLA has the following configuration:

     1.  Latency - 60 seconds

     2.  Accuracy Errors- 35%

     3. Execution Errors - 35%

     4.  Availability Errors - 35%


8:00 AM - Execution Plan starts

8:01 AM - Execution Plan stops with 1 Accuracy error

8:01 AM - AM KM sees 1 error.  No events are raised

8:05 AM - TSPS Console receives the results.  The SLA evaluates the results and sees 1 Accuracy error.  This means there is 100% failure.  This is higher than the 35%.  The Application status is set to red.


8:05 AM - Execution Plan starts

8:06 AM - Execution Plan stops with 1 Accuracy error

8:06 AM - AM KM sees 1 error.  This is the second error in a row, so an event is raised and a notification is sent out as defined in the AM KM policy.

8:10 AM - TSPS Console receives the results.  The SLA evaluates the results and sees 1 Accuracy error.  This means there is 100% failure.  This is higher than the 35%.  The Application status is set to red.


As you can see in the above scenario, the Application status was changed to critical during the first run of the Execution Plan, but the user was not alerted by the AM KM until the 2nd run of the Execution Plan.


Let’s look at a second use case where a user receives a notification from the AM KM, but the application status remains green:


AM KM is configured to alert if there is a failure 2 times in a row

The Execution Plan runs every  minute and takes 30 seconds to complete

The SLA has the following configuration:

     1.  Latency - 45 seconds

     2.  Accuracy Errors- 75%

     3. Execution Errors - 75 %

     4.  Availability Errors - 75%


8:00:00 AM - Execution Plan starts

8:00:30 AM - Execution Plan stops with 1 Accuracy error

8:00:30 AM - AM KM see's 1 error.  No events are raised


8:01:00 AM - Execution Plan starts

8:01:30 AM - Execution Plan runs with 1 Accuracy error

8:01:30 AM - AM KM see's 1 error.  This is the second error in a row, so an event is raised and a notification is sent out as defined in the AM KM policy.


8:02:00 AM - Execution Plan starts

8:02:30 AM - Execution Plan succeeds

8:02:30 AM - AM KM see's 0 errors.  No events are raised


8:03:00 AM - Execution Plan starts

8:03:30 AM - Execution Plan succeeds

8:03:30 AM - AM KM see's 0 errors.  No events are raised


8:04:00 AM - Execution Plan starts

8:04:30 AM - Execution Plan succeeds

8:04:30 AM - AM KM see's 0 errors.  No events are raised


8:05 AM - TSPS Console receives the results.  The SLA evaluates the results and sees 2  Accuracy errors.  This means there is 40% failure.  This is lower  than the defined 75%.  The Application status remains green.


As you can see in the above scenario, the Application status was never changed because the combined results from the 5 minute results bucket did not meet the criteria for the SLA.  However, we did see 2 event threshold failures in a row, which means that the user was sent a notification from TSIM.


I hope this post helps understand how this situation happens and how to investigate.  See more blogs at TrueSight Support Blogs


Lisa Jahrsdoerfer



Hello to the TrueSight APM Community TMART & AppSight


This is Kristin Baskett, Solutions Marketing Manager for TrueSight Operations Management. We’ve been very busy aligning our APM offerings over the last year to the new TrueSight brand. All of our APM solutions (except for the synthetic offering) are now branded as TrueSight App Visibility Manager. As of last April, APM is now seamlessly integrated into the overall TrueSight Operations Management portfolio. This much anticipated streamlining of APM offerings from a product perspective is driving a need to restructure the taxonomy of our APM communities.


Here are the changes you can expect to see in the coming weeks:


  • We will be retiring the AppSight Community and the TMART community as we are no longer actively selling these products. Don’t worry – these communities will be moved to More Communities. All of the permissions will remain the same. You’ll still be able to search content, post new content and interact with existing resources and all bookmarked topics.
  • We will be combining the App Diagnostics and End User Experience Management communities. This move is reflective of our product-level changes and will encourage more interaction in the community. Additionally, it will allow the BMC champions to better manage all the great Ideas suggested by our users.


This is the first step in a larger initiative to simplify interaction for our TrueSight friends in the BMC Communities. More improvements to the communities are coming soon.


We are looking forward to this journey with you.


Best Regards,


Kristin Baskett

Filter Blog

By date:
By tag: