Best-Practice? Using PDQ across international sites



  • Mark Davies

    Hi Michael, 

    I was about to raise a different topic based on international sites.

    Do you use Central server mode? Or just standalone with the Repo's sync'd?

    I want to use central server mode but would love the ability to use local repos as apposed to the one on the central server as that would mean clients copying files over the WAN.

    Comment actions Permalink
  • Michael Yorke

    Hi Mark,

    We use Central Server mode, so the database and main repo is stored at HQ. In PDQ Deploy, I have set the repository path to a DFS-N share, shown below. Each site therefore resolves this path to their local repo.

    Site 1: resolves to \\site1fileserver\shares\pdqrepo$
    Site 2: resolves to \\site2fileserver\shares\pdqrepo$
    Site 3: resolves to \\site3fileserver\shares\pdqrepo$

    The repo contents are then replicated (using DFSR) to the other two sites. But you could use many other methods of keeping these repo's in sync.

    Then in my PDQ Deploy packages, I use the $repository variable in all the paths, such as...

    The only thing to watch out for is to ensure in each package Properties you set the 'copy mode' to "pull", see below. This makes the endpoint "pull" the package from the repo, so it can resolve DFS-N paths to its local repo. If you used "push" mode instead, it will push the files to the endpoint from the central server (over the slow WAN/VPN), which we don't want to happen.

    What is frustrating is the time it takes to send, complete and return Deploy and Inventory commands to my remote sites. I'm sure 99% of this due to slow WAN/VPN speeds, but having a distributed architecture might go so may to improve this. I'm comparing to PRTG, which is a monitoring tool we use, where you deploy a remote probe at a remote site for all local monitoring, which then sends the results back to a central server.


    Comment actions Permalink

Please sign in to leave a comment.