Finally! Connect multiple PDQ Deploy 13+ consoles to a Central PDQ Server

Uncategorized

So let it be written, so let it be done.” All due respect to the fellow bald-headed Yul Brynner, but I wish the writers of The Ten Commandments would have had someone (Charlton, perhaps?) retort, “Hey, Russian Ramses, that’s easier said than done”. Many of you have, most assuredly, noticed that PDQ Deploy version 12 is a little long in the tooth. It was released on December 7th, 2016. That date is, of course, infamous for being Tom Waits’ 67th birthday.

Anyway, the long wait is over as we have finally completed one of the most requested features for PDQ Deploy: A centralized server in PDQ Deploy 13. To update your console, click the “A new version is available” notice in the status bar of your console. If the update link is not visible, go to File > Preferences > Alerts to enable update notices.

TL;DR – Enterprise customers with multiple licenses can now connect multiple PDQ Deploy consoles concurrently (based on the number of licenses held) to a single “PDQ Deploy server” and thus centrally maintain packages, deployment history, schedules, etc. The Central Server is not required and is an optional feature.

PDQ Deploy was built to be a standalone deployment solution. The console and server resided on the same computer. While this is still the default way to run Deploy (in fact it is probable that most of our customers will continue running PDQ Deploy in this fashion) the fact remains that quite a few of our customers wanted something a little more centralized to accommodate multiple administrators. Enter Central Server.

Central Server Modes

Central Server isn’t a component, instead it’s a mode of operation. It works in one of three modes. A computer can only be in one mode at a time and all components installed on that computer (console, CLI, and background service) operate in that same mode. The modes are as follow:

Local Mode

This is the only mode available for Free and Pro users and is the default mode that PDQ Deploy has used since the beginning. It’s the mode the application is in when the Central Server is disabled; we include it in Central Server because it indicates that Central Server is “OFF”. In this mode, only the console and the CLI on the same computer can attach to the background service. The console also maintains its own repository.

Server Mode

In this mode, a computer (possibly running a Windows Server OS) is acting as a server for other computers in Client Mode. This means that the console and CLI on other computers can connect to the server and access its background service and repository. The console and the CLI on the Server computer work the same as if the computer is in Local Mode. The server computer will host the central PDQ Deploy repository and facilitate all the deployments.

Client Mode

In this mode, a computer is acting as a client and connects to another computer in Server Mode. The background service on the client computer is not running and the console and CLI connect to the background service on the computer in Server Mode and use its repository. A computer can only be connected to one background service at a time. This is a computer-wide setting so it applies to all of the consoles and CLI running on the client computer. All packages, schedules, and most other tasks are housed on the server and can be seen and used by other client computers.

FAQ

I will present some facts about this new feature in the form of anticipated questions.

  • Is this feature available in Free or Pro mode?
    No, this feature is only available in Enterprise mode.
  • I have one license of Enterprise mode. Will I be able to use this feature?
    Yes. With one license you can have one concurrent connection to the server. What you won’t be able to do (with only one license) is run concurrent consoles on another computer.
  • My company has 25 licenses. Are you saying that if I am connected via a client console to the server that I can see other deployments and activity from other administrators and that they, in turn, can see my deployments?
    Yes, that is exactly what I am saying.
  • How can I control which console users connect to my central server?
    Through the Console Users option on the toolbar. In order to add a new console user you must enter the password for the account running the “background service”. Any user that isn’t either the background service user or an approved console user will not be able to connect to the central PDQ Deploy server.
  • Niccccceeeee. Is a similar central server feature available for PDQ Inventory?
    Not yet. This similar feature is expected in version 13 of PDQ Inventory.
  • My organization has 4 administrators each with their own PDQ Deploy installation. How do we migrate to this central server thingy?
    Let me refer you to this article which details how you migrate existing installations and packages to a central server.  When you designate a computer to run in Server Mode the schedules, packages and other settings on that computer are retained. When you move a computer into Client Mode any existing packages on that computer will not automatically be moved to the central server.
  • How does this affect the Sharing feature in PDQ Deploy?
    This replaces Sharing.

A short video tutorial is on the way. In the meantime, enjoy our PDQ Deploy beta webcast.



