[sims] Has anybody else had the misfortune of using SOLUS3 to deploy SIMS to clients?

[tockwell]

Has anybody else had the misfortune of using SOLUS3 to deploy SIMS to clients? It looks and functions as though it was designed, developed, and tested in a weekend, by a solitary programmer whose experience of Windows networking and good programming practice was obtained by a quick search on Google.

 

Firstly, it has the most counterintuitive UI known to man – in fact, the method of adding clients and deploying software defies logic, and ignores windows design guidelines (for instance not using the standard AD computer selection common dialogue box, and the need to keep prompting for credential).

 

Secondly, it attempts to solve a problem that doesn’t need to exist in the first place; why does a company like Capita feel that it needs to develop a substandard deployment system rather than allowing their application to be deployed via an MSI or using MSSCCM like every other software package developed in the last 10 years (notwithstanding other applications aimed as schools designed by well-meaning but inexperienced programmers).

 

Essentially, all admins need is an MSI or even a setup programme that will run silently (without any user input), that is generated every time SIMS is updated, that could be deployed using the group policy software installation extension, or MSSCCM.

 

The biggest problem with SOLUS3 is the agent deployment. If the server doesn’t think that the agent is the right version, the agent isn’t installed, or the agent doesn’t match that which the server has a record that the server installed (presumably it has some kind of unique ID), then it isn’t possible to install the agent without removing it and reinstalling it. The assumption that the computer be offline because the agent be offline is non sequitur.

 

The easiest way to demonstrate this behaviour is to deploy the agent on a computer install SIMS &c. then rebuild this computer with the same name (this is of course standard practice way in schools and businesses alike, to refresh a computer). As part of the specialize phase of sysprep, the process will reset the computer account in AD and then re-join the computer to the domain using the computer account. This will result in a computer to which SOLUS thinks the agent is deployed, but the agent is not installed.

 

If the agent is reported to be offline, then there is no way to expedite the installation of the client without first completely removing it and re-adding it; there is only a ‘remove computer’ option. This can happen if the computer is rebuilt, but I have recently had a finance computer report to be offline even though it worked last time SIMS and FMS was updated.

 

To overcome these problems, SOLUS would do well to have a method to reinstall the agent should the agent report to be offline, but a computer with that hostname be contactable. If we take MSSCCM as a model, then the agent could auto-install in this case, or the agent be deployable by other means, or at least an option be there to re-install and re-fresh the agent.

 

The most obvious way to overcome this would be to allow for the agent to be installed via an MSI and Group Policy Installation Extension. Is it possible that deploying the agent to new and existing clients could be effected in this manner?

 

The current situation dictates that, in order to get a computer to deploy SIMS, it was required to remove the agent and targets from the list from the server UI, close and re-open the server UI, add the computer again, and then install the agent, which required entering administrative credentials again.

 

I have had instances whereby the SOLUS3 console in Environment > Agents >> Agents reports that the agent status is offline (even though the computer is running and the agent is running). The only option given with the agent selected is ‘Remove Computer’. If I select ‘Remove Computer’ then the computer is removed from the Agents. The only option then presented to me is to add the client again from Environment >> Targets >> Clients. However, if I attempt to do that, then SOLUS3 informs me that the client is already installed. Therefore, I have to log onto the computer in question and then uninstall the client from Add/Remove programs. If I then deploy the client again then it installs SIMS.

 

If you rename a computer, SOLUS3 does not reflect that the computer has been renamed, it simply reports that the computer of the old name is ‘offline’. It should refer to computers using the SID of the computer (which of course will not change) rather than the computer name. In order to resolve the problem the computer must be removed, the client manually uninstalled and then added again as per the other bug. It is of course bad practice to refer to computer objects using names as they can change, the SID is designed as an immutable identifier and would protect against this.

In fact, most of the problems faced with SOLUS3 deployment require the client to be removed from the computer and SOLUS3, and added again, but this is far from a straightforward. It seems that Capita expect the following to be carried out every time a computer is rebuilt!

 

• Connect via RDP to the SIMS server

• Open the SOLUS deployment UI

• Go to SOLUS agents

• Select the failed computer

• Click on Remove computer

• Click on Update environment

• Set the channel to SIMS

• Click on select Computers, next to Workstations

• Click on Add

• Navigate to the required OU (after working out which OU it is)

• Click on Browse computers

• Select the computer in question and click Add

• Click Save

• Enter the Administrator credentials

 

(edit: I wrote the steps above in relation to an early version, although the current version is slightly better, the rigmarole is still deficient)

 

