How to Run PowerShell as Different User

I’ve had plenty of moments where I needed to open PowerShell with another account just to test permissions, access a secured share, or run a script under an admin profile. It usually happens when your current session does not have the right rights, but you do not want to log off and back on.

That is where run PowerShell as different user becomes useful. In this guide, I’ll show you the practical ways to launch PowerShell under another account, when to use each method, and what to watch out for.

This Tutorial Covers:

Run PowerShell as Different User: The Right Approach

In real environments, I use this for troubleshooting, permission checks, and running admin-only commands without changing my main desktop session.

The most common options are:

Using Run as different user from the Start menu or shortcut.
Starting PowerShell from Command Prompt with alternate credentials.
Using RunAs for a one-time elevated session.
Using Start-Process when you want to launch a script or another PowerShell window.

If you only need to test one command, the quickest method is usually a right-click launch. If you need repeatable automation, Start-Process or a saved shortcut is cleaner.

What “Different User” Means

When you run PowerShell as a different user, Windows starts a new process under another account. That account can have different access to files, network shares, registry keys, or admin-only resources.

A cmdlet is a built-in PowerShell command like Start-Process or Get-ChildItem. A parameter is the option you pass to a cmdlet, like -Credential or -Verb RunAs. The pipeline is the | symbol that sends output from one command to the next.

For example, if your normal account cannot read a folder, the alternate account might be able to. That is why this technique is so useful in Windows automation and admin troubleshooting.

Method 1: Start Menu or Shortcut

The easiest way is to launch PowerShell with another user account from Windows itself. This works well when you want a quick interactive session.

Steps

Hold Shift and right-click the PowerShell shortcut.
Choose Run as different user.
Enter the username and password of the other account.
Wait for the new PowerShell window to open under that identity.

This method is simple because Windows handles the authentication for you. It is best for manual checks, not for script automation.

Here is a screenshot for your reference:

Why I use it

I use this when I need to confirm whether a permissions issue is tied to the account, not the script. It is also useful when testing network access to a file share or SharePoint-related admin task.

Method 2: RunAs from Command Line

If you already have a Command Prompt window open, you can start PowerShell with another user by using runas.

runas /user:DOMAIN\AdminUser powershell.exe

runas starts a program under another user account.
/user:DOMAIN\AdminUser tells Windows which account to use.
powershell.exe opens Windows PowerShell in that session.

If you want PowerShell 7, replace the executable name with pwsh.exe if it is installed.

runas /user:DOMAIN\AdminUser pwsh.exe

This is a good option when you want a quick alternate session without leaving the keyboard. It is also handy in remote admin workflows.

Method 3: Start-Process with Credentials

For script-based work, Start-Process is often the cleanest approach. It lets you launch a new PowerShell process with a different user and, in some cases, with elevation.

$cred = Get-Credential
Start-Process powershell.exe -Credential $cred

Get-Credential opens a secure prompt for username and password.
$cred stores the credentials in a credential object.
Start-Process launches a new PowerShell window with those credentials.

This is useful when you want a repeatable pattern in a script file. A script file is just a .ps1 file that contains PowerShell commands.

If you want to launch a specific script file, use:

$cred = Get-Credential
Start-Process powershell.exe -Credential $cred -ArgumentList '-File "C:\Scripts\Test.ps1"'

Why this matters

This method gives you more control than a right-click launch. It is the one I prefer when I need a consistent admin workflow.

Pro Tip: I’ve found that alternate-user sessions often fail for the same reason scripts fail later: the account lacks rights to a folder, a share, or a registry path. Test the identity first, then test the script.

Windows PowerShell vs PowerShell 7

The launch idea is the same in both versions, but the executable changes. Windows PowerShell uses powershell.exe, while PowerShell 7 uses pwsh.exe.

If your environment mixes older scripts and newer automation, this matters. Some modules still work best in Windows PowerShell, especially older admin tools. PowerShell 7 is great for modern cross-platform work, but the alternate-user launch still depends on what is installed.

If you want a broader refresher on PowerShell basics, read this tutorial on how to check PowerShell version.

Using Alternate User with Scripts

If you need to run a script under another user, think about the workflow first. Do you want the script to run interactively, or do you want it to run in the background?

A practical pattern looks like this:

$cred = Get-Credential
Start-Process powershell.exe -Credential $cred -ArgumentList '-NoProfile -ExecutionPolicy Bypass -File "C:\Scripts\Inventory.ps1"'

Why these options help

-NoProfile avoids loading the user’s profile scripts.
-ExecutionPolicy Bypass helps when the policy blocks a trusted local test.
-File runs a specific script directly.

Be careful with execution policy. It is a safety setting that helps control which scripts can run. Do not use bypass casually in production unless you understand the risk.

For safer scripting habits, the article on Try Catch in PowerShell is a good next read.

Things to Keep in Mind

Use the right account. A domain admin, local admin, and standard user can behave very differently.
Test without damage first. Run read-only checks before you change files, services, or registry settings.
Avoid storing plain-text passwords. Use Get-Credential or a secure secret store instead.
Watch execution policy. Policy blocks are common, but do not weaken security without a reason.
Check module availability. Some commands only work when the needed module loads under that user.
Remember profile differences. A different user may have different PATH values, aliases, or profile scripts.

Frequently Asked Questions

How do I run PowerShell as different user without admin rights?

You can still start PowerShell under another account if you know that account’s credentials. That account does not have to be an administrator. The key point is that Windows must allow the sign-in and the target account must have the needed access.

Can I run a PowerShell script as another user?

Yes. The common pattern is to use Start-Process with Get-Credential and pass -File to the script. That lets the script run in a separate process under the alternate identity.

What is the difference between RunAs and Start-Process?

runas is a Windows command that launches a program under another account. Start-Process is a PowerShell cmdlet that gives you more scripting control. I usually pick runas for quick manual work and Start-Process for automation.

Does PowerShell 7 use the same command?

The idea is the same, but the executable is usually pwsh.exe instead of powershell.exe. If you launch the wrong one, you may open the older shell by mistake. That matters when a script depends on a specific version.

Why does my alternate-user session still not have access?

The account may lack folder permissions, admin rights, or network permissions. It can also be blocked by execution policy or missing modules. I usually test access with a simple read command first, then move to the real task.

Is it safe to use execution policy bypass?

It is safe only in the right context, such as a trusted local test or a controlled admin workflow. Do not use it to hide script issues. Fix permissions, signing, or deployment settings when you move into production.

Running PowerShell as different user is really about choosing the right identity for the job. Start small, test carefully, and then automate more once you are confident. I hope you found this article helpful.