1. PDQ Deploy & Inventory Help Center
  2. Community
  3. PDQ Deploy
 

Important Notice: On February 29th, this community was put into read-only mode. All existing posts will remain but customers are unable to add new posts or comment on existing. Please feel to join our Community Discord for any questions and discussions.

Solution for getting same PDQ Repository Source over multiple Domains

Avatar
Sebastian Hosp

Dear PDQ folks,

I love your piece of software but stuck with a problem I am probably not alone with.

We used PDQ Deploy Auto Deployment and since the new version Auto Download for our main domain (for example a.local) with domain-based DFS for the repository (about 20 VPN connected branches in Germany).

Everything works like a charm.

Now we acquired two new companies with their own domain forrests (for example b.local and c.local) and we already integrated all their sub division branches in our vpn network. So far so good. Now we have three domains to administer. 

As far as I know its not possible to expand our current domain based DFS to this new forrests b.local and c.local  and therefore the Auto Download function will not work for these divisions. So we have to manually build the packages for the new domains and use different credentials. Its working but nasty after you start using the Auto Download functionality.

Are there any practicle solutions or nearby feature requests to solve our ploblem to get a accessable PDQ repository for using Auto Download for all of them?

My quick and dirty solution would be:

  • Create identical PDQ DFS structure in domain b.local and c.local like already exists in a.local.
  • Copy PDQ Repository on a.local after work hours with robocopy to one DFS target in domain b.local and c.local and let them replicate to all their DFS servers over night.
  • Deploy a script generated hosts file to all windows clients and servers and point for example host pdqdeployserver to the nearest DFS server IP which shared the PDQ Repository data. We have to do that because the different branches sometime have not the best WAN connections, so we have place the data on the local windows server in their subnet.
  • Alter this steps alter the PDQ Repository target to the new dns dummy name.

I hope you have a much better solution and until now I am just missed and overlooked it while I investigated possible solutions in the Microsoft Techpapers/Forums etc.

Obi Wan you are my last hope _\|/_

Best regards ...
Sebastian

 

0

Comments

3 comments
Date Votes
  • Avatar
    Sebastian Hosp
    (Edited )

    After discussin our scenario with PDQ support I came up with a better solution (like above) that seems to work.

    Our active PDQ Deploy installation is under Domain a.local. Choose DFS Replication / DFS Namespaces and DNS aswell to fit in your enviroment.

    So here is what I've done:

    • Created DFS-Replication folder DFS-DATA (and exact same path tree) in every Domain a.local, b.local and c.local

    • Created DFS-Namespace EDV separately in all domains and inherit DFS-DATA as target folder. 

    • Make all Windows Servers in our VPN Network branches Namespaceserver for better subnet client performance (Domain a.local, b.local and c.local)
      This step isnt required for all enviroments, but with branches with weak WANs it results in faster network response for the DFS share.

    • Created a DNS CNAME pdqdeployrepo and point it to the local domain name a.local. Done the same in b.local and c.local

    • Placed PDQ-PackageLibrary Folder under DFS-DATA in Domain a.local and adjust PDQ Deploy preferences to
      \\pdqdeployrepo\EDV\DFS-DATA\Deployment\_PDQ_PackageLibrary 

    • Created a PDQ Deploy package that syncs the DFS deployment folder with robocopy from domain a.local to one fast DFS Site in b.local and c.local and run it every day outside our work hours. DFS replication will do the rest and replicate all content to the slower branches sites.

    • Auto-Download start installations minimum 3 days after the download to be sure all content (even bigger files) are already replicated to all DFS Nodes. Adjust this to the performance of your network.

    That’s it . Hope it help in other scenarios.

    Please keep in mind that our vpn network have many branches and every branch have its own DC. The reason for this DFS/DNS approch is to be sure that all data lies within the branch subnet and the local clients/servers choose by DFS their local DC as PDQ source because of many weak WAN connections within the network. There are other approaches like the one I will post from Brigg or to established trusts between the domains and use one central DFS-Share.

    Best regards ...

    Sebastian

    0
  • Avatar
    Sebastian Hosp

    To be complete I post another angle of approach from Brigg (PDQ):

    First, you could "move" (copy) PDQ to the new domains. In order to copy the products you'll have to move the database over with the new install. Here are instructions on how to do that, and a video:
    Moving PDQ Deploy to another computer
    Moving PDQ Inventory to another computer
    YouTube Video: Moving PDQ Deploy or PDQ Inventory to a New Machine

    In this way, you duplicated the PDQ application(s) in b.local and c.local. You'll need to change the credentials, of course, but the same functionality should exist. You will need to build anything separately on top of that once you've moved that should you need to add/remove Auto Downloads for those different domains, but management will be much reduced. You can use DFS native to those domains or another method to have those install files accessible by the program.

    0
  • Avatar
    Sebastian Hosp
    (Edited )

     

    Deleted because of double posting -oops-

    0