Software Deployment

ORIGINAL: VBScab

Hmmm...a product which requires script to get the most out of it...why not just build a VBS/HTA (HTA to get some user interface goodies)?!? Is it me? It must be me...



Sorry to play the Devil's Advocate card so strongly but I'm struggling to see what features I'd get for the money that I couldn't already build fairly easily.



I'll bite, I used bigfix for about a year for a mid-sized client (2200 machines) and got to be pretty familiar with the relevance and actionscript languages, as well as some of BigFix's capabilities and limitations.

"Relevance" itself as a language may have questionable value, and you're absolutely right that VBscript can do everything that it can do in a complete sense. However, especially as relates information gathering for deployment, Relevance is a hell of a lot easier to learn and use. That said, let's go through the list!



Bigfix will deploy a package and install it with whatever command line flags you specify. And you can wrap this into a script with actions to be executed before your package installation, and after.
Like a VBS would.


Bigfix's wrapper and deploy technology is much more involved than you could reasonably expect from a VBS. With a relatively short time investment, Bigfix will:
Copy your package out to all deploy points (called Relays in Bigfix parlance)
Have clients intelligently select which source to use based on network distance
Use any sort of criteria to determine whether to deploy or not deploy
Be available to all clients on your network within minutes.


Instead it excels at targeting your application to your machines. It is very strong in detecting all sorts of characteristics of your machines, so if you have detailed requirements that must be met before you have your app deployed, bigfix is great
Like a VBS would.


The trick with Bigfix is that the detection happens before any payload is delivered. In a more traditional system using scripts, you would generally deliver the content, then run your detection routine. In this regard Bigfix is pretty effective at managing network traffic.


It can pull data out of the filesystem, registry, WMI, etc.
Like a VBS would.


These things are common to all scripting languages, Relevance does have some handy classes that are very simple to use and provide very easy access to add/remove programs, adapter information, etc...


It has strong scheduling capabilities
D'oh! You got me there. Never mind, I'll use WinCron or similar.


Scheduling that can be manipulated on the fly for your entire organization with near-instant response times is value that you just don't really understand until you've had a chance to use it. Again, the ease of the interface and the sheer speed it has is the difference.


some pretty smart wake-on-lan features,
Mmmmm...WMI calls in a VBS?


No offense, but I wouldn't want to be the dude tasked with replicating BigFix's WOL with some vbscripts. WOL from bigfix does not rely on broadcasting, and instead uses live clients (as reported in bigfix, realtime data go!) as wakeup points on a per-subnet basis. It will target individual clients or all clients on the subnet (by IP or by computer name) and use as many currently live machines as you specify. There are plenty of back-end configuration options to streamline the process even further and allow for some nifty power management, but this all works out of the box.

Again, all of this happens ridiculously quickly, I can have all 2200 machines online on a weekend in less than 15 minutes, with basically nothing configured.



ability to reboot or shutdown machines after installation, the ability to only install when a particular user is logged in, or only when no user is logged in. There are other criteria too.
Like a VBS would.


This is pretty standard for deployment apps, it would be more notable if this functionality were missing.


Many of them are easily accessible through a reasonable GUI console,
One could build a brilliant GUI - to one's own design - in an HTA.


The console is well laid out, and allows nearly instant access to any property you can code or imagine. Sure you could design a new deployment interface with HTA, but this one is actually pretty decent, unlike the complete clusterfuck you see with say... the SMS console.


and you can script even more.
You mean, like a VBS?


For the most part you can leverage VBS in bigfix instead of using Relevance. The real advantage with Relevance is that it's run on a very fast, very responsive engine, and gives you direct output to the console for real-time data gathering. If I have a query I want data for on my entire enterprise right away, I can write up some data gathering code, hit send, and have my results for every online machine in a sweet report in a retardedly short timespan. This was especially effective with a virus outbreak I had dealt with a year ago, it was insanely easy to identify infected machine, and run a custom IPSec policy on them through Bigfix (provided by Bigfix,) which still allows bigfix to issue commands, but essentially neuters the computer otherwise.



