This report is a bit confusing, so need some information.
On the system where you received this error, please try running any of the commands from Microsoft.PowerShell.Utility, such as get-member, or get-date. The error message and the information you provided seems to indicate that the module is already loaded, so we are looking for other indications that it is not.
Paul Higinbotham (MSFT) has done some analysis in https://github.com/PowerShell/JEA/issues/42
His conclusion: "This is old endpoint configuration code that imports core modules into the restricted session through "snapins". The Microsoft.PowerShell.Utility module consists of binary and script components but snapins only deal with the binary component and leave the script out, which is why the script functions are not available.
I think this is just old legacy code that should be re-written to use module loading rather than snapins.
Can you create an issue on https://github.com/powershell/powershell?
I believe the fix is to re-write how core modules are loaded in the InitialSessionState.CreateRestrictedForRemoteServer() method."
As this issue is related to PowerShell 5.1, I think it's the best place for it.
This issue appears only if VisibleFunctions or VisibleCmdlets parameters are used. I filled an issue here: https://github.com/PowerShell/JEA/issues/42 and proposed some workarounds here: https://jnury.github.io/JEA_term_not_recognized_name_cmdlet
Thanks for the feedback! I have personally heard this request from a number of customers. IMHO having the ability to use GMS accounts would be a quite useful in DSC configurations. If this is an important feature for you as well, vote it up so that we can appropriately prioritize it as we move forward.
I experienced the same issue in PowerShell 4.0. It's an annoying behaviour when exchanging data with Java apps.