ALittleFish

With ESS/SIMS Connected, you will have a 'Third Party Connector' (TPC) setup on a server/workstation at the school to handle any 3rd party integrations. It will be best installed onto a Virtual Machine, so you can migrate it across to other physical hosts when/were required. VPN link is installed onto the device to link with the ESS network. Local SIMS client is installed on the device for third party applications to sync data from, everything else from your 3rd party links work the same. The DB details (Server & DB Name) will be listed in the connect.ini file as usual, and just need copying across into the required apps. Staff SIMS Users will have 'SIMS ID' logins to log onto the SIMS Connected platform, but third party apps will retain just the standard System Manager logins. The SIMS Client will be updated automatically via the Third Party Connector, (Runs a separate service to update the SIMS client) but sometimes you may need to restart the device if the client fails to update correctly. Troubleshooting is typically just checking that the VPN Services are running and checking that the SIMS Client is working as normal. Otherwise you can log a support ticket with ESS. (We did recently have a school migrate and the 3rd party connector took about 2-3 weeks for them to fix an issue with before it was working, but that does seem to be an outlier.) FMS: Any schools using FMS, and use the Budget interfaces to sync with 3rd party budgeting tools, will also need the Third Party Connector installed on a workstation for the Finance Team to use. The Finance team could log onto the Third party connector (TCP) for this, but it may be best to have a separate TPC installed on one of the Finance workstations instead of needing them to remote onto another device just for the budget interface. On-Boarding Make sure to note on the on-boarding forms any how many Third Party connectors you need installing. They will usually allow 2 installs during the on-boarding stage. They may charge for additional TCPs, if you need more than the 2 included. New Third Party connectors: If you re-image or replace a machine with the TPC installed, then you'll need to log a new install with the ESS 'Professional Services Team' which will charge for each new TCP you need installing. (I think around £350-£400 per install, so worth trying to avoid re-installs if you can.)

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.

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.

This might explain one of the issues I was having recently with a school. My work around was to re-deploy the SIMS Summer Full release to the new/re-built workstations once they had been added into Solus3.

The easiest option for you will be to download the Summer upgrade ISO from Capita's My Account Website and running the upgrades that way. Then just install Solus3 on the new server during your migration. Once they have been released they will be available to download from this webpage: https://myaccount.capita-cs.co.uk/Notifications/SIMS-Release-Download-Links [/Notifications/SIMS-Release-Download-Links] (does require you to have an account to access the downloads). Capita's Ess_Upgrade_Tools do have a way of updating the configuration files on the workstations but that will require you to have a copy of the tools in the first place. The amount of time taken to set up Solus3 on the current server, configuring of the SQL server's, databases and services in Solus3 to then change them all again once you've migrated to the new server will account for the time it'd take to download the ISO files from Capita anyway. You'll also need to create the Solus3 Repository's shared folder on the new server and either copy across the files to the new server or download again from Solus3. A way around the workstation agents if you do install before migrating would be just to reinstall the agents from Solus3 if they don't update automatically. The agents will show with a Red circled "R" if they haven't communicated with the new Solus3 Server. However if you install Solus3 on the current Server and don't migrate the Solus3 database properly (Actually install a brand new Solus3 SQL database instead of migrating the old one to the new server) then you will have issues with the Solus3 agents as they will be assigned completely different Solus3 Agent ID's. If this does happen then you will need the ESS_Upgrade_Tools.exe to correct the Agent config files, or then Query the Solus3 database in SQL Manager to get the correct agent ID's for the workstations and update these manually. (You could export the agent ID's from the SQL Database Query into a spreadsheet and create a script to update the agent config files from the spread sheet, but that goes past my knowledge of scripting.) Basically save your time and effort and just use the ISO files to upgrade SIMS.

I believe the issue is caused by Solus3 not picking up the target information correctly for the Solus3 targets (Database, Services, UI) which in older versions we can't actually see. From 3.10 onwards we are able to view the Solus3 targets in Settings | Solus3 | Show SOLUS3 targets (Blue Hyperlink) I have two ways around this issue both of which I've used plenty of times on our schools in the past but mainly number 2. 1: Within Solus3 Settings | Solus3. Reset the Service Host back to the Solus3/SIMS Server. --To do this you need to select a different computer or server (Select one from random in the Agents list.), [ignore the warning message about Solus3 not working if the wrong computer is selected. As we're not going to save these settings.] ---Then change the Service Host back to the correct Solus3/SIMS Server and Save the settings. - Redeploy the Solus3 upgrade and see if this has worked. 2: Manually upgrade the Solus3 database and then redeploy the upgrade through Solus3. --Extract the Solus3 upgrade from Solus ---Then manually upgrade the Solus3 database by running the Solus3DeploymentServerDatabaseInstaller.msi. (This will pick up that the a Solus3 database is already installed and just upgrade it.) -Redeploy the Solus3 upgrade in Solus3. As the Solus3 database is now already upgraded it won't fail during the deployment. It may go over the Solus3 database again but can't fail as the upgrade is already applied.