Automating Client Deploy tool

Usage and Config Platform
1

(imported topic written by smill59)

Is there a way to feed the Deploy tool a list and have the deploy tool automatically push the BiGFix client? We are looking for an automated way to ensure that the BigFix client is on every machine in our enironment.

2

(imported comment written by SystemAdmin)

Hi Smill59,

This KB article should address your question: http://support.bigfix.com/cgi-bin/kbdirect.pl?id=148

Cheers!

3

(imported comment written by trickey91)

Tyler,

Iā€™ve tried this method as describe in article 148 and article 368. It seems as though the executable is ignoring the /useComputerNameList switch entirely. When ran with this switch, the Client Deployment application starts at the ā€œFind computersā€ section just as if it was started without the switch. I then tried the command using the /automatic (and other required switches). The Deployment Wizard begins at the ā€œPress start to begin installingā€ window, but there are no computers listed in the Computer Name column.

Any ideas?

Ron

4

(imported comment written by SystemAdmin)

I get the same behavior Trickey, I think you are correct. Iā€™ll check with development and find out if weā€™re missing something or if its just a bug.

5

(imported comment written by SystemAdmin)

It looks like this is a bug, I have verified its fixed in later builds but these arenā€™t publicly available yet. Sorry for the inconvenience and thank you for bringing this to our attention.

6

(imported comment written by trickey91)

Tyler,

Thanks for the update. However, it begs the question. In your opinion, what is the best method for automating the deployment of new clients? My intention was to have a line in the logon batch that has each client write out a file by its computer name to a central point if they donā€™t have BigFix installed. A script would then gather the names of these files into the computerlist.txt, then run the client deployment on the list. I suppose I could put a line in our logon batch having the client run the msi if the install directory isnā€™t found, but is there a better method that wonā€™t slow down user logons?

Ron

7

(imported comment written by SystemAdmin)

Hi Ron,

From experience weā€™ve had the best results with the logon script which checks to see if the BES Client is installed and installs it if not. This method is very effective at deploying and keeping BES Clients installed in production. The best check for this script is to look for the BES Client uninstall registry key.

HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Uninstall\
{BF7023BC-319B-4FE1-B569-C854A19F81F8
}

The script just checks for this key and does nothing if it exists so it should be very fast and not slow down user logon. Even if it needs to install the BES Client that should still be fast.

There are going to be some inherit problems with collecting a install list and running the deployment tool. Mainly, there will be some computers that arenā€™t online at the time you try to run the install process and you may never ā€˜catchā€™ them to do the install. Secondly, the remote deployment is less reliable then the logon script, you should check the automated script regularly to see if there are some computers that its always failing on and troubleshoot them. The logon script doesnā€™t have as many ways to fail so it tends to do better.

Its possible to script the same process that the deployment tool is using directly as well. The deployment tool is basically just fancy ui on top of a simple RPC script. I could dig up an example if you want to go down that route.

8

(imported comment written by trickey91)

Tyler,

After speaking with Weylan, I linked a batch file (that does exactly what you suggested) to a GPO (User/logon). This works great.

Thanks for your help.

Ron

9

Hi Ron,
can you share please the whole content of your script?

Thanks.

10

Holy necrothreading, batman. You might want to check the date of the last reply, @davincecode, seeing as how itā€™s been 11 years since this was imported from the old forumsā€¦

Youā€™re probably better off asking a new question that is specific to your scenario; chances are the tool may not even work like it did a decade ago, or the tool may have new features that accomplished what you want to do. Either way, Iā€™d really recommend starting a new thread.

2 Likes