Sorry if this is the wrong place, I created an issue https://github.com/chef/chef/issues/7765 but I am not sure its an issue with Chef.
I have also created an issue https://github.com/PowerShell/PowerShell/issues/8148 .
I am not very familiar with Powershell sorry, so I am unable to replicate without Chef (If I knew how it would be handy to try and replicate with pure WinRM).

Steps to reproduce

In Chef
powershell
cd C:/Test
Add-AppxPackage Example_1.0.0.0_x64.appx -DependencyPath "Dependencies\\x64\\A.appx","Dependencies\\x64\\B.appx","Dependencies\\x64\\C.appx"

This is trying to install an appx for a standard user. I believe Chef uses WinRM to run the commands.

Expected behavior


App installs. Testing the command when physically logging in as the standard user and running powershell, it does work (appx installs).

powershell
get-appxpackage -allusers -name *example*
(result is empty)


Actual behavior


Win32 internal error "Access is denied" 0x5 occurred while reading the console output buffer. Contact Microsoft Customer Support Services.


Environment data

```powershell
Name Value

PSVersion 5.1.17134.228
PSEdition Desktop
PSCompatibleVersions {1.0, 2.0, 3.0, 4.0...}
BuildVersion 10.0.17134.228
CLRVersion 4.0.30319.42000
WSManStackVersion 3.0
PSRemotingProtocolVersion 2.3
SerializationVersion 1.1.0.1
```

Additional Notes

I have tried everything I can think of, the only thing that works is starting another powershell script as the user (see the ticket on Chef). Please see https://github.com/chef/chef/issues/7765 for more details.

I recently posted this on TechNet, and was directed here...

I couldn't remember how many times I've heard Jeffrey Snover talk about the experience that the Powershell team are after being one where you can start at a PS prompt and find and finish everything you need.

First, great job, because it is actually shaping up to an environment that is just that. However, I just ran in to something that made me curse out loud alone in my office, and I want to believe that the majority of the community will be with me on this.

I started, as we should, with a PS prompt and an idea of what I was trying to accomplish (connect to a mongodb). Easy enough.

PS C:\WINDOWS\system32> Get-Module mongo

ModuleType Version Name

Binary 18.0.67... MongoDBCmdlets

Hey, there we go. I bet that's what I'm looking for. So

PS C:\WINDOWS\system32> Get-Command mongo

CommandType Name

Cmdlet Add-MongoDB
Cmdlet Connect-MongoDB <------- yes sir. I'll take that one please.

PS C:\WINDOWS\system32> get-help Connect-MongoDB

NAME

Connect-MongoDB

SYNTAX

Connect-MongoDB -Database <string> -Server <string> <-enough said. I'm on a roll here

And then this happened...

Database: PS C:\WINDOWS\system32> Connect-MongoDB -server aMongoDBServer -Database db

A valid license is required to use MongoDBCmdlets.
Would you like to install a license now? (You may use "TRIAL" as the Product Key to activate a trial license.)
[Y] Yes [N] No [?] Help (default is "Y"):

And now I'm sitting here in my office waiting for an HR rep to show up and talk to me about my volume and my language.

I recognize that this isn't a Microsoft module. I'm just suggesting that Microsoft not allow these paid modules to exist in the repository if the desired experience is for a user to start at the PS prompt and use this workflow to get things done. I don't expect people to not get paid for their work, and I'm not of the mind that I should get everything free. I'm just saying, I have never had anything sold to me at a BASH prompt.

So I have Windows 10, in Windows optionalFeatures.exe Powershell is marked as version 2.0 in windows system32 is it version 1.0 and Windows Powershell HOST command says Version 5.1

Despite the above information, my Powershell does not know how to do any commands such as 'install-module' or 'PSVerstonTable'
I have a suspicion that my Powershell is somehow corrupted or the incorrect version that was manually installed previously.

I have turned Windows PowerShell 2.0 OFF in Windows Features but Powershell remains and I can open and access it.

I have looked for guides and help on how to do a clean install, or repair. I need help.

when I call:
Restart-Computer -ComputerName $lotsOfComputers -Force

