How to install new FOG Client to a Windows Computer in a workgroup
-
The right answer is what Wayne posted. But if you can’t recapture it then this method will work.
Since I don’t use snapins (not reason, I just used this method before fog and still do). If you have a known local admin account you can use the free version of PDQ Deploy. Just create a pdq deploy package with the FOG Client MSI. You will need to add the command line parameters to point to your FOG server. Once PDQ Deploy is setup you can create a package in less than 5 minutes (once you have done it one time).
-
PS Exec from the “PsTools Suite” might do the trick, but it still requires that the technician knows the name of the destination computer; after it has been Quick Imaged. Kinda defeats the remote idea.
I have 80+ sites with 18 physical and a half dozen mobile virtual FOG servers. My images are hardware universal and are used at every site. They are created by role, not by site.
Each server of course has their own SSL/CA which means I cannot pre-install the new FOG Client into the image, it must be installed after sysprep and pointed to the correct server. Identifying which subnet and subsequently which server the client should be tied to requires a fixed script. If the subnets change… the script in the image must change to follow it. Not a longterm solution.
-
@sudburr Just loop through all names. You have them in fog, you can export them.
-
There is no record of the machine in FOG. It has never seen FOG. Virgin …
-
@sudburr They weren’t registered?
Use your DHCP list then. Export it and blast the client to all.
-
My experience tells me that the more external steps involved the less likely it to succeed when it must be performed by Level 1 field techs. Even when it was Ghost Suite that was being used, the interface can be overwhelming to some for even that seemingly simple function.
I’m looking for an exceedingly simple or push-button solution.
-
@sudburr This is still not out of the realm of possibilities.
With pdq deploy you can deploy applications based on AD-OU (which you don’t have), as well as some other items, and then a text list. If you have a list of systems you can drop them into a pdq deploy package. So that is how to get things scheduled for deployment.
my MDT package that installs the FOG client looks like this:
start /wait msiexec.exe /i FOGService.msi /quiet USETRAY="0" WEBADDRESS="192.168.1.88" net stop "FogService" sc config "FogService" start= disabledThe fog client is a fog client until it first connects to the FOG server to get its certificate. So you can have just one MSI.
The missing part is to select which fog server the client needs to connect to. This can be done with a vb script that would pickup the target computers IP address and then match that address to a table in a csv text file to locate the proper fog server for the target’s subnet.
This part sounds harder than it really is. The csv file might look something like this
192.168.1, 192.168.1.88
192.168.2,192.168.2.33
192.168.10,192.168.10.101and so on. So this part will tell the fog client what fog server to connect to. You can deploy with pdq deploy (suggested) or even psexec. Now all you need is the finishing to make it work.
-
@george1421 Domain work is a no-brainer. It’s the workgroup solution that I’m trying to simplify.
I wish my scope comparison was that simple. My current end-of-sysprep solution determines the correct server for the legacy client in our current 80+ subnets with two dozen servers. One subnet’s server just changed which broke the script for that site.
But pucker up. We’re planning out 500 new scopes …
-
@sudburr I’d suggest you get the fog client on all your images. It’s difficult to do anything to computers with no control over them besides knowing local credentials.
-
You may start looking into Ansible, version 1.7 or greater comes with ability to control windows clients.
http://docs.ansible.com/ansible/intro_windows.htmlAnd ansible is free (I think), but Ansible Tower costs.
