Whether you’re involved with a company that just decided to open a new remote location or an MSP responsible for patching your clients’ machines, this post is a must-read.
Helpful cmdlets:
DFS may be an option, but why open another RDP window when you can quickly reconfigure your client installation, create a report, approve the auto-download and move on to the next thing on your ever-growing kanban board.
Whatever your reasons may be for having acquired, multiple PDQ server instances, here are a couple of different options to help manage them.
Understanding which credentials need modified
Before we go off into the weeds too far, it’s imperative that we understand which credentials we need to modify/call to get this to work seamlessly. If you haven't familiarize yourself with this KB, it's probably best you do so:
For the sake of simplicity and demonstration, the scripts below use Get-Credential when invoking different console users. In the wild, you might want to use encrypted credential objects. Check out the links to create those below:
Your installed clients store their server, and TCP port information in the registry, so with a quick click of the heels we’ll be back in Kansas, or at least not in the server we were just last configuring.
This is the place in the registry we’ll be poking around:
“HKLM:\SOFTWARE\Admin Arsenal\PDQ Deploy\Protocol"Within that path we’ll be messing with at least one, maybe two keys. The first, “ServerHostName'' the second “ServerPort” they do just what they say they do, no magic tricks here.
What to do if your console user is the same on multiple servers
With that, let’s get into it. Here is all you need to do if your console user is the same on the multiple servers
Set-ItemProperty -Path "HKLM:\SOFTWARE\Admin Arsenal\PDQ Deploy\Protocol" -Name "ServerHostName" -Value "ServerToConnectTo"
& PDQDeployConsole.exe
Set-ItemProperty -Path "HKLM:\SOFTWARE\Admin Arsenal\PDQ Inventory\Protocol" -Name "ServerHostName" -Value "ServerToConnectTo"
& PDQInventoryConsole.exe
If we need to run as a different user, we can, it just takes some finagling and run as magic. The context in which the client console is running needs to match the console users list on the server you are connecting to. If an account attempts to connect to the server without existing as a console user, you will be prompted to enter the password for the background service user. If you enter the password correctly the account that is running the client process will be added as a console user.
#Don’t really use “Get-Credential” go look at the links above.
$Creds = Get-Credential
Set-ItemProperty -Path "HKLM:\SOFTWARE\Admin Arsenal\PDQ Deploy\Protocol" -Name "ServerHostName" -Value "ServerToConnectTo"
Start-Process powershell -Credential $creds -ArgumentList '-noprofile -command &{Start-Process pdqdeployconsole.exe -verb runas}'
Set-ItemProperty -Path "HKLM:\SOFTWARE\Admin Arsenal\PDQ Inventory\Protocol" -Name "ServerHostName" -Value "ServerToConnectTo"
Start-Process powershell -Credential $creds -ArgumentList '-noprofile -command &{Start-Process pdqinventoryconsole.exe -verb runas}'
If changing your client install to point to other servers isn't your cup of tea I get it. I love my remote desktop connection manager too. There are still some neat things you can do between servers if you can copy/paste. Grab a collection on one server, copy, then paste it on another Inventory server. Tada! This works for almost every item you can copy within both Deploy and Inventory. Go ahead, grab that command step out of the package and paste it to another package.
A word of caution
Some items can be copied that reference items by database ID. A few things that come to mind: schedules, scan steps using unique scan profiles, collections using “member of collection.” When these are pasted / imported into another installation they will reference the local ID number, this could be a completely different collection / scanner, than you were expecting.
For anyone who wants to take it one step further why not invoke all your PDQ tasks from a small Windows forms application in PowerShell? This assumes you have remote PowerShell enabled on your servers.
[System.Reflection.Assembly]::LoadWithPartialName('Microsoft.VisualBasic') | Out-Null
$target = [Microsoft.VisualBasic.Interaction]::InputBox("Enter your target", "target", "target")
[System.Reflection.Assembly]::LoadWithPartialName('Microsoft.VisualBasic') | Out-Null
$package = [Microsoft.VisualBasic.Interaction]::InputBox("Enter your package name", "package", "package")
[System.Reflection.Assembly]::LoadWithPartialName('Microsoft.VisualBasic') | Out-Null
$pdqserver = [Microsoft.VisualBasic.Interaction]::InputBox("pdq server name", "pdqservername", "pdqservername")
$creds = Get-Credential
Invoke-Command -ComputerName $pdqserver -Credential $creds -ScriptBlock{
pdqdeploy.exe deploy -package "$($Using:package)" -targets $($Using:target)
}Whether you're bouncing around your many client sites or juggling a few consoles off at remote sites, the above examples (along with following server patching best practices) should make your life a little bit easier. Always remember to practice safe hacking in the registry, take a backup just in case something goes belly-up. And don't leave your credentials to chance; no matter if you're a Level 13 PowerShell Mage or you only deal in experimental and introductory spells, encrypting your credential objects is a must. ow, that you've got a little extra time on your hands, you can get around to working on those April Fools Day pranks for your coworkers; or you know that Kanban board that's still begging for your attention.
