Using the LiteralPath parameter for Get-Acl and Set-Acl does not work for registry keys unless your location is set to the root directory of the registry key in question.

Steps to reproduce:

input:
--------------------------------------------------------------------
PS C:\WINDOWS\system32> Get-Acl -LiteralPath
output (error):
-------------------------------------------------------------------'HKCU:\Environment'
Get-Acl : Cannot find path 'HKEY_CURRENT_USER\Environment' because it does not exist.
At line:1 char:1
+ Get-Acl -LiteralPath 'HKCU:\Environment'
+ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+ CategoryInfo : ObjectNotFound: (:) [Get-Acl], ItemNotFoundException
+ FullyQualifiedErrorId : GetAcl_PathNotFound,Microsoft.PowerShell.Commands.GetAclCommand

input:
------------------------------------------------------------------------
PS C:\WINDOWS\system32> Set-Location -LiteralPath 'HKCU:\Environment\'
PS HKCU:\Environment\> Get-Acl -LiteralPath 'HKCU:\Environment'

output (error)
------------------------------------------------------------------------
Get-Acl : Cannot find path 'HKEY_CURRENT_USER\Environment' because it does not exist.
At line:1 char:1
+ Get-Acl -LiteralPath 'HKCU:\Environment'
+ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+ CategoryInfo : ObjectNotFound: (:) [Get-Acl], ItemNotFoundException
+ FullyQualifiedErrorId : GetAcl_PathNotFound,Microsoft.PowerShell.Commands.GetAclCommand

input:
------------------------------------------------------------------------
PS HKCU:\Environment\> Set-Location -LiteralPath 'HKCU:\'
PS HKCU:\> Get-Acl -LiteralPath 'HKCU:\Environment'

output (no error):
------------------------------------------------------------------------
Path Owner Access
---- ----- ------
Microsoft.PowerShell.Core\Registry::HKEY_CURRENT_USER\Environment NT AUTHORITY\SYSTEM NT AUTHORITY\RESTRICTED Allow ...

Hi there

Im working with WindowsPE and have to identify my USB-Drive.

So I´m looking for the drive and assign a variable:

$usb_drive = (Get-WmiObject -class Win32_LogicalDisk -filter DriveType=2 | Foreach {Get-ChildItem -Filter *.wim -r -d 1 $_.DeviceID} 2>$null | Where {$_.name -eq "boot.wim"}).PsDrive.Root

With Powershell 5.1.14393.2791 its working as expected. With 5.1.18361.1 not.

The reason is this part:

Get-WmiObject -class Win32_LogicalDisk -filter DriveType=2 | Foreach {Get-ChildItem -Filter *.wim -r -d 1 $_.DeviceID}

The Reason is handling of $_.Deviceid. On both versions the Result is c:

On both versions Get-Childitem C: gets the entries of the local directory (which makes absolutely no sense!!!!)
Get-Childitem c:\ gets the root-entries form c: - which makes sense.

However - the code postet here works on 14393, but not on 18361.1

imho it should

Write-Information does not show in a file transcribed by Start-Transcript unless you set $InformationPreference to 'SilentlyContinue'... which then means it does not display in the console.

I believe this is a bug in Windows PowerShell (as of v5.1.17134.590) that has been fixed in PowerShell Core? If we cannot go to Core I have to do some workarounds (like using Write-Host or creating a function that combines 2 Write-Information calls with different preferences).

There looks like a better formatted thread here on this issue:
https://stackoverflow.com/questions/55191548/write-information-does-not-show-in-a-file-transcribed-by-start-transcript

Here's $PSVersionTable:
---------------------------------------------------------------------------
PSVersion 5.1.17763.316
PSEdition Desktop
PSCompatibleVersions {1.0, 2.0, 3.0, 4.0...}
BuildVersion 10.0.17763.316
CLRVersion 4.0.30319.42000
WSManStackVersion 3.0
PSRemotingProtocolVersion 2.3
SerializationVersion 1.1.0.1

Allow the DISM Repair-WindowsImage command to use HTTPS URIs for image sources. We use a common image to repair the insanely frequent container store corruption issues on our systems. It occurred to me that if somebody with malicious intent was able to alter the WIM files we use to facilitate this process it would lead to easy mass pwnage. Therefore, it makes sense to use an extremely simple, easy-to-lock-down protocol like HTTPS to provide access to these rather huge files rather than a complex protocol like SMB that forces us to expose many other RPC services as well. Yes, this can be locked down well *in theory*. But HTTPS can be locked far better and with far less effort.

Currently module imports initiated via the RequiredModules statement in a Module Manifest do not allow for verbosity preference.

This results in a lot of additional noise for end users.
For example. If a DSC Resource module requires other modules, and imports them via RequiredModules in the Module Manifest then the following happens:

If an end-user is attempting to troubleshoot their DSC configuration they will utilize

Start-DscConfiguration -UseExisting -Verbose -Force

The results will be a verbose line for every cmdlet imported/exported from every included module. Which is A LOT of noise surrounding the verbose messages actually relevant to the end user.

There should be a way to avoid this. Something like this:

RequiredModules = @(@{ModuleName = "MSOnline"; ModuleVersion = "1.1.183.17"; Verbose:$false })

I have a filter in a script module that a does a little error formatting and flags the fact that it's seen an error. Most of the time, it seems to do its little job just fine. About once a week a sharing violation triggers some kind of infinite recursion and PowerShell emits the depth overflow error. The odd thing is that the function is not recursive. I've run procmon and I can see that the sharing violation happens just once - most of what happens after than is PowerShell writing to a pstrace log (I've wrapped the offending section in Trace-Command *). I can supply the .PML from procmon and the pstrace file, both for a failing instance and for a successful run 2 minutes later.