How to set up PDQ to work with remote workers

I have not been paying attention to current events as I have been replaying the new Final Fantasy 7 demo nonstop, if you are reading this in the future please imagine a nondated example. The bosses, however, have told me that it is an excellent time to talk about PDQ working on computers connected to the VPN. I failed to get details, but I will assume it is because bees are making a comeback, and they are extremely upset about all of those hive collapses. 

I usually get to come in with all kinds of specific examples on how to set something up. With this subject, it is very dependent on your particular environment. Showcasing how I would do it in our environment would only be relevant to a pretty small group. It would be kind of like me giving you my glasses and saying, “Hey, I can see better with these glasses and you will too!” No, instead, we are going to approach this by talking about the main concepts you need to configure and leave it up to your excellent skills to put those into your super special and unique setup.

PDQ Server Setup

You don’t actually need to make a lot of changes with your PDQ settings to get this to work. However, you have the potential for a lot of DNS turnover. So we will need to do two things to lessen the issues from DNS. 

• Set PDQ Inventory to check multiple addresses.

• Flushing your DNS often.

In certain cases DNS can end up having multiple (often two or three) addresses for each computer. Setting Inventory to check multiple addresses will make sure Inventory attempts each returned address until one of them responds. This comes with the downside of your heartbeat scans taking longer, but where we have a higher risk of duplicate or stale records, this gives you much more accurate results when scanning. Keep in mind that heartbeat (the ping) has a time out of one second, so if your VPN has higher latency, it may move on to the next address before you get a response. If all addresses fail to respond within the time limit Inventory will view that computer as offline. Open preferences in Inventory (CTRL + ,) and go to the Scanning page, and then check "Ping before scanning" to enable this setting.

Now for creating the scheduled task for flushing your DNS. I think about every time Inventory does a heartbeat scan, you will want to flush your DNS. The triggers will vary based on your set up, but the action is simple and captured in the screenshot below.

One other gotcha you may run into is your console user. If the credentials you are using for your local deployments do not have the same permission on your remote machine, your scans and deployments will fail. You will need to make sure the credentials in PDQ Deploy and PDQ Inventory have the correct permissions.

Firewall and VPN Setup

This block is where we will do most of the heavy lifting for this configuration. The first thing you are going to need is to have a correctly configured firewall, mostly what ports you allow. Brigg wrote about this with more eloquence than I can muster, so if you are looking for a deeper dive, I recommend you read this. The quick breakdown is you need to open UDP ports 137, 138, and 445. As well as TCP ports 139 and 445. You do not need to open these up to the public, but only through traffic on the VPN Tunnel

If those ports are all set, the next step is to make sure that the Virtual IP’s(VIP) are registering properly with your DNS, if you are one of those lucky few whose firewall/VPN device can register with the DHCP server you are done! Give your network team a high five for their absolute awesomeness. If, however, you are unable to do that, stick with me a bit longer. We have a few more steps to follow. I am going to assume that if your firewall/VPN device can’t pass right to DHCP, then it does not have a domain account, so it can’t authenticate as a domain member to update. So we are going to need to head over to your DNS server and make a quick change. Open the properties for the DNS zone, and then you need to change it to allow Unsecure and Secure updates. If you have Linux clients, there is a pretty good chance this setting is changed.  

The last thing to take note of is your scavenging settings. If your remote users are not always connecting and your potential number of clients is more than your reserved allotment of addresses, you may need to set some pretty aggressive scavenging. What exact setting will be dependent on your environment, so you may have some trial and error. PDQ products success relies on the accuracy of your DNS, so you will want to make sure you don’t have stale records hanging around and causing issues for you.

Conclusion

That is pretty much all you need. There are not a lot of steps, but there is enough potential for variation you will just need to customize for your particular set up.

Just remember:

• Allow the proper ports on your virtual IP’s

• On your PDQ Server flush your DNS about as often as you run a heartbeat

• DNS requires insecure authentication if your device handling the VPN can’t authenticate with your domain controller

• If you have more devices than reserved IP’s, you will need to have some aggressive scavenging set up.

Now if you will excuse me, I am going to return all of my honey to the nearest beehive to appease our new overlords.