How to Automate Password Resets at Your MSP: From Scripts to AI

9 min read

Password resets account for 20-50% of all help desk tickets at most MSPs. They’re simple, they’re repetitive, and they consume a disproportionate amount of technician time — not because resetting a password is hard, but because the steps around it (identity verification, finding the right directory, generating a compliant password, documenting the action, notifying the user) add up. If your team handles 15-25 password resets per day, that’s 1-2 hours of tech time spent on a task that follows the exact same sequence every time. Automating password resets is the single highest-ROI change most MSPs can make to their help desk operations.

The challenge is that “automate password resets” means different things depending on how far you want to go. A PowerShell script that resets a password in Active Directory is automation. A self-service portal where users reset their own passwords is automation. An AI agent that detects a password reset ticket, verifies the user’s identity, executes the reset via Microsoft Graph API, documents it in your PSA, and notifies the user — all before a tech touches it — is also automation. The outcomes are wildly different.

Here’s what each approach actually looks like, where it breaks down, and what a modern MSP password reset workflow should be.

The Manual Password Reset Process

Before talking about automation, it helps to map the full manual process most MSPs run today:

User submits a ticket (email, phone, chat, or portal)
Technician reads the ticket and identifies it as a password reset
Technician verifies the user’s identity — checks the contact in ConnectWise, cross-references the email or phone number, maybe calls back
Technician identifies the correct directory — on-prem Active Directory, Entra ID (Azure AD), hybrid sync, or a standalone M365 tenant
Technician opens the admin console and resets the password
Technician generates or chooses a temporary password that meets the client’s complexity requirements
Technician communicates the temporary password securely (not in plaintext in the ticket)
Technician documents the action in the PSA with timestamps and notes
Technician closes the ticket

That’s 9 steps. The actual reset — step 5 — takes about 10 seconds. Everything else is overhead. And every step is a place where things go wrong: a tech resets the wrong user’s password because the display name was ambiguous, a temporary password doesn’t meet the client’s complexity policy, the documentation gets skipped because the tech is already on the next ticket.

At 5-10 minutes per reset and 15-25 resets per day, your team is spending 75-250 minutes daily on a task that follows the same pattern every single time.

Password Reset Automation with PowerShell

The first attempt at automation for most MSPs is scripting. PowerShell has been the go-to tool for Active Directory password resets for years:

# The classic approach (on-prem AD)
Set-ADAccountPassword -Identity jsmith -Reset -NewPassword (ConvertTo-SecureString "TempP@ss2026!" -AsPlainText -Force)
Set-ADUser -Identity jsmith -ChangePasswordAtLogon $true

For M365 and Entra ID, the old approach used the now-retired AzureAD or MSOnline modules. Those are dead — Microsoft killed them in 2025. The replacement is Microsoft Graph:

# Microsoft Graph PowerShell SDK
Import-Module Microsoft.Graph.Users
Connect-MgGraph -Scopes "User.ReadWrite.All"

Update-MgUser -UserId "jsmith@contoso.com" -PasswordProfile @{
  Password = "TempP@ss2026!"
  ForceChangePasswordNextSignIn = $true
}

Or via direct Graph API call:

PATCH https://graph.microsoft.com/v1.0/users/{userId}
{
  "passwordProfile": {
    "password": "TempP@ss2026!",
    "forceChangePasswordNextSignIn": true
  }
}

Where PowerShell Falls Short

PowerShell handles the reset itself. It doesn’t handle anything around it:

No identity verification. The script assumes the tech already confirmed who’s asking. There’s no automated check against the contact record in your PSA.
No client-aware password policy. Client A requires 16-character passwords with special characters. Client B requires 12-character alphanumeric. The script doesn’t know the difference.
No cross-tool documentation. The reset happens in AD or Entra ID, but ConnectWise doesn’t know about it unless the tech manually updates the ticket.
No secure delivery. Generating a temporary password is one thing. Getting it to the user without putting it in a ticket note or email body is another.
No audit trail beyond the directory logs. If someone asks “who reset this password and why?” three months later, you’re digging through event logs.
No hybrid directory handling. If the client has on-prem AD synced to Entra ID, resetting in the wrong place causes sync conflicts. The script doesn’t detect this.

Scripts are a tool. They’re not a workflow.

Self-Service Password Reset Portals

The next evolution is self-service: give users a portal where they can reset their own passwords without submitting a ticket at all.

Microsoft’s Self-Service Password Reset (SSPR) is the most common option for M365 environments. When configured, users go to passwordreset.microsoftonline.com, verify their identity via MFA, and reset their own password.

The SSPR Gap for MSPs

Self-service works well inside a single organization. For MSPs managing 30-100 tenants, the picture changes:

Configuration at scale. SSPR needs to be enabled, configured, and maintained per tenant. Authentication methods (phone, email, authenticator app) need to be set up for every user across every client. That’s a project, not a setting.
User adoption. The users who submit password reset tickets are often the same users who haven’t registered for SSPR, don’t know it exists, or can’t complete the MFA challenge because the password they forgot is the one tied to their authenticator.
On-prem AD. SSPR handles Entra ID natively. For clients with on-prem Active Directory (even synced to Entra), you need Azure AD Connect with password writeback enabled. Not every client has that configured.
Coverage. Even with SSPR deployed across every tenant, a significant percentage of users will still call or email instead of using the portal. Industry data suggests SSPR deflects 30-60% of password reset tickets. The rest still land on your help desk.

Self-service reduces volume. It doesn’t eliminate the workflow problem for the resets that still come through as tickets.

