If you ever generated an ITM Agent Builder based agent that didn’t contain any Availability filters, your agent probably ended up with a TEPs node called Performance Object Status.

The Performance Object Status attribute group provides a dashboard view of the status of all the attribute group collections occurring in a Agent Builder / Agent Factory based agents. While this information is great, it’s not always preferable to have that information so prominently displayed in the TEP navigator as a distinct node.

To remove the Performance Object Status navigator node from your agent, add the following element to your itm_toolkit_agent.xml file before you generate your agent:

<perf_status_obj_nav_item enable=”false” />

This entry should be immediately above and at same level in the XML as the attribute_group_list element.

If you’ve added the above text to your agent xml and generated your agent, the Performance Object Status node should now be suppressed. Note: Even though you’ve suppressed the navigator node, the Performance_Object_Status attribute group and all of it’s data is still available to create workspaces / views with.

A common question in regards to ITM Agents is how to perform a silent install. In this blog, I will perform a silent, local installation of the Blue Medora ITM Agent for Remote SSL Certificates. This installation will mirror a silent installation for any ITM Agent Builder – Agent installation, version 6.2.2 and above.

– Mike Major

Options File

The first thing you must do to install an agent silently is create an options file. This is just a file that tells the installer what options to perform the install with. In other words, it contains the information you would be entering into the installer during a GUI install.

A sample options file is included in the installation media, named silent.txt. I highly recommend making your own copy of the file, especially if you would like to install the agent on a large number of machines.

Enter all the information that applies to your installation into the options file. A brief description of each field and the data we entered for our example follows:

Installation

Now all we need to do is run the correct setup program with the options file we just made. In our case, we are installing a local solution of the agent to a Red Hat 4 machine. In this case, we will use setupLinux.bin. The options are entered like this:

./setupLinux.bin -options {optionsFile} -silent

Where {optionsFile} is the path of the options file we just created. For more information on the installation of Agent Builder Agents, please visit the Agent Builder’s User Guide.

We will continue our tour of the Blue Medora ITM Agent for Ping Probe with a walkthrough of the agent in the TEP. In this post, we will consider a number of enterprise scenarios and use the agent to solve them. It is my hope that the information given here will help you to quickly begin taking advantage of the agent’s features in your ITM environment.

– Mike Major

General Overview

Consider this scenario: The network administrator arrives at the office on Monday morning. The first thing they would like to do is check the overall status of the network and troubleshoot any problem areas.

For this scenario, we have set up 2 instances of Ping Probe. One instance represents our on site servers, and the other represents off site servers. To see a complete network overview, we click on “Ping Probe” in the navigator window.

You can quickly get an idea of the overall health of the network with the graphs located on the right side. More detailed results can be found down below. But what if you are only interested in the off site hosts that are down (not slow)? It would be a pain to scan through that list. Under the “OffSite” instance, click “Ping Probe Results”:

The default view shows us the overall health of all off site hosts, with a detailed list of slow or unreachable hosts at the bottom. To see only the unreachable hosts, right click on “Ping Probe Results” and choose Workspace->Down. We now have a list off all unreachable off site hosts:

Ping Probe also comes with default views for showing ony the slow hosts, healthy hosts or showing all hosts in the instance.

Critical Servers

Let’s try another scenario: Your network has many small servers that are expected to go down often throughout the day for whatever reason. However, there are also a number of critical servers. You would like the Ping Probe agent to notify you when one of the critical servers is down, but you do not want to be flooded with messages for the other servers.

This problem could be solved in multiple ways. First, you could set up separate instances for critical servers. In our example, we would end up with 4 instances: CriticalOnSite, OtherOnSite, CriticalOffSite and OtherOffSite. Then, change the autostart for the KXF_DOWN_RESPONSE situation in the instances you would like to be notified on. However, you might only have a handful of critical servers, so you may not need separate instances.

In this example, I will instead show you how to modify the situation to only fire if specific servers go down. First, right click on the instance you would like to apply the situation to and click “Manage Situations”:

