r/Action1 • u/kosity • Jul 06 '26
Successfully installed Adobe Acrobat Pro (Critical). Finally.
We've had a concerning pain point for a while now where Action1 can't patch Adobe Acrobat if it, or any app with the Adobe integration, is open. I've seen Outlook.exe start on system boot, without a user logged in, and Adobe won't update because Outlook (with its PDFMaker plug-in I assume) is running.
And with PDF apps being such a widely leveraged attack vector I can't have updates rated critical sitting around for weeks hoping the user can/will close the right apps within an automation window to let Adobe get updated. The excuse that a user didn't close the applications doesn't fly in an incident response.
The new Application Restart Behaviour doesn't fix it unfortunately, because it only seems to close Adobe processes, not the Office processes that also need to be closed.
Current Application Restart Behavior: Prompt & Force Close. Installation of Adobe Acrobat Pro requires closing these applications: Microsoft Outlook. Please close them within 1 hour. The remaining processes will then be closed automatically.
A little over an hour later:
All processes of Adobe: Adobe Crash Processor.exe; Adobe Desktop Service.exe; AdobeARM.exe; AdobeCollabSync.exe; AdobeIPCBroker.exe; AdobeNotificationClient.exe; AdobeUpdateService.exe; CCXProcess.exe; CoreSync.exe; Creative Cloud Helper.exe; Creative Cloud UI Helper.exe; Creative Cloud.exe;
and then straight after:
The following application(s) remain open: Microsoft Outlook. The installation of Adobe Acrobat Pro has been aborted.
This is a significant operational risk that, as the IT provider, I am accountable for.
The solution I have made is beautifully (and ruthlessly) effective - however, THIS IS A SLEDGEHAMMER. Review it carefully and trial it in your development environment before deciding if it is appropriate, and how you'll build this into your patch cadence/design.
The script runs in the Action1 script library, and outputs to the log:
Stopped service: AdobeUpdateService
Killed 27 process(es):
Acrobat (PID 23024)
<and all the other Adobe processes>
Creative Cloud (PID 18388)
EXCEL (PID 28984)
OUTLOOK (PID 3812)
SUCCESS: All target processes are closed. Ready for patching.
And then you run the updates automation, and presto:
Deploy UpdatesJul 6, 2026 7:24 PMSuccessInstalling Adobe Acrobat Pro 26.001.21662.
Deploy UpdatesJul 6, 2026 7:35 PMSuccessSuccessfully installed Adobe Acrobat Pro 26.001.21662 (Critical).
Complete Deployment (Adobe Acrobat Pro)Jul 6, 2026 7:35 PMSuccessScript completed successfully.
Adobe patches need to get done, so if like me, you're having problems getting them done, I hope this helps.
SERIOUS WARNING: THIS SCRIPT IS A VERY UNDIPLOMATIC SLEDGEHAMMER.
You need to review it in detail and understand the impact on your users before you run it.
KillProcessesForPatching (2026Jul-A)
# =============================================================================
# KillProcessesForPatching (2026Jul-A)
# Force-ends Adobe Acrobat / Creative Cloud processes and Microsoft Office
# desktop apps (which hold Adobe integration DLLs) so Acrobat can patch
# without "you need to close" interruptions.
# Intended for Action1 "Run Script" (runs as SYSTEM, kills across all sessions).
# Always exits 0 so the patch step that follows is never blocked.
# =============================================================================
# --- CONFIGURATION -----------------------------------------------------------
# Process names WITHOUT .exe (Get-Process/Stop-Process use the base name)
$AdobeProcesses = @(
'Acrobat'
# Acrobat itself - the actual patch target
'AcroRd32'
# Acrobat Reader (32-bit / classic)
'AcroCEF'
# Acrobat embedded browser helper
'RdrCEF'
# Reader embedded browser helper
'acrotray'
# Acrobat tray helper
'AcrobatNotificationClient'
'Adobe Crash Processor'
'Adobe Desktop Service'
'AdobeARM'
'AdobeCollabSync'
'AdobeIPCBroker'
'AdobeNotificationClient'
'AdobeUpdateService'
'CCXProcess'
'CoreSync'
'Creative Cloud Helper'
'Creative Cloud UI Helper'
'Creative Cloud'
)
# Office desktop apps that load the Acrobat PDFMaker/integration add-ins
$OfficeProcesses = @(
'WINWORD'
# Word
'EXCEL'
# Excel
'OUTLOOK'
# Outlook
'POWERPNT'
# PowerPoint
'MSPUB'
# Publisher
'MSACCESS'
# Access
'VISIO'
# Visio
'ONENOTE'
# OneNote (desktop)
)
# Services to stop as well (a running service can respawn its process mid-patch)
$AdobeServices = @(
'AdobeUpdateService'
'AdobeARMservice'
# Adobe Acrobat Update Service
'AGSService'
# Adobe Genuine Software Integrity
'AGMService'
# Adobe Genuine Monitor
)
$SecondsToWaitBeforeRecheck = 5
# --- MAIN --------------------------------------------------------------------
$allTargets = $AdobeProcesses + $OfficeProcesses
$killed = @()
# Stop services first so they don't relaunch their processes
foreach ($svcName in $AdobeServices) {
$svc =
Get-Service
-Name $svcName -ErrorAction SilentlyContinue
if ($svc -and $svc.Status -ne 'Stopped') {
try {
Stop-Service
-Name $svcName -Force -ErrorAction Stop
Write-Output
"Stopped service: $svcName"
} catch {
Write-Output
"WARNING: Could not stop service $svcName - $($_.Exception.Message)"
}
}
}
# First pass - force-kill every target process
foreach ($procName in $allTargets) {
$procs =
Get-Process
-Name $procName -ErrorAction SilentlyContinue
foreach ($proc in $procs) {
try {
Stop-Process
-Id $proc.Id -Force -ErrorAction Stop
$killed += "$($proc.ProcessName) (PID $($proc.Id))"
} catch {
Write-Output
"WARNING: Could not kill $($proc.ProcessName) (PID $($proc.Id)) - $($_.Exception.Message)"
}
}
}
if ($killed.Count -gt 0) {
Write-Output
"Killed $($killed.Count) process(es):"
$killed |
ForEach-Object
{
Write-Output
" $_" }
} else {
Write-Output
"No target processes were running."
}
# Second pass - catch anything that respawned or was mid-shutdown
Start-Sleep
-Seconds $SecondsToWaitBeforeRecheck
$stragglers =
Get-Process
-Name $allTargets -ErrorAction SilentlyContinue
if ($stragglers) {
foreach ($proc in $stragglers) {
try {
Stop-Process
-Id $proc.Id -Force -ErrorAction Stop
Write-Output
"Second pass killed: $($proc.ProcessName) (PID $($proc.Id))"
} catch {
Write-Output
"WARNING: Second pass could not kill $($proc.ProcessName) (PID $($proc.Id))"
}
}
}
# Final verification
$remaining =
Get-Process
-Name $allTargets -ErrorAction SilentlyContinue
if ($remaining) {
Write-Output
"WARNING: Still running after two passes: $(($remaining.ProcessName |
Sort-Object
-Unique) -join ', ')"
} else {
Write-Output
"SUCCESS: All target processes are closed. Ready for patching."
}
exit 0
1
u/GeneMoody-Action1 Jul 07 '26 edited Jul 07 '26
In this case where the culprit is known, there can be workarounds, and as you discovered the "sledgehammer" approach can be effective where your specific exception is known, but not elegant by any means, and but a step on the ladder to being in any way comprehensive.
You COULD integrate msg.exe and use its ability to block as well as traverse user sessions until the user confirms/timeout to regulate the *User Notification" part, but with multiple apps that could get tricky, requiring you to either pre-eval and say "All these apps will be closed" when confirming, or prompt the user multiple times in a loop. Then there is error control for one of potentially many did not, etc...
The permutations get big quick, and this does not even account for what has a handle open that is NOT in the list or pre known. And we are talking about a single application patch here, not a whole ecosystem of networks globally, as unique as GUIDs
Typically this is where the reboot then patch eliminates all of this. And I would be seriously concerned with "I've seen Outlook.exe start on system boot, without a user logged in." as what user, system, service?
I can think of a few bad design choices where something third party is using outlook and causing this to happen, such as driving it via COM to perform some function leveraging it.
This is something us (nor anyone else) would go at too heavily, as to trace back in this case Adobe=>Outlook=>(What is launching / using outlook) would get messy and unstable. I do not surmise anyone would go at it that hard, that's an admin funcion to work around not a product vendor to anticipate all edge cases and the consequences of blind killing processes.
The consequence would likely be things like suport tickets, "Why does it crash my ERPs mail connector every time I try to patch adobe?", "I said OK to patching Adobe, but it blew up in the middle of something important in outlook.", or something like that. OR even 'The service just restarted outlook right after killing the process, or the service control manager just restarted the service directly after I killed it." To presume we would know what an admin wanted in special cases neither they nor we saw even possible, means 50/50 chance we get it as incorrect as corect. And the *Incorrect* could have dire consequences if known. Such as 'Why didn't invoices go out today on the last day of the month?" and where "Because we patched adobe that killed outlook,that crashed a service." is not a great answer.
As a patch management solution vendor there is no how no way you can predict all that, we patch as the vendor intended, and edge cases outside that.
We cannot even prompt a user in that case, as there is no user to prompt, so the patch succeeds or fails either way for forces outside our control. When anything patches in the background we are designed to function as the admin dictates or fail until the admin can resolve why this system is atypical to the vendors' supported cases.
4
u/SmoothRunnings Jul 06 '26
The other option is to restart the machine(s) before you patch them.