I am trying to map persistent drives using New-PSDrive on a remote winrm session, but when I opened a new session the mapping driver got the status of "Unavailable". I am using CREDSSP

Session A creating the mapping

$credentials = Get-Credential user
$session = New-PSSession -ComputerName Server1 -Credential $credentials -Authentication CredSSP
$computername = "Server2"
Invoke-Command -Session $session -ScriptBlock {

param($computername)
New-PSDrive -PSProvider FileSystem -Name "X" -Root "\$computername\scripts" -Persist -Verbose -Scope Global
} -ArgumentList $computername

Session B checking the mapping

$credentials = Get-Credential user
$session = New-PSSession -ComputerName Server1 -Credential $credentials -Authentication CredSSP
$computername = "Server2"

Invoke-Command -Session $session -ScriptBlock {
get-PSDrive
net use
}

Session B return:

Status Local Remote Network

Unavailable X: \Server2\scripts Microsoft Windows Network
The command completed successfully.

Am I doing something wrong?
or this is not possible?

Possible Bug WFM 5.1 with WinRM via Command line. (Can provide Screenshots of issue)

When trying to authenticate to WinRM via command line receive the following error using password with ^ as a special character.

Example Command:

winrm id -r:https://servname:5986 -a:Kerberos -u:serviceaccount@localdomain.local -p:gt^qB%CxkaSQ -encoding:utf-8

Error:
WSManFault

Message = The user name or password is incorrect.

Error number: -2147023570 0x8007052E

When change ^ to ! receive the following output:

C:\Users\shawns>winrm id -r:https://servername:5986 -a
:Kerberos -u:serviceaccount@localdomain.local -p:gt!qB%CxkaSQ -encoding:ut
f-8
IdentifyResponse

ProtocolVersion = <a rel="nofollow noreferrer" href="http://schemas.dmtf.org/wbem/wsman/1/wsman.xsd">http://schemas.dmtf.org/wbem/wsman/1/wsman.xsd</a>

ProductVendor = Microsoft Corporation

ProductVersion = OS: 6.3.9600 SP: 0.0 Stack: 3.0

SecurityProfiles

    SecurityProfileName = <a rel="nofollow noreferrer" href="http://schemas.dmtf.org/wbem/wsman/1/wsman/secprof">http://schemas.dmtf.org/wbem/wsman/1/wsman/secprof</a>

ile/http/spnego-kerberos, http://schemas.dmtf.org/wbem/wsman/1/wsman/secprofile/
https/spnego-kerberos

When importing this module in a restricted session type or when making a function or a cmdlet from this module visible, i.e:
VisibleFunctions = 'Get-FileHash'
the following message is returned:
WARNING: The 'Microsoft.PowerShell.Utility' module was not imported because the 'Microsoft.PowerShell.Utility' snap-in was already imported.
In practice, the module is not being imported.
Get-PSSnapin shows that a snapin with the same name is indeed loaded:
Name : Microsoft.PowerShell.Utility
PSVersion : 5.1.14409.1005
Description : This Windows PowerShell snap-in contains utility
cmdlets that are used to view and organize data in different ways.
but exposes no commands
Get-PSSnapin from a regular (not remote) session does not show this snapin.

With default session type everything is working as expected.

By default tab completion is disabled in JEA endpoints- and there is no guidance on how (or if) it can be enabled safely.
Without tab completion it is
1. Harder to discover available commands (no Get-<tab>)
2. Harder to execute available commands with correct parameter name spelling etc.
3. Harder to populate correct values (e.g., no help with ValidateSet scenarios)
This all works against the applicability of JEA for delegation scenarios where a less expert sub-admin has to blindly type out a potentially complex and unfamiliar command.
Please make some basic level of tab completion work by default, and please provide guidance around tab completion and endpoint safety so we don't accidentally undermine the security boundary while adding or modifying tab completion in the field.

My operating system environment is W8.1/WS12R2 with Windows Mangagement Framework 5.1 installed

After installing KB4103724 (May, 2018 Preview of monthly Rollup for NT6.3), I found that some of the files in WMF/WINRM 5.1 were changed, and those changes were not listed on the update history.

Let me say a few questions about this change:

1: Generally speaking, the monthly Summary preview update is used to resolve performance and reliability issues, but this update history does not list the changes in WMF/WINRM 5.1. The affected file in WMF/WINRM 5.1 is listed only in file information for update 4103724.

2: I noticed that after installing KB4103724, there were 9 affected files, 2 EXE files and 7 DLL files. With one DLL file WsmSvc.dll from its version number that should be the updated file.

The WsmSvc.dll version rises from 10.0.14409.1005 (rs1srvoob.161208-1155) to 10.0.14409.1014 (rs1srvoob.180328-1058).

But the remaining seven files were reduced in version numbers from 10.0.14409.1005 (rs1srvoob.161208-1155) to 10.0.14394.1046 (rs1srvoob.160927-1700).

I want to know if the file with the smaller version number is caused by error substitution. Because a file that does not need to be updated in a SxS update for Windows generally maintains a previous version number.

The affected files are located in this folder after the update is installed:
C:\Windows\WinSxS\amd64microsoft-windows-w..for-management-core31bf3856ad364e357.2.9600.18993none_e45992096d23473d

The original file is in this folder before the update is installed:
C:\Windows\WinSxS\amd64microsoft-windows-w..for-management-core31bf3856ad364e357.2.9600.16384none_e465846b6d1a2277

(The reason for listing the paths in WinSxS is to make it easier to describe)

Original:https://social.technet.microsoft.com/Forums/en-US/cfbff396-f685-4323-b128-2de55cb48e20/wmf51-system-file-change-issues-after-installing-kb4103724?forum=winserverpowershell

From a win7 or win10 workstation running PS5 I can create a PSRemoting session (new-pssession) to a server running PS4. But if that session should become disconnected, I'm unable to reconnect (or receive) the session, receiving, instead the following error:
Receive-PSSession : Connecting to remote server hsfsrpw001 failed with the following error message : The server that is running
Windows PowerShell does not support connect operations on the protocolversion 2.3 that is negotiated by the client computer. Make
sure the client computer is compatible with the build 6.3.9600.17400 and the protocol version 2.2 of Windows PowerShell. For more
information, see the aboutRemoteTroubleshooting Help topic.

I think it makes sense that if we can initiate the remote session to a 'downlevel' server, that we should be able to reconnect to it, even if that were to mean adding a parameter to Connect-pssession and receive-pssession in order to do so.

Also, as far as I can tell, the aboutremotetroubleshooting help article does not cover this situation.