On computers that deploy SIMS and FMS, the agent will install SIMS first and then report that there is no Capita software to install. The user may then try and open FMS and it be reported of an incompatible data file. Eventually the agent will deploy the new version of FMS, but the interface would benefit by being more intuitive for the user. It stands to reason that the agent report straight away that both pieces of software need to be upgraded – at least it should know that they are pending – the software knows the installed version of FMS on the client and the current version downloaded.

 

There appears to be no way to expedite the installation of SIMS or FMS from the SOLUS 3 deployment UI. If the computer was off when a new version of SIMS &c was deployed, then there is no way of knowing when the new version will be installed – it is frustrating to know that there is a new version available and that the agent is working, but the client does not appear to be installed.

 

Similarly, if the agent reports that another installation is in progress, then there is nothing that can be done from the SOLUS 3 deployment UI. The ‘message’ is displayed under Environment >> Agents >> Agents – there is no specific information deployed for a particular package (products such as MSSCCM display information for both the deployment status of a package and the status of the agent). However, should this be displayed, then there is little one can do. The logical step for one to take is to select the item and then click on the ‘Check status’ button. This results in the message unhelpfully changing to ‘Agent responded to status check’. This leaves one with no indication of what progress is made with the installation of the package.

 

The logical place for expediting and at least determining the status of a package install is ‘Environment >> Agents >> Targets’, however the only information given is the version. The context menu gives the options of ‘copy computer name to clipboard’ and ‘open network path in explorer’ both of which appear to offer no real value. One cannot easily determine if the correct version is deployed and if it hasn’t, then why. It does not seem logical for this information to be displayed under only ‘Environment >> Agents >> Agents’, and only the last ‘message’ displayed with no history. Reading client and server logs to determine an overview of what installs were successful seems unnecessary.

 

Granted, there is the ‘Environment >> Reports’ option, but this appears to be a particularly vague overview with no details (of least that which I can find) of the status of the deployment of the clients, only listing the result as ‘partially successful’.

 

Another problem is that the application cannot cope with different program files paths, and it is required to install a 32-bit program into the x64 program files folder in a mixed environment. This appears to undermine the point of that folder.

 

In fact, SOLUS 3’s only redeeming feature is that it circumvents the pure stupidity of SOLUS 2 such that SOLUS 2 would update using the current user’s credentials, which would give you either the option of manually going to every computer and logon on as an administrator to update the software, or expose various parts of the registry and file system to the user.

 

Before I was an IT administrator for a school, I worked for a software company that produced server/client applications and was responsible for QA and testing. Software this buggy and fundamentally ill-designed would never be acceptable in a real commercial product. Capita is praying on the fact schools are tied into this maladroit concoction of ini files and other dated concepts.

 

…and relax :-D

Edited April 25, 2015 by tockwell

[TechieWils]

All I can say is I sympathise, understand and appreciate every word above. I hate solus 3 and Sims as a whole. Bloated and messy I actually miss CMIS for all its dated looks you updated the server then relaxed as the clients sorted them selves out.

 

Solus 3 also has no manual install of Sims when the inevitable client actively refused connection and been told the firewalls are on (no there not your software is awful) and the deputy is breathing down your neck asking why it isn't working.

 

Infuriating when 6 updates come down in one with no warning, the auto deployment is off now cause of the charming little feature I had on Friday.

[Boredguy]

TBH I got round the issue of the issue of rebuilding stations loosing their SOLUS 3 id very simply.

 

I exported the Agents database to csv so I had station name and GUID, and then install the client via script that checks station against the CSV and if it exists passes the stored GUID to the MSI installer so every time a workstation is rebuilt it gets the same SIMS applications installed without any headaches.

[psydii]

.....very simply.

 

 

I actually LOL'd. Wondering whether Solus is so bad that it made you genuinely think that is a simple workaround, or whether you are being deliberately understated.

[Cache]

3.9 isn't that bad. Yes it's not great but the Spring Update for SIMS and Discover deployed to the majority of computers in under 2 hours when I did it earlier this week. Those which were offline did start installing almost instantly when the computer booted up/connected tot he network.

 

Yes the agents are still a bit finicky, but the Reinstall agent is in 3.9 and works pretty well. Admittedly I haven't tried it after rebuilding a computer, however i have used it for 4 agents which for some reason refused to start or had altered their config to point to localhost for some reason and immediately started installing the Spring update thereafter.

 

I thought that 3.9 was supposed to prompt if a user launched the software and an update was available, but I haven't been able to see that working but atleast it does close all SIMS windows down now automatically in order to do an upgrade.

 

It's been a long long road since I initially installed Solus3 and while yes it still has a lot of improvements to make to be better (adding new computers I agree is still a huge faff) it now does sit happily and need less investment from me. I still wouldn't trust it to do a SIMS upgrade unattended dues to past experience of one going wrong, but i will schedule Discover and Solus3 upgrades to do out of hours as they are "less critical".

