Using a VPN Connection to Manage Remote Computers with PDQ Deploy and PDQ Inventory

Purpose

You want to use PDQ Deploy and PDQ Inventory to manage computers over a VPN connection.

Configuring the Environment

Firewall

VPN connections are often more restrictive than the internal network and may require additional firewall ports to be opened on the VPN network to work correctly. You'll need to make sure the following protocols are enabled and ports opened bi-directionally:

ICMP Enabled
UDP 137
UDP 138
UDP 445
TCP 139
TCP 445
TCP 6336 (ONLY if using PDQ Deploy Central Server)
TCP 7337 (ONLY if using PDQ Inventory Central Server)

Reference: Windows Firewall Ports and Exceptions

Setting DHCP to Update DNS

By allowing your DHCP server to update your DNS server, this can help to ensure that the VPN IP addresses are properly associated with the hostname of the endpoint. If you are using Windows DHCP, the following setting is recommended for environments where machines move in and out of the network frequently.

1. Open the DHCP MMC.

2. Right-click either the scope or the protocol (e.g. IPv4) > Properties > DNS tab and ensure the following is enabled:

Thinking this through with user Billy as an example and we've set the DHCP lease for the VPN range to 10 hours:

8:00 AM Billy connects to the VPN, gets a lease of 10.10.10.50, and the DHCP server registers LT-BILLY to DNS.
12:30 PM Billy disconnects from the VPN to get lunch then reconnects. Billy gets the same IP because the lease is still active.
5:00 PM Billy disconnects from the VPN and goes to answer the same question we've all been asking ourselves during this time, am I hungry or bored? Billy is done working for the night.
6:00 PM The lease of 10.0.10.10.50 expires since LT-BILLY is not around to renew. The DHCP server then removes the A and PTR records created at 8:00 AM that morning.
DNS stays updated, Deploy and Inventory keep chugging away.

DNS

In order to clean up and remove out-of-date DNS entries, we recommend turning DNS scavenging on.

To set up scavenging, perform the following:

1. Open the DNS MMC.

2. Click on View > Advanced to enable (checked) the advanced views.

3. Next, right-click > Properties on the zone you wish to scavenge and click on the General tab >Aging button:

And ensure "Scavenge stale resource records" is checked. 4 days is a good starting point, but you may need to lower this value if you are still getting DNS errors In PDQ:

4. On the DNS server, right-click > Properties > Advanced tab and check the, "Enable automatic scavenging of stale records."

5. Once scavenging has been configured for the resource record, the zone(s), and the server, run the following command from an administrative/elevated command prompt on the DNS server (changes should replicate to all member DNS servers).

dnscmd /startscavenging

Or, from an administrative/elevated PowerShell prompt on the DNS server, run,

Start-DnsServerScavenging -Verbose

Or, from the DNS MMC, right-click the DNS server and select "Scavenge Stale Resource Records".

Configuring PDQ Deploy and PDQ Inventory

There are few additional settings to consider when managing endpoints over a VPN connection:

We recommend checking out our PDQ Recommended Performance Settings guide for getting the best performance out of your PDQ server.
Specifically, in Deploy / Options / Preferences / Performance, we found that setting Total Concurrent Targets to 20 worked well for us: (You may need to test this and find what works best for you)
As far as PDQ Inventory, we found we were getting quite a few false positives when we had ping before scan enabled. We have since attributed that to higher latency and some packet loss. We saw this most often when deploying to remote targets with slow or unreliable internet connections. PDQ only sends 2 ICMP echo requests to the target. If they are not returned in time or both timeout, the machine will be considered offline. Here's what we recommend under Inventory / Options / Preferences / Scanning:
One final consideration is that most packages, aside from taking a little longer to copy, will deploy successfully as they always have on the local office network. However, there are some scenarios where large or custom deploy packages may have more difficulty deploying reliably to remote targets with slow or intermittent internet connections. In these cases, you may want to consider creating a deployment that combines copying the installation files locally, then installing from the local source: