SOLUS MSI and GPO Deployment

[nick3young]

Hi All,

 

Has anybody managed to package up the SOLUS agent for network deployment?

 

We have been using the SOLUS server for years to deploy the agent remotely but, with 99% of our other applications being delivered via MSI/GPO, we can sometimes forget to install the agent after building a new computer on to the network. Not to mention there is a direct relationship between how little I have to use SOLUS and my happinesss!

 

There is a way to export the SOLUS agent for manual install... but this creates a batch of files and a javascript file for the install. I could do with it all in a nice, tidy MSI (with perhaps an accompanying MST).

 

Any help would be much appreciated.

 

Cheers

Nick

[bobsmith]

Pretty sure this has been covered before, but isn't there an issue with it not creating a unique id if you deploy it this way?

[nick3young]

Yep - there is another thread on it but from a long time ago. I private messaged the chap who had managed it... but it was so long ago he no longer has the files.

 

It must be possible because it is possible to manually install the agent using the exported files. It should just be a case of automating that process... somehow?!

[nick3young]

I've had a go this morning and the tricky part is building in a key.xml file into the installation. When installing manually, it prompts for it during the installation and you simply specify it's location.

 

The challenge is making this part silent. I feel this is more of a generic questions so I have started a thread about this here.

 

I'll make sure I update this thread with the results...

[Michael]

I totally agree with this, Solus 3 is backwards. Being able to download/deploy the agent via MSI, then the agent grabbing the relevant SIMS/FMS files it needs would make a lot more sense. You could even have separate MSIs for SIMS and FMS, so only the required software is installed.

 

If all applications worked like this, they'd be no point in imaging. To be honest though I highly doubt Capita would do something about this, given that their efforts are no doubt more on SIMS Online and not legacy SIMS.

[matt40k]

Being able to download/deploy the agent via MSI, then the agent grabbing the relevant SIMS/FMS files it needs would make a lot more sense. You could even have separate MSIs for SIMS and FMS, so only the required software is installed.

 

??? That's exactly how it works :S - The Agent is msi, you deploy that via SOLUS UI\SCCM\GPO\manually, then you define what the machine is within SOLUS3 UI then it pushes out the programs\modules\components whatever you want to call them. If it isn't finance machine, it won't get FMS for example. Can't 100% remember how to do it exactly - I know its a lot easier now because Capita fixed it that if the client doesn't have a GUID, it deploys it.

[nick3young]

The Agent is msi, you deploy that via SOLUS UI\SCCM\GPO\manually

 

Do you know how to deploy via GPO Matt? This is exactly what I'm after...

[Michael]

??? That's exactly how it works :S - The Agent is msi, you deploy that via SOLUS UI\SCCM\GPO\manually, then you define what the machine is within SOLUS3 UI then it pushes out the programs\modules\components whatever you want to call them. If it isn't finance machine, it won't get FMS for example. Can't 100% remember how to do it exactly - I know its a lot easier now because Capita fixed it that if the client doesn't have a GUID, it deploys it.

 

Then why do I need Solus 3 to deploy an MSI?

[AliG]

We managed to deploy it with a bat or vbs which is then pushed out with PDQ it took some trial and error from my tech who is a programmer. I'll see if I can dig it out.

[Michael]

I'm still not entirely convinced it's an MSI, otherwise (as I said above) why go to the trouble of creating Solus 3 in the first place?

 

It's just ironic SIMS.net is Windows only, yet Capita (it appears) have neglected the fact you can deploy MSIs using Group Policy. Something that's been around since the Windows 2000 days and has hardly changed.

 

In saying that, the only real benefit of Solus 3 is it obtains MIS updates from higher up the chain automatically; this makes sense (creating a local cache/deployment directory), but the initial deployment mechanism makes no sense and is time consuming.

[Arthur]

I'm still not entirely convinced it's an MSI

It definitely is.

 

 

I can't see why an MST couldn't do what the .bat and .js files do.

Edited December 2, 2016 by Arthur

[sparkeh]

The Agent is msi

Wait what!? Are you sure. Remember the brush offs we got about getting an msi to deploy sims? So it's ok to give us an msi for the agent but not the actual software? Makes no sense.

 

Then why do I need Solus 3 to deploy an MSI?

But you still need to define what machine get what software in the S3 UI. If the above is true then it's only an msi for the agent.

 

S3 is a solution to a nonexistent problem. Give us an msi for the software and a lot of people would be happy. But don't hold your breath as we've been on this ridiculous roundabout before.

[AliG]

We are going to do the initial push out via the solus management console and then use this vbs to pick up machines that are re imaged after the event. We accept no responsibility for this and it may help you come to your own solution. VBS -

 

 

' Q:\SIMS\SOLUS3\Agent Installer\AgentInstaller.vbs

Option Explicit

 

dim strParam

 

const logFileName = "agent_installer.log"

const agentAddress = "net.tcp://localhost:52966"

const dsAddress = "net.tcp://simsservername:52965"

const keyFileName = "\\simsservername\solussharepath"

const msi32 = "SOLUS3AgentInstaller_x86.msi"