Also, the biggest advantage Bigfix has is all of the pregenerated content. Bigfix writes loads and loads of relevance and actionscript, and makes it available to their customers through feeds, so all the latest stuff is available at all times and can be run on your environment. It's really pretty slick, but if the backend support didn't exist, it would be a much more mediocre product.

EDIT: Oh, and the real reason Bigfix is worthwhile: www.pimpmybes.com

Hi,

We have an application which used the big fix client to update some information on a application. We don't use it directly but there is a lot of problem with the application which use it. Moreover, each time that you start the application, there is a lot of request which are sent to the editor in order to check if there is available update.

I still have some doubt about this software, but I cannot help you about distributing packages throught this solution, sorry

Regards,

Bigfix is an amazing program once you get used to its own langage. I used it at Freeport-McMoRan and Intel also uses it. It was a bit expensive but had amazing response times in a large environment. Still prefer it over SMS and SCCM.

Well there are two conflicting posts - not that I pretend to really understand the first one!

Weird to get 200 hits but only 10 votes [:'(] I'll assume that 190 of the non-voters never heard of it...

I have spent some time using BigFix under an evaluation plan. Not purchased yet mainly due to machinations of the bureaucracy of my large organization. I have worked on power and patch management features. I haven't used it for application deployment but since you have few responses, I 'll chime in a bit on what I've seen for those capabilities.

IMO, bigfix is a great deployment system IF you are very comfortable with the commandline and scripting. Bigfix will deploy a package and install it with whatever command line flags you specify. And you can wrap this into a script with actions to be executed before your package installation, and after.

BigFix won't help you at all with any packaging or repackaging. It just doesn't have any features there. It doesn't go out of its way to give you a GUI to help you deploy a non-packaged application.

Instead it excels at targeting your application to your machines. It is very strong in detecting all sorts of characteristics of your machines, so if you have detailed requirements that must be met before you have your app deployed, bigfix is great. It can pull data out of the filesystem, registry, WMI, etc. That allows it to detect interesting cases like when your application has been installed, but a critical dll overwritten to a different version by some other app. And you can have bigfix take a specific action in that case. It has strong scheduling capabilities, some pretty smart wake-on-lan features, ability to reboot or shutdown machines after installation, the ability to only install when a particular user is logged in, or only when no user is logged in. There are other criteria too. Many of them are easily accessible through a reasonable GUI console, and you can script even more.

Thanks for your comments Phil.

It certainly is a flexible product as long - as you said - that you are happy with the language and the conecpt of relevance (which loosly relates to SMS collection criteria). A couple of drawbacks I see in using this is as a package delivery tool are;

1) You need to compress the installation source which BigFix delivers to the client, before uncompressing and executing the installation command line. This means that the source files need to be left on the client workstation in case of repair etc - effectively doubling the footprint for each package. There are potentially ways around this (to get the installation to be called from a central source repository) none of which seem to be supported by the vendor.