This will bring up a list of the currently defined situations. We want to edit the KXF_DOWN_RESPONSE situation, so we right click that and click “Edit Situation…”:

This is the situation editor. Right now, we can see that this situation would fire off whenever a host comes back unreachable. We want to add another condition, so click the “Add conditions…” button:

For this condition, we want to check the host attribute for some specific values. So choose “Attribute Comparison” and select the “Host” attribute item. Click OK:

The new attribute condition was added to our situation editor. Now we just type in the critical hostnames and click Apply:

Back in the “Manage Situation” dialog, right click the KXF_DOWN_RESPONSE situation and click Start Situation:

We are now notified when a critical server is down!

What if you have a number of off site servers located in an unstable network area? You may expect the servers to be unreachable from time to time, but that may not mean the servers themselves are down. Having a situation fire off every time they are unreachable might be overkill. Ping Probe can solve this problem as well. Navigate back to the situation editor for the KXF_DOWN_RESPONSE situation and click the Advanced button:

Now, change the “Consecutive true samples” to 5. This means the server will have to be unreachable for 5 consecutive Ping Probe samples before the situation will fire.

This should be sufficient enough to confidently say that the server is truly unreachable.

Well, that’s it for now. I hope these scenarios have given you a good idea of the power behind the Blue Medora ITM Agent for Ping Probe. As always, if you have any questions regarding this post, the Ping Probe Agent or anything else related to Blue Medora ITM Agents, feel free to drop me a line directly at: mike.major@bluemedora.com

Hello again. Now that we have mastered the use of the Blue Medora Agent for Remote SSL Certificates, let’s take a look at installing and configuring the Blue Medora Agent for Ping Probe. The installation will look very similar to that of the Remote SSL agent. So if you have already followed me through the previous blogs, this should be a breeze.

– Mike Major

Agent Installation

• Verify Application Support has been loaded into all the TEMs, TEPS, and TEPD components in your environment that the Ping Probe monitoring data will flow through.
• A previously installed IBM ITM agent is required. In our example, ITM Windows Operating System agent v6.2 FP1+ is pre-installed to C:\IBM\ITM.
• Ensure an IBM JRE 1.5 is installed on the system, a JAVA_HOME is set for that JRE, and that the JRE’s bin directory has been added to the PATH.

From the installation media, select the appropriate installer. Since we will be installing on a Windows platform (Windows Server 2003 in our case), run the setupwin32.exe executable.

Note: Installation on a Linux machine is essentially the exact same. Just make sure to double check your install paths.

The first screen appears to tell you that you are about to install the Blue Medora Agent for Ping Probe. Click Next:

Accept the License Agreement and click Next:

Enter the location of your existing Agent installation (CANDLEHOME) and click Next:

Select “Perform a local install of the solution on this machine” and click Next.

Note: This screen is a bit confusing in that it indicates that it is going to add application support. When installing on a non TEMS/TEPS/TEPD server, the “Perform a local install of the solution on this machine” equates to “Install just the monitoring agent”.

Select “Ping Probe” and click Next:

This screen summarizes the actions that will be taken by the installer. Click Next:

If all went well, you will get a successful installation message. Click Finish.

Installation is complete. To confirm that the base Ping Probe Agent has been installed on the system click the Manage Tivoli Monitoring Services icon. It may be on your desktop or you may need to navigate to Start –> All Programs –> IBM Tivoli Monitoring folder to find it.

If installation was successful, you will see a Monitoring Agent for Ping Probe Template as one of the items listed under Service/Application.

Alternate Installation Method: TEP based Remote Deploy

If you’ve previously added the Ping Probe agent to a TEMS Depot, you can remotely install the agent instead of performing a local installation. To perform a remote installation, navigate to the server node you want to deploy the Agent to (in our case server tw3g10 ), right-click the node and select “Add Managed System”:

Select the Agent you want to remote deploy. We want to deploy the Ping Probe agent so select “Monitoring Agent for Ping Probe” and click OK:

Now, you will be shown the same ITM configuration screen as in the next section. The only difference here is that you need to specify the instance name.

Agent ITM Configuration: Windows

Next we are going to create an agent instance. Double click on “Monitoring Agent for Ping Probe” and you will be prompted to enter a unique instance name. This should be a descriptive name that helps you identify the agent instance when viewed in the TEP and elsewhere. Enter your instance name and click OK:

Note: The Blue Medora Agent for Ping Probe is a multi-instance agent. Many administrators may find it helpful to create separate instances for their on site servers and their off site servers, or any other logical divide.

The following screen is where the Ping Probe basic configuration is entered. Enter the information and click Next.

A brief description of each field and the data we entered for our example follows:

Below is a screenshot of the configuration panel from our example Agent Instance:

The next screen is where you can enter some global timeout values. Enter the information and click OK

A brief description of each field and the data we entered for our example follows:

The next screen asks for an optional host file. This option is very handy when you have a large number of hosts to monitor. We will cover this file in a later section and skip it for now. Click Next:

The next screen is where you enter the hosts you want to monitor. Enter the information for these hosts and click OK

A brief description of each field and the data we entered for our example follows:

You will be returned to the Manage Tivoli Enterprise Monitoring Services screen. To start the Agent instance, right click the agent instance and select Start.

Agent ITM Configuration: Linux

Let’s create an agent instance on Linux. First, you will need to run the itmcmd command that is located in the CANDLEHOME/bin/ directory (in our case /opt/IBM/ITM/bin/):

./itmcmd config -A {product code}

Where {product code} is the product code for the agent (xf for the Blue Medora Agent for Ping Probe).

Now you will be asked to enter a unique instance name. This should be a descriptive name that helps you identify the agent instance when viewed in the TEP and elsewhere. Enter your instance name:

Agent configuration started...
Enter instance name (default is: ): Stark

You will be asked if you’d like to edit the “Monitoring Agent for Ping Probe” settings. Choose “1″ or just hit enter to use the default:

Edit "Monitoring Agent for Ping Probe" settings? [ 1=Yes, 2=No ] (default is: 1): 1

Now you will be asked if you’d like to edit the “Basic Configuration” settings. Choose “1″ for yes and enter the information.

A brief description of each field and the data we entered for our example follows:

Edit 'Basic Configuration' settings? [ 1=Yes, 2=No ] (default is: 1): 1
Logging Level of the agent [ 1=Debug, 2=Info, 3=Warn, 4=Error, 5=Fatal ] (default is: 3): 3
Data collection interval (in minutes) (default is: 1440): 1

We’re asked if we’d like to edit “Optional Global Ping Values” settings. Choose “1″ for yes and enter the information.

A brief description of each field and the data we entered for our example follows:

Edit 'Global Ping Values' settings? [ 1=Yes, 2=No ] (default is: 1): 1
Global ping timeout value (default is: 3000): 3000
Slow response threshold (default is: 1000): 60
Retry Attempts (default is: 2): 2
Maximum Concurrent Pings (default is: 10): 10

We’re asked if we’d like to edit “Optional Ping Probe Host File” settings. Again, we will cover the optional host file below. Choose “2″ for no right now:

Edit 'Optional Ping Probe Host File' settings? [ 1=Yes, 2=No ] (default is: 1): 2

We’re asked if we’d like to edit “Hosts to Ping” settings. Choose “1″ for yes. We can now add, edit or delete hosts we’d like to monitor. Enter all hosts you’d like to monitor.

A brief description of each field and the data we entered for our example follows:

Edit 'Hosts to Ping' settings? [ 1=Yes, 2=No ] (default is: 1): 1
No 'Hosts to Ping' settings available?
Edit 'Hosts to Ping' settings, [1=Add, 2=Edit, 3=Del, 4=Next, 5=Exit] (default is: 4): 1
Hostname (default is: ): www.bluemedora.com
Timeout (default is: ):
Alias (default is: ): Blue Medora Website

'Hosts to Ping' settings: Hostname=www.bluemedora.com
Edit 'Hosts to Ping' settings, [1=Add, 2=Edit, 3=Del, 4=Next, 5=Exit] (default is: 4): 5

When asked if this agent will connect to a TEMS, choose “1″ for yes and enter the hostname for your ITM server. Then enter your network protocol information:

Will this agent connect to a TEMS? [1=YES, 2=NO] (Default is: 1): 1
TEMS Host Name (Default is: tr4g10): tw3g10

Network Protocol [ip, sna, ip.pipe or ip.spipe] (Default is: ip.pipe):

Now choose the next protocol number from one of these:
- ip
- sna
- ip.spipe
- 0 for none
Network Protocol 2 (Default is: 0):
IP.PIPE Port Number (Default is: 1918):
Enter name of KDC_PARTITION (Default is: null):

Configure connection for a secondary TEMS? [1=YES, 2=NO] (Default is: 2):
Enter Optional Primary Network Name or 0 for "none" (Default is: 0):
Agent configuration completed...

Your configuration is now complete! Start the agent instance by using the following command:

./itmcmd agent -o {instance name} start {product code}

Where {instance name} is the instance name you entered and {product code} is the product code for the instance (e.g. xf for the Blue Medora Agent for Ping Probe).

Agent Host File Configuration

To configure an agent using the optional host file, you first need enter the host information into a CSV file. An example file is provided with the agent, so you can simply open that and plug away.

Note: You should rename this file. If you update the agent, the default file will be overwritten if it is not renamed.

A brief description of each field and the data we entered for our example follows:

Below is the file we used in our example:

After completing the host file, simply create a new instance by following the steps in the appropriate section above for your platform. When prompted for the host file, enter the fully qualified path for the file you just created. You do not have to enter any hosts directly into the ITM configuration (but you may do so if you desire).

Conclusion

Congratulations! You’ve successfully installed the Blue Medora Agent for Ping Probe. In the next blog post, we will use the agent to solve real problems that often come up in an enterprise.

If you have any questions regarding this post, the Ping Probe Agent or anything else related to Blue Medora ITM Agents, feel free to drop me a line directly at: mike.major@bluemedora.com

We will continue our tour of the Blue Medora Agent for Remote SSL Certificates with a walkthrough of the agent in the TEP. In this post, we will consider a number of enterprise scenarios and use the agent to solve them. It is my hope that the information given here will help you to quickly begin taking advantage of the agent’s features in your ITM environment.

– Mike Major

Default Workspaces

Okay, let’s start with something easy. Consider this scenario: Your security administrator wishes to generate a weekly reminder list of all X.509 Certificates that will expire in the next 90 days. So, how can we get this information? Luckily, the agent comes with a workspace that will tell us what we need to know. Simply right click on “Certificate Status” and choose Workspace->Nearly Expired Certificates.

We now get a list of all certificates that will expire in the next 90 days, like below:

This would be a great time to take advantage of the agent’s TCR Reporting feature to generate a custom report for the data you have chosen (which we will cover in a later blog post). You can also export the data to a .csv file or .txt file. Just right click in the window and choose “Export…”

A dialogue will pop up asking for the file name and format to create or save to. You can also choose which rows and columns to export.

The resulting file looks like the one below:

This is a view of an exported text file. It is more visually pleasing for this demonstration, but a .csv could be easily imported to other software.

Custom Views

Now for something a little more tricky. Consider this scenario: To determine the budget for the upcoming year, the security administrator requires a report on the expiration date for all the X.509 Certificates in the enterprise. This can be accomplished by creating a custom Workspace View. From the “Certificate Status” Workspace, I will close the “SSL Certificates Results” view to make more room. Now, click the “Table” icon on the toolbar. It looks like this:

Now click anywhere inside the View area that we are changing:

Now, right click inside the View area and choose Properties…

The first thing you might notice is that we are currently viewing a Certificate Status Summary. Under the “Query” tab, click Click here to assign a query:

Now, switch the query to “Remote Certificates” located under “KB4 REMOTE CERTIFICATES.” Then click OK:

