Service Desk Practitioners Forum

SD 5.x Clustering Issues

Rikard Ekman
Super Contributor.

SD 5.x Clustering Issues


For an SD 5.1 cluster to work fully there is an interesting feature included with certificates.
The thing is, I we do it by the book, that is:
1. Generate a Certificate on main server
2. Import certificate on second server

We have this issue:
Users loging in on primary server and being transfered automagically to second server will not have a trusted communication and therefore be denied a login.
Same users going direct to second server will be accepted...

The servers are functioning together just fine, the SLM module is running on the second server and they seem to like ech other, except for the transfere of login from server one to two..

Anyone that have a clue?

Computers are evil, destroy them, destroy them all!
Super Contributor.

Re: SD 5.x Clustering Issues

As far as I know, failover is not enable in SD 5.1 and is expected to be resolved in SP3.

Also the problem for "ignore client settings" will be resolved.

Chris Terzian
Trusted Contributor.

Re: SD 5.x Clustering Issues

Hi Rikard,

We had the same problem. I'll list the steps that worked for us:

Load Balance / Failover

1. On the primary server (the one running the certificate server) run the following command:
ovcert -exporttrusted -file c:\trusted.cert -ovrg server
(c:\trusted.cert is an example file name. You can choose any name.)

2. Transfer the file that is created (trusted.cert) to the secondary server (assuming it is put in c:\ again)

3. On the secondary server, stop all processes (ovc -stop)

4. On the secondary server, run the following command:
ovcert -importtrusted -file c:\trusted.cert

5. On the secondary server start the object server processes again (ovc -start).
If you now run the command ovcert -list on the secondary server it should show the trusted certificate that has been imported. Load balancing will work fine now if the primary server is used as the login server as well. To be able to use the secondary server as the login server, some additional steps need to be taken.

Only management servers that have a valid certificate installed can act as a login server. The previous steps installed a Trusted Certificate. However, if you run 'ovcert -list', it will show that the secondary server does not have a certificate of it's own. To obtain this, the certificate needs to be issued from the certificate server. These steps need to be taken:

Now, on the Secondary server run:


This will return the coreid of the installed management server. Copy this id or write it down somewhere.

2. On the Certificate server (your Primary server) run the following command (make sure the certificate server is running):
ovcm -issue -file c:\cert -name -pass password -coreid

Below is an example coming from a test environment:
ovcm -issue -file c:\cert -name -pass password -coreid e1966932-c832-7518-043c-e26554f88817
Copy the file that is created to the secondary server.

3. On the secondary server run the following command:
ovcert -importcert -file c:\cert -pass password

This will import the certificate into the Keystore of your secondary server (you can check using: ovcert -list). After you have done this you should be able to use the secondary server as a login server as well.
Be sure to do an ovc â restart on both servers for good measure and make sure the box to join servers and allow client connections is checked on both serverâ s configurations.

Rikard Ekman
Super Contributor.

Re: SD 5.x Clustering Issues

Hello Chris,

Well, those are more or less the steps I found in an abscure part of the online documentation. Great work on writing down them step by step!
I even for good measure did this just now:
ovconfchg -ns sec.login.signer.accepted -set SERVICEDESK 3e68ae02-0f36-751c-04b1-f1fed22a1444
ovconfchg -ns sec.login.signer.accepted -set SERVICEDESK2 c9a65ab2-73f5-7522-0467-de35aaac905c

On the two servers

But since all system are live.......

Ill get back later on the results.

Computers are evil, destroy them, destroy them all!