2) Delivery of package pre-requisites needs careful consideration. Say an application has 3 pre-reqs, do you combine all 4 packages into 1 job or split them... If you deceide to split (which I'd prefer) and the installation order is vital - for example one app may require a specific version of .NET Framework to install - how do you manage the installation order? It guess it's relevance again but I see a bit of a management headache with this.

The product itself is designed and marketed as a patching solition but there is scope to do more with it... weather you should or not is another issue. I'm not sold on it as a deployment tool yet but if that's what the company wants then I guess we have to embrace the horrible interface and 80's style language [:@]

Cheers,
Rob.

Hmmm...a product which requires script to get the most out of it...why not just build a VBS/HTA (HTA to get some user interface goodies)?!? Is it me? It must be me...

Bigfix will deploy a package and install it with whatever command line flags you specify. And you can wrap this into a script with actions to be executed before your package installation, and after.
Like a VBS would.

Instead it excels at targeting your application to your machines. It is very strong in detecting all sorts of characteristics of your machines, so if you have detailed requirements that must be met before you have your app deployed, bigfix is great
Like a VBS would.

It can pull data out of the filesystem, registry, WMI, etc.
Like a VBS would.

It has strong scheduling capabilities
D'oh! You got me there. Never mind, I'll use WinCron or similar.

some pretty smart wake-on-lan features,
Mmmmm...WMI calls in a VBS?

ability to reboot or shutdown machines after installation, the ability to only install when a particular user is logged in, or only when no user is logged in. There are other criteria too.
Like a VBS would.

Many of them are easily accessible through a reasonable GUI console,
One could build a brilliant GUI - to one's own design - in an HTA.

and you can script even more.
You mean, like a VBS?

Sorry to play the Devil's Advocate card so strongly but I'm struggling to see what features I'd get for the money that I couldn't already build fairly easily.

can you please tell me the relevance code for finding the location of different relays based on subnet.

Sounds like you are wasted on packaging Ian.. why not knock up the product, undercut BigFix, present and sell it to Intel and the world is your oyster...

Nah...not so keen on shellfish...

Hi,

I recently started using BigFix. Can anyone please tell me a way to upload exe to the BigFix server other than using Software Distribution Wizard and manual copy, preferably through Action Script ?

ORIGINAL: MSIPackager

Thanks for your comments Phil.

It certainly is a flexible product as long - as you said - that you are happy with the language and the conecpt of relevance (which loosly relates to SMS collection criteria).  A couple of drawbacks I see in using this is as a package delivery tool are;

1) You need to compress the installation source which BigFix delivers to the client, before uncompressing and executing the installation command line.  This means that the source files need to be left on the client workstation in case of repair etc - effectively doubling the footprint for each package.  There are potentially ways around this (to get the installation to be called from a central source repository) none of which seem to be supported by the vendor.

2) Delivery of package pre-requisites needs careful consideration.  Say an application has 3 pre-reqs, do you combine all 4 packages into 1 job or split them... If you deceide to split (which I'd prefer) and the installation order is vital - for example one app may require a specific version of .NET Framework to install - how do you manage the installation order?  It guess it's relevance again but I see a bit of a management headache with this.

The product itself is designed and marketed as a patching solition but there is scope to do more with it... weather you should or not is another issue.  I'm not sold on it as a deployment tool yet but if that's what the company wants then I guess we have to embrace the horrible interface and 80's style language [:@]

Cheers,
Rob.


Rob,

For your 1) even though bigfix itself does not provide any source resiliency (installations will be unaware of other Relays to get data from) you can still implement your own with either a DFS (for a multisite enterprise) or just a single alternate server, and leveraging the SOURCELIST property to register all of your alternate network source locations.

For 2) Relevance to determine installed program status is actually ridiculously easy to incorporate into a deployment. You might try:

If (Exists regapp "Yourapp.exe") then True

Yes - I use it but not for package deployment
Yes - I use it for package deployment
No - I've never heard of it

None of the above. Never used it but have heard of it. salesforce.com uses it. If you want a job with them in app deployment, learn it!

Rob,

For your 1) even though bigfix itself does not provide any source resiliency (installations will be unaware of other Relays to get data from) you can still implement your own with either a DFS (for a multisite enterprise) or just a single alternate server, and leveraging the SOURCELIST property to register all of your alternate network source locations.

For 2) Relevance to determine installed program status is actually ridiculously easy to incorporate into a deployment. You might try:

If (Exists regapp "Yourapp.exe") then True

Thanks for the comments Jsaylor - I appreciate that there are ways around the shortcomings as far as a deployment tool, fortunately for me though I hear that my client is dropping the product next year and going with SCCM - so hopfully I'll never have to see the horrid interface again... unless I end up at salesforce.com ;-)