[Boredguy]

I actually LOL'd. Wondering whether Solus is so bad that it made you genuinely think that is a simple workaround, or whether you are being deliberately understated.

No it is actually quite simple to get station to rebuild with the same GUID if you know how then were generated to begin with, where they were stored, and how to replicate it without using the automated agent deployment or their JS file

 

I know how bad S3 is, but it was a step toward progress to making updating SIMS a easier once the agent is on (which is the biggest pain if you do the "official" steps)

We've asked for the best part of a decade for Capita to just give us proper MSI's for deployment but never got far, but at least this is better than having to allow users PowerUser rights just in case a station failed an update.

[Griff]

Post of the year for me, cheers pal. SOLUS3....SLG....TeacherApp.....none of them are up to standard. I am sure some SIMS fanboys will be along soon to defend it all blame the users, blame our servers, blame our networks. God I love Mondays

[SovietRussia]

Never had a "significant or major" problem using SOLUS3 here!

[vikpaw]

…and relax :-D

 

to EduGeek )

 

I'm sure the solution to sorting the agents is Solus⁴

@Boredguy - i'm sure not long ago, we were promised that we could have an MSI, but that guy left so maybe they won't keep his promise. @Griff - i agree, it's a contender for sure, certainly #1 for this forum.

[matt40k]

Connect via RDP to the SIMS server

 

Why don't you install it on your workstation and cut this step out?

 

Capita is praying on the fact schools are tied into this maladroit concoction of ini files and other dated concepts.

 

No, no they are not. If you school doesn't want to use SIMS, then don't use SIMS. The government isn't forcing you to use SIMS. Your LA isn't forcing you to use SIMS. Fact.

 

As for the whole SCCM debate, look at the MS Office vs OpenOffice, you think people will be happy with more MS lock in. Also you have to remember most of Capita's schools are small primary schools, they want something simple and free. If you don't want to use SOLUS3 to install to your desktops, then don't, extract installers and package it, just use it to download the updates and keep your DB upgrade. They aren't forcing you to use it to deploy to your clients. If it still bothers you that much, there are plenty of third parties who do a managed service who would take the support off your hands, Capita even offers hosted SIMS in Azure.

[TomFreeman]

Why don't you install it on your workstation and cut this step out?

 

I didn't know you could do this??

[matt40k]

I didn't know you could do this??

 

Before I was an IT administrator for a school, I worked for a software company that produced server/client applications and was responsible for QA and testing.

 

It's makes me worried about a QA\Tester wouldn't have thought to have tried this! Sorry, bit narked off at the Capita Dev slating, I know a few of them and they're really clever, a few of them are a bit stupid, like the guy who thought the S3 agents need a unique GUID rather then using the computer name - I mean seriously. Still we're all human, we all make mistakes

[TomFreeman]

So how do you run the solus deployment server UI off the server?

[matt40k]

When you install S3 you (well you did when I last did it), ran 3 MSIs, 1 was the UI, you run that on your workstation, point it at the s3 server and bingo*.

 

 

 

* Assuming permissions etc

[TomFreeman]

When you install S3 you (well you did when I last did it), ran 3 MSIs, 1 was the UI, you run that on your workstation, point it at the s3 server and bingo*.

 

 

 

* Assuming permissions etc

Thanks @matt40k be great to get this working.

[tockwell]

It's makes me worried about a QA\Tester wouldn't have thought to have tried this! Sorry, bit narked off at the Capita Dev slating, I know a few of them and they're really clever, a few of them are a bit stupid, like the guy who thought the S3 agents need a unique GUID rather then using the computer name - I mean seriously. Still we're all human, we all make mistakes

 

Excuse me, I didn't say I didn't know how to do that. This is by the bye anyway as connecting to a server remotely is hardly the annoying and relevant step in this process - the focus is the issue of having to remove and re-add computers when they are rebuilt using WDS.

 

Furthermore we don't 'have' to use SIMS, but all our data and training is invested in it, and other systems are integrated into it. So in that respect we are tied into it.

[Boredguy]

the focus is the issue of having to remove and re-add computers when they are rebuilt using WDS.

Yes this is the biggest bugbear of S3, which is why I have a custom VBS script to reuse the GUID so it removes that hassle of removing/re-adding the station in Solus Admin each time.

 

As @matt40k said, it would have been better if the agent used the station name instead of the unique GUID, but we're stuck with that method until S4 is developed at a guess.

[IWDave]

For me it turned out to be IPv6 related, my frustrations where dissolved after that.

 

