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.

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 (rs1_srvoob.161208-1155) to 10.0.14409.1014 (rs1_srvoob.180328-1058).

But the remaining seven files were reduced in version numbers from 10.0.14409.1005 (rs1_srvoob.161208-1155) to 10.0.14394.1046 (rs1_srvoob.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\amd64_microsoft-windows-w..for-management-core_31bf3856ad364e35_7.2.9600.18993_none_e45992096d23473d

The original file is in this folder before the update is installed:
C:\Windows\WinSxS\amd64_microsoft-windows-w..for-management-core_31bf3856ad364e35_7.2.9600.16384_none_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

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 = http://schemas.dmtf.org/wbem/wsman/1/wsman.xsd
ProductVendor = Microsoft Corporation
ProductVersion = OS: 6.3.9600 SP: 0.0 Stack: 3.0
SecurityProfiles
SecurityProfileName = http://schemas.dmtf.org/wbem/wsman/1/wsman/secprof
ile/http/spnego-kerberos, http://schemas.dmtf.org/wbem/wsman/1/wsman/secprofile/
https/spnego-kerberos

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 about_Remote_Troubleshooting 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 about_remote_troubleshooting help article does not cover this situation.

jea cannot be used if the calling user isn't an administrator

I have an issue similar to this but slightly different.

https://windowsserver.uservoice.com/forums/301869-powershell/suggestions/13788477-jea-can-not-be-used-with-local-account-if-runasvir

I have JEA configured and set up. When I connect to the endpoint with an account that is an administrator where the endpoint is located it works fine. My commands are limited to what I set in my profile etc.

When I try to connect as a non-privileged user that is in the correct group to use the endpoint it fails with "the username or password is incorrect". If I add that SAME account to the local administrator's group on the endpoint it works fine.

When it fails, in the security log on the endpoint I can see where the domain account logged in just fine. But then there are these two audit failures with the virtual account and I'm running out of ideas as to why this is happening....I've tried multiple endpoints and multiple accounts with the same results.

A privileged service was called.

Subject:
Security ID: WinRM Virtual Users\WinRM VA_1475067010_COMPANY_svc.jea.tst
Account Name: WinRM VA_1475067010_COMPANY_svc.jea.tst
Account Domain: WinRM Virtual Users
Logon ID: 0x22C5FC5

Service:
Server: NT Local Security Authority / Authentication Service
Service Name: LsaRegisterLogonProcess()

Process:
Process ID: 0x200
Process Name: C:\Windows\System32\lsass.exe

Service Request Information:
Privileges: SeTcbPrivilege

An account failed to log on.

Subject:
Security ID: WinRM Virtual Users\WinRM VA_1475067010_COMPANY_svc.jea.tst
Account Name: WinRM VA_1475067010_COPMANY_svc.jea.tst
Account Domain: WinRM Virtual Users
Logon ID: 0x22C5FC5

Logon Type: 3

Account For Which Logon Failed:
Security ID: NULL SID
Account Name:
Account Domain:

Failure Information:
Failure Reason: Unknown user name or bad password.
Status: 0xC000006D
Sub Status: 0xC0000064

Process Information:
Caller Process ID: 0x9f4
Caller Process Name: C:\Windows\System32\wsmprovhost.exe

Network Information:
Workstation Name: SERVER
Source Network Address: -
Source Port: -

Detailed Authentication Information:
Logon Process: C
Authentication Package: Kerberos
Transited Services: -
Package Name (NTLM only): -
Key Length: 0

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.

Concurrent operations on an open shell always increase (eg, for each command run) even when the Terminate signal message is sent and (apparently) properly processed after each command. This eventually causes the MaxConcurrentOperationsPerUser quota to be hit, requiring a new shell to be created.

A simple reproduction using pywinrm is available at: https://github.com/diyan/pywinrm/issues/124. I'm guessing there's just something wrong with the way the Terminate signal is being sent by pywinrm, but the server appears to be happy with it.

To run the repro, ensure python and pip are available, create a file with the repro code (and adjust the wsman endpoint, username, password, and change the "transport" arg to ntlm if basic isn't configured) then do:
pip install pywinrm==0.2.0
python (path_to_repro).py

Lower the MaxConcurrentOperationsPerUser to something less than 100 to hit the repro more quickly.