Just migrated Sims & FMS to new SQL version but what about Solus3?

[TwistedHelixis]

I have just completed a test migration of Sims and FMS going from SQL 2012 to SQL2016.

 

To get them working I needed to go into the S drive and update the connect .ini files, so they listed the new database instance.

 

This then made me think about Solus3....

 

If I open Solus3 I notice that under 'Enviroment / Targets / Databases it lists the old instance'.

 

Also if I open 'Settings / Solus3 / Solus', the database instance is also the old instance.

 

Q1. Should the migration not automatically update the .ini files?

 

Q2. Should I be following some instructions that follow on after the migration? and if so where can I get them?

[TwistedHelixis]

For the moment, this is probably the most important question for me to move forward.....

 

If I just want to leave Solus3 on the old database for now, should I update 'Enviroment / Targets / Databases' in Solus3 after Sims & FMS have migrated, or will this interfere with the database redirection service I ticked in the migration tool?

 

Wish there was some information on all this in the migration PDF

[mrwoberts]

When you open SolusDS, is the DB still running on the old 2012 instance, or have you managed to migrate that over to 2016?

 

Edit: To clarify, is this your current setup (post migration)

 

SIMS2012 - solus

 

SIMS2016 - sims, ccfms

Edited April 13, 2019 by mrwoberts

[TwistedHelixis]

Edit: To clarify, is this your current setup (post migration)

 

SIMS2012 - solus

 

SIMS2016 - sims, ccfms

 

Yes after the migration this is my current setup.

 

I am creating step by step instructions, so really need to know what the next step is after the migration tool has finished moving Sims & FMS. I assume it is to test Sims and FMS are OK, get users logged in etc, but I am worried that my users will get a connection.ini error (like I did).

[mrwoberts]

Fantastic.

 

Regarding the connect.ini problem, that can typically be resolved by redirecting to a centralised connect.ini, on a network share (I put mine in simshare for simplicity). This is specified in the Environment >> Configure Workstations section.

You would then push that out, through Solus3, requesting it to overwrite local copies - assuming there's nothing unique about any users' settings...

 

Something else I also did, was specify the FQDN of the server within the connect.ini file. This resolved an issue for me when connecting through VPN.

[TwistedHelixis]

Thanks for your help so far

 

Regarding the connect.ini problem, that can typically be resolved by redirecting to a centralised connect.ini, on a network share (I put mine in simshare for simplicity). This is specified in the Environment >> Configure Workstations section.

 

I think this is why I am getting confused, we do have this already setup, but Environment >> Configure Workstations section seems to be the place to go to push the settings out, but it is not the place to enter the new ini settings. Is Enviroment >> Targets >> Databases the place to actually update the ini file information with the new server/instance information, or should I be updating the actual .ini file that is located in the Sims share.

 

Possibly both work but Enviroment >> Targets >> Databases seems like the right place to do it automatically.

 

Note sure I am making much sense.

[mrwoberts]

You're welcome

 

There are two things at play, as far as I can see.

#1) The Database the Solus DS knows about, and therefore updates. I believe the connect.ini (if unchanged by my next point) is automatically generated by this info

#2) The (Custom) Workstation ini files specified in the Environment settings

 

Let's say you have two instances of SQL Server, SIMS2012 (old), and SIMS2016 (new).

You've migrated the databases from 2012 to 2016

 

I think there are two problems now existing.

 

P#1) I'm thinking that Solus still has pointers to the 2012 instance, with no mention of the 2016??

P#2) If the above is true, and if you've not modified the connect.ini file mentioned above, then Solus would continue to push out a connect.ini file that listed the old 2012 instance.

 

To solve P#2, you need to customise the settings in connect.ini to point to your new 2016 instance, with a FQDN for the server, then change the SOLUS settings similar to this...

 

To solve P#1, you need to add the new Server instance and Database settings in the appropriate Target tabs. I haven't tried having two database in there, but it allows you to add a second so I imagine it will work. However, might be better to remove the 2012 then add the 2016, assuming you're happy with the migration.

 

For my own personal interest in this solution I'd like to be able to solve the reason of why the solus3_deployment_server db remains under the 2012 instance and wasn't moved to the 2016. Once you've entered the references to the 2012 instance in the (Settings, SOLUS3, Solus) section, it wouldn't allow me to point that to the 2016\solus db that I'd made a copy of.

Edited April 13, 2019 by mrwoberts

[TwistedHelixis]

Just went back through the entire migration process (love virtual systems) and both Sims and FMS started without any issues, I also tested our Sims / FMS backup script and that backed up the new databases OK.

 

For anyone else reading this, I manually updated the .ini files on the sims share (S drive), then updated the Enviroment >> Targets >> Servers info in Solus, and finally pushed the ini files out to clients from Environment >> Configure Workstations.

 

Felling a lot more confident doing all this on the live server next week.

 

So next bit for both of us to workout is how to move Solus to a new SQL version.

 

Thanks for your time :0)

[mrwoberts]

Sounds like progress :-)

 

Did you set the connect.ini to be redirected - so that the client connect.ini file simply points to a centralised connect.ini file??

If not, one good thing about doing that is you can very quickly redirect users between the databases you set in the central connect.ini file, also you can prevent anyone from logging into SIMS by simply removing the file (for maintenance reasons...)

[TwistedHelixis]

Did you set the connect.ini to be redirected

Yes I did.

 

I did notice there is also a tab to redirect the Sims.ini but I left this blank. Is yours also blank?

[mrwoberts]

Yes I did.

 

I did notice there is also a tab to redirect the Sims.ini but I left this blank. Is yours also blank?

 

Not blank, but points to a basic sims.ini, which isn't redirected, but is added to the client sims.ini upon installation of SIMS.

 

Here's mine

[setup]
SIMSDirectory=\\MY_SERVER.admin.school\simshare\SIMS
SIMSSetupsDirectory=\\MY_SERVER.admin.school\simshare\SIMS\Setups
Folder=SIMS Applications

[Damon]

Is it also worth setting up an SQL redirect in your old 2012 instance? Just in case there is a dodgy connect ini out there or S3 doesn't replace it. It wouldn't necessarily draw your attention to the workstation issue though.

[TwistedHelixis]

Is it also worth setting up an SQL redirect in your old 2012 instance? Just in case there is a dodgy connect ini out there or S3 doesn't replace it. It wouldn't necessarily draw your attention to the workstation issue though.

The migration tool does do that. In the old SQL version you can see a Sims and fms redirect.

 

It anoying that the tool does not do all the other little bits n bobs.