The use case is copying a local file to a remote server using PowerShell remoting and Copy-Item:

$remote = "aremotemachine.example.com"
$cred = Get-Credential
$session = New-PSSession -ComputerName $remote -Credential $cred
echo "testcontent" > testfile.txt

# Works when we only specify a destination directory
Copy-Item -Path testfile.txt -Destination C:\ -ToSession $session

# Doesn't work when we specify a filename
Copy-Item -Path testfile.txt -Destination C:\testfile.txt -ToSession $session

# Even if it's different from the original filename
Copy-Item -Path testfile.txt -Destination C:\testfile2.txt -ToSession $session

# Here is the output I get for the first failed command
Copy-Item : Destination folder 'C:\testfile.txt' does not exist.At line:1
char:1
+ Copy-Item -Path testfile.txt -Destination C:\testfile.txt -ToSession ...
+ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+ CategoryInfo : WriteError: (C:\testfile.txt:String) [Copy-Item]
, IOException
+ FullyQualifiedErrorId : RemoteDirectoryNotFound,Microsoft.PowerShell.Com
mands.CopyItemCommand

Jea will not allow authenticate as local user on Windows if "RunasVirtualAccount" is set to $true for PssessionConfiguration

[ADMIN]: PS > Enter-PSSession mivcustftp1 -Credential $gregcred -ConfigurationName JEA
Enter-PSSession : Processing data from remote server mivcustftp1 failed with the following error message: There are currently no logon servers available to
service the logon request. For more information, see the about_Remote_Troubleshooting Help topic.
At line:1 char:1
+ Enter-PSSession server -Credential server\account -ConfigurationName ...
+ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+ CategoryInfo : InvalidArgument: (server:String) [Enter-PSSession], PSRemotingTransportException
+ FullyQualifiedErrorId : CreateRemoteRunspaceFailed

Switching configuration RunAsVirtualAccount to $false will allow to authenticate

Server reports following error during failure

An account failed to log on.

Subject:
Security ID: WinRM Virtual Users\WinRM VA_1462826167_server_account
Account Name: WinRM VA_1462826167_server_account
Account Domain: WinRM Virtual Users
Logon ID: 0xE593B

Logon Type: 3

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

Failure Information:
Failure Reason: An Error occured during Logon.
Status: 0xC000005E
Sub Status: 0x0

Process Information:
Caller Process ID: 0xb10
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

WMF 5.0 lets you create DSC Resources using Powershell Classes like so:

[DscResource()]
class My_DSC_Resource
{
...
}

But right now it will only look in the .psm1 file. If you try to dot source a class based DSC resource into the .psm1 file then Get-DSCResource can't find it and it can't be used in DSC configurations.

We have many DSC resources combined into a single module, and our .psm1 file is getting difficult to manage. If two people are working on different resources they are likely to have a git merge conflict.

We would prefer to have the resources defined in separate files and then dot source them into the .psm1 file, similar to how other modules are designed.

Install-PackageProvider cannot retrieve the list of available providers if the machine doesn't have direct access to the internet.

PS C:\Windows\system32> Install-PackageProvider -Name NuGet -MinimumVersion 2.8.5.201 -Force
WARNING: Unable to download the list of available providers. Check your internet connection.
Install-PackageProvider : No match was found for the specified search criteria for the provider 'NuGet'. The package
provider requires 'PackageManagement' and 'Provider' tags. Please check if the specified package has the tags.
At line:1 char:1
+ Install-PackageProvider -Name NuGet -MinimumVersion 2.8.5.201 -Force
+ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+ CategoryInfo : InvalidArgument: (Microsoft.Power...PackageProvider:InstallPackageProvider) [Install-Pac
kageProvider], Exception
+ FullyQualifiedErrorId : NoMatchFoundForProvider,Microsoft.PowerShell.PackageManagement.Cmdlets.InstallPackagePro
vider