const msi64 = "SOLUS3AgentInstaller_x64.msi"

 

dim fso : set fso = WScript.CreateObject("Scripting.FileSystemObject")

dim typeLib : set typeLib = WScript.CreateObject("Scriptlet.TypeLib")

dim wshShell : set wshShell = WScript.CreateObject("WScript.Shell")

 

dim msi : msi = msi32 ' set default to 32 bit machine

 

if is64() then msi = msi64 ' if machine bit type is 64 bit reset the msi field

 

' create the msiexec command in a string, makes debugging easier

strParam = "msiexec.exe /QN /lv* " & fso.BuildPath(wshShell.Environment("SYSTEM")("TEMP"), logFileName) _

& " /i " & chr(34) & wshShell.CurrentDirectory & "" & msi & chr(34) _

& " AGENTSERVICEADDRESS=" & agentAddress _

& " AGENTID=" & GetGuid() _

& " DEPLOYMENTSERVERADDRESS=" & dsAddress _

& " RSAKEYPATH=" & chr(34) & keyFileName & chr(34)

 

wscript.echo strParam

 

' wshShell.Run strParam,0,true ' run the msiexec command, the 0 & true parameters, 0 is hide window, true - means wait for completion

 

wscript.quit(0)

 

'-----------------------------------------------------

Function is64() ' will tell us if 32 or 64 bit

 

dim isInStr ' position of number 64 in string

 

isInStr = inStr(wshShell.Environment("SYSTEM")("PROCESSOR_ARCHITECTURE"),"64")

if isInStr > 0 then is64 = true ' found number 64

 

End Function

 

'-----------------------------------------------------

Function GetGuid()

 

GetGuid = Left(CStr(TypeLib.Guid), 38) ' return the computer guid

 

End Function

[Arthur]

@AliG. There are several lines in your script (22 & 40) that contain extraneous spaces. Use CODE tags to avoid that...

 

' Q:\SIMS\SOLUS3\Agent Installer\AgentInstaller.vbs
Option Explicit

dim strParam 

const logFileName = "agent_installer.log"
const agentAddress = "net.tcp://localhost:52966"
const dsAddress = "net.tcp://simsservername:52965"
const keyFileName = "\\simsservername\solussharepath"
const msi32 = "SOLUS3AgentInstaller_x86.msi"
const msi64 = "SOLUS3AgentInstaller_x64.msi"

dim fso : set fso = WScript.CreateObject("Scripting.FileSystemObject")
dim typeLib : set typeLib = WScript.CreateObject("Scriptlet.TypeLib")
dim wshShell : set wshShell = WScript.CreateObject("WScript.Shell")

dim msi : msi = msi32 ' set default to 32 bit machine

if is64() then msi = msi64 ' if machine bit type is 64 bit reset the msi field

' create the msiexec command in a string, makes debugging easier
strParam = "msiexec.exe /QN /lv* " & fso.BuildPath(wshShell.Environment("SYSTEM")("TEMP"), logFileName) _
			   & " /i " & chr(34) & wshShell.CurrentDirectory & "" & msi & chr(34) _
			   & " AGENTSERVICEADDRESS=" & agentAddress _
			   & " AGENTID=" & GetGuid() _
			   & " DEPLOYMENTSERVERADDRESS=" & dsAddress _
		           & " RSAKEYPATH=" & chr(34) & keyFileName & chr(34)

wscript.echo strParam 

' wshShell.Run strParam,0,true ' run the msiexec command, the 0 & true parameters, 0 is hide window, true - means wait for completion

wscript.quit(0)

'-----------------------------------------------------
Function is64() ' will tell us if 32 or 64 bit

dim isInStr ' position of number 64 in string

isInStr = inStr(wshShell.Environment("SYSTEM")("PROCESSOR_ARCHITECTURE"),"64")
if isInStr > 0 then is64 = true ' found number 64

End Function

'-----------------------------------------------------
Function GetGuid()

GetGuid = Left(CStr(TypeLib.Guid), 38) ' return the computer guid

End Function

Edited December 4, 2016 by Arthur

[free780]

What's in the property table if you open the MSI in instedit?

[Michael]

It definitely is.

 

 

I can't see why an MST couldn't do what the .bat and .js files do.

 

The Agent is an MSI, the actual software isn't; I suspect (pure speculation), that because Solus 3 is comparatively new and the SIMS/FMS software is comparatively old, it's probably the perfect way to bridge the gap, but in reality it takes time to deploy an image and then deploy SIMS/FMS afterwards.

 

As I said above, if all software worked like this, they'd be no point imaging. You'd be just as well to manually join the machine to the domain, but the reality is very different.

[mavhc]

Why they couldn't just put a custom action in the msi to run the script is unknown.

 

Except that Capita just own one programming book: How to write Windows 3.1 software, and they've not finished it yet.

[matt40k]

@AliG @Arthur - code should be in version control - uses GitHub gist - https://gist.github.com/