where: $lotsOfComputers is 20-150 other computers on the LAN in our AD environment

This is the sequence of events: First, the command completes quickly, the expected computers reboot, and no errors are displayed. I can then type in the console exactly 1 new line of input and hit enter, after which the PowerShell console hangs for a long period of time (several minutes), possibly in correlation to the size of the array of computers. Once it begins hanging it does not register any new keyboard input onscreen during the hang (but it does stay queued up), and after random periods of time, several of the typed keys will show up in the console, then the hang continues, then a few more keys, then eventually they all show up, the hang has finished, and the console is usable again.

Currently occurs on Windows 10 v1709 with the built-in Windows PowerShell version (PSVersion = 5.1.16299.785 as I type this) Does not seem to be machine-specific, it's happened on any Windows 10 machine I've tried this on Windows Powershell 5.1 went RTM.

I've noticed some behavior in PowerShell that I can't explain, but I'm hoping that someone else can.

If I want to build a list of file objects from drive C:\, and I want to ignore shortcut folders (reparse points) such as C:\Documents and Settings. The following command works well:

$FileList = @(Get-ChildItem -Path C:\ -Recurse -Force -Attributes !ReparsePoint);
$FileList | Where-Object {$_.DirectoryName -like "Documents and Settings"};

The Where-Object command returns no files as expected, since C:\Documents and Settings\ is a reparse point.

However, if I run the Test-Connection command first, then the Get-ChildItem command appears to ignore the -Attributes !ReparsePoint parameter, and it traverses C:\Documents and Settings.

Test-Connection -Computer MyComputer;
$FileList = @(Get-ChildItem -Path C:\ -Recurse -Force -Attributes !ReparsePoint);
$FileList | Where-Object {$_.DirectoryName -like "Documents and Settings"};

In this case, the Where-Object command displays a lot of files. Note that the Test-Connection can be run against any computer, not just the local computer to exhibit this behavior.

I've duplicated this behavior on computers running PowerShell 4.0 and PowerShell 5.1. Can anyone please explain what's happening?

Additional note: To duplicate this behavior, please make sure that you are using an elevated instance of PowerShell (Run As Administrator). If you use a standard instance of PowerShell, you won't have permissions to view C:\Documents and Settings.

I originally posted this issue here:
https://stackoverflow.com/questions/47802040/why-does-test-connection-force-enumeration-of-reparse-points

If you utilize Smart Cards with certificates that are not directly linked to users (no suitable user DN in Subject and no UPNs in SANs), you are able to link a single certificate to multiple accounts dynamically with the caveat that users need to provide explicit user name hints during logon in order to log on.

User name hints need to be enabled via GPO or registry settings ("X509HintsNeeded"), after which all standard credential dialogs in Windows support them, except PowerShell's Get-Credential. This effectively prevents using PowerShell remoting with such Smart Cards / certificates if different credentials are required.

In today's landscape where Microsoft recommends explicitly tiering your infrastructure and user accounts and using secure methods of administration such as PowerShell Remoting, the omission of this feature is a big letdown. It also reinforces bad habits because Remote Desktop fully supports this scenario while PowerShell does not.

This feature should be implemented.

[Bug] On Windows Management Framework 5.1, ExecutionPolicy set via "User Configuration" (Group Policy) does NOT apply to the "UserPolicy" scope (defaults to "Undefined") on OSs other than Windows 10 and Windows Server 2016

Affected operating systems:
Windows Server 2012 (confirmed)
Windows Server 2008 R2 (confirmed)
Windows 8.1 (unconfirmed)
Windows 8 (unconfirmed)
Windows 7 SP1 (confirmed)

Explanation:
I want to set ONLY the UserPolicy ExecutionPolicy scope to be "Restricted" and leave the MachinePolicy ExecutionPolicy scope as "Undefined" so that it isn't overriding the UserPolicy scope. This will allow the "Builtin\System" \ "NT Authority\System" \ "%ComputerName%$" account to run scripts but NOT user accounts. I believe Windows Management Framework 5.1 has a bug on Windows 7 SP1 and Windows Server 2008 R2 regarding this logic.

