splattthecat

Check you have read / write permissions to C:\ProgramData\Solus 3 where the keys are stored

@bkbarry do you use SIMS Discover, and if so is there much assessment customisation within it? Also do you have track changes enabled in SIMS - Tools | Setups | data Change Management - both of these have caused us issues in the past as the overnight Discover transfer process is not very efficient.

Timetables and assessment marksheets would link to the staff record, and if a separate system manager record exists timetables and marksheets would need to be searched for rather than appearing in the timeline automatically

I had exactly this at one of the schools we support yesterday. Another one today was fine.

On the same lines, if you test DMS from one of the affected machines how long does it take to respond. It may also, as a test, be worth changing the protocol DMS is using, and re-testing. The protocol will need to be changed for the DMS server service, and in SIMS.

Thanks Graham and Tim from Groupcall, following a remote session with Tim we have now pinpointed that it isn't Groupcall Xporter holding open files - it's another 3rd party product ZiNET that is. You have both been very helpful - very much appreciated.

The database upgrades fine, it's the application upgrade on the server that fails, with dll files being locked and left at the old version. I will drop you an email. Thanks Adrian

Hi Graham, the Xporter version is 5.6.0.1610, and each upgrade we are having to stop the Groupcall service before re-deploying the workstation upgrader to the server to get it to apply after it fails to upgrade initially.

Graham, we experience minor, but annoying issues with each SIMS upgrade at schools we support where Groupcall exporter is in use, where the SIMS client upgrade on the server always fails due to the exporter holding open files. Is there any guidance from Groupcall on how we can manage this situation better?

The SQL Instance will need to be restarted before the capping change will come into effect

Have you checked regional settings and display settings for the user to make sure they are UK not US.

The issue is most likely that when SIMS was originally installed it was installed to C:\Program Files\SIMS and by default SOLUS3 installe to C:\Program Files(x86)\SIMS. The latter is the one SOLUS3 is upgrading, while the users shortcuts are probably pointing to the former. We changed the installation directory settings in SOLUS3 to C:\Program Files\SIMS at the point we installed it to make sure this wasn't a problem for our schools.

We have upgraded our approx. 250 schools to SOLUS 3.11 this week, with relatively few problems, and will be pushing out the SIMS upgrade on 21st to 23rd November.

Another issue can be the ports 50000, 50001 used by SIMS Services Manager are in the middle of a range of addresses used by DNS. We add an exception to the DNS settings to prevent it using these two adresses. An extract of the script we use for this is: dnscmd /Info /SocketPoolExcludedPortRanges dnscmd /Config /SocketPoolExcludedPortRanges 50000-50001 dnscmd /Info /SocketPoolExcludedPortRanges NET STOP "DNS Server" NET START "DNS Server"

I have been told this will be fixed in the Autumn release. In the mean time there is a patch that can be applied to set the User role where it is missing (The patch will need running after any new users are added) if like us System Manager 6 has been removed at all of our schools

Yes, FMS will support this. You will need to work with Capita on how to achieve it. Consortium for Purchasing and Distribution are using a web portal service to achieve this with some of our schools.

It will depend on the size of the school, number of staff and contracts, but 20 to 30 minutes seems excessive. The amount of time taken did increase 2 or 3 upgrades ago, but I would expect even in large schools less than 10 minutes.

Also worth checking the FMSConnect.ini file (in the same folder as the Finance.exe) is pointing to the correct server and database.

We had some issues in a few schools with performance many years ago that we pinpointed down to the Document Management Server. Changing the DMS protocol from http to tcp resolved things for us.

We are using SOLUS3 on servers and clients here. It works reasonably well, and allows workstation patches, like the recent one to fix an issue with detentions, to be deployed to clients easily. SOLUS3 has become much more reliable than it was in the early days, when it was a PITA, and we have relatively few issues upgrading 250+ schools. (Still not quite as reliable as SOLUS2 was for us, but SOLUS3 does more than SOLUS2 did!)

We have several schools where the SIMS database is much larger than we are happy with, caused by the overnight Discover transfer routines, (which in my opinion are unfit for purpose, but Capita are refusing to look at until the Autumn upgrade) and having Data Change Tracking enabled for some third party integration products. The largest database got to 60Gb until Capita produced a patch to shrink the DB. We have a call logged for another school where the DB is 22GB, and the school are unable to make exam entries. Not sure the two things are connected, but as it is Assessment tables that are growing out of control I suspect it may be.

Are you using http or tcp for your SIMS Document Management Server? We use tcp as we found performance better in a few schools. In Tools | Setups | Document Management Server how long does it take Test server connection to respond?

The Discover overnight transfer can cause the SIMS ldf file to grow significantly in a school where Discover Aspects are used extensively. Up to 12Gb in size at one of our schools, where the MDF is just over 8Gb. Hopefully this will be addressed in the Autumn upgrade, along with a couple of other major headaches the Discover transfer is causing us!

Make sure all of the pre-requisites are in place first, especially the firewall rules, also that there are no issues with DNS. These are the two leading causes of issues wit the schools we support.

Worth checking that the Connect.ini files are pointing correctly to the new server name/sql instance, that the clients are resolving the new server name to its correct IP address, that the SQL Browser service is running on the new server and that any firewall in place isn't blocking SQL traffic.