Powershell: Connect-SPOService : The term 'Connect-SPOService' 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.

[ghost]

Steps to reproduce

Installed PowerShell though: $ yaourt -S powershell
Then tried to connect:

`PS /home/... > Connect-SPOService -Url "https://***-admin.sharepoint.com" -Credential "***@***.***"`

Expected behavior

That Connect-SPOService is working.

Actual behavior

Connect-SPOService : The term 'Connect-SPOService' 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
+ Connect-SPOService -Url "https://***-admin.sharepoint.com" -Cred ...
+ ~~~~~~~~~~~~~~~~~~
    + CategoryInfo          : ObjectNotFound: (Connect-SPOService:String) [], CommandNotFoundException
    + FullyQualifiedErrorId : CommandNotFoundException

Environment data

PS /home/...> $PSVersionTable                                                                                             

Name                           Value                                                                                             
----                           -----                                                                                             
PSVersion                      6.0.0-beta                                                                                        
PSEdition                      Core                                                                                              
GitCommitId                    v6.0.0-beta.3                                                                                     
OS                             Linux 4.12.4-1-ARCH #1 SMP PREEMPT Fri Jul 28 18:54:18 UTC 2017                                   
Platform                       Unix                                                                                              
PSCompatibleVersions           {1.0, 2.0, 3.0, 4.0...}                                                                           
PSRemotingProtocolVersion      2.3                                                                                               
SerializationVersion           1.1.0.1                                                                                           
WSManStackVersion              3.0     

[mklement0]

The error message just tells us that a cmdlet by that name doesn't exist (and isn't defined in an auto-loading module).

Generally, many cmdlets simply don't work on PS _Core_ (yet), given that the underlying frameworks differ - see Known Issues.

More specifically, this issue suggests that the SharePoint cmdlets are contained in a _snapin_, which PS _Core_ fundamentally doesn't support. This blog post states that a module is now being used for the Sharepoint Online cmdlets, but as @markekraus demonstrates below, the issue is that the included DLL is compiled for the Windows-only full .NET Framework.

On a side note: Generally, please make sure that you're running the _latest_ version of PS Core before reporting issues (you're running beta _3_ - current is beta _5_).

[markekraus]

You can import the SharePoint Online Management Shell using this:

$SPOModulePath = 'C:\Program Files\SharePoint Online Management Shell\'
$adminUPN = '[email protected]'
$orgName = 'adatum'

$userCredential = Get-Credential -UserName $adminUPN
$Env:PSModulePath = '{0};{1}' -f $Env:PSModulePath, $SPOModulePath
Import-Module Microsoft.Online.SharePoint.PowerShell -DisableNameChecking
$uri = "https://$orgName-admin.sharepoint.com"
Connect-SPOService -Url $uri -Credential $userCredential

But, there is a some kind of compatibility issue in Microsoft.SharePoint.Client.ClientContext.GetFormDigestInfoPrivate() where it is sending a 0 length SOAP POST to SharePoint Online when trying to determine if it has a tenant admin site or not. Connect-SPOService always returns The remote server returned an error: (400) Bad Request. in beta.5.
It looks like is has something to do with the way it uses System.IO.TextWriter to write to the System.Net.RequestStream. In any case, that is something for either the SharePoint Online Module maintainers to correct or something in CoreFX.

[ghost]

@mklement0, thanks, but Arch has only the beta3 at the moment (I like indeed having the latest software and so using Arch is part of it).

@markekraus, on the line Import-Module Microsoft.Online.SharePoint.PowerShell -DisableNameChecking I get:

PS /home/...> Import-Module Microsoft.Online.SharePoint.PowerShell -DisableNameChecking                                                                           
Import-Module : The specified module 'Microsoft.Online.SharePoint.PowerShell' 
was not loaded because no valid module file was found in any module directory.
At line:1 char:1
+ Import-Module Microsoft.Online.SharePoint.PowerShell -DisableNameChec ...
+ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
    + CategoryInfo          : ResourceUnavailable: (Microsoft.Online.SharePoin 
   t.PowerShell:String) [Import-Module], FileNotFoundException
    + FullyQualifiedErrorId : Modules_ModuleNotFound,Microsoft.PowerShell.Comm 
   ands.ImportModuleCommand