Since we are interested in all certificates that will expire this year, we now need to change the filters. Click the “Filters” tab and scroll over until you see “Days until Certificate Expires.” Clicking the box will allow you to edit the current formula. Change the equality to Less than or equal:

Change the value to 365 and click OK. You can also decide which columns you would like to appear in the new view. For this example, I have selected to show the Alias, Host, Port, Days until Certificate Expires and Certificate Expiration Date:

Now let’s take a look at our new View:

Again, this would be a good time to use TCR Reporting or exporting the data to a file.

Situations and Expert Help

Consider this scenario: You are a small company with a new product about to launch. You do not want to lose possible sales due to problems with your X.509 Certificates. You wish to be notified as soon as a problem pops up.

You’re in luck! By default, the agent comes configured to autostart situations for when a certificate is close to expiring or already expired. However, what if you aren’t interesting in viewing certificates that will expire in 90 days (the default value), but 30 days instead?

You can edit the default situations by clicking on the “Situation Editor” on the toolbar. The icon looks like this:

In the situation editor, choose the situation you would like to edit. In our case, we will be editing the “KB4_SSL_Cert_Near_Expiration” situation under “Remote SSL Certificates”. Just change the formula to 30 days instead of 90 and click OK:

To start or stop a situation, right click the instance name and click Manage Situations:

Then, right click the situation and choose the appropriate action. Notice that you can also edit a specific situation from this screen:

You can view any current situations by mousing over the icon on the instance name:

If you need some help in solving the situation, click the link icon next to it to open the expert help panel in the bottom right portion of the TEP:

Well, that’s it for now. I hope these scenarios have given you a good idea of the power behind the Blue Medora Agent for Remote SSL Certificates. As always, if you have any questions regarding this post, the Remote SSL Certificates Agent or anything else related to Blue Medora ITM Agents, feel free to drop me a line directly at: mike.major@bluemedora.com

Welcome back! Now that we have installed the application support for the Blue Medora Agents for Remote SSL Certificates and Ping Probe, let’s see how to install and configure the actual agents on a dedicated machine. Remember, you always have the option of installing these agents on the ITM server if you prefer. Once again, we will cover this in a step by step fashion with plenty of screenshots along the way. We will begin with installing and configuring the Blue Medora Agent for Remote SSL Certificates.

– Mike Major

Agent Installation

• Verify Application Support has been loaded into all the TEMs, TEPS, and TEPD components in your environment that the Remote SSL Certificates monitoring data will flow through.
• A previously installed IBM ITM agent is required. In our example, ITM Windows Operating System agent v6.2 FP1+ is pre-installed to C:\IBM\ITM.
• Ensure an IBM JRE 1.5 is installed on the system, a JAVA_HOME is set for that JRE, and that the JRE’s bin directory has been added to the PATH.

From the installation media, select the appropriate installer. Since we will be installing on a Windows platform (Windows Server 2003 in our case), run the setupwin32.exe executable.

Note: Installation on a Linux machine is essentially the exact same. Just make sure to double check your install paths.

The first screen appears to tell you that you are about to install the Blue Medora Agent for Remote SSL Certificates. Click Next:

Accept the License Agreement and click Next:

Enter the location of your existing Agent installation (CANDLEHOME) and click Next:

Select “Perform a local install of the solution on this machine” and click Next.

Note: This screen is a bit confusing in that it indicates that it is going to add application support. When installing on a non TEMS/TEPS/TEPD server, the “Perform a local install of the solution on this machine” equates to “Install just the monitoring agent”.

Select “Remote SSL Certificates” and click Next:

This screen summarizes the actions that will be taken by the installer. Click Next:

If all went well, you will get a successful installation message. Click Finish.

Installation is complete. To confirm that the base Remote SSL Certificates Agent has been installed on the system click the Manage Tivoli Monitoring Services icon. It may be on your desktop or you may need to navigate to Start –> All Programs –> IBM Tivoli Monitoring folder to find it.

