Disable the server automatically updating, or auto deploy the update to clients so both are in sync would be easiest way
I've just taken over running a school network. On Wednesday morning Solus 3 automatically upddated the school SIMs system with the result that every workstation in the school bar one reported "Incomapatible Database!" for morning registration. Capita helpdesk were very helpul. I had expected a reponse something like "You need to change this setting to __". Instead I got five hours of editing congfig files and setting up ports in firewalls, and the problem still not solved compeletely.
Is this a typical experience?
Are there any steps I can take to avoid all this in the summer?
Disable the server automatically updating, or auto deploy the update to clients so both are in sync would be easiest way
Unfortunate problem to have when starting out.
We very definetly have auto-deploy disabled, as it takes it out of our control and will justhappen when it feels like it. We do however have auto-download ticked so it's ready to go when we are.
Whilst it usually goes smoothly now, we still have problems with one or two machines not applying the upgrade, but this is due to machine setup rather that a solus/sims thing.
That's the issue with solus 3, it updates the clients in batches. If you have 100+ and the update happens overnight there will be incompatible errors. I usually test it works then rdp in and run it. Then remotely start the computers to run the client upgrade. It's a major ommision there isn't a check update option in the solud client taskbar. Solus 2 was easier.
Who has deployed 3.5, any problems? We are looking to do this along with Spring release next Monday?
Apologies, I was told a while back that it did batches of clients resulting in some taking q while to update. I would still say the process is flawed, if a client was off when the update happens the incompatible database error appears and there is no way for the user to know why. Solus can take a while to think about getting its update...shouldn't the agent instantly ask the server what version I am on? "Hi I am desktop28, what version of sims should I be running" if its the wrong version a pop up should tell them to sit tight and shut up. Just my 2 penneth
Indeed the client does realise that it is out of date and pulls down the new version. It hasn't been 100% reliable with this action however. The new release should sort out those oddities.
You have to turn them off in Solus 3, I did manage to do the upgrade but needed capita to fix something in the database as it wouldn't let me upgrade to solus 3.5. Have you looked in system settings? We never have problems with the auto upgrade.
We don't have auto-download or auto-update ticked. When I deployed the re-release of the Spring Release yesterday, it took a few minutes to upgrade the SIMS server and DB (watching it in the Deployment History) then when it had done it took around 1.5 hours to download to and install on clients - as I don't have autodownload ticked, it watched it 'downloading to target... installing on target... successfull on target...' or whatever it says.
I had only minutes earlier downloaded the 2nd Spring Release to SOLUS so it can't have pushed out to clients earlier prior to the server install.
What I did notice yesterday was that I had loads of clients which I'd recently put the agent on which didn't update SIMS. The agent was online, communicating, in the SIMS channel. I then discovered that the version 1 release had been withdrawn, leaving me with those clients which I'd pushed the agent to yesterday giving incompatible database.
I had to go to the redeploy option and tell it to push the withdrawn version 1 release to clients.
My concern @PhilNeal is that when an update is withdrawn, we don't know about it (until we maybe receive the supportnet update mailing next week) and thus we do end up with incompatible database clients that haven't updated, whether by auto-deploy (if enabled) or by eek-i'm-out-of-date pulling by the agent.
Could we have more email alert options in SOLUS, and make the ones which are present more useful? (Another issue: I don't want 50 emails when 50 clients individually take the update as the agent comes online)
We do not bother with the auto update because we normally give it a few weeks before applying upgrade as there have had many bugs. I normally push out the upgrades every half term/ Solus 3.5 looks like a big improvement, but it is very annoying when I receive emails automated emails when a workstation has completed being deployed. It would be nice to configure Solus 3.5 to stop nagging so much lol.
Was similarly eager to gain benefit of the “improved” Solus, so decided to bite the bullet and deploy the 3.5.20 agent whilst things were quiet and had time to check it out this week. Sad to say – experience so far is that this is yet another not entirely clean/reliable piece of Capita software.
Set a deployment overnight and checked the UI to see how it had gone the following morning, knowing that only a percentage of machines across the school would have been left on. Happily the majority of those appear to have updated ok. But there were a handful still showing as 3.4.118 and with status “install failed”. So looked into those one by one. Tried a re-install – this failed. Tried a removal from list and fresh add as an agent machine. This failed.
So logged on to the workstation to make sure nothing unusual. Seemingly environment ok, so ended up deciding to manually remove the existing agent using Control Panel. This would not work since it indicated it was looking in C:\Documents and Settings\All Users\Application Data\Capita\Solus3\Deployments\a5c4366a-53ea-4143-a3a1-b7a8da59fb65\Packages\2b9f5dd9-c3fa-45e1-8a65-727205b469e1\Unpack\ or the like and the SOLUS3AgentInstaller_x86.msi wasn’t there – which was true when I looked myself. Whether it had got into that state from the previous 3.4.118 install or as a result of the failed 3.5.20 install is impossible to say. Oddly, in doing some searching, I found a 3.4.64 version of the msi in C:\Documents and Settings\NetworkService\Local Settings\Temp, which as I have later discovered, appears to be where the 3.5.20 install actually leaves it. So whether the deploy method has been recoded between versions or perhaps something on our network caused these specific 3.4.118 installs to end up in a different package area, again I can only guess.
But it left me with several machines where I couldn’t use the clean manual method to remove the existing agent and try the 3.5.20 install again, so I tried a crude “delete the install directory and links and try again” method! Doing this, the UI would actually complete the install as a new agent add, but the Agent version would simply not show and it could not display any target info when I queried the agent.
Finally, I took the largest sized spanner to it – uninstalled the 3.5.20 using Control Panel (which of course now worked), went through the registry and cleaned out what I felt were any potentially important Solus 3 references, and then found the C:\Documents and Settings\All Users\Application Data\Capita\Solus3\Deployments area where it puts the downloaded stuff and wiped that completely! Only then, when adding as a new agent machine would it install and show itself online correctly with Agent version.
What an unholy mess. Also noticed, when doing that last Control Panel uninstall of 3.5.20, the removal doesn’t cleanly delete the C:\Program Files\Solus3\ folder or the All Programs link for the agent, which you’d tend to think any well coded application ought to do?
What else – oh yes, I see several machines that apparently updated to 3.5.20 ok the first time, showing more recent messages of “Successfully finished downloading update.” (actually the exact text is that with only one quote at the end and the full stop – sloppy!). Excuse me – why is it re-attempting to download what it already successfully downloaded and used earlier? Just want to add load to our network do ya??
And… I also ended up having a look at C:\ProgramData\Capita\Solus3\Logs\ds_systemlog on the server at one stage when trying to understand what had been happening, and my eye caught regular entries (every 30s or so) in this saying that a particular agent machine is “downloading update 296ccde2-f7e1-40e1-9b46-3c78861b587e for target SIMS Workstation”. That machine isn’t on, wasn’t on when I did the deploy, and probably hasn’t been for some time. So why on earth is it spending time trying or thinking it is trying to download to something it cannot get to???
And... I have now gone and switched on one machine that would have been on the original deploy list but wasnt on at the time. I watched the UI to see what would happen automatically - it soon showed that it had downloaded the update, but so far, it seems unwilling to install itself. I assumed this would work the same way as the SIMS updates i.e. once a machine on the deploy list became live again, it would go ahead and update?
Oh, and just for afters – does anyone else get the same issue, when looking at the new Targets tab in the Deployment environment part of the UI – I get no scroll bar on the right hand side. So the list of machines show alphabetically up to a certain point, you can of course reverse alphabet using the column header, but I find no way to key scroll the list to be able to see those machine in the middle of the alphabet that are not displayed either way. Nice eh?
If I could bill back the number of un-productive days to Capita, at their daily consultancy rate, for all the time I have spent re-solving issues with Solus 3 over the past couple of years in our school, I could happily give up work for a year or so, and every time I’m dealing with it, that is exactly what I feel like doing!!
Last edited by resin1; 11th April 2013 at 01:26 PM.
First of all I wanted to say a big thanks for your reply, some interesting topics in here. Here's what happened to me:
Solus 3.5: In the release notes of the new SIMS 2013 spring release I noticed that it recommends installing solus 3.5 before upgrading to sims spring 2013. However I was getting a error when i went to deploy the SOlus 3.5 upgrade, it was complaining about the version number or something and it would not do the upgrade. I spoke to capita and they said that it was another bug and they could fix the issue by changing something in the datbase. They remoted on and changed the data and it still didn't work. They said to me that I should just deploy the new verison of SIMS as I was under time pressure by my school. I deployed SIMS, FMS and Discover which worked fine with the Solus 3.4 client.
Strangley, after this deployment of SIMS I was then able to deploy solus 3.5 which worked fine for most stations. I then began to troubleshoot the other stations, when logging onto the machine and testing they had the latest version of solus on there but the deployment version said otherwise. I then tried a manual uninstall and then removed the agent from the deployment UI and then reassigned the agent. This worked and then automatically deployed SIMS. This did work for most stations but one of the station said "Another deployment is still in progress install of agent failed". I tried uninstalling the client and it did not work, but what really surprised me was that it said it was tryinging to deploy SIMS Spring release 2013 2 AMPARK update? Even though I did not deploy the update and auto deployment is switched off. In the end I just gave up and manually copied the sims files onto the affected machines, will rebuild machine and start again next half term, sigh!
I also get the same issues in the Targets tab whereby I cannot scroll down, I can only search for specific machines using the search facility. Capita support are very annoying aswel as they always ask what version we are and refuse to help unless we are running the most up to date version.
There are currently 1 users browsing this thread. (0 members and 1 guests)