How to Remotely Manage SharePoint On-Premises With PowerShell and Client Tools

There are two ways to manage a SharePoint Server farm without signing in to the servers. For farm-level work, use PowerShell remoting with CredSSP, so SharePoint cmdlets run on the server but you type them at your own workstation. For site-level work, such as inventories, permissions and content, use a client-side tool that talks to SharePoint over HTTPS and needs nothing installed on the farm, such as the free SharePoint Essentials Toolkit Community Edition.

Published:

Last updated: 2026-10-29

Why manage SharePoint remotely?

  • Security. Fewer people sign in to server desktops, and the servers keep a smaller attack surface.
  • One place for scripts. One admin workstation can run the same script against several farms, such as test, staging and production.
  • Less friction. No more jumping through remote desktop for a two-line command.
Version check. SharePoint Server 2016 and 2019 reached the end of extended support on July 14, 2026. Everything here still works on them, and it works the same on SharePoint Server Subscription Edition. If you are still on 2016 or 2019, the inventory steps below are also the first phase of a move to SharePoint Online.

Which method fits which task?

TaskPowerShell remotingClient-side tool (CSOM or REST)
Services, service applications, timer jobsYesNo
Content databases, moving site collections between databasesYesNo
Patching, farm configuration, Central Administration settingsYesNo
Site, list and library inventoriesYes, with scriptingYes
Permissions reports, broken links, content searchYes, with a lot of scriptingYes
Copying lists and sites to SharePoint OnlineNoYes
Needs anything installed or enabled on the serversWinRM and CredSSPNo

Option 1: PowerShell remoting for SharePoint Server

Why CredSSP?

SharePoint cmdlets run on the SharePoint server, which then connects to SQL Server. That is a second hop. A normal remoting session can't pass your credentials on, so cmdlets fail with The local farm is not accessible. CredSSP delegates your credentials to the SharePoint server so it can reach SQL Server as you. Microsoft explains the second-hop problem in Making the second hop in PowerShell Remoting.

1. Prepare the SharePoint server

Pick one server to remote into, usually an application server. Run these in an elevated SharePoint Management Shell on that server:

# Turn on WinRM and its firewall rule (often already on in Windows Server)
Enable-PSRemoting -Force

# Let this server accept delegated credentials
Enable-WSManCredSSP -Role Server -Force

# SharePoint cmdlets need more memory than the default shell allows
Set-Item WSMan:\localhost\Shell\MaxMemoryPerShellMB 2048

# Give the admin account shell access to the configuration and content databases
Get-SPDatabase | Where-Object { $_.Type -in "Configuration Database", "Content Database" } |
    ForEach-Object { Add-SPShellAdmin -UserName "CONTOSO\sp-admin" -Database $_ }

# Allow the account to open a remote session
Add-LocalGroupMember -Group "Remote Management Users" -Member "CONTOSO\sp-admin"

If you prefer, run Set-PSSessionConfiguration -Name Microsoft.PowerShell -ShowSecurityDescriptorUI and grant the account Read and Execute instead of using the local group. Older guides use Microsoft.PowerShell32; SharePoint is 64-bit, so use Microsoft.PowerShell.

2. Prepare your workstation

On your admin workstation, in an elevated Windows PowerShell 5.1 window, allow delegation only to the server's fully qualified name:

Enable-WSManCredSSP -Role Client -DelegateComputer "sp-app01.contoso.com" -Force

Find the fully qualified name with Resolve-DnsName sp-app01 if you aren't sure. Don't use wildcards such as *.contoso.com: they let your credentials go to any machine in the domain.

3. Connect and run SharePoint cmdlets

$cred = Get-Credential "CONTOSO\sp-admin"
$s = New-PSSession -ComputerName "sp-app01.contoso.com" -Authentication Credssp -Credential $cred

Invoke-Command -Session $s -ScriptBlock {
    Add-PSSnapin Microsoft.SharePoint.PowerShell -ErrorAction SilentlyContinue
    Get-SPContentDatabase | Select-Object Name, WebApplication, CurrentSiteCount,
        @{ n = "SizeGB"; e = { [math]::Round($_.DiskSizeRequired / 1GB, 1) } }
}

Invoke-Command -Session $s -ScriptBlock {
    Get-SPServiceInstance | Where-Object Status -eq "Online" | Select-Object TypeName, Server
}

For an interactive prompt on the server, run Enter-PSSession $s. The prompt changes to [sp-app01.contoso.com]: PS>, and every command runs on the server. Type Exit-PSSession to leave, and Remove-PSSession $s when you're done.

4. Example: create a document library remotely