If installation was successful, you will see a Monitoring Agent for Remote SSL Certificates Template as one of the items listed under Service/Application.

Alternate Installation Method: TEP based Remote Deploy

If you’ve previously added the Remote SSL Certificates agent to a TEMS Depot, you can remotely install the agent instead of performing a local installation. To perform a remote installation, navigate to the server node you want to deploy the Agent to (in our case server tw3g10 ), right-click the node and select “Add Managed System”:

Select the Agent you want to remote deploy. We want to deploy the Remote SSL Certificates agent so select “Monitoring Agent for Remote SSL Certificates” and click OK:

Now, you will be shown the same ITM configuration screen as in the previous section. The only difference here is that you need to specify the instance name.

Agent ITM Configuration: Windows

Next we are going to create an agent instance. Double click on “Monitoring Agent for Remote SSL Certificates” and you will be prompted to enter a unique instance name. This should be a descriptive name that helps you identify the agent instance when viewed in the TEP and elsewhere. Enter your instance name and click OK:

Note: The Blue Medora Agent for Remote SSL Certificates is a multi-instance agent. Many administrators may find it helpful to create separate instances for their SSL certificates and their TLS certificates, or any other logical divide.

The following screen is where the Remote SSL Certificates basic configuration is entered. Enter the information and click Next.

A brief description of each field and the data we entered for our example follows:

Below is a screenshot of the configuration panel from our example Agent Instance:

The next screen asks for an optional certificate configuration file. This option is very handy when you have a large number of hosts to monitor. We will cover this file in a later section and skip it for now. Click Next:

The next screen is where you enter the hosts whose certificates you want to monitor. Enter the information for these hosts and click OK

A brief description of each field and the data we entered for our example follows:

You will be returned to the Manage Tivoli Enterprise Monitoring Services screen. To start the Agent instance, right click the agent instance and select Start.

Agent ITM Configuration: Linux

Let’s create an agent instance on Linux. First, you will need to run the itmcmd command that is located in the CANDLEHOME/bin/ directory (in our case /opt/IBM/ITM/bin/):

./itmcmd config -A {product code}

Where {product code} is the product code for the agent (b4 for the Blue Medora Agent for Remote SSL Certificates).

Now you will be asked to enter a unique instance name. This should be a descriptive name that helps you identify the agent instance when viewed in the TEP and elsewhere. Enter your instance name:

Agent configuration started...
Enter instance name (default is: ): Minsc

You will be asked if you’d like to edit the “Monitoring Agent for Remote SSL Certificates” settings. Choose “1″ or just hit enter to use the default:

Edit "Monitoring Agent for Remote SSL Certificates" settings? [ 1=Yes, 2=No ] (default is: 1): 1

Now you will be asked if you’d like to edit the “Basic Configuration” settings. Choose “1″ for yes and enter the information.

A brief description of each field and the data we entered for our example follows:

Edit 'Basic Configuration' settings? [ 1=Yes, 2=No ] (default is: 1): 1
Data collection interval (in minutes) (default is: 1440): 1
Logging Level of the agent [ 1=Debug, 2=Info, 3=Warn, 4=Error, 5=Fatal ] (default is: 3): 3

We’re asked if we’d like to edit “Optional Cert Config File” settings. Again, we will cover the optional certificate configuration file below. Choose “2″ for no right now:

Edit 'Optional Cert Config File' settings? [ 1=Yes, 2=No ] (default is: 1): 2

We’re asked if we’d like to edit “Remote X.509 Certificates” settings. Choose “1″ for yes. We can now add, edit or delete hosts whose certificates we’d like to monitor. Enter all hosts you’d like to monitor.

A brief description of each field and the data we entered for our example follows:

Edit 'Remote X.509 Certificates' settings? [ 1=Yes, 2=No ] (default is: 1): 1
No 'Remote X.509 Certificates' settings available?
Edit 'Remote X.509 Certificates' settings, [1=Add, 2=Edit, 3=Del, 4=Next, 5=Exit] (default is: 4): 1
Hostname (default is: ): smtp.gmail.com
Port (default is: ): 587
Service Type [ 1=SSL, 2=TLS/SMTP ] (default is: 1): 2
Alias (default is: ): gmail