@Michael - Your missing the point still. The SOLUS3 agent IS the SIMS \ FMS installer, it IS an MSI. Once the SOLUS3 agent is installed, you no longer care how Capita actually put the darn program on, so long as it works. They could have a 7z with a single dll that it copies over the top, it really doesn't matter so long as it works, its like AV definitions. The only reason why the .exe (wise) installer still exists is because some folks still leave in caves and clone machines.

@nick3young - Sorry mate, not touched this for years and years - I'd prob have to spend a day looking for the old call then check it was still up-to-date. It was either a MST (like @Arthur has posted) or a startup script depending on the scenario.

[sparkeh]

@matt40k no I think that @Michael has it exactly right: the agent is not the installer it's exactly as it says it is: an "agent" which downloads the required installers to actually install the software. And you still need the S3 console to get the software on the machine regardless of how you get the agent on it. The agent checks in to see what needs installing and installs it.

 

What was argued for before was an msi to install sims (i.e. Run it and sims is installed, or deploy from sccm or whatever your favourite software deployment solution is). That is very very different.

Edited December 5, 2016 by sparkeh

[matt40k]

Still thinking of that the relic that is SIMSApplicationSetup.exe as the installer. It should be left in the past along with floppy installation discs. SIMS\FMS should be nothing more then modules that get downloaded to the client based on subscription (license). The SIMS client shouldn't be a single package\module either. For starts you should had a core module (a headless version) and a UI module. Why do you need to do a full client install on a server, you might the SIMS core for third party stuff like GroupCall, but you should never run the SIMS client on the server (beyond maybe one-off debugging).

SIMS should be getting updated daily. If you want to waste time updating packages, fine. Personally I'd rather package it once, then effectively, tick the auto-update because there are more interesting things in life then updating SIMS!

Yes, Capita should really have created a MSI, but that technology is now long in the tooth, its 17 years since Microsoft introduce MSI deployments, move on and let it go. You can argue this point until your blue in the face, but the fact is the biggest pain in desktop application development is folks not updating. Its why Apple created the App Store and basically forces app updates on you. It's why the cloud is more popular then web based - because they control the environment so they can auto-update.

[FN-GM]

@matt40k no I think that @Michael has it exactly right: the agent is not the installer it's exactly as it says it is: an "agent" which downloads the required installers to actually install the software. And you still need the S3 console to get the software on the machine regardless of how you get the agent on it. The agent checks in to see what needs installing and installs it.

 

What was argued for before was an msi to install sims (i.e. Run it and sims is installed, or deploy from sccm or whatever your favourite software deployment solution is). That is very very different.

 

The console is just a pain really. Can you imagine if every software vendor had a console to deploy software, imaging machines will take forever!! Before Solus 3 I had had SIMS silent install during the deployment. Now after the imaging I have to fiddle around the with the Solus 3 console. Backwards step IMO.

[Arthur]

What happened to my post with the MST? It's been deleted. Did I do something wrong?

[sparkeh]

Still thinking of that the relic that is SIMSApplicationSetup.exe as the installer.

Of course. Because its the installer

 

It should be left in the past along with floppy installation discs.

Agreed. There's no need to create an .exe installer when there is a well established, thoroughly documented procedure (created by the OS vendor) for providing installation source (msi).

 

SIMS should be getting updated daily.

With the thrice yearly updates being recalled fairly often I would be horrified to learn that sims was being updated daily.

 

If you want to waste time updating packages, fine. Personally I'd rather package it once, then effectively, tick the auto-update because there are more interesting things in life then updating SIMS!

That's the beauty of using msi and a software deployment product. With sccm I could just update the sims package with an updated msi and all the clients would update. This would take less than a minute. I hardly call that a waste of time

Yes, Capita should really have created a MSI, but that technology is now long in the tooth, its 17 years since Microsoft introduce MSI deployments, move on and let it go.

Age is irrelevant. Its the standard way to install software in windows, create by Microsoft. It works, it works really well. And how difficult would it be for a company the size of Capita to create an msi? (though you could argue that the very size of Capita is actually an impediment with cumbersome internal procedures and inertia hindering change).

 

 

You can argue this point until your blue in the face

I have. But dammit this is the Internet, I am right so will continue to argue

 

The console is just a pain really. Can you imagine if every software vendor had a console to deploy software, imaging machines will take forever!! Before Solus 3 I had had SIMS silent install during the deployment. Now after the imaging I have to fiddle around the with the Solus 3 console. Backwards step IMO.

Totally agree. And think of the man hours going into the development work to produce the S3 system when they could have just created an msi. And we still don't have a sensible UI to use!

[mavhc]

What happened to my post with the MST? It's been deleted. Did I do something wrong?

 

Not sure, did you get a PM from anyone? If not post it again.

[matt40k]

I have. But dammit this is the Internet, I am right so will continue to argue

This made my day. I could point out that even Microsoft don't create MSI for alot of their own software, that the WiX installer, aka the preferred way to create MSI installers is actually a open source side project, but you'll get even me ranting about MSI usage. Seriously though, I don't wanna work with software where it takes 4 months to fix a simple mistake. The main reason they have to recall a release is because people can't cope with apply this, then that, then this. Anyway, SaaS for the win