Invoke-Command -Session $s -ScriptBlock {
    Add-PSSnapin Microsoft.SharePoint.PowerShell -ErrorAction SilentlyContinue
    $web = Get-SPWeb "https://intranet.contoso.com/sites/legal"
    $id  = $web.Lists.Add("Contracts", "Signed contracts", [Microsoft.SharePoint.SPListTemplateType]::DocumentLibrary)
    $web.Lists[$id].OnQuickLaunch = $true
    $web.Lists[$id].Update()
    $web.Dispose()
}

Keep CredSSP safe

  • Use it only from dedicated admin workstations, never from a shared or general-purpose PC.
  • Delegate only to named SharePoint servers, as above.
  • Turn it off when a project ends: Disable-WSManCredSSP -Role Client on the workstation and Disable-WSManCredSSP -Role Server on the server.
  • Across untrusted networks, add an HTTPS listener (port 5986) instead of using HTTP (5985).
  • Turn on PowerShell transcription or script block logging so remote sessions are recorded.
  • If CredSSP isn't allowed in your organization, Kerberos constrained delegation from the SharePoint server to SQL Server solves the second hop without sending credentials, but it needs Active Directory changes.

Troubleshooting

ErrorLikely cause
Access is denied when opening the sessionThe account isn't in Remote Management Users, or lacks Execute on the session configuration.
The local farm is not accessibleThe session isn't using CredSSP, or the account has no SharePoint_Shell_Access role (run Add-SPShellAdmin).
The WinRM client cannot process the request ... CredSSPThe client delegation list doesn't include the exact name you connected to. Connect with the fully qualified name you delegated to.
Cmdlets stop with out-of-memory errorsMaxMemoryPerShellMB is too low on the server.

Option 2: Manage sites without touching the servers

Most day-to-day SharePoint administration is site-level: who has access, what's in each site, what's broken, what's old. None of that needs server access. SharePoint's client object model (CSOM) and REST API expose it over the same HTTPS address users browse to.

SharePoint Essentials Toolkit is a Windows desktop app built on those APIs. Nothing is installed on the farm.

  1. Add a connection with your web application URL, for example https://intranet.contoso.com. The toolkit detects that it's on-premises.
  2. Choose Windows account to sign in as the account running the toolkit (Kerberos or NTLM), or Username & password to use a stored account.
  3. Pick sites and run a report. The reports run with the permissions of the account you signed in with, so use an account with access to the sites you're auditing.

Free in Community Edition, on up to 20 site collections:

The same app connects to SharePoint Online, so one workstation covers the farm and the tenant. For the SharePoint Online side in PowerShell, see Manage SharePoint Online with PowerShell.

Frequently asked questions

Why does remote SharePoint PowerShell need CredSSP?

SharePoint cmdlets connect from the SharePoint server to SQL Server. That is a second hop, and a normal Kerberos or NTLM remoting session can't pass your credentials on to it, so cmdlets fail with "The local farm is not accessible". CredSSP delegates your credentials to the SharePoint server so it can reach SQL as you.

Is CredSSP safe?

It sends reusable credentials to the remote server, so a compromised server could capture them. Limit delegation to the SharePoint servers' fully qualified names, use it only from admin workstations, and turn it off when you are done. Kerberos constrained delegation avoids CredSSP but takes more setup.

Does this work with SharePoint Server Subscription Edition?

Yes. The steps are the same for SharePoint Server 2016, 2019 and Subscription Edition. SharePoint Server 2016 and 2019 reached the end of extended support on July 14, 2026, so plan an upgrade or a move to SharePoint Online for those farms.

Can I manage SharePoint on-premises without PowerShell remoting?

For site-level work, yes. Tools that use the client object model or REST, such as SharePoint Essentials Toolkit, connect over HTTPS with your Windows account and need nothing installed on the servers. Farm-level tasks such as services, content databases and patching still need PowerShell on the farm or Central Administration.

What permissions does the remote account need?

Local remote access on the SharePoint server (the Remote Management Users group or the session configuration's permissions), and the SharePoint_Shell_Access role on the configuration and content databases, granted with Add-SPShellAdmin. Farm administrator rights are needed for farm-level cmdlets.

Report on your farm from your desk, free

SharePoint Essentials Toolkit Community Edition is free. Inventory sites, audit permissions, find broken links and copy sites to SharePoint Online on up to 20 site collections, with nothing installed on your servers. Get your free Community Edition license key.

About the author. The Cognillo SharePoint Team builds and supports SharePoint Essentials Toolkit and has worked with SharePoint administrators on permissions audits, migrations and cleanup projects since 2012.