'Remote X.509 Certificates' settings: Hostname=smtp.gmail.com
Edit 'Remote X.509 Certificates' settings, [1=Add, 2=Edit, 3=Del, 4=Next, 5=Exit] (default is: 4): 5

When asked if this agent will connect to a TEMS, choose “1″ for yes and enter the hostname for your ITM server. Then enter your network protocol information:

Will this agent connect to a TEMS? [1=YES, 2=NO] (Default is: 1): 1
TEMS Host Name (Default is: tr4g10): tw3g10

Network Protocol [ip, sna, ip.pipe or ip.spipe] (Default is: ip.pipe):

Now choose the next protocol number from one of these:
- ip
- sna
- ip.spipe
- 0 for none
Network Protocol 2 (Default is: 0):
IP.PIPE Port Number (Default is: 1918):
Enter name of KDC_PARTITION (Default is: null):

Configure connection for a secondary TEMS? [1=YES, 2=NO] (Default is: 2):
Enter Optional Primary Network Name or 0 for "none" (Default is: 0):
Agent configuration completed...

Your configuration is now complete! Start the agent instance by using the following command:

./itmcmd agent -o {instance name} start {product code}

Where {instance name} is the instance name you entered and {product code} is the product code for the instance (e.g. b4 for the Blue Medora Agent for Remote SSL Certificates).

Agent Certificate File Configuration

To configure an agent using the optional certificate configuration file, you first need enter the host information into a CSV file. An example file is provided with the agent, so you can simply open that and plug away.

Note: You should rename this file. If you update the agent, the default file will be overwritten if it is not renamed.

A brief description of each field and the data we entered for our example follows:

Below is the file we used in our example:

After completing the configuration file, simply create a new instance by following the steps in the appropriate section above for your platform. When prompted for the configuration file, enter the fully qualified path for the file you just created. You do not have to enter any hosts directly into the ITM configuration (but you may do so if you desire).

Conclusion

Congratulations! You’ve successfully installed the Blue Medora Agent for Remote SSL Certificates. In the next blog post, we will use the agent to solve real problems that often come up in an enterprise.

If you have any questions regarding this post, the Remote SSL Certificates Agent or anything else related to Blue Medora ITM Agents, feel free to drop me a line directly at: mike.major@bluemedora.com

Hello everybody! I hope you enjoyed the demo videos for the Blue Medora Agent for Remote SSL Certificates and the Blue Medora Agent for Ping Probe. Over the next few days, I will be adding a series of technical posts to help you get started with these agents. We will go through the installation and configuration for each agent in a step by step manner as well as run through some typical enterprise scenarios with the agents themselves. So let’s kick things off with the installation of application support for the agents to your ITM Server infrastructure (e.g. TEMS, TEPS, TEPD).

Note: The installation of application support for the two agents is identical. In this example, we will install application support for the Blue Medora Agent for Remote SSL Certificates.

– Mike Major

Installing Application Support

From the installation media, select the appropriate installer. Since we will be installing on a Windows platform (Windows Server 2003 in our case), run the setupwin32.exe executable.

The first screen will appear indicating you are about to install “Blue Medora ITM Agent for Remote SSL Certificates”. Click Next.

Next you will be prompted to accept the License Agreement. Press Next after you have accepted the license agreement.

The next panel will ask you for the location of the Tivoli Monitoring installation directory. In our case, TEMS, TEPS, and TEPD are all installed under C:\IBM\ITM.The Solution Installer should auto-detect this location for you and automatically fill in the top panel along with the location of the installation media in the 2^nd panel.

