CA Service Management

Hello All - Sorry its been a while since I have posted here. Through the spring season I have been involved in a lot of projects and initiatives which everyone will hopefully see the benefits of shortly down the road!   With that, I wanted to post a tip here for an easy workaround to a problem that more and more folks are coming across as many start to test and upgrade to Service Desk Manager 12.9.

As you know, starting with Service Desk Manager 12.9, we have introduced GUI functionality for adding and configuring secondary servers, as well as for configuring Standby and Application servers in an Advanced Availability architecture.  In doing so, a new table has been introduced - called "usp_servers" - which holds the information for each server that is configured in the environment.

So wheres the problem with this?   Well there is no "problem" per se, however, there is a challenge or pesky "Gotcha" that comes up when you run pdm_configure after copying an MDB database from one 12.9 environment to another.   Whether building out a new Service Desk Manager 12.9 Test/Dev system, or refreshing the data on an existing Service Desk Manager 12.9 Test/Dev system by copying the MDB from Prod to Test/Dev, when you try to run pdm_configure after the MDB restore (and fixing the orphaned user in SQL) it will fail with an error stating:  “Already following servers are using same Database: servername-of-systems-where-mdb-came-from.  Make these servers as Inactive to proceed.”

Have no fear - we have a fairly easy workaround to get things back in working order...
Using either SQL Management Studio, or SQLPlus for Oracle, set the value of the “del” field on all rows in the usp_servers table to have a value of “1”.  You can do this with a simple statement such as the following:

update usp_servers set del=1

This will make all records in the table "inactive".  Then run pdm_configure on the Primary or Background server.  This will add the server (which you are running pdm_configure on) to the usp_servers table and make it active. 

Now, if you your Test/Dev environment has Secondary servers, or if you are using Advanced Availability and have Standby and Application servers, you will need to re-add and configure those.  To do this, log into Service Desk Manager on the Primary or Background server re-add any Secondary servers, or Standby servers and Application servers that you have in your Test/Dev environment.  Then edit the "configuration" that you want to use to ensure you have the appropriate daemons configured on each of those servers. 

Once you have completed the server configuration, you will then need to run pdm_configure on any Secondary servers, or Standby servers and App servers that you have in your Test/Dev environment, and everything should be back up and running.

Going forward, one thing you can do prior to restoring the MDB to a test or dev system is to first extract the usp_servers, and usp_configuration tables.  Then after you restore the mdb from prod, you can do the following steps:
- inactivate all records in the usp_servers table as described above
- run pdm_configure on the Primary or Background server
- load in your extracts for usp_servers and usp_configuration table
- run pdm_configure on ALL servers in the test or dev environment

I hope this will help clarify and simplify your process going forward.   At this time we are actively working with our product teams to come up with a more user-friendly solution to this, and I will update this post when that is finalized as well.

Thanks and have a great week!!

Jon Israel
Principal Support Engineer
CA Technologies

Yes, this is something we faced while working with SD 12.9, by inactivating the entires in the 'usp_servers' table overcome this.

If any user friendly option would be  helpful, something like configurable(inactive/activate connections which will effect the table values) option in pdm_configure console will help this.

Thanks,

Hi Jon,

many thanks for this workaround.

Are there any updates for a fix?

Many thanks and regards

Christoph

Hi Christoph,  There is a fix that was rolled into CP1, however its not quite what we had expected so there is still work going on to figure out the best way to address this.  In the mean time, the best way to handle this is to use manual steps to inactivate the usp_servers table records.  In SQL you can use "update usp_servers set del=1" which will inactivate all of the records in the table.  Then you can run pdm configure without a problem.  Once pdm configure is complete, you will then need to add in secoondary servers or background/app servers if you are using the advanced availability architecture.

Thanks,

Jon I.

Great tip Jon_Israel !

If you could please use the tags "Tuesday Tips" and "tips" for these posts so more people can find your content, it would be much appreciated.

I corrected the tags on this post for you. Keep the great content coming!