How to reproduce:
1. Setup a network completely separate from the internet.
2. Setup an HTTP-proxy in that network as following:
2.1. The machine with HTTP-proxy has 2 network interfaces: 1 connected to a LAN and another one - to the internet.
2.2. Configure the proxy in a way to require authentication, not allowing anonymous connections. Configure Kerberos authentication.
2.3. Allow access to the internet via the proxy for AD user accounts only, not for the computer ones.
3. Publish the proxy with WPAD.
4. Use Group Policy to configure Internet Explorer throughout the network to use WPAD as a source of proxy settings.
5. Try access the internet (http://example.com) via Internet Explorer - everything works fine.
6. Launch PowerShell console as an administrator, using AD account allowed to access internet via the proxy.
7. Try to download NuGet provider using Install-PackageProvider cmdlet - you receive an error shown above.

If a Node is configured using a RegistrationKey so that ConfigurationNames can be used, then the CertificateID attribute is ignored under the ConfigurationRepositoryWeb block, and instead a self-signed certificate is generated called "DSC-OaaS".

This certificate is used for both client authentication to the pull server as well as encrypting configuration Mofs at rest on the server host.

The problem is two fold:

1. Becuase the CertificateID gets ignored when using CONfigurationNames, admins cannot control the key length or encryption of the files.

2. The certificate generated is a SHA-1 1024bit length. This is completely unacceptable as 1024 went out of use years ago, and SHA-1 is getting retired this year as an encryption standard.

Please allow administrators to select the certificate for use and NOT force a weak self-signed certificate.

In WMF 5.0 (tested on Win7 w/ KB3134760 and Win10 10240), the presence of certain Import-Module statements in a module in $env:PSModulePath will cause Get-Module -List to throw. In particular, if a module attempts to import another module with a path relative to $PSScriptRoot, it seems to break things. We do this type of thing within psm1s in cases where a manifest cannot express the behavior we need. Here's a repro:

## On Win7, using the re-released WMF 5.0 (KB3134760):

PS C:\> $PSVersionTable

Name Value
---- -----
PSVersion 5.0.10586.117
PSCompatibleVersions {1.0, 2.0, 3.0, 4.0...}
BuildVersion 10.0.10586.117
CLRVersion 4.0.30319.42000
WSManStackVersion 3.0
PSRemotingProtocolVersion 2.3
SerializationVersion 1.1.0.1

PS C:\> gwmi win32_operatingsystem | fl caption, version

caption : Microsoft Windows 7 Enterprise
version : 6.1.7601

## Say I have a directory of modules added to an otherwise stock %PSModulePath%, in this case C:\local\dummy:

PS C:\> $env:PSModulePath
C:\Users\whitema\Documents\WindowsPowerShell\Modules;C:\Program Files\WindowsPowerShell\Modules;C:\Windows\system32\WindowsPowerShell\v1.0\Modules;C:\local\dummy

## In that directory, I have two very simple modules with one function each, foo and bar. foo imports bar using $PSScriptRoot

PS C:\> ls -rec C:\local\dummy

Directory: C:\local\dummy

Mode LastWriteTime Length Name
---- ------------- ------ ----
d----- 3/5/2016 11:47 PM bar
d----- 3/5/2016 11:47 PM foo

Directory: C:\local\dummy\bar

Mode LastWriteTime Length Name
---- ------------- ------ ----
-a---- 3/6/2016 12:04 AM 24 bar.psm1

Directory: C:\local\dummy\foo

Mode LastWriteTime Length Name
---- ------------- ------ ----
-a---- 3/6/2016 12:05 AM 83 foo.psm1

PS C:\> cat C:\local\dummy\foo\foo.psm1
Import-Module (Join-Path $PSScriptRoot '..\bar')
function Get-Foo {'foo'; Get-Bar}
PS C:\> cat C:\local\dummy\bar\bar.psm1
function Get-Bar {'bar'}

## Now, get rid of any existing CommandAnalysis cache and make sure I'm in a fresh shell, otherwise this many not be reproducible, then run Get-Module -ListAvailable. This works without specifying the module name too, it's only shown here to limit the output. DO NOT PRESS TAB WHILE DOING THIS, it may cause a command analysis cache file to be created and break the repro.

PS C:\> get-module -list foo
get-module : The specified module '(Join-Path $PSScriptRoot '..\bar')' was not found. Update the Name parameter to
point to a valid path, and then try again.
At line:1 char:1
+ get-module -list foo
+ ~~~~~~~~~~~~~~~~~~~~
+ CategoryInfo : ResourceUnavailable: ((Join-Path $PSScriptRoot '..\bar'):String) [Get-Module], FileNotFo
undException
+ FullyQualifiedErrorId : Modules_ModuleNotFoundForGetModule,Microsoft.PowerShell.Commands.GetModuleCommand

Directory: C:\local\dummy

ModuleType Version Name ExportedCommands
---------- ------- ---- ----------------
Script 0.0 foo Get-Foo

## This error only occurs when running Get-Module without having already imported the module. Also, if there is a valid CommandAnalysis file for the module, then no error is thrown.

PS C:\> ipmo foo
PS C:\> get-module -list foo

Directory: C:\local\dummy

ModuleType Version Name ExportedCommands
---------- ------- ---- ----------------
Script 0.0 foo {Get-Foo, Get-Bar}

## Won't be reproducible immediately in a new shell because of the CommandAnalysis cache.

PS C:\> exit
PS C:\> powershell -noprofile
Windows PowerShell
Copyright (C) 2015 Microsoft Corporation. All rights reserved.

PS C:\> get-module -list foo

Directory: C:\local\dummy

ModuleType Version Name ExportedCommands
---------- ------- ---- ----------------
Script 0.0 foo {Get-Foo, Get-Bar}

## While attempting to debug this, I also noticed some strange behavior - in the debug shell $PSScriptRoot appears to be an empty string, but it seems to work in spite of that. I've also seen a scenario where the variable object from get-variable showed the expected path, but just using $PSScriptRoot evaluated to an empty string. I can't seem to repro that behavior reliably though. This does not cause any problem beyond confusion, but I'm mentioning it because perhaps it's related?

PS C:\> exit
PS C:\> rm -rec $env:localappdata\Microsoft\Windows\PowerShell\CommandAnalysis
PS C:\> powershell -noprofile
Windows PowerShell
Copyright (C) 2015 Microsoft Corporation. All rights reserved.

PS C:\> set-psbreakpoint -line 1 C:\local\dummy\foo\foo.psm1

ID Script Line Command Variable Action
-- ------ ---- ------- -------- ------
0 foo.psm1 1

PS C:\> $VerbosePreference = 'continue'
PS C:\> ipmo foo
VERBOSE: Loading module from path 'C:\local\dummy\foo\foo.psm1'.
Entering debug mode. Use h or ? for help.

Hit Line breakpoint on 'C:\local\dummy\foo\foo.psm1:1'

At C:\local\dummy\foo\foo.psm1:1 char:1
+ Import-Module (Join-Path $PSScriptRoot '..\bar')
+ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
[DBG]: PS C:\>> l

1:* Import-Module (Join-Path $PSScriptRoot '..\bar')
2: function Get-Foo {'foo'; Get-Bar}

[DBG]: PS C:\>> $PSScriptRoot

[DBG]: PS C:\>> Get-Variable PSScriptRoot

Name Value
---- -----
PSScriptRoot

## So the Join-Path subexpression should fail...

[DBG]: PS C:\>> (Join-Path $PSScriptRoot '..\bar')
Join-Path : Cannot bind argument to parameter 'Path' because it is an empty string.
At line:1 char:12
+ (Join-Path $PSScriptRoot '..\bar')
+ ~~~~~~~~~~~~~
+ CategoryInfo : InvalidData: (:) [Join-Path], ParameterBindingValidationException
+ FullyQualifiedErrorId : ParameterArgumentValidationErrorEmptyStringNotAllowed,Microsoft.PowerShell.Commands.Join
PathCommand

## But it doesn't?

[DBG]: PS C:\>> s
VERBOSE: Loading module from path 'C:\local\dummy\bar\bar.psm1'.
VERBOSE: Exporting function 'Get-Bar'.
VERBOSE: Importing function 'Get-Bar'.
VERBOSE: Exporting function 'Get-Bar'.
VERBOSE: Exporting function 'Get-Foo'.
VERBOSE: Importing function 'Get-Bar'.
VERBOSE: Importing function 'Get-Foo'.
PS C:\>

Votes from Connect: 10

Original Date Submitted: 3/4/2015 1:43:50 AM

Description:
********Contact Information********
Handle: JasonHorner
Site Name: PowerShell
Feedback ID: 1159120
***************************************

Frequency: Always Happens
Regression: Yes, this happens in all previous versions

Problem Description:
JSON is fast becoming a viable alternative to XML.. Therefore PowerShell ISE should support syntax coloring in a similar manner as it treats XML files

Product Studio item created by Connect Synchronizer due to creation of feedback ID 1159120 (http://connect.microsoft.com/PowerShell/feedback/ViewFeedback.aspx?FeedbackID=1159120).

Repro Steps:
open a json file in powershell all the text is black

Expected Results:
.Json should be added to the list of supported files types from the file open menu and basic syntax highlighting within the editor should be implemented.

Internal BugId: 14285

Installing the WMF Production Preview on a Windows Server 2012 machine causes sysprep to fail with the following messages:

2016-01-14 15:58:26, Error [0x0f00bf] SYSPRP CreateSysprepActionList: Invalid action node sysprepOrder found for component Microsoft-Windows-SoftwareInventoryLogging-ScheduledTasks
2016-01-14 15:58:26, Error SYSPRP SysprepSession::Execute: Error in executing actions from C:\Windows\System32\Sysprep\ActionFiles\Generalize.xml; dwRet = 0x10dd
2016-01-14 15:58:26, Error SYSPRP RunPlatformActions:Failed while executing SysprepSession actions; dwRet = 0x10dd
2016-01-14 15:58:26, Error [0x0f0070] SYSPRP RunExternalDlls:An error occurred while running registry sysprep DLLs, halting sysprep execution. dwRet = 0x10dd
2016-01-14 15:58:26, Error [0x0f00a8] SYSPRP WinMain:Hit failure while processing sysprep generalize internal providers; hr = 0x800710dd
2016-01-14 15:58:26, Info [0x0f004c] SYSPRP WaitThread:Exiting spawned waiting thread
2016-01-14 15:58:26, Info [0x0f0052] SYSPRP Shutting down SysPrep log
2016-01-14 15:58:26, Info [0x0f004d] SYSPRP The time is now 2016-01-14 15:58:26

Comparing versions of Generalize.xml from before and after installing WMF 5 Production Preview shows that these stanzas are added:

--- H:\Projects\Windows Image Maint\GeneralizeBefore.xml
+++ H:\Projects\Windows Image Maint\GeneralizeAfter.xml
@@ -213,4 +213,19 @@
<assemblyIdentity name="Microsoft-Windows-ErrorReportingCore" processorArchitecture="x86" publicKeyToken="31bf3856ad364e35" version="6.2.9200.16384" versionScope="NonSxS"/>
<sysprepModule methodName="WerSysprepGeneralize" moduleName="wer.dll"/>
</imaging>
+ <imaging exclude="">
+ <assemblyIdentity name="Microsoft-Windows-SoftwareInventoryLogging-ScheduledTasks" processorArchitecture="amd64" publicKeyToken="31bf3856ad364e35" version="6.2.9616.933" versionScope="NonSxS"/>
+ <sysprepOrder order="0x3300"/>
+ <registryActions>
+ <deleteValue name="Identity" path="HKEY_LOCAL_MACHINE\Software\Microsoft\Windows\SoftwareInventoryLogging"/>
+ </registryActions>
+ </imaging>
+ <imaging exclude="">
+ <assemblyIdentity name="Microsoft-Windows-MiStreamProvider" processorArchitecture="amd64" publicKeyToken="31bf3856ad364e35" version="6.2.9616.933" versionScope="NonSxS"/>
+ <sysprepOrder order="0x3200"/>
+ <registryActions>
+ <deleteValue name="LastTargetUri" path="HKEY_LOCAL_MACHINE\Software\Microsoft\Windows\StreamProvider"/>
+ <deleteValue name="LastFullPayloadTime" path="HKEY_LOCAL_MACHINE\Software\Microsoft\Windows\StreamProvider"/>
+ </registryActions>
+ </imaging>
</sysprepInformation>

Apparently Sysprep on Windows Server 2012 doesn't know what "sysprepOrder" is.

Workaround: Delete the added stanzas, then sysprep runs to completion without errors.

So, it seems as though in WMF 5.0 there is a regression in functionality. In WMF 4.0, you could set up a DSCFileDownloadManager and Credential to have a Target Node contact a Pull Server SMB Share and download new mof files and resources. Everything worked perfectly including Certificate based encryption of the credentials. However, in WMF 5, it seems as though the LCM of the Target Node attempts to contact the SMB Share Anonymously, even in credentials are provided. Now, in a Non domain joined environment, you can just provide EVERYONE full control and then change Local Security Policy such that Anonymous=Everyone (even though this is a massive security risk in an enterprise environment). However, even worse, in a Domain Joined environment, there is no workaround. As the LCM cannot contact the LCM anonymously anymore (at least with no settings I saw), it instead attempts to contact the SMB share as the Computer Account, which of course will fail. This also makes it untenable to provide EVERYONE access because they will still get denied. I haven't found a workaround to get SMB Share working at all in a domain joined environment. Obviously, all of this worked in 4.0 including Certificate encryption with DSCFileDownloadManager. With 8.1 and beyond now offering SMB Encryption as well, the DSCFileDownloadManager is still a viable enterprise solution, and thus a potentially major issue.

If there are any workaround in the mean time, I'd love to hear them. Also, if I have misunderstood/misimplemented the issue, I'd love to hear that too. I did a wireshark capture of the traffic and it appears pretty cut and dry.

Thanks

Votes from Connect: 18

Original Date Submitted: 6/20/2013 11:40:16 PM

Description:
********Contact Information********
Handle: deadlydog
Site Name: PowerShell
Feedback ID: 790577
***************************************

Frequency: Always Happens
Regression: Yes, this happens in all previous versions

Problem Description:
It would be great if PS ISE had a "Save All" files feature to save all open, unsaved files. This is considered standard functionality in most IDEs these days, and it is typically bound to the keyboard shortcut Ctrl+Shift+S. Basically the same functionality as Ctrl+S, just iterate over all open, unsaved tabs and do the same.

Product Studio item created by Connect Synchronizer due to creation of feedback ID 790577 (http://connect.microsoft.com/PowerShell/feedback/ViewFeedback.aspx?FeedbackID=790577).

Repro Steps:
Hit Ctrl+Shift+S and nothing happens.

Expected Results:
Hit Ctrl+Shift+S and all open, unsaved files are saved, prompting you for a path to save a file to if necessary.

Internal BugId: 4257