The next screen asks you to select the ITM Server components that you want to add ITM application support to. You’ll need to add application support to each HTEMS, RTEMS, TEPS, and TEPD instance in your network that the Blue Medora Agent for Remote SSL Certificates data will potentially be flowing through or viewed through. In our case, TEMS, TEPS, and TEPD are all installed on our single server so we will leave the default selections which the Solution Installer auto-detected for us. We also select “Perform a TEMS depot install of the solution on this machine” so we can remote deploy the agent later on. After you’ve made your selections click Next.

Note: You could choose “Perform a local install of the solution on this machine” to install the agent directly to your ITM Server. In this demo, we will install the agent to a dedicated machine elsewhere.

The next panel asks you to enter the ITM Administrative credentials and the hostname of the Hub TEMS. In our case, we enter the credentials for sysadmin and the hostname of the HUB TEMS host you want to install on and then click Next.

The next screen asks you to select which application you’d like to add support for. Not much to do here other than ensure Remote SSL Certificates is checked and click Next.

The next panel tells you what the Installer is going to install. Verify that everything is as you expect and click Next.

Assuming everything went well the installation should complete and you see “Installation completed successfully” in the next panel. Click “Finish” to exit the installer.

There are a couple of things to remember when you are installing:

1. You’ll need to add application support to each Hub TEMS, Remote TEMS, TEPS, and TEPD the Remote SSL Certificates monitoring data might potentially flow through (in the case of HTEMS and RTEMS) or viewed through (TEPS and TEPD).
2. The installation is more or less same for ITM running on other OS platforms. The only notable difference is the name of the installer (e.g. setupwin32 for Windows) is different.

If you have any questions regarding this post, the Remote SSL Certificates Agent or anything else related to Blue Medora ITM Agents, feel free to drop me a line directly at: mike.major@bluemedora.com

Most IT administrators are aware of the pain of adding another console to their toolset. The Blue Medora ITM Agent for Symantec Endpoint Protection helps alleviate a bit of this pain by monitoring your Symantec Endpoint Protection environment within ITM. When this agent is implemented you will quickly be notified of any security concerns or crises that are occurring on your Windows Servers protected by Symantec Endpoint Protection. You’ll be able to browse the Symantec Endpoint Protection logs, and even get updates on the running status of all the key services.

This blog entry continues my series of agent video demos with a quick walk through of the Blue Medora Agent for Symantec Endpoint Protection. As always, I hope you enjoy!

If you have any questions regarding the video, the Symantec Endpoint Protection Agent or anything else related to Blue Medora ITM Agents, feel free to drop me a line directly at: mike.major@bluemedora.com

Hello, Mike Major here again. One of the first agents I worked on when I first came to Blue Medora was the Blue Medora ITM Agent for Ping Probe. Ping Probe is a simple, yet powerful, tool that served me well in learning the ins and outs of the all the major IBM Tivoli Monitoring (ITM) components like TEMS, TEP, TEPD, TDW, etc . Like the Blue Medora Agent for Remote SSL Certificates, I could quickly see its usefulness in the enterprise.

This blog entry continues my series of agent video demos with a quick walk through of the Blue Medora Agent for Ping Probe. Enjoy!

If you have any questions regarding the video, the Ping Probe Agent or anything else related to Blue Medora ITM Agents, feel free to drop me a line directly at: mike.major@bluemedora.com

Hello, my name is Mike Major and I’m a software engineer here at Blue Medora.

One of my first projects here at Blue Medora has been participating as a member of the development team for our newest IBM Tivoli Monitoring (ITM) agent, the Blue Medora ITM Agent for Remote SSL Certificates.

I’ve, not surprisingly, spent a lot of time with this agent and over time I’ve really started to understand the usefulness of this agent for monitoring all the x.509 digital certificates the typical enterprise has and how the agent can be used to pro-actively warn IT administrators when certificates have expired or are near expiration, thereby reducing outages.

This blog entry contains a video where I spend a few minutes walk through some typical use case of the agent and I highlight some of the key features available for monitoring remote certificates.

If you have any questions regarding the video, the Remote SSL Agent, or anything else related to Blue Medora ITM Agents, feel free to drop me a line directly at: mike.major@bluemedora.com