TL;DR: Managing remote computers without a VPN is possible with agent-based endpoint management. IT admins can deploy software, run scripts, automate patching, troubleshoot devices, and provide remote support over the internet, even when endpoints aren't connected to the corporate network. With PDQ, these tasks can happen from a single console, reducing tool switching and making it easier to manage devices wherever users work.

Your users are no longer on your network. Some are at home, others are at a customer site, and some are on hotel Wi-Fi with a laptop that has not rebooted in three weeks. The work still needs to get done: install the app, run the script, and fix what broke.

Two of the most time-consuming jobs in managing a remote fleet are running tasks on machines you cannot reach directly and supporting the people who use them. This guide explains why the old approach breaks down off-network, what a workable setup looks like, and how to handle both jobs in PDQ.

Why the old approach breaks off-network

Most Windows admin tools assume that the endpoint is reachable. That usually means it is on a domain, connected to a VPN, or located in the office.

Remote PowerShell and WinRM (Invoke-Command, Enter-PSSession) need a network path to the target. Off-network, that means using a VPN or opening an inbound port. Nobody wants an open port, and the VPN always seems to be down when you need it most.

Scheduled deployments from a local server can fail quietly when a laptop is closed or the VPN is off. You may not find out until a user submits a ticket saying, “It’s broken.”

Screen-sharing tools handle support, but they live in a separate console with no connection to the fix you deploy afterward.

All three approaches share the same limitation: The admin tool has to reach the machine. An agent-based approach reverses that connection. The machine checks in with the cloud, so its location does not matter as long as it has internet access. There is no VPN, no open inbound port, and no waiting for someone to get back to the office.

Running work on remote machines

How to install software on multiple remote computers at once

Stop pushing and start queuing. In PDQ, the process looks like this:

Package it once. Get a prebuilt package from the Package Library, or build a custom one with your installer, silent switches, and any pre- or post-installation steps.
Target a group, not a list of hostnames. Build the group from inventory data such as OS, installed software, and custom fields. Hostname lists can go stale as soon as you create them.
Create the deployment and let the agent handle the timing. Offline devices pick up the deployment the next time they check in. Nobody has to babysit it.
Verify from inventory. Check the install result and installed version rather than trusting a green checkmark.

Take yourself out of the loop with automations

Once a deployment works, stop running it by hand. An automation deploys one or more packages to devices or groups when a trigger fires.

To create one:

On the Automations page, select Create Automation.
Enter a Name.
Under Packages, search for prebuilt or custom packages and add them. Prebuilt packages default to the Latest version and update automatically. Select a specific version to pin it.
Configure the Trigger:
- Automatic: Deploys when an attached package is updated or a new package is added. If multiple packages are attached, only the updated or newly added package deploys.
- Deploy Once: Choose a date and time.
- Recurring: Set a start date, then repeat daily, weekly, or monthly. For monthly schedules, choose a numbered day (the 18th) or an ordinal weekday (the third Tuesday).
Under Deploy To, select the devices or groups.
Toggle Enabled on and select Save. You can also save without enabling the automation.

Keep a few things in mind before relying on automations:

Times run in UTC. The console shows your browser’s local time, but automations deploy according to UTC. A 4:00 p.m. trigger set from EST runs at 21:00 UTC.
Offline devices queue recurring runs. A device that stays offline through several scheduled instances will run a disruptive deployment, such as a reboot, multiple times in a row. Use caution with recurring schedules for anything that restarts a machine.
There is a five-deployment daily cap. If an automation creates more than five deployments of the same package on the same device in one day, subsequent deployments fail with “Too many deployments for this package for this device.” This helps flag a misconfigured automation before it hammers a device.

How to run scripts on remote computers without a VPN

Running a script remotely presents the same challenge as installing software: It must reach a machine you cannot connect to directly. With PDQ, run the script as a package step in a deployment instead of opening a remote session to each machine. For one-off commands on a single device, use live shell, covered below.

A script run across a fleet should be safe to run more than once and report what it did. Here is a check that reports whether a reboot is pending:

# Reports whether Windows is waiting on a reboot
$paths = @(
    'HKLM:\SOFTWARE\Microsoft\Windows\CurrentVersion\Component Based Servicing\RebootPending',
    'HKLM:\SOFTWARE\Microsoft\Windows\CurrentVersion\WindowsUpdate\Auto Update\RebootRequired'
)

$pending = $paths | Where-Object { Test-Path $_ }

if ($pending) {
    Write-Output "Reboot pending on $env:COMPUTERNAME"
}
else {
    Write-Output "No reboot pending on $env:COMPUTERNAME"
}

A few habits can save you trouble:

Test on a small group first, then widen. Include at least one machine with a history of problems in the pilot group.
Exit with a meaningful code. A script that always exits 0 hides failures, and the deployment report will show that everything worked.
Do not assume a user is logged in. Remote runs often execute in system context, so anything that depends on a user profile or mapped drive will fail.

Deal with limited bandwidth

Field laptops and home connections are not data centers. Keep packages small where possible, deploy outside working hours, and stage large installers instead of sending them to every device at once.

PDQ’s staged deployments help manage bandwidth by limiting active downloads per public IP address. Once the limit is reached, additional deployments remain in “Staged” status until the number of active downloads drops below the limit.

To get started in PDQ:

Settings: Select the gear icon in the lower-left corner of the page.
Bandwidth: Select the Bandwidth tab in the left panel.
Enable slider: Toggle the slider at the top right of the feature description to enable staged deployments.
Set active download limit: Set how many deployments can run concurrently per IP address. The limit applies to each IP address individually, not to all IP addresses combined.
Enter IP addresses: Specify which IP addresses the limit should apply to. Enter single IP addresses (for example, 203.0.113.1) or address blocks in CIDR notation (for example, 198.51.100.0/25).

