I'm fed up with SOLUS3 now. Capita insist that workstations should automatically upgrade if they are online in SOLUS3 and are out of data, but I'm calling b******t on this as it's blatantly not happening.
Got one school that has had SOLUS3 for the past few months and has the agent on all of their SIMS devices. I had a call from a colleague this morning who on site who can't get into SIMS to deliver training due to an "incompatible database" error. I find that this workstation is on 7.146. It was online in SOLUS3 and had not upgraded itself. I manually redeployed the workstation client and it upgraded with out any issues.
I decided to run an environment report against the SIMS Client devices and found 13 devices in SOLUS3, online, but running on various SIMS .net versions between 7.140 and 7.148. Done a re-deployment to all of these devices and they've all upgraded. Can someone please explain to me why these devices have been out of date for so long, and why SOLUS3 has not upgraded them automatically?
Is it a bird? Is it a plane?
No, it's B.S Man!
Rawns (14th March 2013)
The only thing I do when this happens to me is to browse to the machine and delete both the agent and sims then remove it and add it again. Not the best solution I know and Solus 3 is very flakey at times to put it nicely.
I'm with you. Countless times over the past couple of years I have said - let's go back to Solus 2 - I'm wasting way way too much time sorting out each update with S3.
But it has got steadily better.
The peice of the jigsaw which I am sure Phil Neal mentioned on here at some point, or maybe it was on SupportNet, is that they were going to finally add in functionality that basically allowed a client to fallback to the old S2 method of updating itself, if when the user ran SIMS, it checked and found that it was not the same version that the network had been updated to. Not sure when that is due, but it cannot come soon enough for my liking.
That would at least take away the burden on the likes of yourself having to sort out end users when, for whatever reason, the update didnt take with a client when you did the deployment. One intance of that I have seen a number of times is simply that a user had left themselves logged in and with SIMS running. If the S3 update cannot write over the solus.exe because its locked by a process, it updates all the other files but not that one. Then of course its out of date the next time a user re-starts and you get the incompatible database error, but S3 logs that the update was successful. Great eh?
Yes sounds about right, when I recently upgraded SIMS across the school I only got a few incompatible database errors and that was mostly laptops that are never turnt on etc. When I get the incompatible database I just remove the agent and add it again. I always make sure I upgrade the workstation during the holidays and run a sql script to make sure that no one else is logged on at the time.
I've only run Solus 3 once so far, and the biggest problem I had was that it only seemed to want to update 5 clients at a time, meaning it took hours to deploy. Some agents did pick up the latest version on restart, but others didn't. Redeploy always successfully installed the update.
If you download the ISO from Capita, that includes the simsapplicationsetup.exe file which Solus 2 used, so you could deploy that via startup script instead.
I just run a simple query on our SIMS SQL database and that's enough for me. That's a odd on that only 5 update at a time? Doesn it show any error at all or does it just not work? I've only used Solus 3 and I've had no issues.
Originally Posted by enjay
Enable "auto download to agents" so when you receive a new upgrade, SOLUS3 will actually push out the update files to each workstation before the upgrade is due to start. Then once the upgrade kicks off, all the workstations will already have the required upgrade packages and upgrade at the same time.
Last edited by Rawns; 14th March 2013 at 01:15 PM.
May SOLUS3.5 solve all our problems when it gets released.
One can dream...
This still doesn't explain why it didn't start downloading to the clients until after I'd done the database update though. Could it be that I hadn't left it long enough for them to all download it before I scheduled the deployment?
There are currently 1 users browsing this thread. (0 members and 1 guests)