17 Comments

  • Hello,
    While my day job as a system admin at a large accounting firm I see/use SCCM (and see all it’s failings/complexity). As a volunteer IT tech, the Pregnancy Care Center of Springfield, MO at I use both PDQ Inventory & Deploy’s enterprise product with increasing ease… & great new functionality (keep up the good work!)

    Both products have truly has helped us to reduce the amount of administration & inventory it takes to manage even a small environment (~30 systems).

    I do want to bring up an issue that seems to plague us (and I’m sure others); we have a few mobile laptop users who don’t often come into the office or leave their laptops home for over a week etc… Given that these machines are domain joined and that the users aren’t local admins (yes, I managed to implement that many years ago for security reasons) leaves them vulnerable to being out of date of various products… (Hey, it’s not like the NSA can use Notepad++ to do anything… oh, wait… can they?)

    So the question is this: if there is a safe & secure way to update these roaming laptops?
    Suppose there is a scheduled task (no, not an agent, but something simpler) that connects to an open port, authenticates and downloads updates to execute in order… The source of these downloads could be the same system where PDQ deploy is installed… or hosted on a public site in an encrypted format.

    Idea 1: – the Remote client runs a scheduled task/app and connects to a port on the PDQ deploy server, authenticates and then the workstation establishes a connection to the server (TLS encryption would be required but assume that this can be provided using self signed certs that can be made to be trusted via GPOs). Download the patches and executes with whatever set of commands are around it (stored in an encrypted XML file)… .asyncroniously at specific intervals…
    This would require keeping an open incoming port on the local firewall so this would pose some complexity to this option.

    Idea 2. The PDQ server uploads the updates and any commands around it (XML format) to a secure repository accessible either via FTPS or HTTPS.
    Roaming clients would connect to this pre-configured site, authenticate, and securely download the encrypted packages and any command steps around it then execute it and return the results to the site.

    I’m trying to avoid having to create VPN connections from each roaming client, or to have to open a firewall port. In either case an “agent” solution or a complex script is the only option I could think of to make this possible – not exactly the best option for PDQ Deploy?

    Just some ideas and thoughts.

  • Nice!
    Always a challenge when you’re a remote worker, and need to RDP in just to do these tasks…. no more! Many hopes that PDQ inventory will do the same, it was my biggest challenge of the two.

    • Jeremy,

      Glad to hear that this new feature has saved time, that’s definitely our aim to make your lives easier!

      Your wish is our command, PDQ Inventory is next to get the red carpet treatment. If you want to be a beta participant, make sure you go to Preferences > Alerts and check ‘Include Beta Versions’. You’ll be notified in the product when the beta becomes available.

      Emily

  • Question really: I am a one man shop, running Enterprise Deploy and Inventory on essentially it’s own server and RDP to console and work that way. I am curious if there is any advantage for me to run it as Central Server, as I am the only one using it? And is there any long-term disadvantage by not moving towards Central Server model?

    • The advantage would be that you don’t have to RDP to your server just to use PDQ. You will have 2 separate installations of PDQ to maintain though (the Client and Server have to be running the same version). Central Server will always be optional. You will not be at any disadvantage by staying in Local mode.

  • Could you spend some time on how PDQ handles package replication? Is PDQ Central Server location aware? Meaning if we set up Central Server in NY and connect via ‘client’ in our LA office, is PDQ aware to not pull the package from NY for that deployment? Or do you offload that responsibility to other replication technologies like DFS? Sorry if my question doesn’t make sense, I’m curious about long install times and latency concerns.

      • Just to be clear, DFS is not a requirement for Central Server. We do not have any built-in replication, so if you have multiple sites we recommend replicating your Repository with DFS.

    • Jeremy,

      Central Server has no built-in package replication; wherever the Central Server is installed is where the database/repository is housed and all packages, schedules, targets lists, etc. are stored there. The Client computer’s background service is not running, so all processes are done using the Server’s background service.

      While Central Server itself does not replicate packages, you can set this up yourself with DFS (or any similar technology) by pointing the repository to your DFS namespace. With this setup, DFS will be handling any file replication for your repository.

      Emily

  • Morning,

    Do you have a time frame for the release of Central Server for PDQ Inventory? We are running 3 licensed Enterprise editions of Deploy (now Central Server) but as we share the database for Inventory I need to have PDQ Inventory loaded on a server which I RDP to whilst my 2 colleagues run installation from their desktops. When I try to access functions from PDQ Deploy which require PDQ Inventory installed I am unable to as “My” edition of Inventory is on the server. It would be handy to know a ballpark date for release to remedy this situation.

    Kind regards,

    Ian

  • I have updated to the central server feature and export my schedules from my client and imported them to the server machine, relinked my packages to the schedules however since I mostly use the autodeployment feature, they don’t appear to be working anymore. I have the schedules linked to the ‘(old)’ software groupings in inventory and have inventory installed on both the server machine and the client machine. Both Inventory versions are 12 release 2. Should I be seeing autodeployments or has this feature now broken until the server version of Inventory comes back to link back in?

    • I believe you will need to recreate your Auto Deployments. We do not currently have a way to export them. The schedules you exported are normal schedules that were linked to your Auto Deployments. I will open a feature request ticket for exporting Auto Deployments.

      • Thanks for replying I was about to do that this as I found that the schedules, after 3 days, kicked off however all the targets I had setup were messed up. For example the schedule for 7-zip was targeting the Win 8 monthly security group. It so far seems of all the 55 schedules I had setup, even though I checked them when I set them back up in the server console, all are going to different targets. I’ve disabled them all and will start recreating

  • How does the central server handle the target listing in the instance where I have a unique collection in my copy of PDQ Inventory and link an on-going deployment to that but another user using the central server doesn’t’ have that collection and it also doesn’t exist on the version of Inventory on the installation server? Do I need to replicate all custom groups in Inventory until a similar central server option of Inventory is available?

    • Yeah, it’s a bit confusing and awkward until Inventory 13 comes out.

      When you run a Deploy Once it will access the Inventory that is installed on the same machine. When you link a Collection to a Schedule it will use the Inventory that is installed on the Server.

Leave a Reply

Your email address will not be published. Required fields are marked *