Skip navigation
All Places > CA Service Management > Blog > Authors ThomasConnery

CA Service Management

2 Posts authored by: ThomasConnery Employee

If you’ve ever worked for, supported, or were a customer of a managed service provider, you’re probably used to reviewing service level agreements, objectives, critical success factors, KPIs, and related reports. Most customers examine recent performance, compare results to their objectives or service level agreement, and provide a historical view as to how the provider has managed the service.


In this post I’ll share how to go beyond stating known historical facts and metrics of a service and leverage them to achieve value realization.


When you look at service management proactively, you may think about knowledge, problem, and change management—but it doesn’t have to be overly complicated to the point where you need to reexamine your existing processes or methodologies. All you need to do is collect your current report types—all of them—and move from a “prove” perspective to a “show” perspective.


Prove: Demonstrate the truth or existence of something by evidence or argument.

Show: Allow a quality to be perceived; display.


Confused yet? Stay with me.

A common report you may be used to seeing is an incident response report. With this typical report, you might prove that specific support groups or individuals are (or aren’t) meeting expectations—and it could stop there. Look beyond response data to information such as categorization, time of day, and volume.



Since categories allow us to track and monitor areas of risk or improvement for the service, you can use category information to find areas where your service provider can add considerable value. All ticket types should be aligned to a specific category ; request and incident categorization by month and quarter should take precedence. For example, you may notice that 50% of incidents are related to the reporting category across one or more report sub-categories. That should be a red flag to take a deeper look into those tickets. To do that, engage an architect or support resource to explore workarounds or enhancements that could potentially lower the number of report-related incidents.


Ticket Volume

Ticket volume and time of day information can help you correlate burn rate and work effort. It can also help you correlate known environment activity such as bulk onboarding or a new release due to short-term ticket spikes. For contracts that limit the number of incident or request tickets the provider should handle during a set period of time, you and your service manager should monitor ticket volume closely. As far as burn rate is concerned, the service manager can investigate ticket volume by assignee vs. the assignee's time entry for a specific period. This is more of an internal control process to ensure that the service provider is not overcharging the customer or burning through a fixed price contract too quickly. Controlling these areas and forming a plan to combat these trends will lead to value realization over time.


Value Realization

Shifting from proving that objectives have been met to showing customers value by helping them mature and improve their service demonstrates that the service provider cares about quality, professionalism, and going beyond the delivery standard towards reaching long term business objectives. If your service manager doesn’t follow the above steps, your awareness of the importance of these steps can help you collaborate with him/her to deliver added value to your company. If your service manager does follow the above steps, he/she is a leader who may quickly become indispensable to your company. Show your customer value and you will both inherit the success.

Hello Service Desk Manager Community!


Over the past couple of months I have seen some interest popping up on how to setup SSL encryption with CA Service Desk Manager. In addition to Jon Israel's excellent post here:, I wanted to share with the community some information I documented on configuring SSL with SDM 12.7 on IIS 7 and Tomcat based on Go Daddy certificates.


Note the Go Daddy repository here if needed: Go Daddy Repository, SSL Certificate Information


SDM IIS / SSL / HTTP / Tomcat Configuration Tasks


Step one assumes that you already have a .crt file ready for use and a .key file.


