[sims] HELP!!!!! SIMS/FMS/DISCOVER migration.... fail!

[Koldov]

I'd finally worked up enough courage to attempt this over the half-term, going by posts on here it seemed a relatively simple and straight forward process... and it was a complete disaster!

 

I created a 2019 VM and installed SQL server 2016.

 

I used the Capita/ESS migration utility 'SQLMigration.exe' which did what I thought was going to be the hard/scary part quite painlessly (although it didn't do everything that was advertised - 'application setup, set backup folder, scheduled task move, connect.ini and sims.ini not changed' - but it might not do that to a different server, or it might have been my fault for not ticking a box somewhere). But it detached the db from SQL 2012 on the old server and I copied onto the new server and it then attached it to SQL 2016 on the new server.

 

I ran SIMS – Summer 2013.ISO, but a notepad file opened and nothing happened, then I expanded the ISO and ran SIMSINST.exe and nothing happened... I mean nothing!

 

There was a 'SIMSinstaller 32-bit' application hanging in 'Task Manager' and also a notepad file which when 'force closed' produced some sort of error about SQL, but no errors in 'Application' or 'System' in 'Event Viewer'.

 

I have to admit here that our security is a bit 'block all and ask questions later' and I've found a few installers that open notepad instead of doing what it's supposed to (file types for a lot of scripts are associated with 'notepad'exe' - VBScript / Windows Scripting Host (WSH) script. 'cscript', JavaScript blocked etc.) which is what these old installers might need. Anyway, I thought I'd got round it by right clicking the 'install.exe' and choosing 'install'...

 

I honestly lost track of all the things I tried, but running all the installers I could find and then running the SIMS client also produced... nothing! No sign-in, no error, just hanging...

 

I have to say I haven't had to install SIMS for over 10 years thanks to SOLUS, but I did a fair amount of research and reading of post on here and the consensus seems to be:

 

OLD SERVER

run the 'migration utility' (or go dbAttach if you're old school), stop SQL

 

NEW SERVER

run SIMSINT.exe, copy over some folders, run the migration utility/dbattach again and that's all there is to it... NEW SIMS SERVER!

 

If it really is that 'simple' I thought I should be able to accomplish that at my level, save the school anywhere between £500 - £900 and add a feather to my C.V. We had it migrated once by Capita about 9 years ago and I couldn't really see what the engineer was doing, obviously there was a lot of script running and folder/ file copying and it felt a bit uncomfortable in our small server room (cupboard) to be standing over his shoulder...

 

I'd also rather have a reasonably 'fresh' SIMS server, so I'm reluctant to copy over too much (ours is a beast with many, many years of previous install, migrations and errors in folder structure that I'd like to forget about - like SIMSROOT\SIMS$\sims\sims\sims\setups... - obviously the installers are WIN95 or DOS based, not too clever and create folders even when pointed to the right folder).

 

I won't go into the fact that I couldn't find any way to install Discover (no installer, but cannot attach DB until you do), or get SOLUS to install at all... or that it went so wrong I had to try and get everything back on the old server last thing on Friday but finding the 'migration Utility' isn't backwards compatible and dbAttach can't see '.bak' files! Luckily I managed to get in through SQL Management Studio, eventually locate the db in the MSSQL folder and reattach it, but it was a one of those possibly career ending moments I think... especially considering the way budgets are these days I'm on thin ice anyway I think..

 

Needless to say, for once I'm quite glad everyone is in today and I can go back to 'changing toners' and 'turning it off and on again'.....

 

[robintech]

Needless to say, for once I'm quite glad everyone is in today and I can go back to 'changing toners' and 'turning it off and on again'.....

I've not done anything as complex but know that feeling well when the simple procedure leaves you in the black void or looking in the logs afterwards and seeing I'd restarted the server after waiting 10 minutes , when it was actually just taking a long time.

[supportman]

I love these threads simply because it reminds how ridiculous running a local MIS is

 

I remember these days with fondness and dread! Its 20 year old technology, time to move on.

[ALittleFish]

Nothing like a simple job going wrong to make you re-think all of your life decisions.

I'm going to be a bit blunt, and say this is why support units charge to migrate SIMS onto a new server.

 

It might seem a bit of a steep price for a days work or so, but there a number of ways to get a SIMS migration wrong and cause a lot of headaches.

For example with the SIMS database if you don't transfer the SQL Logins on the older server before hand, then you might have to reset passwords for most of the staff members.

Or for Solus3 you might need to re-install the Solus3 agents on all the workstations which could cause you headaches at the next SIMS upgrade.

 

Granted, I have heard stories about migrations being carried out by some support engineers and there still be issues afterwards.

 

For info the DBAttach.exe utility will find .BAK files but only when using the 'Backup' or 'Restore' functions towards the bottom of the UI.

Whilst the 'Attach' and 'Detach' options will only find .MDF files.

 

With Discover there two ways of doing it;

1.) Using the 'Discover.Backup.GUi.exe' to backup the Discover data on the old server, then install a new blank Discover database on the new server and use the DiscoverBackupGui to restore the Discover data from the backup file. (Note this is a Discover backup, not an SQL Backup.)

2.) Or using SQL management studio to attach/restore the existing database on to the new server, and then using the Discover installer to run 'advanced' setup and just install the Discover services.

Although when using the existing db via the SQL studio method, you need to clear out the Discover database users and use the Discover CMD line tools to re-sync the user logins. (Not ideal if you're not familiar with SQL Server)

 

Cleaning up after a failed migration can sometimes take just as long as the migration.

[3s-gtech]

Last time I did anything big with our on-site SIMS server, I ensured that ai had two things in place:

It was a VM

I had snapshots

 

When I updated it from 2008 R2 to 2012 R2 it removed .NET, so broke. I reverted to the snapshot while I worked this out, then tried again.

 

Reduced my stress levels massively.

[Koldov]

Nothing like a simple job going wrong to make you re-think all of your life decisions.

I'm going to be a bit blunt, and say this is why support units charge to migrate SIMS onto a new server. It might seem a bit of a steep price for a days work or so, but there a number of ways to get a SIMS migration wrong and cause a lot of headaches

 

True, I do not wish to demean a fellow professional, we are the first to say our skills are worth the money... I've always thought it was a 'big' thing, it's why I've avoided it for so long, I just thought after quite a few years in the job and with most posts on here saying "it's easy run the installer copy a couple of files move the database - working SIMS on new server"... I guess everything is easy when you know how... maybe they just leave out all the prep work, the things that did go wrong and of course different set-ups create less/more/different issues. The fact that our servers won't even open the .hta menu for the installer being fairly unique I guess...

 

For example with the SIMS database if you don't transfer the SQL Logins on the older server before hand, then you might have to reset passwords for most of the staff members.

Or for Solus3 you might need to re-install the Solus3 agents on all the workstations which could cause you headaches at the next SIMS upgrade.

 

Well, it would appear that the Capita/ESS 'Migration Utility' seems to have taken care of the log-ins (or some code has been run to inject them), as I can log in on the new server and they all appear in 'SQL Management Studio'.

 

I've decided to go with a fresh SOLUS as ours is a bit messy, with constant stalled downloads and needing to do pretty much the same amount of work moving it to a server with a new name I think.

 

Granted, I have heard stories about migrations being carried out by some support engineers and there still be issues afterwards.

 

That's the thing, although it's probably the easiest, most comprehensive and least likely to break, the last time we had a Capita engineer do the migration (about 8 years ago) he just copied the entire S:\ SIMSROOT folder onto the new server, which I guess is OK, but of course even then it had been running so long it was a complete mess, so it just transferred the mess... I wanted a bit of a fresh start without the years of failed installs, patches, incorrect folder paths, software and add-ons we don't even use...

 

For info the DBAttach.exe utility will find .BAK files but only when using the 'Backup' or 'Restore' functions towards the bottom of the UI.

Whilst the 'Attach' and 'Detach' options will only find .MDF files.

 

I found this later on when I had been searching for the dbAttach.exe, it appears I had been using a very, very old version (1.22.220) and it doesn't have the Backup/Restore option at the bottom. Then I found the newer one (1.63.23.0) afterwards...

 

With Discover there two ways of doing it;

1.) Using the 'Discover.Backup.GUi.exe' to backup the Discover data on the old server, then install a new blank Discover database on the new server and use the DiscoverBackupGui to restore the Discover data from the backup file. (Note this is a Discover backup, not an SQL Backup.)

2.) Or using SQL management studio to attach/restore the existing database on to the new server, and then using the Discover installer to run 'advanced' setup and just install the Discover services.

Although when using the existing db via the SQL studio method, you need to clear out the Discover database users and use the Discover CMD line tools to re-sync the user logins. (Not ideal if you're not familiar with SQL Server)

 

Seriously this is all great, thanks! Where were you two weeks ago...

 

Last time I did anything big with our on-site SIMS server, I ensured that ai had two things in place:

It was a VM

I had snapshots

 

When I updated it from 2008 R2 to 2012 R2 it removed .NET, so broke. I reverted to the snapshot while I worked this out, then tried again.

 

Reduced my stress levels massively.

 

Well, yes it is a VM... and no I hadn't taken a snapshot before I started... I guess as I said above I really thought it wasn't going to be a major disaster (PPP on my part), further compounded by the fact that I also remembered I hadn't even added it to any backup schedule (because as yet it wasn't really doing anything).

Edited February 24, 2023 by Koldov

[Koldov]

1.) Using the 'Discover.Backup.GUi.exe' to backup the Discover data on the old server, then install a new blank Discover database on the new server and use the DiscoverBackupGui to restore the Discover data from the backup file. (Note this is a Discover backup, not an SQL Backup).

 

 