Keep the fleet patched and healthy

Software deployment and patching use the same mechanism, so you do not need a second tool. Schedule Windows and third-party updates, and review vulnerability findings to prioritize patches by risk rather than by the calendar alone.

PDQ scans your environment for operating system and software vulnerabilities, including those involving processes, registry and store applications, drivers, services, and the OS itself. Here’s how to work through the findings:

Open the Vulnerabilities page from the left navigation bar. CVEs appear in descending order by PDQ risk score, with the most severe at the top. To run a fresh check, select Scan at the top of the list.
Review the risk score before you respond. The score combines the CVSS score with business impact, access levels, exploitability, and weaponization — that is, whether threat actors are actively using the vulnerability. A CVSS 9 vulnerability that nobody is exploiting can rank below one with a lower score.
Select a vulnerability to view its description, resolution (when available), references from NIST and the vendor, affected applications, and impacted devices.
Deploy the fix. Select Select package to deploy, then choose a package from the Package Library or your own. To patch specific devices, select them in the Impacted devices list, select Deploy, search for a package, then select Deploy again. For the most critical updates, PDQ suggests a package and names the update on the button. Test the suggested fix in your environment and confirm that it works before rolling it out broadly.
Accept the risk when necessary. Sometimes a patch conflicts with a business priority. To ignore a vulnerability for all devices, open it, select the arrow next to the Vulnerable status, and choose Ignore. This applies to all current and future devices, including offline ones. To ignore it for individual devices, use the arrow next to each device’s status in the Impacted devices list and choose Ignore for this device. Make that decision deliberately: The vulnerability will remain unpatched.
Check an individual device. Go to Devices, select a device name, and open the
Vulnerabilities tab to see its vulnerable software and deploy a fix.

Offline devices update when they reconnect.

Supporting remote end users

Deployment covers the machines; support covers the people using them. When a user says, “It’s broken,” you usually need to see what they see.

How to get into a remote machine

PDQ includes built-in remote desktop for troubleshooting and user support. It supports unattended access and remote assistance, so you can fix a machine when nobody is at it or work alongside a user. It works over the internet without a VPN on Windows and macOS.

Setting up a Windows machine takes three steps:

Install the remote desktop agent. In the left navigation bar, select Devices, then the device name, then Remote desktop. If this is your first connection, the status will read “Remote desktop agent not installed.” Select Install remote desktop agent and wait for “Agent installed successfully.” To avoid doing this one device at a time, bulk-install the agent on multiple or all devices from the organization settings.
Install the local viewer on your computer. The session starts from the PDQ web app in your browser but opens in a local viewer app. Select Continue, then Download local viewer. Run PDQ RD Viewer.exe, accept the UAC prompt, select Install, then Finish. On macOS, follow the macOS viewer instructions instead.
Start the session. Select Continue, then Start remote session. If your browser asks whether to open PDQ RD Viewer, allow it.

Keep a few things in mind before your first session:

The user can see you. Depending on your organization’s settings, you can or must notify the logged-in user that a session is starting. They can watch the session and continue using the computer.
You can join an existing RDP session. If the target has an active RDP connection, such as a user on a cloud-hosted PC, you will be prompted to choose which session to join.
There is a second agent. Remote desktop uses a separate agent from ISL Online, a PDQ company, with its own connectivity requirements. If a session will not connect, run the Connection Tester and check the firewall allowances in the troubleshooting article before blaming the user’s Wi-Fi.

Run commands and move files with live shell and live file explorer

Sometimes you do not need to see the screen; you need a command prompt. The action buttons in the top-right corner of the device page offer two options.

Live shell opens a true remote shell session in a popup in the same browser tab. Commands run immediately, and keystrokes pass through as typed, so shortcuts such as Ctrl-R work.

Select Start live shell (the command prompt icon) in the top right of the device page.
Choose a shell from the dropdown in the top right: Windows PowerShell 5, PowerShell 7 (if installed), or CMD on Windows; Bash or zsh on macOS.
Run your commands. End the session with the X icon or by typing exit.

To use PowerShell 7 on a Windows endpoint, deploy the package from the Package Library, then reboot the device. Without a reboot, the PATH change is not detected, and PowerShell 7 will not appear in the shell selector.

Live file explorer lets you browse a device’s file system without opening a separate tool.

Select Start file explorer (the folder icon) in the top right of the device page.
Use the three-dot menu on a file or folder to copy its name or path, or download the file.
To send a file to the device, select Upload, choose the file, and select Open.

Fix it in the same place you connected

The benefit is not just screen sharing; it is avoiding the switch between tools. From one console, you can connect to the device, check system information, run a command, move a file, and deploy the fix — without a second login or copying a hostname between three windows.

A worked support flow

A user reports a slow machine and a failing app.

Open the device record and check inventory: OS version, installed software, and last check-in.
Connect with remote desktop and reproduce the problem.
If the issue needs a command, open live shell and check what the machine is doing. Use live file explorer to retrieve a log if needed.
Deploy a corrected package or script to the device.
Confirm the fix in inventory and close the ticket.

Five steps, one console, and no need for anyone to read you an IP address over the phone.

What teams actually do

“Once PDQ’s remote desktop tool came out, we realized, oh, we don’t need TeamViewer anymore. And the information we need from devices, PDQ provides, so we didn’t need Lansweeper. What NinjaOne was providing, which was primarily deploying updates and rebooting our cloud servers, we’re managing to get now from PDQ Connect as well. So that’s three tools we’re getting rid of because we’ve got it all in PDQ Connect.”

In a serverless school IT environment, Lift Schools replaced TeamViewer, Lansweeper, and NinjaOne with PDQ to access remote desktops, view device information, deploy updates, and reboot cloud servers.

Read the full case study.