Introduction
A few months ago, I was working on a SAP Build Process Automation (BPA) project that started small — just a handful of users running an Excel-driven automation , worked on my machine, on the test users’ machines, and even during the pilot. Then came rollout.
The user base jumped from 20 to a few hundred, with plans to reach 1000+. Suddenly, the install the SAP Desktop Agent on every machine model didn’t feel so simple anymore. Some laptops had restricted admin rights, Some users worked outside the company. Every failure ticket had a different root cause agent not running, Excel version mismatch, SSO token expired, machine asleep at scheduled run time.
That’s when we made the call: stop running automations on user desktops, and move them to an RDP / VM-based execution model.
A second Use-case:
Requirement: We need an automation that picks up a file and processes it every day at 12:00 AM, 12:00 PM, 3:00 AM, and 3:00 PM.
Simple enough — BPA has a built-in timer trigger for exactly this. I built it, tested it and scheduled it on my local agent.
Then the reality check.
At 3:00 AM, my laptop was off. At 12:00 AM, it was asleep. When I opened it in the morning, BPA happily triggered the job — several hours late.
Here’s the thing nobody tells you when you first start with BPA schedulers:
The timer runs in the cloud, but the automation runs on the agent.
If the agent (your laptop) is off, locked, or disconnected, the trigger just queues up and waits.
So a 3:00 AM job on a developer’s laptop is basically a 9:00 AM job whenever the developer walks in.
This is exactly the kind of scenario where an RDP / VM-based agent shines:
- The VM is always on.
- The VM is always logged in (under a technical user).
- The VM is always connected to BPA.
- The timer fires at 3:00 AM → the VM picks it up at 3:00 AM. Done.
After moving that automation to the VM, the scheduled runs became reliable — which is exactly what you want from a scheduled job.
What is RDP in this context?
In simple terms: instead of the automation running on each end user’s laptop, it runs on a centrally managed virtual machine where the SAP Desktop Agent is installed once. Users don’t need the agent — they just trigger the process (via a Fiori form, workflow task, or API), and the VM does the heavy lifting.
Workflow Vs Automation
- Workflow → runs in the cloud, no agent needed.
- Automation → touches Excel, SAP GUI, PDFs, Outlook → needs an agent → needs a machine.
Once we accepted that automations always need a machine somewhere, the question became: whose machine? Every user’s, or one VM we control?
RDP is a solution where the automation runs on a virtual machine (VM) instead of on each user’s personal desktop. In this model, the user does not need to install the agent on their local machine. Instead, the automation is triggered and executed in the VM environment, which is centrally managed.
This is especially useful when:
- many users need access to the same automation
- the process must run consistently without depending on a user’s local machine
- the user machine is not always available or is restricted by security policies
- you want to reduce installation and maintenance effort
What worked well for us
Here’s what genuinely made life easier after the switch:
1. One agent to maintain, not hundreds.
Patching, version upgrades, and Excel/Outlook compatibility issues went from “coordinate with IT for 500 machines” to “log into the VM and fix it once.”
2. Runs even when the user is offline.
This was huge. Users would trigger a process at end of day, log off, and go home. The VM continued executing overnight. Previously, the automation would freeze the moment their laptop went to sleep.
3. Cleaner authorization model.
We use a technical user for backend calls on the VM. No more chasing individual user role assignments across S/4HANA.
The challenges nobody warned us about
This is the part I wish someone had written a blog about before we started. So here it is.
Challenge 1: SSO doesn’t behave the way you think in a VM
Our first big surprise. The automation was calling a BAPI via the SAP GUI script, and it kept failing with authorization errors — even though the same script worked perfectly on a user’s laptop.
The reason: the VM agent runs under a service/technical account, not the actual end user’s SSO context. SSO ticket propagation simply doesn’t work the way it does on a user’s own desktop session.
What we did: switched BAPI-based calls to Basic Authentication with a technical user, and for anything customer-facing, moved to OData actions instead of GUI scripting. Cleaner, faster, and doesn’t depend on GUI at all.
Challenge 2: Agent disconnects at the worst possible time
The VM agent occasionally went into a “disconnected” state — usually after Windows updates or network blips. Because we didn’t have monitoring on it initially, we only found out when users complained that their tasks were stuck.
solution:
- Added an alert on the BPA agent status.
Challenge 3: File and folder access
The automation reads Excel files uploaded by users. On a desktop setup, this was easy — the file was already local. On the VM, we had to build an upload path: user uploads via a form → file lands in a shared folder (or SAP Document Management) → VM picks it up.
Small architectural change, but it caught us mid-project.
Challenge 4: Session locking on the VM
If someone RDP into the VM interactively and locked the screen, some automations (especially GUI-based ones) would fail because the desktop session was locked. We ended up disabling interactive login for the technical user during business hours.
When to use a Local Desktop Agent vs. an RDP / VM Agent
Go with a Local Desktop Agent when:
Go with RDP / VM-based execution when:
|
Configuration checklist we now use
Before going live with any VM-based BPA automation, we run through this list. Sharing it here so you don’t have to build one from scratch:
- VM agent is registered in BPA and shows as connected/healthy
- Excel, Outlook, SAP GUI, and PDF viewer are installed and licensed on the VM
- Shared folders / network drives / DMS paths are accessible from the VM
- Technical user has required S/4HANA / backend role assignments
- Basic Authentication configured for BAPI-based destinations (not SSO)
- Session lock policy on the VM is handled (don’t let RDP sessions lock during runs)
- Windows Update / patch window is scheduled outside automation run times
- Monitoring/alerting on agent status is in place
- End-to-end test with a real trigger, real file, real user — not just a dev sandbox
Not everything in BPA needs an agent. Design your process so that the workflow part (approvals, decisions, notifications) stays in the cloud, and only the desktop-dependent automation part touches the VM.
Conclusion
Moving to RDP / VM-based execution it was one of the highest-impact changes in the project. It turned a fragile, hard-to-support automation into something we now confidently run for hundreds of users — with a clear path to scaling further.
If you’re at the point where you’re installing the SAP Desktop Agent on your fifth, tenth, or hundredth user machine — pause. Consider whether a VM-based setup would save you months of support pain later.
Key takeaways in one line each:
- Workflow can run agentless. Automation almost always needs an agent — the question is where.
- One VM > many user desktops, once you cross a small user threshold.
- Use Basic Auth with a technical user for BAPI calls in VM context. SSO won’t behave as expected.
- Prefer OData actions over GUI scripting wherever possible.
This approach makes the process more reliable, scalable, and easier to manage in enterprise environments.
#abap