"There has been considerable movement on this today; it transpires that the workstations are not successfully connecting to the Solus 3 service hosted on our SIMS server because IPv6 is getting in the way. Whilst IPv6 is installed on all our workstations by default, its not configured, our DHCP servers are not dishing out IPv6 addresses either; so we can either disable IPv6 on the workstations or force a hosts file update pointing our SIMS Server name to the SIMS Server IP address, and it appears to be working."

 

SOLUS 3 Agent Nightmare | ICT Dave

 

I'd still prefer to have MSI files for deployment though.

[tockwell]

Sorry, bit narked off at the Capita Dev slating, I know a few of them and they're really clever, a few of them are a bit stupid, like the guy who thought the S3 agents need a unique GUID rather then using the computer name - I mean seriously. Still we're all human, we all make mistakes

 

I'm happy to demonstrate to the programmers why the software is un-usable in a production network.

[SovietRussia]

bit narked off at the Capita Dev slating, I know a few of them and they're really clever, a few of them are a bit stupid, like the guy who thought the S3 agents need a unique GUID rather then using the computer name - I mean seriously. Still we're all human, we all make mistakes

 

As a programmer it could be any sort of reason why, I look back on projects I did a few months ago and think 'why did I do it that way' - at the time it was a good idea!

[matt40k]

I know what you mean @SovietRussia, but I know why they did and I still think it was a bit of broken logic, even when I first found out about it. As for @IWDave comment about IPv6, its an IPv6 ready app, if its enabled but not configured (correctly) it will cause problems, but again, this is a Windows thing, Microsoft has set IPv6 by default, so if you have a dual stack network - ie both IPv4 and IPv6, Windows by default, will send everything over IPv6. @tockwell it's been in production for many years now, I was harping on about more people engaging with it during the beta, back in 2009, when they had more developers assigned to it. It would have resolved a lot of the issues if we had more people engaged from the off. I'm sure @PhilNeal will be happy to pass on your feedback

 

Furthermore we don't 'have' to use SIMS, but all our data and training is invested in it, and other systems are integrated into it. So in that respect we are tied into it.

 

Data can be migrated, training, well it's always evolving so that'll happen even if you stick with SIMS. As for systems that hang off it, I'm prob not the right guy to ask, I'll get pretty much anything working. We're switching out a lot large incumbent legacy systems then SIMS. If you're using SIMS its because its the best for your school, otherwise you'll be looking at switching your MIS

[vikpaw]

You are tied-in with respect to the deployment method, so if you do choose to use SIMS (because there are many many reasons why it is the best thing for a school), they are making S3 the only method of deployment available.

 

It's great that it's free, so good for primaries (assuming someone runs it for them and troubleshoots all the issues), but for the rest, they should at least still allow S2, or provide an MSI as promised. If i'm forced to go down the S3 road, i shall use it only to download the update and then roll it out manually.

 

For your everyday high school tech - how much of an extra palava is it, to get to grips with this new thing. It seems like a lot. That's why i tried the beta, gave some feedback and then opted to sit and wait. I've spent 6 years doing other more useful things

 

I know quite a few people are getting on fine with it, but you won't hear from them, however there are enough disgruntled people here to be significant.

[synaesthesia]

We get on with Solus 3 particularly well. I have voiced opinion previously that the UI is a little counter-intuitive, although it has significantly improved through 3.8 and 3.9. It is certainly a LOT better than the early versions, which were frankly awful.

It tends to just work, and with 3.9 re-installation on machines should be easier.

 

Unfortunately, as I started to type this message I started to run the Spring update for the school and Solus 3 failed! Sods law of course. However our local Capita support team are rather good and personable and have little doubt they'll be able to help (Bad Data when opening Targets). It's the first problem we've had with it in the couple of years we've been deploying with it.

 

I do however agree that an MSI deployment method should be provided as an option, however with the way things are going that is likely to be a moot point.

[matt40k]

You are tied-in with respect to the deployment method, so if you do choose to use SIMS (because there are many many reasons why it is the best thing for a school), they are making S3 the only method of deployment available.

 

If i'm forced to go down the S3 road, i shall use it only to download the update and then roll it out manually.

 

Contradicting yourself a bit there mate - like I said, if you don't want to use S3 to deploy to the clients and you've got something like SCCM, heck, use it, use s3 to just download and keep the db updated etc, if you don't, then use SOLUS3 to do it all. As for MSI, there is a reason why Microsoft created the windows installer cleanup utility. You can't fool me with your green grass

 

PS: I do giggle when I see your sig about your two MIS, greedy person

[IWDave]

Unfortunately, as I started to type this message I started to run the Spring update for the school and Solus 3 failed! Sods law of course.

Funny you should say that; I tried to upgrade to Spring 2015 last week; 3 times it failed via Solus 3, I'm planning on giving it another go this Wednesday.