[mklement0]

@passboltUser: I see re Arch Linux packages; I have not tried myself (except on Ubuntu), but, based on the installation instructions, I'd expect running the installation script directly to work on Arch Linux too, which would get you the latest release:

bash <(curl -fsSL https://raw.githubusercontent.com/PowerShell/PowerShell/master/tools/download.sh)

[ghost]

@mklement0, Arch doesn't use .deb-based packages and there's no dpkg installed either. In the script there's only centos, ubuntu and opensuse (maybe you should offer Arch packages). The changelog from beta3 to beta5 also doesn't mention anynthing related to my problem.

[markekraus]

@passboltUser

I don't believe this will work on Linux. I believe the dll's for the SharePoint Online Modules are compiled for Full .NET Framework which would require them to be used on Windows. Regardless, it wont work there either. There is either an issue with CoreFX and compatibility between System.IO.TextWriter and System.Net.RequestStream or that is a "by design" change that would require the SharePoint Online Module maintainers to correct within their module.

This is a PowerShell representation of the C# used in the SharePoint Online Module that is causing the issue.

$Uri = 'https://httpbin.org/post'
$WebRequest = [System.Net.HttpWebRequest]::Create($Uri)
$WebRequest.ContentType = "text/xml"
$WebRequest.Method = 'POST'
$BodyString = "<?xml version=""1.0"" encoding=""utf-8""?>`r`n<soap:Envelope xmlns:xsi=""http://www.w3.org/2001/XMLSchema-instance"" xmlns:xsd=""http://www.w3.org/2001/XMLSchema"" xmlns:soap=""http://schemas.xmlsoap.org/soap/envelope/"">`r`n  <soap:Body>`r`n    <GetUpdatedFormDigestInformation xmlns=""http://schemas.microsoft.com/sharepoint/soap/"" />`r`n  </soap:Body>`r`n</soap:Envelope>"
$WebRequest.Headers["SOAPAction"] = "http://schemas.microsoft.com/sharepoint/soap/GetUpdatedFormDigestInformation"
$WebRequest.Headers["X-RequestForceAuthentication"] = "true"
$RequestStream = $WebRequest.GetRequestStream()

[System.IO.TextWriter]$TextWriter = [System.IO.StreamWriter]::new($RequestStream, [system.text.encoding]::UTF8)
$TextWriter.Write($BodyString)
$TextWriter.Flush()
$WebRequest.GetRequestStream().Close()
$WebRequest.GetRequestStream().Close()
$Response = $WebRequest.GetResponse()
[System.IO.StreamReader]$ResponseStream = $Response.GetResponseStream()
$ResponseStream.ReadToEnd().Trim()
````

5.1 result:

```JSON
{
  "args": {},
  "data": "\ufeff<?xml version=\"1.0\" encoding=\"utf-8\"?>\r\n<soap:Envelope xmlns:xsi=\"http://www.w3.org/2001/XMLSche
ma-instance\" xmlns:xsd=\"http://www.w3.org/2001/XMLSchema\" xmlns:soap=\"http://schemas.xmlsoap.org/soap/envelope/\">\r
\n  <soap:Body>\r\n    <GetUpdatedFormDigestInformation xmlns=\"http://schemas.microsoft.com/sharepoint/soap/\" />\r\n
</soap:Body>\r\n</soap:Envelope>",
  "files": {},
  "form": {},
  "headers": {
    "Connection": "close",
    "Content-Length": "356",
    "Content-Type": "text/xml",
    "Expect": "100-continue",
    "Host": "httpbin.org",
    "Soapaction": "http://schemas.microsoft.com/sharepoint/soap/GetUpdatedFormDigestInformation",
    "X-Requestforceauthentication": "true"
  },
  "json": null,
  "origin": "173.239.232.48",
  "url": "https://httpbin.org/post"
}

6.0.0-beta.5 result:

{
  "args": {},
  "data": "",
  "files": {},
  "form": {},
  "headers": {
    "Connection": "close",
    "Content-Length": "0",
    "Content-Type": "text/xml",
    "Host": "httpbin.org",
    "Soapaction": "http://schemas.microsoft.com/sharepoint/soap/GetUpdatedFormDigestInformation",
    "X-Requestforceauthentication": "true"
  },
  "json": null,
  "origin": "173.239.232.48",
  "url": "https://httpbin.org/post"
}

[mklement0]

@passboltUser:

To be clear: this part of the discussion is just about generally running the latest PS Core version on Arch Linux - looks like @markekraus found the real problem.

Re download script: I see, thanks for letting me know (guess I could have looked at the source myself :).

Supporting Arch Linux too via the download script sounds like a great idea, especially if the official package lags behind. (I'm just a fellow PowerShell user, so I can't speak to plans in that regard.)

Have you tried the beta.5 AppImage release from the releases page? Again, I have no personal experience, but it sounds like AppImages are supported on Arch Linux in principle.
If that works, it shouldn't be too hard to integrate it into the download script.

[markekraus]

@passboltUser I'll ad another wrench in this. The SharePoint Online and SharePointPnPPowerShellOnline Modules both have Microsoft.Win32.Registry dependencies. Obviously, the windows registry is not available on Linux.

You might want to take this issue to SharePoint/PnP-PowerShell and see if they have any plans to make this work with Core and/or Linux.

[ghost]

Thanks @markekraus. So the problem doesn't occur with 5.1? Maybe I should try 5.1?

[markekraus]

@passboltUser assuming you have downloaded and installed the SharePoint Online Module on a Windows system, it should work without issue on Windows PowerShell 5.1. Connect-SPOService is not an included command in PowerShell, you have to install the module and as stated previously it is currently only working on Windows.

[mklement0]

@passboltUser: The system requirements stated for the linked download:

Windows 10 , Windows 7 Service Pack 1, Windows 8, Windows Server 2008 R2 SP1, Windows Server 2008 Service Pack 2, Windows Server 2012, Windows Server 2016

PowerShell 3.0

[ghost]

@markekraus, Connect-SPOService works on Windows without problems. I want to install it on my Arch Linux, since PowerShell is open source and available for Linux from what I read.

[markekraus]

@passboltUser as @mklement0 mentioned earlier not all modules will work on Linux (more info). If a module was made specifically to run on Windows or was compiled to use the Full .NET framework, it will not run on Linux. That is not an issue with PowerShell Core. As mentioned, this module has dependencies on the Windows Registry. That means it definitely cannot run on Linux as Linux does not have a Windows Registry. It would be up to the module maintainers to port their code to .NET Standard or .NET Core and to write towards Linux compatibility if they so wish. There may be things required by the SharePoint Online API that may not be possible to accomplish on Linux. Or they may have no desire to make their module available on Linux. or, they may not have had enough demand for it to justify the work required to refactor the module.

As the SharePoint Online Module is not an included PowerShell Core module, your best bet is to reach out to the SharePoint teams and ask if they are making any plans to make a Core and/or Linux compatible version of their module.

[SteveL-MSFT]

As noted by others, we did work to make existing FullCLR Windows PowerShell modules work with PowerShell Core, however, this doesn't mean they will ever work on non-Windows. My recommendation is to ask product teams to port their cmdlets to PowerShell Core and ensure they are cross platform. Feedback coming from users is more likely to succeed than when it comes from the PowerShell Team. The SharePoint UserVoice is a good place to start.

[lipalath-ms]

Make sure you have installed SharePoint Online Management Shell on your system which worked for me!