-
Notifications
You must be signed in to change notification settings - Fork 7.1k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Can not connect to Office 365 / Exchange Online with PowerShell #5561
Comments
This is working for me on 10.13.1. Can you confirm that in $PSHome you have |
PowerShell v6.0.0-rc
Copyright (c) Microsoft Corporation. All rights reserved.
https://aka.ms/pscore6-docs
Type 'help' to get help.
PS /Users/kai> cd $PSHome
PS /usr/local/microsoft/powershell/6.0.0-rc> ls -al *.dylib
-rw-r--r-- 1 root wheel 70224 31 Oct 17:27 System.Globalization.Native.dylib
-rw-r--r-- 1 root wheel 13484 31 Oct 17:27 System.IO.Compression.Native.dylib
-rw-r--r-- 1 root wheel 61460 31 Oct 17:27 System.Native.dylib
-rw-r--r-- 1 root wheel 16932 31 Oct 17:27 System.Net.Http.Native.dylib
-rw-r--r-- 1 root wheel 15132 31 Oct 17:27 System.Net.Security.Native.dylib
-rw-r--r-- 1 root wheel 46016 31 Oct 17:27 System.Security.Cryptography.Native.Apple.dylib
-rw-r--r-- 1 root wheel 75708 31 Oct 17:27 System.Security.Cryptography.Native.OpenSsl.dylib
-rw-r--r-- 1 root wheel 2571480 31 Oct 17:27 libclrjit.dylib
-rw-r--r-- 1 root wheel 6894904 31 Oct 17:27 libcoreclr.dylib
-rw-r--r-- 1 root wheel 883740 31 Oct 17:27 libdbgshim.dylib
-rw-r--r-- 1 root wheel 869664 31 Oct 17:27 libhostfxr.dylib
-rw-r--r-- 1 root wheel 1006336 31 Oct 17:27 libhostpolicy.dylib
-rw-r--r-- 1 root wheel 843792 14 Nov 11:37 libmi.dylib
-rw-r--r-- 1 root wheel 3081760 31 Oct 17:27 libmscordaccore.dylib
-rw-r--r-- 1 root wheel 2021168 31 Oct 17:27 libmscordbi.dylib
-rw-r--r-- 1 root wheel 20568 4 Nov 09:08 libpsl-native.dylib
-rw-r--r-- 1 root wheel 224784 15 Nov 07:39 libpsrpclient.dylib
-rw-r--r-- 1 root wheel 553360 31 Oct 17:27 libsos.dylib
PS /usr/local/microsoft/powershell/6.0.0-rc> |
@kai-h you have the right library with the right file size and permissions. Is DYLD_LIBRARY_PATH defined? What is the output of |
It's undefined. PowerShell v6.0.0-rc
Copyright (c) Microsoft Corporation. All rights reserved.
https://aka.ms/pscore6-docs
Type 'help' to get help.
PS /Users/kai> $env:DYLD_LIBRARY_PATH
PS /Users/kai> |
What does |
PS /Users/kai> [System.Environment]::Is64BitProcess
True |
@kai-h try (in the terminal before starting pwsh): export DYLD_LIBRARY_PATH=/usr/local/microsoft/powershell/6.0.0-rc:${DYLD_LIBRARY_PATH}
pwsh
$Session = New-PSSession -ConfigurationName Microsoft.Exchange -ConnectionUri https://outlook.office365.com/powershell-liveid/ -Credential $UserCredential -Authentication Basic -AllowRedirection |
Thank you for your persistence with this. I'm still getting the same error though.
|
I'd like to confirm that I can successfully connect to Office 365 from PowerShell hosted on an Azure Ubuntu virtual machine, using the exact same details as I'm trying on the Mac. PowerShell v6.0.0-rc
Copyright (c) Microsoft Corporation. All rights reserved.
https://aka.ms/pscore6-docs
Type 'help' to get help.
PS /home/kai> $PSVersionTable
Name Value
---- -----
PSVersion 6.0.0-rc
PSEdition Core
GitCommitId v6.0.0-rc
OS Linux 4.4.0-22-generic #40-Ubuntu SMP Thu May 12 22:03:46 UTC 2016
Platform Unix
PSCompatibleVersions {1.0, 2.0, 3.0, 4.0...}
PSRemotingProtocolVersion 2.3
SerializationVersion 1.1.0.1
WSManStackVersion 3.0
PS /home/kai> $Session = New-PSSession -ConfigurationName Microsoft.Exchange -ConnectionUri https://outlook.office365.com/powershell-liveid/ -Credential $UserCredential -Authentication Basic -AllowRedirection
PowerShell credential request
Enter your credentials.
User: user@example.onmicrosoft.com
Password for user user@example.onmicrosoft.com: ********
PS /home/kai> Import-PSSession $Session
(at this point PowerShell starts loading remote modules etc and preparing the session) |
What I'm going to do in order to remove any possible issues with me having tweaked something on my Mac that is conflicting with this is set up a clean install of macOS 10.12 and then a fresh install of PowerShell 6.0.0-rc and test if it works tonight. |
It is dup #3606 |
Issue #3606 is kind-of a dup, but they also saw the error which I haven't seen occur in my testing.
|
I have been able to reproduce this on a clean install of macOS 10.12.6 and a clean install of PowerShell 6.0.0-rc. Everything is with default settings, new admin account created on first boot and no settings changed for the Terminal app. Last login: Thu Nov 30 08:11:57 on ttys000
Administrators-Mac-mini:~ admin$ pwsh
PowerShell v6.0.0-rc
Copyright (c) Microsoft Corporation. All rights reserved.
https://aka.ms/pscore6-docs
Type 'help' to get help.
PS /Users/admin> $PSVersionTable
Name Value
---- -----
PSVersion 6.0.0-rc
PSEdition Core
GitCommitId v6.0.0-rc
OS Darwin 16.7.0 Darwin Kernel Version 16.7.0: T...
Platform Unix
PSCompatibleVersions {1.0, 2.0, 3.0, 4.0...}
PSRemotingProtocolVersion 2.3
SerializationVersion 1.1.0.1
WSManStackVersion 3.0
PS /Users/admin> $env:DYLD_LIBRARY_PATH
PS /Users/admin> [System.Environment]::Is64BitProcess
True
PS /Users/admin> $Session = New-PSSession -ConfigurationName Microsoft.Exchange -ConnectionUri https://outlook.office365.com/powershell-liveid/ -Credential $UserCredential -Authentication Basic -AllowRedirection
PowerShell credential request
Enter your credentials.
User: admin@example.onmicrosoft.com
Password for user admin@example.onmicrosoft.com: *********
An error has occurred that was not properly handled. Additional information is shown below. The PowerShell process will exit.
Unhandled Exception: System.NullReferenceException: Object reference not set to an instance of an object.
at System.Management.Automation.Remoting.PrioritySendDataCollection.Clear()
at System.Management.Automation.Remoting.Client.BaseClientTransportManager.CloseAsync()
at System.Management.Automation.Remoting.Client.WSManClientSessionTransportManager.CloseAsync()
at System.Management.Automation.Remoting.Client.BaseClientTransportManager.Finalize()
Abort trap: 6
Administrators-Mac-mini:~ admin$ |
Here are the results on a clean 10.12.6 install Last login: Thu Nov 30 08:48:11 on ttys000
Administrators-Mac-mini:~ admin$ pwsh
PowerShell v6.0.0-rc
Copyright (c) Microsoft Corporation. All rights reserved.
https://aka.ms/pscore6-docs
Type 'help' to get help.
PS /Users/admin> $Session = New-PSSession -ConfigurationName Microsoft.Exchange -ConnectionUri https://outlook.office365.com/powershell-liveid/ -Credential $UserCredential -Authentication Basic -AllowRedirection
PowerShell credential request
Enter your credentials.
User: admin@example.com
Password for user admin@example.com: ********
An error has occurred that was not properly handled. Additional information is shown below. The PowerShell process will exit.
Unhandled Exception: System.NullReferenceException: Object reference not set to an instance of an object.
at System.Management.Automation.Remoting.PrioritySendDataCollection.Clear() in /PowerShell/src/System.Management.Automation/engine/remoting/fanin/PriorityCollection.cs:line 158
at System.Management.Automation.Remoting.Client.BaseClientTransportManager.CloseAsync() in /PowerShell/src/System.Management.Automation/engine/remoting/fanin/BaseTransportManager.cs:line 949
at System.Management.Automation.Remoting.Client.WSManClientSessionTransportManager.CloseAsync() in /PowerShell/src/System.Management.Automation/engine/remoting/fanin/WSManTransportManager.cs:line 1219
at System.Management.Automation.Remoting.Client.BaseClientTransportManager.Finalize() in /PowerShell/src/System.Management.Automation/engine/remoting/fanin/BaseTransportManager.cs:line 998
Abort trap: 6
Administrators-Mac-mini:~ admin$ |
This could be related to the issues I was seeing that are documented on #4029 |
For help. I had the same problem in a Debian 9 docker container. After read the comments above I saw thet there was some broken linkes libraries and it was because the system libraries are newer than expected. Then , i made some symbolic links and everything ran ok. root@db70f6f67c51:/usr/lib/x86_64-linux-gnu# ldd /opt/microsoft/powershell/6.0.1/libmi.so
root@db70f6f67c51:/opt/microsoft/powershell/6.0.1# cd /usr/lib/x86_64-linux-gnu/ -rw-r--r-- 1 root root 738444 Nov 2 11:29 libssl.a root@db70f6f67c51:/usr/lib/x86_64-linux-gnu# ln -s libcrypto.so.1.0.2 libcrypto.so.1.0.0
|
I was having a similar problem but for me the problem was with the -AllowRedirection Parameter. If i tried in linux.
My Powershell Version
Same thing in Powershell in windows 10
I get a warning of a redirection but I do get the connection succesfully. My PSversion on Windows 10
Now running the same command in linux but using the redirected URI we got in windows.
This seems to me the problem is that the allowredirection paratemer is not working properly. |
After installing the latest PowerShell (v6.0.2) this is no longer working for me: [kai@blackmac ~]$ pwsh
PowerShell v6.0.2
Copyright (c) Microsoft Corporation. All rights reserved.
https://aka.ms/pscore6-docs
Type 'help' to get help.
PS /Users/kai> $PSVersionTable
Name Value
---- -----
PSVersion 6.0.2
PSEdition Core
GitCommitId v6.0.2
OS Darwin 17.5.0 Darwin Kernel Version 17.5.0: Mon Mar 5 22:24:32 PST 2018; root:xnu-4570.51.1~1/RELEASE_X...
Platform Unix
PSCompatibleVersions {1.0, 2.0, 3.0, 4.0...}
PSRemotingProtocolVersion 2.3
SerializationVersion 1.1.0.1
WSManStackVersion 3.0
PS /Users/kai> $UserCredential = Get-Credential
PowerShell credential request
Enter your credentials.
User: admin@example.onmicrosoft.com
Password for user admin@example.onmicrosoft.com: ***********
PS /Users/kai> $Session = New-PSSession -ConfigurationName Microsoft.Exchange -ConnectionUri https://outlook.office365.com/powershell-liveid/ -Credential $UserCredential -Authentication Basic -AllowRedirection
New-PSSession : [outlook.office365.com] Connecting to remote server outlook.office365.com failed with the following error message : Client did not get proper response from server. For more information, see the about_Remote_Troubleshooting Help topic.
At line:1 char:12
+ $Session = New-PSSession -ConfigurationName Microsoft.Exchange -Conne ...
+ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+ CategoryInfo : OpenError: (System.Manageme....RemoteRunspace:RemoteRunspace) [New-PSSession], PSRemotingTransportException
+ FullyQualifiedErrorId : 1,PSSessionOpenFailed
PS /Users/kai> |
@SteveL-MSFT Should we consider this as unstable, as bad UX or as bad documented? |
Is this something that's changed in the latest versions so that Basic auth doesn't work, or is it more than that? I'm happy to do some more testing if required. |
The servicing updates to 6.0.0 have not had any changes that affect this. Not sure if there have been any changes on the server side. cc @dantraMSFT |
On MacOS, I do see a regression in 6.0.1 with a consistent ERROR_WSMAN_INVALID_SELECTORS error. I don't see any issues in 6.0.0 and 6.0.2 and libpsrpclient hasn't changed across these releases. The machine hasn't been upgraded to High Sierra yet so that might be contributing. |
My testing was on a Mac that was recently upgraded from macOS 10.12 Sierra to 10.13 High Sierra. I also upgraded PowerShell from whatever version I had previously (likely to be 6.0.0 or 6.0.1) to the latest version 6.0.2. I also updated my MacPorts installation to the latest version and updated all of my ports. I have a symlink for PowerShell from where it expects to find the OpenSSL libraries as installed by Homebrew to where they are installed by MacPorts and this was all working prior to the upgrades for connecting to Office 365 |
I have powershell 6.0.2 installed. I've installed MacPorts and created the OpenSSL pkg and installed that. When I try to create $Session = New-PSSession -ConfigurationName Microsoft.Exchange -ConnectionURI https://outlook.office365.com/powershell-liveid/ -Credential $O365Cred -Authenticatin Basic -Allowredirection, and I get the same error of New-PSSession : This parameter set requires WSMan, and no supported WSMan client library was found. Name Value PSVersion 6.0.2 What do I need to do to fix the issue of WSMan? |
I am new to O365 and PS on Mac. I am facing the same error message here. Would appreciate any help I can get. Name Value PSVersion 6.0.2 PS /Users/AdityaBhasin> $Session = New-PSSession -ConfigurationName Microsoft.Exchange -ConnectionUri https://ps.protection.outlook.com/powershell-liveid/ -Credential $UserCredential -Authentication Basic -AllowRedirection
PS /Users/AdityaBhasin> System Version: macOS 10.13.5 (17F77) |
Do you have OpenSSL installed with Homebrew? Or, if you are using MacPorts (which I recommend), have you linked the OpenSSL library directory to where PowerShell thinks it should be?
|
It's getting late in the day for me so I'll have another look at it tomorrow. Just a few questions though: Is MMI actually used for the native WSMan client. AFAIK the actual WSMan native dll is called through libpsrpclient on Unix. While MMI does actually use The psl-omi-provider AFAIK is the server plugin and is unrelated to any client based activities. I'm sure getting that working would be nice but honestly I think the client side is the most important part of this story. |
@PaulHigin Could you please explain how we get libmi in PowerShell distributive? If it comes from PSPR package is it possible update the package to more new OMI version (to 1.5 or 1.6)? |
We do not support WinRM/OMI anymore. I believe part of the reason is that OMI itself is no longer in support. @TravisEz13 may be able to provide more information. |
My question comes from the fact that there is already inconsistency - MMI was moved to new version some months ago but PSPR was not - and both reference libmi. I'd expect MSFT makes the minor update to PSPR package and close many questions about the issue. |
You would have to ask the OMI team for this, and they have said they will not make changes or releases for PowerShell. |
@TravisEz13 My ask about update OMI version in https://github.com/PowerShell/psl-omi-provider/blob/master/omi.version
|
@TravisEz13 the OMI team may not create any more releases for you but what’s stopping you from using one of the existing releases yourself. Seems like you currently do this for MMI so why is the WSMan client any different. Clearly you can use one of the newer releases that is compatible with OpenSSL 1.1.x and drop the requirement for OpenSSL 1.0.x which is outdated and probably insecure. This whole setup may be deprecated but to me it’s clear that there’s still a use case for using WSMan. Why not try and have PowerShell be more useful on non-Windows platforms. |
@jborean93 This is the opposite of clear. OMI is fundamentally broken. If we move to 1.1, we will break (segfault pwsh) distros that use 1.0. It's a non-starter. OMI refuses to fix the fundamental issue that they don't load libraries correctly, causing segfaults. |
So only use libmi that is compiled against OpenSSL 1.1 for the distros that actually come with OpenSSL 1.1? Or better yet, have the OpenSSL 1.1 build as the default and just use existing OpenSSL 1.0 for the ones that don't have 1.1. Why should we hinder newer distro builds that can take advantage of newer libs. Hell even some of the more older distros that are supported by PowerShell offer both OpenSSL versions in some shape or form.
While I totally understand not wanting to take on more work technically there's nothing stopping you from making the fixes yourself and compiling it specifically for PowerShell. Also is the seg faults in relation to a known problem that's unrelated to OpenSSL or just a comment that trying to load it without the required libs will fail? If it's about the libs not being available then you already have that issue on newer distros that don't come with OpenSSL 1.0.x. Why should newer distros be hindered in the same way you are stating that older ones are hindered if the package is updated? From a consumer of PowerShell this is all very frustrating to see that crucial components of the language is unavailable outside of Windows hosts. Not being able to use WSMan as a client stops me not only managing existing Windows hosts from a non-Linux host but as the title of this issue states it stops me from using PowerShell to manage online service like O365 or Exchange Online. Being forced to run Windows just to manage those services really does fly in the face of cross platform support that PowerShell normally offers. I know it is all deprecated but without an alternative in place you will continue to have people try and get it working and get frustrated that it doesn't. What really annoys me is that it can actually work but there is little or no desire from the PowerShell team to actually make that happen. It seems like the team is content to keep things in the current broken state and offer platitudes to use a newer transport like ssh which won't work for these situations. I'm sorry for being blunt, I really do appreciate the time and effort you, and the team, make into this language. This is just going to be my last attempt to try and make the out of box setup more usable for end users. If the consensus is still no then I'll continue to have my own workarounds that others are free to follow if they wish. |
@jborean93 Your questions were previously asked and answer in this thread. I've filed MicrosoftDocs/PowerShell-Docs#6491 to document that OMI ( |
Just an FYI for anyone still interested in getting OMI working on Linux/macOS. I've just opened up my fork of the OMI repo which includes a wide range of fixes to get things working properly in PowerShell. You are more than welcome to have a look and play around with it if you wish. I've also written a blog post called Wacky WSMan on Linux to cover my journey in creating the fork and the various issues I came across. Please bear in mind this is not affiliated with Microsoft or the PowerShell/OMI team in any way. The changes are my own and come with no warranty of guarantees of support. I'll try my best to help with any issues opened there if you are still having problems with the fork. |
Today was the first time I was using PowerShell and I'm already disappointed.
If you say a dependency of PowerShell is deprecated but this dependency is required to configure DKIM in Exchange 365, you are saying that Exchange 365 is deprecated including all these docs making use of the broken software: Do I need to buy a Windows computer just to get some DKIM keys into Exchange? |
Three years still a bug, and instead of Microsoft bringing a solution and update their dependencies, non-Microsoft people need to provide forks and workarounds. Evidence of incapacity. |
Still waiting for a fix... |
Please re-open |
Just to be sure I'm not missing something, I heard it was possible to run a Docker instance on macOS and spin up a PowerShell 7 core using mcr.microsoft.com/powershell — but when I tried that I hit the same roadblock. I believe this would only work for the Windows-based images, correct? So we're still stuck in the same boat ⛵ |
I've written up some instructions that work around these issues and are confirmed working with the latest version of PowerShell (I've tested with 7.1.0 Release) and any recent version of macOS (I've tested on macOS 11 Big Sur). Basically, install PowerShell via the pkg installer on GitHub. Then install MacPorts and with MacPorts install OpenSSL 1.0 I am yet to test, but I believe this will NOT work on any of the new M1 arm64 architecture Macs as the PowerShell binaries are x86_64 yet the OpenSSL libraries installed by MacPorts will be arm64. I'm sure there is a way to specify that MacPorts installs the x86_64 version of a library on an arm64 machine, but I don't know how to. Despite the fact that this works, it shouldn't need to be done. PowerShell needs to work with up-to-date versions of OpenSSL. It should also NOT have hardcoded paths for support libraries. It should not require old, and known insecure, versions of third-party libraries. All this is going to be a moot point in due course as the Mac version of PowerShell will not authenticate to MS365 with modern authentication, it only supports legacy authentication. I have been unable to get an answer about, or even find out who is responsible for, modern authentication in PowerShell on non-Windows platforms.
|
@kai-h That's a nice writeup and it's a noble effort, but honestly - if anyone has tenants left on 365 that DON'T use MFA then they're being foolish at best and negligent at worst. I strictly require it across the tenants I engage with. So not being able to connect with modern auth is a non-starter unfortunately. I hope MS stops finger pointing and just finds a way to fix this. Is it really that much of an edge case to want to manage 365 from a Mac these days? |
I hear you. I strongly advise my clients to use MFA for all of their user accounts, even if it is not turned on tenancy-wide. |
@kai-h you shouldn't need to install the older OpenSSL if you use my fork. It's compiled against the newer OpenSSL version (1.1.x) distributed by Homebrew and I've been meaning to see if it will be possible to use the LibreSSL version that comes stock standard. I haven't actually tested it against Big Sur (or M1) but I would assume it would just need to be recompiled and that's it. |
Thank you @jborean93, I'll have to give that a go. Why Microsoft can't do this is beyond me. |
I honestly can't blame them even if I wished the situation was better. The mi library was maintained by a separate team and is based on C so requires a completely different skill set to maintain and support. From experience the code there is quite complex and not something easy to maintain. Once that team dropped support for macOS or PowerShell then the PowerShell team had little choice. What would be nice is if the WSMan code could be implemented in pure .NET and maintained by them as a lot of the fundamental work is already in place in .NET but this is also not a trivial task to achieve. So in the end I decided to just fork the library and fix up the stuff I could. Things that I fixed with this fork
Before I continue, all this is relevant only to macOS, for Linux this info does not apply. It's still hardcoded to In saying all that, if you really want to rely on the environment or use a different path for your specific setup you can change them yourself. To do this you need to run
If I wanted to change the libssl and libcrypto library to scan from rpath I would run install_name_tool -change \
/usr/local/opt/openssl@1.1/lib/libssl.1.1.dylib \
@rpath/libssl.1.1.dylib \
/usr/local/microsoft/powershell/7/libmi.dylib
install_name_tool -change \
/usr/local/opt/openssl@1.1/lib/libcrypto.1.1.dylib \
@rpath/libcrypto.1.1.dylib \
/usr/local/microsoft/powershell/7/libmi.dylib You would need to run this as sudo and I highly recommend you make a backup of the libraries before you change them in case something breaks. You also want to make sure that the library you are linking to is actually compatible. You won't be able to use I've been meaning to look into linking against the builtin LibreSSL libs that macOS ships with but I would be concerned it will start to lag behind just like the shipped OpenSSL version that Apple had before they swapped to LibreSSL. For now relying on a newer version from homebrew gives us a new library that continues to be updated by homebrew which follows what other Linux distributions offer. |
This is an obsessive situation for the past few years, but this is a fact, possibly the result of internal political wars. :-) It seems MSFT PowerShell team has decided to convert Remoting to a subsystem, which will open up the possibility of creating alternative Remoting implementations. If this happens, perhaps we will have time in next milestone to get a new implementation based on .Net WebSockets (?) that will work on all platforms without external dependencies. |
Same issue. |
So in the end, it's not possible to connect to exchange online via linux powershell if MFA is enable yet, right ? |
As far as I know, no - not on a non-Windows platform. |
With the one provided with PowerShell there's a good chance it won't work but it really depends on the distribution, i.e. macOS is very likely not to work. With my forked version you definitely can. It's one of the integration scenarios I test out when creating a new release https://github.com/jborean93/omi/blob/67fb46865b76ecd5d89a990fdedeb32cd219143f/libmi.tests.ps1#L470-L518.
|
@jborean93
|
I can not connect to Office 365 / Exchange Online with PowerShell.
Apparently others can with the latest version of push, but it is not working for me on either macOS 10.12 or 10.13 with pwsh 6.0.0-rc
I get an error creating the New-PSSession. Depending on the exact syntax of the command I'm using, it either says New-PSSession : This parameter set requires WSMan, and no support WSMan client library was found, or PowerShell quits with an unhandled exception and abort trap 6.
Steps to reproduce
Install PowerShell 6.0.0-rc on macOS 10.12 or 10.13.
Use Get-Credential to get an Office 365 administrator credential and then use New-PSSession to create a new session.
You will note from the prompt in the last line above that it's dropped me back into the bash shell.
Expected behavior
It is expected that New-PSSession will work on macOS
Actual behavior
Depending on the precise syntax of the command, New-PSSession either returns an error message:
New-PSSession : This parameter set requires WSMan, and no supported WSMan client library was found
Or, New-PSSession has an unhandled exception and PowerShell quits with abort trap 6.
The differences in the syntax are with the ConnectionUri - whether or not there is a trailing slash on the uri seems to make the difference. With a trailing slash, I get the error about WSMan missing. Without the trailing slash, the PowerShell session aborts.
With trailing slash:
Without trailing slash:
Environment data
The text was updated successfully, but these errors were encountered: