6

I just installed SharePoint 2013 Foundation on a server. I'm confused as to how I can access the PowerShell cmdlets from my client pc. Everything I read assumes you're in front of the actual server. Is there anything like an RSAT module I can install on my client PC?

I don't want to use psremoting, because that has some limitations (I have a lot of custom modules loaded on my client pc). Is there really nothing like say the AD, DNS, DHCP, etc. PowerShell modules, but for SharePoint?

6

You have to be either on the sharepoint server, or use the PSSession module (PSRemote)

New-PSSession -ComputerName SP2013Server

Then add:

Add-PSSnapin Microsoft.SharePoint.Powershell
  • Booo is that really the only way? They have a management shell for Sharepoint Online which looks like what I want, but this is an in house installation (technet.microsoft.com/en-us/library/fp161362(v=office.15).aspx). I'm surprised they have this for the cloud offering, but not in house- or maybe I'm not misunderstanding something? – user1028270 May 27 '14 at 16:44
  • 3
    Nope, that's the way it is. Probably for security reasons, but I agree the parts available in the Online shell could be available for client in on prem as well – Robert Lindgren May 27 '14 at 16:46
  • @user1028270 you could just add it to your profile.ps1 and you wouldn't have to remember the command – Kolob Canyon Oct 28 '16 at 2:47
17

Instead of using PowerShell Remoting with SharePoint you could consider another approach.

Since SharePoint 2013 supports several sets of APIs, you could utilize client APIs (CSOM/REST) in PowerShell.

As you already mentioned Microsoft released Windows PowerShell for SharePoint Online for working with SharePoint Online. This SDK uses CSOM as the underlying API for SharePoint Online cmdlets.

To summarize, instead of using PowerShell based on Server Side Object Model (SSOM), it is proposed to perform an operations using client APIs (CSOM/REST) in PowerShell

Example

Get-SPFeature cmdlet returns the SharePoint Features, for example:

Get-SPFeature -Limit ALL | Where-Object {$_.Scope -eq "SITE"}

The CSOM version:

$context = New-Object Microsoft.SharePoint.Client.ClientContext($url)
$siteFeatures = $context.Site.Features 
$context.Load($siteFeatures) 
$context.ExecuteQuery()

The REST version:

$Url = "https://tenant.sharepoint.com/_api/site/features"
$data = Invoke-RestSPO $Url Get $UserName $Password

Invoke-RestSPO is a custom cmdlet, follow this post for a details.

References

  • 1
    Nice alternative approach! – Robert Lindgren May 27 '14 at 21:29
  • Both of these seem to require Microsoft.SharePoint.Client.dll. Which I'm not sure if is up-to-date. – Nae Oct 16 '18 at 8:12
  • 1
    @Nae, yep, it has a dependency to SharePoint Client SDK which could be downloaded here – Vadim Gremyachev Oct 16 '18 at 8:16
  • 1
    @VadimGremyachev Thanks for the reply, can you also verify that this is compatible with Office365's Sharepoint? – Nae Oct 16 '18 at 8:18
  • 1
    @Nae, i confirm it, the provided link for SDK which targets Office365/SharePoint Online – Vadim Gremyachev Oct 16 '18 at 8:20
1

An alternative to the snapin is to load the module directly in PowerShell.

& ' C:\Program Files\Common Files\Microsoft Shared\Web Server Extensions\15\CONFIG\POWERSHELL\Registration\\sharepoint.ps1 '
  • ....and the syntax to load the module would be? Putting single quotes around the path to it ain't it... – vapcguy Mar 12 at 20:05
  • The ampersand "&" symbol means 'execute what follows'. You could also CD to that path on a SharePoint Server and execute the sharepoint.ps1 directly. – Underverse Mar 18 at 7:26
  • I get The term 'sharepoint.ps1' is not recognized as the name of a cmdlet, function, script file, or operable program. Check the spelling of the name, or if a path was included, verify that the path is correct and try again. At line:1 char:1 + sharepoint.ps1 +~~~~~~ +CategoryInfo: ObjectNotFound: (sharepoint.ps1:String) [], CommandNotFoundException +FullyQualifiedErrorId: CommandNotFoundException Suggestion [3,General]: The command sharepoint.ps1 was not found, but does exist in the current location. Windows PowerShell does not load commands from the current location by default. – vapcguy Mar 18 at 15:26
  • If you trust this command, instead type: ".\sharepoint.ps1". See "get-help about_Command_Precedence" for more details. So I tried .\sharepoint.ps1 instead and got Add-PsSnapin : No snap-ins have been registered for Window PowerShell version 5. - which of course is the very thing I've been trying to workaround. Same error if I use the "&" technique. Note that I'm attempting this on another computer than the SharePoint server, just like the OP, and just copied sharepoint.ps1 to it. Maybe there's other things it needs from the server? – vapcguy Mar 18 at 15:28
1

The is no need to open a PSSession with the server, you can just use the CSOM service as @vadim says (another answer in this thread), in order to work with lists or Sharepoint sites data. Here is a very good guide which details the first steps: https://www.itunity.com/article/connecting-spo-csom-api-powershell-1038

  • As I understand it, the PowerShell snap-in has more capabilities than the CSOM. (It's more comparable to the SSOM.) – jpaugh Aug 30 '17 at 18:23
  • that's correct @jpaugh – Mike Sep 4 '18 at 21:28
  • 1
    Link only answers are discouraged, and this one is now broken. Saying "Use the CSOM service" is incredibly vague. Summarize what other pages say so answers here don't become useless. – vapcguy Mar 12 at 22:16
  • 1
    It's a good idea to copy across the relevant points when posting answers. That website currently throws a 404 – Underverse Mar 18 at 5:53

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.