If you manage a LAN center, a university esports lab, or a corporate training room full of gaming PCs, uninstalling Valorant one machine at a time is not a plan, it’s a punishment. Riot’s own support page still walks through a single-PC, click-by-click removal process for Valorant and its Vanguard anti-cheat driver. That process works fine for one laptop. It falls apart the moment you have 20, 50, or 200 machines that all need the same cleanup before a semester ends, a lease turns over, or a venue reconfigures its bays for a different title.
This tutorial builds a repeatable, scriptable way to remove Valorant, the Riot Client, and the Vanguard kernel driver across an entire fleet of Windows PCs. You’ll write a PowerShell script that handles the actual uninstall, stops and deletes the vgc and vgk services that Vanguard relies on, cleans up leftover files, and verifies the result, then you’ll push that script out with PsExec, Group Policy, Intune, or SCCM depending on how your environment is already managed. By the end you’ll have a working script and a deployment plan you can run again the next time a game rotation calls for it.
None of this requires anything exotic. Every command in this guide is either a native Windows tool (sc.exe, PowerShell’s service cmdlets) or a free Microsoft download, so you can build and test the whole workflow without buying new software or opening a support ticket with Riot. What you’re really building is a small piece of internal tooling: one script that does the removal correctly, and one delivery mechanism that runs it everywhere it needs to run.
Why the manual, per-PC uninstall doesn’t scale
Riot’s documented removal process for Vanguard involves opening an elevated command prompt, running sc delete vgc and sc delete vgk, rebooting, and then manually deleting any files left behind in the Vanguard install folder. It’s accurate and it works, but it assumes a human is sitting at the keyboard for every single machine. In a lab with real inventory turnover, that assumption breaks fast.
Three problems show up repeatedly when IT staff try to do this by hand across a fleet. First, technicians skip steps under time pressure, so some PCs end up with the Riot Client removed but the Vanguard driver still registered as a boot-start service. Second, there’s no central record of which machines were actually cleaned, so the next audit turns into a manual walk of every bay with a checklist. Third, Vanguard is a kernel-level driver, which means a botched removal (renaming files instead of properly deleting the service, for example) can leave a machine in a state where Windows still tries to load a driver that no longer has its binary in place. None of these are hypothetical. They’re the reason this tutorial exists as a scripted, auditable process instead of a repeat of the single-PC walkthrough.
There’s also a time-cost argument that’s easy to underestimate until you run the numbers on your own fleet. A careful technician doing the full manual process, closing the client, running the delete commands, rebooting, confirming, and cleaning files, needs roughly five to ten minutes per machine when nothing goes wrong. On a 40-seat lab, that’s most of a working day spent on a task a script can run unattended overnight. Scripting the removal doesn’t just reduce errors, it gives you the labor back for something more useful than clicking through the same uninstall dialog forty times in a row.
Prerequisites and versions
You don’t need exotic tooling for this. Everything below is either built into Windows or a free download from Microsoft. Confirm you have the following before you start.
| Requirement | Version / Notes | Why you need it |
|---|---|---|
| Windows 10 or Windows 11 | Any currently supported, patched build | Target OS for both the script and the machines you’re cleaning |
| PowerShell | 5.1 (built in) or PowerShell 7.4+ | Runs the uninstall and service-removal script |
| Local admin or domain admin rights | N/A | Required to stop services, delete drivers, and uninstall software |
| PsExec (Sysinternals) | Latest release from Microsoft’s Sysinternals suite | Runs the script remotely without pre-staging PowerShell remoting |
| PowerShell remoting (WinRM) | Enabled via Enable-PSRemoting | Alternative to PsExec if your fleet already trusts remoting |
| Microsoft Intune or Configuration Manager (SCCM) | Latest current branch (optional) | For pushing the script as a managed Win32 app or task sequence |
| A machine list (CSV or Active Directory OU) | N/A | Defines which PCs the script targets |
Test everything on one or two lab machines before you point a script at 50 PCs at once. That’s not a formality, it’s the difference between a clean rollout and a support ticket queue.
What you’re actually removing: Riot Client, Valorant, and Vanguard
A full removal touches three separate pieces of software, and each one behaves differently. Treating all three the same way, which is the mistake most manual walkthroughs invite because they present removal as one continuous process, is where most incomplete cleanups come from.
- Valorant itself is a standard application, installed and removed through the normal Windows uninstall mechanism, the same registry-driven process any desktop app uses.
- The Riot Client is the launcher shell that manages Valorant and other Riot titles. It has its own entry in the Windows uninstall registry, separate from Valorant.
- Vanguard is not an application. It’s a kernel-mode anti-cheat driver, registered under the service names
vgk(the driver itself) andvgc(a supporting service). According to Riot’s own support documentation, the officially supported way to remove it is to stop and delete both services withsc, then reboot before deleting any leftover files.
The driver detail matters for a fleet script because kernel drivers load at boot, before most user-mode cleanup tools even start. That’s exactly why Riot’s process insists on deleting the service entries and rebooting rather than just deleting files. Skip the service deletion and you can end up with a machine that still tries to load a driver whose files are half gone, which is a worse state than leaving Vanguard installed in the first place. Community troubleshooting threads through 2026 keep landing on the same fix when Vanguard won’t fully go away: stop vgc, stop vgk, delete both service entries, then reboot before touching anything else.
Microsoft’s own documentation for sc delete is worth reading once even if you never touch the command outside this script, since it explains why a service marked for deletion can still show up in sc query until every handle to it closes. That’s the same mechanic behind the “access is denied” errors you’ll see if Vanguard’s driver is still active when you try to remove it, and it’s the reason the reboot step in this tutorial isn’t optional.
Step 1: Inventory the fleet
Before you write a line of removal code, build a list of every machine that needs cleaning. If your PCs are domain-joined, pull them straight from an Active Directory organizational unit. If they aren’t, a plain CSV with hostnames or IP addresses works just as well.
# Pull hostnames from an AD OU
Get-ADComputer -Filter * -SearchBase "OU=GamingLab,DC=yourdomain,DC=local" |
Select-Object -ExpandProperty Name |
Out-File -FilePath C:\Fleet\machines.txt
# Or start from a plain CSV: hostname,notes
# lab-pc-01,Bay 1
# lab-pc-02,Bay 2
Keep this list under version control or at least in a shared folder your team can update, since it becomes the source of truth for every later step, including the verification pass at the end.
It’s worth splitting this list by role before you move on, even if you only run one script against all of them. Separate “always remove” machines (public lab stations, rental fleet hardware) from “ask first” machines (a coach’s PC, a streaming rig with custom overlays tied to Valorant). Feeding the wrong list into a fleet-wide uninstall is a support-ticket generator, and it’s much cheaper to catch that mistake in a spreadsheet than after 40 machines have already rebooted.
Step 2: Confirm remote access before you touch anything
Pick one of two paths: PsExec, which needs no pre-configuration beyond admin credentials and file/print sharing, or PowerShell remoting (WinRM), which needs to be enabled ahead of time but integrates more cleanly with modern management tools. Test connectivity against a handful of machines first.
# Quick reachability check across the fleet
Get-Content C:\Fleet\machines.txt | ForEach-Object {
$pc = $_
if (Test-Connection -ComputerName $pc -Count 1 -Quiet) {
Write-Host "$pc reachable" -ForegroundColor Green
} else {
Write-Host "$pc UNREACHABLE" -ForegroundColor Red
}
}
Fix unreachable machines before running the removal script against the whole list. Chasing failures after a partial run is far more tedious than clearing them up front.
Step 3: Stop the Riot Client and Valorant processes
A running Riot Client or game process will block the uninstall or leave file locks behind. Kill both before anything else runs. This script uses Stop-Process rather than the service-oriented Stop-Service cmdlet, since Valorant and the Riot Client run as ordinary user-mode processes, not Windows services, unlike Vanguard’s vgc and vgk further down this script.
$processNames = @("RiotClientServices", "VALORANT-Win64-Shipping", "RiotClientCrashHandler")
foreach ($name in $processNames) {
Get-Process -Name $name -ErrorAction SilentlyContinue | Stop-Process -Force
}
Step 4: Locate the installed products in the registry
Riot doesn’t publish a documented silent-install flag for enterprise use, so instead of guessing at a command line, have the script ask Windows what it already knows. Every installed application registers an uninstall entry, and that entry usually includes the exact command Windows itself would run.
$uninstallKeys = @(
"HKLM:\SOFTWARE\Microsoft\Windows\CurrentVersion\Uninstall\*",
"HKLM:\SOFTWARE\WOW6432Node\Microsoft\Windows\CurrentVersion\Uninstall\*"
)
$riotEntries = Get-ItemProperty -Path $uninstallKeys -ErrorAction SilentlyContinue |
Where-Object { $_.DisplayName -match "Riot|VALORANT" }
$riotEntries | Select-Object DisplayName, UninstallString, QuietUninstallString
This returns whatever uninstall command Riot’s installer registered on that specific machine. Some entries expose a QuietUninstallString, which is designed to run without prompts. If that value is present, use it. If only UninstallString is there, test it against one lab PC first, since not every installer accepts a silent flag out of the box.
Step 5: Run the uninstall
foreach ($entry in $riotEntries) {
$cmd = if ($entry.QuietUninstallString) { $entry.QuietUninstallString } else { $entry.UninstallString }
if ($cmd) {
Write-Host "Uninstalling: $($entry.DisplayName)"
Start-Process -FilePath "cmd.exe" -ArgumentList "/c $cmd" -Wait -NoNewWindow
}
}
This removes Valorant and the Riot Client the same way a manual uninstall would, just without anyone clicking through dialogs. It does not touch Vanguard, that’s a separate step, because Vanguard is a service, not an application.
Step 6: Stop and delete the vgc service
This is the step Riot’s own support documentation centers on. Run it exactly this way, stop before delete, every time.
sc.exe stop vgc
sc.exe delete vgc
Step 7: Stop and delete the vgk service
vgk is the kernel driver itself, and it’s the one most likely to resist removal if a game process or another service still references it. Stop it the same way.
sc.exe stop vgk
sc.exe delete vgk
If either delete command reports “access is denied,” the driver is still loaded and locked. Don’t fight it here, that’s what the reboot in the next step is for.
Step 8: Clean up leftover files and folders
$leftoverPaths = @(
"C:\Program Files\Riot Vanguard",
"C:\ProgramData\Riot Games",
"$env:LOCALAPPDATA\Riot Games"
)
foreach ($path in $leftoverPaths) {
if (Test-Path $path) {
Remove-Item -Path $path -Recurse -Force -ErrorAction SilentlyContinue
}
}
Wrap this in -ErrorAction SilentlyContinue deliberately. A locked file here shouldn’t halt the whole script, the post-reboot verification pass in step 10 will catch anything that survives.
Step 9: Force the mandatory reboot
Riot’s guidance is explicit that a reboot is required after deleting the Vanguard services, and it’s not optional in practice either. A kernel driver’s service entry can be gone from the registry while the driver itself is still resident in memory until the next boot cycle. Skip this step and your verification pass in the next section will give you false readings.
Restart-Computer -Force -Delay 15
If you’re running this against a live lab during open hours, schedule the reboot with a task instead of forcing it immediately, so users get a warning.
Step 10: Verify removal after the reboot
Run a second, short script after machines come back online. This one just checks state, it doesn’t try to remove anything.
$vgcStatus = Get-Service -Name vgc -ErrorAction SilentlyContinue
$vgkStatus = Get-Service -Name vgk -ErrorAction SilentlyContinue
$vanguardFolder = Test-Path "C:\Program Files\Riot Vanguard"
[PSCustomObject]@{
Hostname = $env:COMPUTERNAME
VgcPresent = [bool]$vgcStatus
VgkPresent = [bool]$vgkStatus
VanguardFolder = $vanguardFolder
CleanRemoval = (-not $vgcStatus) -and (-not $vgkStatus) -and (-not $vanguardFolder)
}
Expected output on a clean machine:
Hostname : LAB-PC-01
VgcPresent : False
VgkPresent : False
VanguardFolder : False
CleanRemoval : True
Anything that returns CleanRemoval : False goes on a short list for manual review instead of a second automated pass, since a service that survives two removal attempts usually points to something machine-specific like a stuck driver lock or a third-party security tool interfering.
Step 11: Log results centrally
Don’t rely on scrollback in a terminal window. Append every machine’s verification result to a shared CSV so you have an actual audit trail, which matters if a compliance review ever asks whether a kernel-level driver was fully removed from decommissioned or repurposed hardware.
$result | Export-Csv -Path "\\fileserver\FleetLogs\vanguard-removal-$(Get-Date -Format yyyyMMdd).csv" -Append -NoTypeInformation
Step 12: Choose a delivery method for the fleet
Everything above is one script that runs locally on a machine. The last step is deciding how that script actually reaches every PC in your fleet. The right answer depends on what you’re already running.
| Method | Best for | Setup effort | Notes |
|---|---|---|---|
| PsExec loop | Small labs, no existing management tooling | Low | Runs the script remotely over SMB, needs admin credentials on each hop |
| Group Policy startup script | Domain-joined fleets already using GPOs | Medium | Runs at next boot for all machines in the linked OU |
| Microsoft Intune (Win32 app / script) | Cloud-managed or hybrid-joined fleets | Medium | Reports success/failure per device back to the console |
| SCCM / Configuration Manager task sequence | Large on-prem enterprise fleets | High | Best audit trail and scheduling control, more overhead to configure |
For a PsExec loop, wrap the whole thing in a simple foreach:
Get-Content C:\Fleet\machines.txt | ForEach-Object {
.\PsExec.exe \\$_ -accepteula -s powershell.exe -ExecutionPolicy Bypass -File C:\Fleet\Remove-ValorantVanguard.ps1
}
If you’re already on Intune for Win32 app management, package the same script as a remediation script instead, that gets you per-device success and failure reporting in the console without building your own logging pipeline.
The complete working script
Here’s every step above combined into one file. Save it as Remove-ValorantVanguard.ps1 and run it with an elevated PowerShell session, either locally or through whichever delivery method you picked in step 12.
#Requires -RunAsAdministrator
param([switch]$SkipReboot)
$log = "C:\Fleet\removal-log-$env:COMPUTERNAME.txt"
Start-Transcript -Path $log -Append
# Step 3: Kill running processes
@("RiotClientServices", "VALORANT-Win64-Shipping", "RiotClientCrashHandler") | ForEach-Object {
Get-Process -Name $_ -ErrorAction SilentlyContinue | Stop-Process -Force
}
# Step 4-5: Uninstall Valorant and Riot Client via registered uninstall strings
$uninstallKeys = @(
"HKLM:\SOFTWARE\Microsoft\Windows\CurrentVersion\Uninstall\*",
"HKLM:\SOFTWARE\WOW6432Node\Microsoft\Windows\CurrentVersion\Uninstall\*"
)
$riotEntries = Get-ItemProperty -Path $uninstallKeys -ErrorAction SilentlyContinue |
Where-Object { $_.DisplayName -match "Riot|VALORANT" }
foreach ($entry in $riotEntries) {
$cmd = if ($entry.QuietUninstallString) { $entry.QuietUninstallString } else { $entry.UninstallString }
if ($cmd) {
Write-Host "Uninstalling: $($entry.DisplayName)"
Start-Process -FilePath "cmd.exe" -ArgumentList "/c $cmd" -Wait -NoNewWindow
}
}
# Step 6-7: Remove Vanguard services
foreach ($svc in @("vgc", "vgk")) {
sc.exe stop $svc | Out-Null
sc.exe delete $svc | Out-Null
}
# Step 8: Clean leftover files
@(
"C:\Program Files\Riot Vanguard",
"C:\ProgramData\Riot Games",
"$env:LOCALAPPDATA\Riot Games"
) | ForEach-Object {
if (Test-Path $_) { Remove-Item -Path $_ -Recurse -Force -ErrorAction SilentlyContinue }
}
Stop-Transcript
# Step 9: Reboot unless explicitly skipped
if (-not $SkipReboot) {
Restart-Computer -Force -Delay 15
}
Run it once with -SkipReboot on a test machine so you can inspect the transcript log before you commit to a fleet-wide reboot cycle. The transcript captures every command’s output, including any “access is denied” responses from the service deletion calls, which is usually the fastest way to spot a machine that’s going to need a second pass after its first reboot.
Once the test run looks clean, promote the same script and the same parameters to your pilot group, five to ten representative machines rather than the whole fleet, before you run it everywhere. A pilot group surfaces environment-specific issues (a locked-down execution policy, a conflicting security agent, a machine with a stale Riot install from years back) while the blast radius is still small enough to fix by hand if something goes sideways.
Common pitfalls when bulk-removing Vanguard
Most of the failures teams hit when they first script this process trace back to treating Vanguard like a normal application instead of the kernel-mode driver it actually is. The list below covers the mistakes that show up most often once a script moves from a single test machine to a real fleet run.
- Deleting files before deleting the service. If you remove the Vanguard folder while
vgkis still registered, Windows will keep trying to load a driver that no longer exists on disk, which shows up as boot errors or Event Viewer warnings on the next startup. - Skipping the reboot. The service entries can be gone from
sc queryoutput while the driver is still loaded in memory. Verification run before a reboot will lie to you. - Running the script while Valorant or the Riot Client is still open. File locks will cause the uninstall step to fail silently in some installer implementations, leaving a partial removal that looks successful in the script’s exit code but isn’t.
- Assuming every machine has the same uninstall string. Different install paths or prior partial uninstalls can change what’s registered in the uninstall key. Always query the registry per-machine instead of hardcoding a path.
- No credential fallback for domain vs. local accounts. Labs that mix domain-joined and standalone machines need two credential paths in the PsExec loop, or half the fleet will fail on an access-denied error that has nothing to do with Vanguard.
- Treating a failed
sc deleteas fatal. An access-denied response usually just means the driver is locked and needs the reboot, not that something is broken. Don’t build error handling that aborts the whole run on this specific failure.
Troubleshooting
Even a well-tested script hits edge cases across a large enough fleet, usually because of something specific to one machine rather than a flaw in the script itself. The table below covers the issues that come up most often, roughly in the order you’re likely to hit them during a first fleet-wide run.
| Symptom | Likely cause | Fix |
|---|---|---|
sc delete vgk returns “access is denied” | Driver still loaded in memory | Reboot, then rerun the delete command before touching files |
vgc or vgk reappear after a clean run | Valorant was reinstalled, or another script reinstalled Riot Client silently | Confirm no scheduled task or image reinstalls the game post-cleanup |
| Uninstall registry entries are missing entirely | Prior manual/partial uninstall already removed the entry | Skip step 5, jump straight to service and file cleanup |
| PsExec loop fails with “access denied” on some machines | Credential mismatch between domain and local admin accounts | Split the machine list by join type and run with the matching credential |
Script hangs on Start-Process -Wait | Uninstaller is waiting on a hidden confirmation dialog | Add a timeout wrapper, or test the quiet string manually first |
Verification shows VanguardFolder : True after reboot | A file was locked by another process (AV scan, backup agent) during step 8 | Rerun step 8 alone post-reboot, the lock should be released |
| Event Viewer shows driver load failures after removal | Files were deleted before the service entry, leaving a dangling reference | Confirm service deletion via sc query vgk returns “specified service does not exist,” then clean any leftover keys under HKLM\SYSTEM\CurrentControlSet\Services\vgk |
| Machine won’t reboot on schedule during the run | A user is actively logged in and Windows is blocking the forced restart | Use shutdown /r /t 900 /c "message" instead of an immediate forced restart to give users warning |
Verifying a clean removal across the whole fleet
Once every machine has rebooted and reported back, aggregate the CSV logs from step 11 into one view instead of checking machines individually.
$allResults = Get-ChildItem "\\fileserver\FleetLogs" -Filter "vanguard-removal-*.csv" |
ForEach-Object { Import-Csv $_.FullName }
$allResults | Where-Object { $_.CleanRemoval -eq $false } |
Select-Object Hostname, VgcPresent, VgkPresent, VanguardFolder
An empty result set here means every machine on your list came back clean. If you see any rows, that’s your manual-review list, and it should be short, usually a handful of machines out of a full lab rather than a large fraction.
Scripted removal vs. reimaging: which one to use
Scripted removal isn’t always the right tool. If your lab already reimages machines between semesters, tournaments, or bookings, ask whether removal even needs to be a separate step at all.
Reimaging wins when the turnover is predictable and total, a computer lab that flips its entire software catalog every semester, for example, or a rental fleet that gets wiped between events. There’s nothing to verify after a fresh image, because Vanguard was never installed on it in the first place. The tradeoff is time and bandwidth: pushing a multi-gigabyte image to 50 machines over a shared network takes longer than running a removal script, and it wipes out anything else installed on that machine that you might have wanted to keep.
Scripted removal wins when turnover is partial, a handful of machines need Valorant gone while the rest of the fleet keeps its current setup, or when you don’t control the imaging pipeline and only have admin access to the machines themselves. It’s also the faster option when you need results in the next hour rather than the next maintenance window. Most labs end up using both: reimaging on a fixed schedule, and a script like this one for anything that falls between scheduled refreshes.
Advanced tips for repeat runs
If your lab reinstalls and removes games on a semester or seasonal cycle, a few refinements save real time on the next pass.
- Schedule the whole script as a Group Policy startup task so it runs automatically the next time flagged machines boot, rather than requiring someone to trigger it manually.
- Add a dry-run mode that only reports what would be removed, without deleting anything, useful for auditing a fleet before you commit to a live run.
- If you’re managing a mixed environment where some machines should keep Valorant (a competitive team’s practice PCs, for example) and others shouldn’t, drive the machine list from an AD group instead of a static CSV so you only need to update group membership, not the script.
- Pair this with a base image strategy. If your lab already re-images machines between semesters through SCCM task sequences, a clean image without Vanguard ever installed is often less work than removing it after the fact.
Security and compliance considerations
Vanguard’s kernel-level access is exactly why some IT teams want it fully gone from machines that leave a gaming context, whether that’s a lab PC being repurposed for coursework or a corporate laptop returning from an event. A driver with ring-0 privileges is a meaningfully different risk profile than a normal application, and leaving a half-removed service entry behind isn’t a cosmetic issue, it’s an unmanaged piece of privileged software sitting in your environment.
This is also a good moment to double-check who actually has permission to run this script. A removal tool that stops and deletes kernel services and force-reboots machines needs the same access controls you’d put around any other administrative script, scoped credentials, a change record of when it ran and against which machines, and ideally a review step before it’s pointed at a production fleet rather than a lab of test PCs. None of that is unique to Vanguard, but it’s easy to skip when a script feels like “just an uninstaller.”
Keep the CSV logs from step 11 as your audit trail. If a security review or a device handoff ever asks whether a kernel-level anti-cheat driver was verifiably removed from specific hardware, a timestamped log beats a technician’s memory of “yeah, I think I got that one.” This also matters if your organization has separately covered Vanguard’s kernel driver controversy in policy discussions, since a documented removal process is the practical follow-through on that conversation.
Frequently asked questions
Does Riot Games offer an official tool for bulk-uninstalling Valorant and Vanguard?
No. Riot’s published support documentation describes a manual, per-machine process built around sc delete commands and a reboot. There is no documented enterprise or fleet management tool from Riot for this, which is exactly the gap this script fills. If Riot publishes an official bulk-management option in the future, it would likely still be worth wrapping in your own logging and verification layer, since the CSV audit trail this script produces is useful independent of which removal method actually runs underneath it.
Do I need to delete both the vgc and vgk services, or just one?
Both. vgk is the kernel driver and vgc is a supporting service, and Riot’s own guidance removes both together. Deleting only one typically leaves the other behind, which defeats the point of a clean removal.
Can I skip the reboot after deleting the Vanguard services?
Not if you want an accurate result. The driver can remain loaded in memory even after its service entry is deleted, so a verification check run before rebooting can report a clean state that isn’t actually clean yet.
Will this script work over PowerShell remoting instead of PsExec?
Yes. Swap the PsExec loop for Invoke-Command -ComputerName $list -FilePath .\Remove-ValorantVanguard.ps1 once WinRM is enabled across your fleet. The underlying removal script doesn’t change either way.
Does Microsoft Intune support removing kernel-level drivers like Vanguard?
Intune doesn’t have a Vanguard-specific removal feature, but it can run the same PowerShell script as a Win32 app uninstall action or a remediation script, which gets you centralized reporting on top of the same underlying commands used in this tutorial.
What happens if a machine reinstalls Valorant later? Will Vanguard conflicts return?
Reinstalling Valorant reinstalls Vanguard as part of the normal install flow, since the game requires the driver to launch. A prior clean removal doesn’t cause any conflict with a fresh install, the services just get recreated the same way they were the first time. If a machine that was previously cleaned starts showing Vanguard services again without anyone manually reinstalling the game, treat that as a signal worth investigating, either a user reinstalled it themselves, or your imaging or app-deployment pipeline is pulling in software you thought was excluded.
Is it safe to run this script on machines where Valorant is still actively being played?
No. Target only machines where the game and client are already closed, ideally confirmed by the process-kill step in the script itself. Running a full uninstall against an active game session is a good way to generate support tickets you don’t need.
How do I confirm Vanguard is fully gone after a fleet-wide run?
Run the step 10 verification script after every machine has rebooted, then aggregate the results as shown in the fleet verification section above. A machine only counts as clean when both services and the install folder are all confirmed absent. Keep the exported CSV rather than just eyeballing terminal output, it’s the difference between a one-time cleanup and a process you can point to later if anyone asks whether a specific machine still has Vanguard on it.
Related Coverage
- How to Uninstall Valorant Completely: 10 Steps
- Valorant Won’t Uninstall: 12 Fixes for Vanguard
- Remove Vanguard Anti-Cheat After Uninstalling Valorant: 10 Steps
- Riot Vanguard Bricks $6K Devices, Goes Optional
- How to Climb Valorant Ranks: 25 Tiers, 12 Steps
- Cloudflare Tunnel Setup: 12 Steps, 45 Min
- More Esports Coverage