AI-Driven Password Reset Automation

The approach that actually solves the whole problem — identity verification, directory detection, policy compliance, execution, documentation, and notification — is an AI-driven runbook that handles the complete workflow end to end.

This is what runbooks that run themselves look like in practice. Here’s the step-by-step workflow:

Step 1: Ticket Classification

A ticket comes into ConnectWise. The AI reads the subject and body, classifies it as a password reset, and triggers the password reset runbook. No manual triage needed — the same intake process that handles ticket triage at scale catches it automatically.

Step 2: Identity Verification

The runbook pulls the requestor’s contact record from ConnectWise and cross-references it with the ticket metadata. It checks:

Does the email address on the ticket match the contact record?
Was the ticket submitted through an authenticated channel (client portal vs. forwarded email)?
Does the user record in Entra ID / Active Directory match the contact?

If the identity check passes, the runbook continues. If it fails or is ambiguous, it flags the ticket for a tech to verify manually. This is human-in-the-loop AI applied to the most basic security step most MSPs skip under time pressure.

Step 3: Directory Detection

The runbook identifies the client’s directory environment:

Cloud-only Entra ID — reset via Microsoft Graph API
On-prem Active Directory — reset via the NinjaOne or RMM agent running a local script
Hybrid (AD Connect with sync) — reset in on-prem AD and wait for sync, or reset in Entra ID if password writeback is enabled

This step alone prevents the sync conflict errors that cause repeat tickets.

Step 4: Password Generation and Reset

The runbook generates a temporary password that meets the specific client’s complexity requirements — pulled from the client’s configuration in the platform, not hardcoded in a script. It then executes the reset through the appropriate API:

Entra ID: Microsoft Graph API resetPassword endpoint
On-prem AD: PowerShell Set-ADAccountPassword executed via RMM agent
Hybrid: Whichever path the client’s environment supports, with writeback awareness

The password is flagged as requiring change on next sign-in.

Step 5: Secure Notification

The runbook sends the temporary password to the user through a secure channel — not in the ticket body. Options include a time-limited secure link, a direct message in Teams, or an encrypted email, depending on the client’s preference.

Step 6: Documentation and Closure

The runbook updates the ConnectWise ticket with:

Timestamped log of every action taken
Which directory was used
Confirmation that the password was reset and the user was notified
Resolution category and closure notes

The ticket closes automatically. The full audit trail lives in the PSA, not scattered across directory event logs.

The Complete Workflow at a Glance

Ticket arrives → Classify as password reset → Verify identity against PSA contact
  → Detect directory type (Entra ID / AD / Hybrid)
  → Generate compliant temporary password
  → Execute reset via Graph API or RMM agent
  → Send secure notification to user
  → Document in ConnectWise → Close ticket

Total tech involvement: zero for standard resets, 30 seconds for flagged identity checks.

Per-Client Configuration: Why It Matters

MSPs don’t have one password reset process. They have one per client. The automation has to respect that.

With Junto, password reset runbooks support per-client configuration using three runbook modes:

AI mode (full auto): The entire workflow runs without tech intervention. Best for clients with authenticated portal submissions and clear identity verification paths.
Hybrid mode (selective approval): The runbook prepares everything but pauses before executing the reset for tech approval. Best for clients who require a human checkpoint.
Human mode (guided checklist): The runbook provides the step-by-step guide and pulls all the context, but the tech executes each step. Best for clients with unusual directory configurations or strict compliance requirements.

Client A requires manager approval before any password reset outside business hours. Client B allows fully automated resets for portal-submitted tickets. Client C has a legacy on-prem AD environment that requires manual RDP to the domain controller. All three configurations run on the same runbook with different settings — no forking, no separate scripts.

This is the same per-client architecture that powers automated user onboarding and every other runbook in the system.

Measuring the Impact of Password Reset Automation

The math on password reset automation is straightforward:

Metric	Manual	Scripted	AI Runbook
Time per reset	5-10 min	2-4 min	0-30 sec
Identity verification	Manual (often skipped)	None	Automated
Documentation	Manual (often incomplete)	None	Automatic
Per-client policy compliance	Tech’s memory	Hardcoded	Configured
Error rate	High (wrong user, wrong password policy)	Medium (no context)	Low (verified end-to-end)

At 20 resets per day and 5 minutes saved per reset, that’s 100 minutes of tech time recovered daily — roughly 36 hours per month. For a tech billing at $150/hour, that’s $5,400/month in recovered capacity from a single runbook.

But the bigger win isn’t time. It’s consistency. Every reset follows the same process, every identity check happens, every action is documented, and every client gets their specific policy enforced. No shortcuts under pressure, no steps skipped at 4:55 PM on a Friday.

Getting Started

If password resets are eating your help desk capacity, the progression is clear:

If you’re fully manual: Start by standardizing the process. Map out your 9-step workflow and identify which steps can be scripted.
If you’re using PowerShell scripts: You’ve automated the reset itself. Now look at what’s missing — identity verification, per-client policies, documentation, notification. Those are the steps that take the most time.
If you have SSPR deployed: Good — you’ve reduced volume. Now automate the tickets that still come through.
If you want the full workflow automated: That’s what Junto’s password reset runbook does end to end — from ticket intake to identity verification to execution to documentation, with per-client configuration and human-in-the-loop controls where you need them.

Password resets are the smallest, most frequent, most well-defined ticket your MSP handles. They’re the proof case for automation. If your system can’t automate a password reset reliably, it can’t automate anything else either.

See how it works at juntoai.com.