Get-PnPfile throwing error "The underlying connection was closed: The connection was closed unexpectedly"

[bukhaaaa]

Reporting an Issue or Missing Feature

Hi all! Apologies if this is the wrong place to post this. If so, please advise on where to get help for the issue.

We have 3 windows servers that run scheduled tasks daily, DEV, QUA, PRD (for development, test, and production respectively). The configuration of these servers are identical. We are running a PowerShell script that calls 2 PnP commands:

Connect-PnPOnline -Url [SharePoint URL] -ClientId [clientid] -ClientSecret [clientsecret] -WarningAction Ignore 
Get-PnPFile -serverrelativeurl [relative URL] -Path [location in C:\] -Filename "divisions.csv" -AsFile -Force

These commands work perfectly as expected on DEV and PRD servers, BUT not in QUA. In QUA, Connect-PnPOnline seems to work, but when we run the Get-PnPFile command, we get an error saying

"The underlying connection was closed: The connection was closed unexpectedly"

We have ensured TLS1.2 is being utilized by running the below code and checking the settings in regedit:

[Net.ServicePointManager]::SecurityProtocol = [Net.SecurityProtocolType]::Tls12

We have also ran the below command in command prompt in all 3 servers to compare the path the computer takes to reach SharePoint - all 3 servers returned an identical result for the trace.

tracert [companyname].sharepoint.com

Are there any other settings or things we should check or try to further diagnose the issue? Any help would be highly appreciated.

Expected behavior

The expected behavior is that the commands are run, the file is downloaded, and there is no output or errors in the terminal.

Actual behavior

"The underlying connection was closed: The connection was closed unexpectedly"

Steps to reproduce behavior

1. Remote into the QUA VM
2. Open PowerShell as administrator
3. Run Connect-PnPOnline
   Connect-PnPOnline -Url [SharePoint URL] -ClientId [clientid] -ClientSecret [clientsecret] -WarningAction Ignore
4. Run Get-PnPFile
   Get-PnPFile -serverrelativeurl [relative URL] -Path [location in C:\] -Filename "divisions.csv" -AsFile -Force

What is the version of the Cmdlet module you are running?

PnP.Powershell version 1.3.0

Which operating system/environment are you running PnP PowerShell on?

- [x] Windows

• Linux
• MacOS
• Azure Cloud Shell
• Azure Functions
• Other : please specify

[veronicageek]

@bukhaaaa - I think it'd fair to say that the cmdlet works (as you stated) but there might still be something different on your 3rd server? I'll be moving this to the discussions for wider inputs.

[bukhaaaa]

@veronicageek Hmm okay, understood. Yes, while the cmdlets do work on 2 servers, get-pnpfile still fails on the third identical server. We aren't sure what other settings/configurations to check at this point. In addition, I haven't found anyone else on the internet that has run into this "The underlying connection was closed: The connection was closed unexpectedly" error. Do you have any thoughts as to what might be causing this/any other things we should check and compare between servers?

Thanks.

[TheOnlySharePointGuy]

I know this is old, but we are currently experiencing this exact same issue. Did you ever find out the solution or cause of the issue to get it corrected?

[bukhaaaa]

@TheOnlySharePointGuy Yes, there were a couple things at play:

• Ensure your SharePoint (or Azure application) credentials are valid & have the right permissions. Test it on a different machine.
• Run a tracert to see where the traffic is being routed. Our firewall had rules that were preventing connection to SharePoint.
• We had a case open with Microsoft, and found that our TLS ciphers were inactive. Ensure the following Cipher Suites are active (you can use a tool like IIS crypto):
  • TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384
  • TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256
  • TLS_DHE_RSA_WITH_AES_256_GCM_SHA384
  • TLS_DHE_RSA_WITH_AES_128_GCM_SHA256

Then ensure TLS1.2 is being used for PowerShell.

Some helpful links:
For TLS1.2 the following cipher suites are supported
Update to enable TLS 1.1 and TLS 1.2 as default secure protocols in WinHTTP in Windows
Azure Front Door - Frequently asked questions | Microsoft Docs
Authentication errors when client doesn't have TLS 1.2 support - SharePoint | Microsoft Docs

[bukhaaaa]

@TheOnlySharePointGuy We had this issue come up twice. First time was due to the fact that the endpoint was being blocked by firewall. Second time around was due to the cipher suites.

[TheOnlySharePointGuy]

Thank you for this! If you can or dont mind sharing, happen to know how / what was being blocked on firewall? I already found the IIS crypto before troubleshooting and it didn't seem to fix it for us. I will check powershell itself is running in tls 1.2. Thanks again!

[bukhaaaa]

The endpoint was being blocked on the firewall (company.sharepoint.com)

[TheOnlySharePointGuy]

Thank you again, this gets me a new starting point to work with the security team. Here's hoping.

[bukhaaaa]

No prob & good luck! Worst case scenario you might be able to open a ticket with Microsoft Premier Support (if your company has a contract with MS).