Creating a Local Service Account Remotely on Domain‑Joined PCs (When All You Need Is Task Scheduler Permissions)

Domain‑joined machines give you centralized identity and policy, but real‑world operations don’t always line up with the neat diagrams in onboarding docs. Sometimes you need a local service account — not a full local admin, not a domain user, just a credential that Task Scheduler can run under.

And sometimes, you need to create that account remotely, with nothing but local administrative rights.

I learned this the hard way.
During a layoff cycle, I briefly lost my domain admin access. When I was called back, I returned with only local administrative permissions on several machines — and a backlog of tasks that needed a dedicated service account to run reliably. No domain rights meant no domain user creation. And every GUI‑based method to create a local user remotely was blocked or broken.

But the work still had to get done.
That’s when the old‑school net user command saved the day.

Why a Local Service Account Matters (Even on Domain‑Joined PCs)

This isn’t about giving someone local admin. It’s about creating a minimal‑privilege account that Task Scheduler can run under — one that:

• survives domain outages
• doesn’t depend on your personal domain identity
• doesn’t break when AD replication lags
• doesn’t require domain admin to create
• keeps scheduled tasks isolated and predictable

In my case, I needed an account that could:

• authenticate locally
• run a scheduled task
• and nothing else

That’s exactly what a local service account is for.

The Core Technique: Run the Command On the Remote Machine

The key insight is simple:

You can’t create a local user on a remote machine unless the command executes inside that machine’s local context.

That’s why so many methods fail — they try to create the user from your context, not the remote machine’s.

PowerShell Remoting solves this cleanly:

Invoke-Command -ComputerName <PC> -ScriptBlock {
    net user "TaskSvc" "SuperSecretPassword123!" /add /active:yes
}

This creates a local account on the remote machine, even if you have zero domain privileges.

If the account only needs to run a scheduled task, you don’t need to add it to Administrators.
You only need to grant it:

• “Log on as a batch job”
• permission to run the specific task

You can set that via Local Security Policy or Group Policy, but the account itself is now created and ready.

Assigning “Log on as a batch job”

This is the one right Task Scheduler requires:

Invoke-Command -ComputerName <PC> -ScriptBlock {
    secedit /export /cfg C:\temp\secpol.cfg
    (Get-Content C:\temp\secpol.cfg).Replace("SeBatchLogonRight =","SeBatchLogonRight = TaskSvc") |
        Set-Content C:\temp\secpol.cfg
    secedit /configure /db secedit.sdb /cfg C:\temp\secpol.cfg /areas USER_RIGHTS
}

Or, more simply, if you have GUI access:

Local Security Policy → Local Policies → User Rights Assignment → Log on as a batch job

Add the service account there.

What About the Profile Folder?

A service account doesn’t need a full profile, but Windows will create one automatically the first time the account runs a process. If you want to pre‑create it:

runas /user:TaskSvc cmd.exe

This forces Windows to generate:

C:\Users\TaskSvc

Not required — but sometimes helpful.

Why This Pattern Became My Default

After being laid off and then brought back, I no longer had domain admin rights. But I did have local admin on the machines I was responsible for. And I still had to deliver.

Every GUI method failed:

• Computer Management wouldn’t connect
• MMC snap‑ins refused to enumerate users
• WMI user creation threw access errors
• Domain‑based methods were off the table

But Invoke-Command + net user worked instantly, every time.

It taught me a lesson I should have learned earlier:
Build service accounts that don’t depend on your domain identity.

Now, even with full access restored, I still use this pattern. It’s clean, deterministic, and resilient.

Operator‑Grade Summary

• You can create a local service account remotely using Invoke-Command + net user.
• You only need local admin rights — not domain admin.
• For Task Scheduler, the account only needs “Log on as a batch job.”
• This pattern is ideal for resilient, minimal‑privilege automation.
• It’s especially valuable when domain access is limited or unavailable.