Does anyone know where I might find this file...?

 

I've searched both the current SIMS server and the new (test) one for 'DiscoverBackupGui' but can't find it anywhere...

 

SIMS, FMS and SOLUS are now up and running on the test server (not used in anger yet though), but Discover just won't play ball!

 

Opening Discover gives an error about being 'unable to load the catalogue'

 

 

and the transfer says it's unable to contact the database.

 

 

Attaching the database with dbAttach gives an error too, but attaches it anyway...

 

[ALittleFish]

Does anyone know where I might find this file...?

I've searched both the current SIMS server and the new (test) one for 'DiscoverBackupGui' but can't find it anywhere...

This is in the SQL BINN folder on your SQL Instance, and gets installed when the 'SIMSSQLApplicationSetup.exe' installer is ran.

To be honest you only need to restore/migrate the Discover database if the school are using Discover groups or custom graphs.

 

If you use the DiscoverBackupGUI, you can backup the Discover DB on the old server.

Then run a new Discover install (including a new discover DB), an run a data transfer for the current year.

After that, use the DiscoverBackupGUI to restore the Discover backup from the old server, to restore groups and settings to the new discover database.

 

The errors you're seeing appear when old Discover Database Users haven't been cleared out, and permissions to the Discover database need refreshing.

If you check the Database user properties the "User type" listed under General, will likely show as "SQL user without login".

 

