How To Replace An Expired SSL Certificate For Dyamics Management Reporter

I periodically find myself blogging about Microsoft Dynamics products. Mainly because they are a pain in the ass, and fixing problems tends to yield decent blog articles...

Anyway, the other day I was faced with an issue. We use Dynamics Management Reporter 2012 at my day job, and it rarely gets used. Because of that, certain issues like an SSL certificate expiring easily gets overlooked until someone goes to use it and you find out a certificate has expired and you neglected to replace it!

Well, that happened to me when our Accounting Director went to use it and received the below error when trying to connect to our Management Reporter server:

Management Reporter 

The server presented a certificate that could not be validated. Verify the certificate has been installed and is configured as a trusted root certificate on the client. Contact your administrator for help with certificate configuration.

I Googled around a bit and only found articles about changing the certificate in IIS. The issue is, we don't use IIS with Management Reporter in our environment. I did find a solution though, using netsh via the command line!

Before you do anything else, install your new SSL certificate in your local computer's certificate store like you normally would. Google how to do that if you don't already know how.

Next, find out how binding is currently configured by running the following:

netsh http show sslcert

You will get something like this:

Next you want to delete that binding by running the following:

netsh http delete sslcert hostname=hostname:4713

Be sure to replace hostname and port above with the information provided from the first command.

Now, we want to bind your new certificate. First you will need the thumbprint from your new certificate. You can find that by looking at your certificate's details tab, and scrolling to the bottom to see the thumbprint. Copy that information to notepad and remove the spaces.

Now you are ready to bind the new certificate by running the following:

netsh http add sslcert hostnameport=hostname:4713 certhash=<your certificates thumbprint> appid=<Your Application's ID> certstorename=MY

Be sure to replace the hostname with the hostname from the first command above, use your new certificate's thumbprint without spaces, and use your application's ID from the first command above.

After that, not sure if you have to, but I restarted the Management Reporter services and everything worked fine.

If you know of an easier way to do this, I'm all ears. This worked for me though. If this helped you too, let us know in the comments!

Read more »

Cisco Finesse Cannot Authenticate With The Notification Service

I love waking up in the morning extra early, and hearing the lovely sound of my IM client at my computer (I work from home). It usually means that something is broken for someone. Well, this morning was no different. I got a message from one of my company's client support folks saying that she couldn't get into the Cisco Finesse phone queue, and that she was getting an error saying that it failed to load workflows.

When I tried logging in myself, I was greeted with a much different message. I got a message saying:

Cisco Finesse
Cannot authenticate with the notification service. There may be a configuration mismatch. Please contact your administrator.

Well shit... That's no good...

Anyway, I decided to try logging into Cisco Unified CCX Administration. When I logged in there I was greeted with a different message. This one said:

The Cisco JTAPI Client versions are inconsistent. Please go to Cisco JTAPI Resync in the Unified CM Telephony Subsystem to install the Cisco JTAPI Client.

Well shit... That's no good...

So I decided to follow instructions. From within Cisco Unified CCX Administration I went to Subsystem > Cisco Unified CM Telephony > Cisco JTAPI Resync. Then clicked OK when prompted.

After that I got another message saying:

For changes to take effect, please restart the Cisco Unified CCX Engine.

In order to do that, I had to go into Cisco Unified CCX Serviceability. Once in there I had to browse to Tools > Control Center - Network Services.

Once in there I had to find Cisco Unified CCX Engine service and restart it. Once that was done, I restarted the Cisco Finesse Tomcat service as well. After that users were able to login to the call queues again!

These last two services have to be restarted from an SSH terminal using the following commands:

• utils service stop Cisco Unified CCX Engine
• utils service stop Cisco Finesse Tomcat
• utils service start Cisco Unified CCX Engine
• utils service start Cisco Finesse Tomcat

Did this post help you out? Let us know in the comments!

Read more »