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.
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.
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:
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.
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
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.
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.
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.
Whether you're bouncing around your many client sites or juggling a few consoles off at remote sites, the above examples 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.
Ever since becoming the Solutions Manager at PDQ, Josh has other people do work for him, including writing this bio. We're pretty sure he eats food, has ~10+ years of IT experience, and would be quite content to never see another Intel IMS ever again. Josh is proud he maintains his CompTIA A+ certification.