An alternative solution to fix these errors (using the existing discover database .MDF/.BAK), is to delete the Discover Database Users on new SQL Instance via SQL Management Studio and then run the Discover CmdLine tools to re-sync and grant user permissions.

1.) SSMS.

Expand and highlight [Databases | 'Discover DB' | Security | "Users" ] then select "View > Object Explorer Details" window to be able to bulk select and delete Users.

 

2.) Then use the "Discover.SqlUserManager.Console.exe" in the Discover Services directory.

 

2a.) Grants access to the Discover Transfer services. (Default user = Network Service)

Discover.SqlUserManager.Console.exe /Operation=GrantTransferAccountRights /AccountName="NT AUTHORITY\NETWORK SERVICE" /Server=%SIMS-SRV% /SIMSDatabase=%SIMS-DB% /TargetServer=%Disc-SRV% /DiscoverDatabase=%Disc-DB% /USERNAME=sa /Password=%SA-Pass% /verbose

2b.) Re-syncs Users from SIMS into Discover.

Discover.SqlUserManager.Console.exe /Operation=SynchroniseWithSIMS /Server=%SIMS-SRV% /SIMSDatabase=%SIMS-DB% /DiscoverDatabase="%Disc-DB%" /Username=SA /Password=%SA-Pass% /verbose

 

3.) Restart the Discover services.

[Koldov]

Thank you @ALittleFish

 

Well, you're a big fish in my pond...

 

[ITGURU]

Done numerous SIMS migrations before - rough steps below

- Spin up new server

- Install SQL etc

- setup new S drive share

- Use SIMS installable media to setup blank database

- run release version manual ISO to update instance to same level as existing SIMS release

- Copy over old S drive

- detach database from new server and move files.

- detach database from old server, (ensures logins are transferred from master database) and transfer to new server

- attach / restore database

- check login to SIMS

- reinstrall SIMS services manager

- reinstall SOLUS

- reinstrall discover

SOLUS and discover databases moved from old to new server in same way with backups - discover has its own backup tool

- if different server name, update connect.ini files to point to new server/instance.

[Koldov]

I really don't want to copy over the old S:\ drive...

 

I know it's probably the easiest/most comprehensive method of not missing anything, but it's an absolute mess and full of useless stuff, it's been going for longer than I've worked here!

 

The Capita engineer must have done that when he migrated it last time from the original server to this one...

 

Does anyone know if there are any 'must have' folders in there other than the ones SIMS has produced from installing (for continuity/history)?