Webcast: Imaging with FOG, Managing with PDQ
-
@x23piracy said in Webcast: Imaging with FOG, Managing with PDQ:
Sounds great how do you guys want to manage fog images in a better way as it is? Little details please?
FYI i am a paying PDQ Deploy Customer Lovely tool.What i found so far:
http://bobhenderson.org/fog-zero-touch-imaging-with-pdq-deploy/
http://bobhenderson.org/pdq-deploy-fog-imaging-happiness-take-2/Regards X23
Mod edited
ha, holy crap, thatâs me!
-
@Bob-Henderson == Now famous.
-
@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!
-
@Troye-Johnson Did you ever get an answer to your question? I am running into the exact same problem. Since the service runs as SYSTEM, it doesnât have permissions to even remote powershell to our PDQ server.
-
@bmorris Yes I we created a domain user added that users under the âpdq deploy> Preferences>Credentialsâ to allow it access to deploy apps and then added those credentials into the PDQdeploy script by powershell. Here is my script I encrypted the password for best practices.
<# .SYNOPSIS Start a PDQ Deploy Deployment on a target machine .DESCRIPTION Trigger a PDQ Deploy deployment to start locally or on a remote machine with PDQ Deploy installed .EXAMPLE Start-Deployment -PackageName "Example Package" -Targets "Wolverine" .EXAMPLE Start-Deployment -ScheduleName "Example Schedule" -Targets "Wolverine" .EXAMPLE Start-Deployment -ScheduleID 123 -Targets "Wolverine" .PARAMETER DeployComputerName The machine with PDQ Deploy installed. This defaults to the local machine .PARAMETER PackageName The names of packages on DeployMachine that you wish to use .PARAMETER ScheduleName The names of schedules on DeployMachine that you wish to use .PARAMETER ScheduleID The schedule IDs on DeployMachine that you wish to use .PARAMETER Targets A list of targets that you wish to deploy a package or schedule to. Leave blank if you wish to target the local machine. #> [cmdletbinding( SupportsShouldProcess = $True )] Param( [String]$DeployComputerName = $env:COMPUTERNAME, [Parameter(ParameterSetName = "Package")] [string]$PackageName, [Parameter(ParameterSetName = "Package")] [String[]]$Targets = $env:COMPUTERNAME, [Parameter(ParameterSetName = "Schedule")] [string]$ScheduleName, [Parameter(ParameterSetName = "ScheduleID")] [Int]$ScheduleID ) Process { # Add parameters to a hashtable to easily push into invoke-command as an argument $MyParameters = @{ DeployComputerName = $DeployComputerName PackageName = $PackageName Targets = $Targets ScheduleName = $ScheduleName ScheduleID = $ScheduleID DeploymentType = $PSCmdlet.ParameterSetName } #OS Check $PSScriptRoot = Split-Path -Parent -Path $MyInvocation.MyCommand.Definition #Credentials $User = "domain\user" $PasswordFile = "$PSScriptRoot\Password.txt" $KeyFile = "$PSScriptRoot\AES.key" $key = Get-Content $KeyFile $MyCredential = New-Object -TypeName System.Management.Automation.PSCredential ` -ArgumentList $User, (Get-Content $PasswordFile | ConvertTo-SecureString -Key $key) # This outputs a powershell.log to the root directory of the target machine $MyParameters | Out-String | Out-File C:\powershell.log # Testing to see if PSRemoting is enabled If (Test-WSMan -ComputerName $DeployComputerName) { Write-Verbose "Test-WSMan test passed on $DeployComputerName" # Added -Whatif capability to script If ( $PSCmdlet.ShouldProcess($DeployComputerName, "Starting deployment with the following parameters:`n $($MyParameters | Out-String)") ) { # Connect to Deploy machine and attempts to start a deployment Invoke-Command -ComputerName $DeployComputerName -credential $MyCredential -ArgumentList ($MyParameters) -ScriptBlock { Param ($MyParameters) # This outputs a powershell.log to the root directory of the deploy machine $MyParameters | Out-String | Out-File C:\powershell.log # Build command string based on deployment type Switch ($MyParameters.DeploymentType) { "Package" { $PDQDeployCommand = "pdqdeploy deploy -package ""$($MyParameters.PackageName)"" -targets $($MyParameters.Targets)" } "Schedule" { $DB = "$env:ProgramData\Admin Arsenal\PDQ Deploy\Database.db" $SQL = "SELECT ScheduleID FROM Schedules WHERE Name = '$($MyParameters.ScheduleName)' COLLATE NOCASE;" $ScheduleID = $SQL | sqlite3.exe $db $PDQDeployCommand = "pdqdeploy StartSchedule -ScheduleId $ScheduleID" } "ScheduleID" { $PDQDeployCommand = "pdqdeploy StartSchedule -ScheduleId $($MyParameters.ScheduleID)" } } # Append the actual command that will be run to powershell.log "Invoke-command: $PDQDeployCommand" | Out-File C:\powershell.log -Append # Create and invoke scriptblock $PDQDeployCommand = [ScriptBlock]::Create($PDQDeployCommand) $PDQDeployCommand.Invoke() } } } }
Im not sure if it works with server mode of PDQ deploy that was just released yet though I have not tested it. If you get a chance to please let me know.
-
@Troye-Johnson Thank you very much for this. I will report back if this works for server mode of PDQ Deploy.
-
@bmorris Please remember to add this registry setting based on PDQ recommendations
Additionally, youâll need to add an entry into the registry on the PDQ Deploy machine in order to tell the background service to use TCP/IP:
Location: HKLM\Software\Admin Arsenal\PDQ Deploy\
Type: DWORD Name: ServicePort Value: <port number>The value needs to be a port number that is allowed within your network.
or find it here https://www.adminarsenal.com/webcast-bonus-content/
-
@Troye-Johnson I forgot to ask, which I am sure I will find out anyway through testing, but is your FOG Service running as the default SYSTEM account on the client using this script? Since you are specifying creds in the script, this doesnât matter now, I assume.
-
@Troye-Johnson Thanks for this. PDQ actually provided me with an update that fixes this issue on v13. No need for the registry setting change. The update put us on v13.2.0.0.
-
@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!