Create a p7b file using openssl:  (filename.*** below is often named after the domain - ex.

openssl crl2pkcs7 -nocrl -certfile filename.crt -certfile gd_bundle.crt -certfile gd_iis_intermediates.p7b -out filename.p7b
(gd_iis_intermediates.p7b and gd_bundle.crt can be obtained from the Go Daddy repository)

Create a pfx file for IIS import – Execute this from the cert location

Example: openssl pkcs12 -export -out <cert.pfx> -inkey <privatekey.key> -in <cert.crt> -certfile <gd_bundle.crt> -certfile <iisintermediate.crt>

Sample:  openssl pkcs12 -export -out -inkey -in -certfile gd_bundle.cer -certfile gd_iis_intermediates.p7b


(.crt or .cer ??? -->


Open Server Certificates in IIS – Click Hostname Connection First on left hand side


Double click to Open Server Certificates


Click the Import… link on the right


Browse for the .pfx file from your local server and then enter the cert password
(the password was specified during creation)



Sample successful pfx import

Next, open up the “Sites” parent level in IIS on the left side.

Then click the “Default Web Site”

Left click on “Bindings” located on the far right side.


Click the ‘Add’ button to add a binding.



Select type: https,   IP Address:  All Assigned,  Port 443 (default - but can be changed),   SSL Certificate – Select yours from drop down

Click: OK


Once the binding is complete, if you are using a loadbalancer, ensure it has already been setup for port 443 access, then restart the website IIS service.





Open My computer or file explorer goto the wwwroot directory (Default: C:\inetpub\wwwroot)

Create a backup of iisstart.htm

Next, open iisstart.htm in Notepad or a text editor

Select All – Delete – Then Past in the following:


Save the updated iisstart.htm file

Test the url:  sample  https://environment.url



TOMCAT SSL CREATION – tomcat.keystore

As a final step, create a tomcat.keystore for use with Business Objects SSL or any tomcat based service.

Below is an example of the manual commands you could utilize:


cat gd_intermediate.crt gd_cross_intermediate.crt valicert_class2_root.crt gd_bundle.cer gd_iis_intermediates.p7b > environment-certificate-chain.txt

openssl pkcs12 -export -inkey -in environment-certificate-chain.txt -out

../Java/jdk1.6.xx/bin/keytool -importkeystore -srckeystore -srcstoretype PKCS12 -destkeystore tomcat.keystore


Copy the tomcat.keystore to the BO app server or wherever tomcat SSL encryption is needed.



CONFIGURE Tomcat for Repository use with SSL - tomcat.keystore

Configuring Tomcat for ssl involves updating the server.xml file for the Tomcat instance.

<Install Path>\Service Desk Manager\bopcfg\www\CATALINA_BASE\conf\server.xml

*Note, you can also do this same process for REST under: ..\CATALINA_BASE_REST\conf\server.xml (Use an alternate port number to avoid a conflict!)
***Backup the default server.xml prior to making changes!

A sample server.xml section would look like the following: (Port can be customized per your environment - but don't use 443 if IIS is configured for that port)

    <Connector SSLEnabled="true" clientAuth="false" keystoreFile="C:\filename.keystore" keystorePass="password_goes_here" maxThreads="150" port="4430" protocol="HTTP/1.1" scheme="https" secure="true" sslProtocol="TLS"/>

Restart the tomcat service from a command prompt to apply the changes. (*Note, restart all services if you think the manual tomcat restart may not have executed successfully)

pdm_tomcat_nxd -c stop
pdm_tomcat_nxd -c start



CONFIGURE Tomcat for Business Objects use with SSL - tomcat.keystore

Configuring Tomcat for BO or CABI involves updating the server.xml file for the Tomcat instance, similar to what is above.

<Connector port="8443" minSpareThreads="25" maxThreads="150" maxSpareThreads="75" maxHttpHeaderSize="8192" enableLookups="false" disableUploadTimeout="true" acceptCount="100" sslProtocol="TLS" clientAuth="false" secure="true" scheme="https" keystorePass="password_goes_here" keystoreFile="C:\filename.keystore"/>


One item I did not mention about server.xml is that there will be two sections for connector ports. A non-SSL config and an SSL config. If you do want SSL to be functioning, you will need a segment similar to what I have shared in this post for each server.xml file. You will also need a section similar to what is shown below that specifies a redirect port for non-SSL incoming requests:

<Connector URIEncoding="UTF-8" acceptCount="100" connectionTimeout="20000" disableUploadTimeout="true" enableLookups="false" maxHttpHeaderSize="8192" maxSpareThreads="75" maxThreads="150" minSpareThreads="25" port="8085" redirectPort="8443"/>

*A redirectPort specification should exist in each server.xml file - along with a separate config line for the SSL connector port information.




Login to the SDM environment as an Administrator

Click the Administration tab and navigate the left side menu.
Click Attachments Library – Repositories
Right click on the Service Desk repository and left click Edit.

Change the Servlet Path to reflect the full SSL address.
Ex. https://<environment custom url>:4430/CAisd/UploadServlet


Do the same for the Images and Knowledge repositories!!





“Logging Out Of The Web Report Server…”is displayed as a pop-up and doesn't go away.

To resolve this logoff issue, do the following:

From inside ServiceDesk – Administration tab – Options Manager – Web  Report

Ensure that all 3 report options are disabled!



Thank you for checking out my first community blog post! Maybe these notes from a past SDM configuration I have performed will come in handy to someone else in the community.

If you found this information valuable, please leave a comment below. Also, if you found any errors - I'd like to know as well - Special thanks to Scott Weeks!