Looking for understanding - strange behavior after moving SCSM operational database

David_Hicks

Last night we migrated the SCSM operational database from a SQL2012 instance to SQL2016.

The Cireson Service Portal broke because in our install, we had used a server name in the connection string instead of an alias. Thus, Cireson was no longer looking in the right place for the ServiceManager database.

I ran the Service Portal setup on our cache builder server, pointed it to the new location, and all was well. (This was a newer version of the portal, as I couldn't find the previous versions on the downloads page.)

In addition to the cache builder server, we have 6 other servers running the portal. I upgraded two of them. So far, so good. But within 15 minutes, we were broke. The portal was again trying to connect to the old db location.

I reran setup on the cache builder and we were fixed-- for about 15 minutes. This same thing repeated twice more, with it all breaking, then being fixed by a reinstall on the cache builder server.

We never determined what kept setting the database location back. However, when I completed the upgrade on all the other servers, the behavior ceased, and we've been good ever since.

Could it be that the non-upgraded servers were passing an old connection string back to the cache builder server (and thus breaking everyone)?

Adam_Dzyacky

I've ran into something similar with several frontend servers and with the help of @Justin_Workman we were able to come to a resolution. Here's the short of it -

On the servers in question head into "C:\users\USERNAME\AppData\Roaming\Cireson Setup\" and open up setup.config where USERNAME is your username within your environment. This is the file used by the Cireson installer on subsequent installations so you don't always have to key in the same information every single time.

But it comes with one, very slight drawback - if you ever disable one of the features to install (e.g. Analytics or the DB which is somewhat typical when you're deploying just the IIS frontend) where you've previously installed them. Setup.Config still uses the originally configured values as opposed to null them out. As such, you should just be able to edit setup.config, re-run the installer, and have order restored permanently.

Adam_Dzyacky

I've ran into something similar with several frontend servers and with the help of @Justin_Workman we were able to come to a resolution. Here's the short of it -

On the servers in question head into "C:\users\USERNAME\AppData\Roaming\Cireson Setup\" and open up setup.config where USERNAME is your username within your environment. This is the file used by the Cireson installer on subsequent installations so you don't always have to key in the same information every single time.

But it comes with one, very slight drawback - if you ever disable one of the features to install (e.g. Analytics or the DB which is somewhat typical when you're deploying just the IIS frontend) where you've previously installed them. Setup.Config still uses the originally configured values as opposed to null them out. As such, you should just be able to edit setup.config, re-run the installer, and have order restored permanently.