If I set the UserPolicy ExecutionPolicy scope via Group Policy (User Configuration\Administrative Templates\Windows Components\Windows PowerShell > Turn on Script Execution), I can confirm that it is applied via the Resultant Set of Policy snap-in and find the correct key in the Registry (HKCU\Software\Policies\Microsoft\Windows\Powershell [ExecutionPolicy]/[EnableScripts]). However, when I run "Get-ExecutionPolicy -List" the UserPolicy ExecutionPolicy scope is "Undefinied" on Windows 7 SP1 and Windows Server 2008 R2. This is definitely not correct and does NOT happen on Windows 10; on Windows 10, it works as expected.

Note that the MachinePolicy ExecutionPolicy scope (Computer Configuration\Administrative Templates\Windows Components\Windows PowerShell > Turn on Script Execution) applies correctly and ALSO applies the MachinePolicy ExecutionPolicy setting to the UserPolicy scope on Windows 7 SP1 and Windows Server 2008 R2. I suspect that, on any machine running a Windows OS other than 10 or Server 2016, Windows Management Framework 5.1 is looking at the MachinePolicy ExecutionPolicy registry key (HKLM\Software\Policies\Microsoft\Windows\Powershell [ExecutionPolicy]/[EnableScripts]) for the UserPolicy ExecutionPolicy scope for some reason.

It seems I'm not the only one with this problem: https://social.technet.microsoft.com/Forums/windowsserver/en-US/0214e13e-3478-4a65-a6f7-a3418d5d8db1/group-policy-for-execution-policy-does-not-work-for-powershell-5?forum=winserverGP

This is an issue for System Admins who manage domains containing machines other than Windows 10 and Windows Server 2016.

I have only tested this on Windows 7 SP1, Windows Server 2008 R2 and Windows 10, so I cannot comment on Windows 8/8.1.

I hope that I'm being clear.

Testing results:
Please see https://hastebin.com/ubojoqovar.tex

We need a PowerShell version of tpmvscmgr.exe to manage TPM virtual smart cards.

The tpmvscmgr.exe tool 1) does not accept PIN, PUK and AdminKey numbers as arguments, these must be entered interactively in powershell.exe only, not ISE or with a pop-up, 2) cannot list currently existing virtual smart card ID strings, and 3) is somewhat crude in how it manages card lockout policies and unlocks.

This is needed not just for Windows clients, but also because Server 2016 Hyper-V supports virtual smart cards for guest VMs, such as for VDI scenarios.

We need to be able to pass in PIN, PUK and AdminKey numbers as arguments (not be prompted in an interactive shell) so that, among other things, we can have simple GUI wrappers written in PowerShell for this. These arguments could be PS secure strings.

If a cmdlet replacement is impossible for some reason, then please add the above functionality to tpmvscmgr.exe (so that we don't have to script sending keystrokes).

We also need the ability to list existing vCards, rename vCards, clear selected certificate+privkey pairs, clear all key pairs, unlock vCards which have suffered too many failed auth attempts, manage the lockout policies, etc.

A resource module for DSC would be nice, but not mandatory. Updating the graphical TPM Management snap-in for mmc.exe would be nice too, but not mandatory.

Here is a C# project with some of the code needed for the cmdlet:

https://code.msdn.microsoft.com/windowsapps/Smart-card-sample-c7d342e0

Please add the cmdlet(s) to the built-in TrustedPlatformModule posh module and not just to the PSGallery, though that would be OK as long as it is sponsored and supported by Microsoft as future TPM versions and future Windows OS'es are released.

Thank You!
Jason

Object Oriented Programming seems to be supported now in PowerShell, but custom classes defined in modules don't seem to behave the way they should.

There only seem to be two consistent ways to make these work when importing a module that has classes defined:
1. Import the module, then run "using module ..." to make the classes available in the session. Alternatively, you can import the module with the using statement, but this isn't ideal (no versioning).
2. Add the class definition file(s) to the ScriptsToProcess attribute of the module. This isn't ideal either as it runs the scripts in the global session which is bad practice.

Please provide a method that allows classes to be packaged with a module to support OOP scenarios. Thanks!