Webcast: Imaging with FOG, Managing with PDQ
-
@Bob-Henderson said in Webcast: Imaging with FOG, Managing with PDQ:
@george1421 Actually reminded me to renew the domain name on that one before I lost it! God I need to post more updates.
We’re still using FOG and PDQ to image out our 1:1 fleet of computers, as well as having it tied into our server deployments automated via Ansible onto our Proxmox KVM boxes. It’s working fantastically.
The next thing I’m working on (shoot for the moon, right?) is to use FOG to host Snapins and make them accessible outside of the LAN, that’ll then pull down some powershell to grab files via HTTPS from our web cluster to do remote installations if needed. I’ve got a proof of concept working, but I’m a 1 man shop and haven’t had time to do much more on it. But if it works, I’ll effectively be able to push installs both on and offsite, without having to use DirectAccess as the tie back. The powershell has some if’s in there to see if they’re on the LAN, which will then tell it to grab PDQ’s packages, but if they’re off, it’ll grab them from the HTTPS repository and fire off msiexec on them manually.
It’s poor mans SCCM!
An update on this. I got it working, and it worked fantastically. Presents a webpage, user pics what apps they want, and it makes an exe that fires off to tell PDQ to install it.
HOWEVER
In discussions with PDQ, I was told that it’s a violation of the EULA, as each user who is ‘interacting’ with pdq, in this case telling it to fire off, would need to be licensed. It doesn’t apply as much in this instance, so you’re the one firing it off each time in the image, but something to consider if you have multiple techs who do the imaging, etc.
-
@Bob-Henderson Interesting. Probably a good thing each of our techs are licensed for PDQ Deploy then! Good work though.
-
@bmorris Yes no need to change the fog user on the service.
-
@Troye-Johnson Excellent. I will let you know what I find out! Thanks again.
-
For the licensing aspect you can create different power-shell scripts for each of your techs so that you can keep an audit of who ran what when applications are being deployed. This way not only will you stay in compliance with the eula but you also have an audit if something happens.
-
@Troye-Johnson Just had a chance to dig into your script. Very new to fog, so forgive my ignorance. How are you getting the password file and key to the tmp fog service directory on the client? I don’t see a way to copy supporting files in the snapin manager in FOG?
-
@Troye-Johnson I should have checked a littler harder. I found the snapin pack option when creating a snapin. It pays to know how to read.
-
@bmorris is the 13.2 patch official?
-
@bmorris No problem just let me know if you have anymore questions I am happy to help.
-
@x23piracy I actually am not sure. They provided a link to me via email for the update, so my assumption is that it is not. You can always reach out to them and get it. Their support is excellent.
-
@Troye-Johnson Your script with the creds works perfect with the Server/Client setup of PDQ Deploy. Thanks again for the help!
-
@bmorris Happy to help.
-
@x23piracy
The following thing I’m taking a shot at (shoot for the moon, right?) is to utilize FOG to have Snapins and make them available outside of the LAN, that’ll at that point pull down some powershell to get records by means of HTTPS from our web group to do remote establishments if necessary. I have a proof of idea working, yet I’m a 1 man shop and haven’t had sufficient energy to do considerably more on it. In any case, in the event that it works, I’ll viably have the capacity to push introduces both on and offsite, without utilizing DirectAccess as the tie back. The powershell has a few if’s in there to check whether they’re on the LAN, which will then instruct it to snatch PDQ’s bundles, however on the off chance that they’re off, it’ll get them from the HTTPS store and shoot msiexec on them physically.
Dafont 123Movies FileHippo
