Integrated Modules are not loaded if you have a Network Path in $env:PSModulePath which is not reachable.

##############
I have customized the PSModulePath:

PS C:\Users\username> ($env:PSModulePath).split(';')
C:\Users\username\Documents\WindowsPowerShell\Modules
C:\Program Files\WindowsPowerShell\Modules
C:\Windows\system32\WindowsPowerShell\v1.0\Modules\
c:\Program Files\Microsoft Security Client\MpProvider\
C:\Program Files\Microsoft Monitoring Agent\Agent\PowerShell\
\\my.domain\share\Modules\

##############
If i try to execute e.g. Invoke-RestMethod

PS C:\Users\username> Invoke-RestMethod
Invoke-RestMethod : The 'Invoke-RestMethod' command was found in the module 'Microsoft.PowerShell.Utility', but the
module could not be loaded. For more information, run 'Import-Module Microsoft.PowerShell.Utility'.
At line:1 char:1
+ Invoke-RestMethod
+ ~~~~~~~~~~~~~~~~~
+ CategoryInfo : ObjectNotFound: (Invoke-RestMethod:String) [], CommandNotFoundException
+ FullyQualifiedErrorId : CouldNotAutoloadMatchingModule

PS C:\Users\username> Get-Command Invoke-RestMethod
Get-Command : The term 'Invoke-RestMethod' is not recognized as the name of a cmdlet, function, script file, or
operable program. Check the spelling of the name, or if a path was included, verify that the path is correct and try
again.
At line:1 char:1
+ Get-Command Invoke-RestMethod
+ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+ CategoryInfo : ObjectNotFound: (Invoke-RestMethod:String) [Get-Command], CommandNotFoundException
+ FullyQualifiedErrorId : CommandNotFoundException,Microsoft.PowerShell.Commands.GetCommandCommand

PS C:\Users\username> Import-Module Microsoft.PowerShell.Utility -Verbose
VERBOSE: Loading module from path
'C:\Windows\system32\WindowsPowerShell\v1.0\Modules\Microsoft.PowerShell.Utility\Microsoft.PowerShell.Utility.psd1'.
Import-Module : The network path was not found
At line:1 char:1
+ Import-Module Microsoft.PowerShell.Utility -Verbose
+ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+ CategoryInfo : NotSpecified: (:) [Import-Module], IOException
+ FullyQualifiedErrorId : System.IO.IOException,Microsoft.PowerShell.Commands.ImportModuleCommand

Slow "." hash lookups (more than 100 times slower than []) from PowerShell Version 2 to Version 5.1

This could be either a documentation problem or a bug. The documentation never says that the "." hash lookup can be much slower than the [] lookup. I hope it is a bug (one less thing to remember). They both worked at the same speed in PS Version 2.0 and diverged sometime after that.

Two script files. The first calls the second forcing versions 1 thru 5 of PowerShell.

The "." hash lookups in PS Version 2.0 take .028 seconds.
The "." hash lookups in PS Version 5.1 take 5.052 seconds.

# versions.ps1
foreach ($v in 1..5) {
powershell -version $v .\slowHashLookup.ps1
}

# slowHashLookup.ps1
"PS Version $($PSVersionTable.PSVersion)"
$lines = @()
foreach ($i in 1..100) {
$lines += -join (32..126 | Get-Random -Count 20 | foreach {[char]$_})
}
$counts = @{}
foreach ($line in $lines) {
for ($i = 0; $i -lt $line.Length-1; $i++) {
$counts[$line.Substring($i,2)]++
}
}
$secs = (Measure-Command {
foreach ($line in $lines) {
for ($i = 0; $i -lt $line.Length-1; $i++) {
$n = $counts[$line.Substring($i,2)]
}
}
}).TotalSeconds
"[] hash lookups $secs seconds"
$secs = (Measure-Command {
foreach ($line in $lines) {
for ($i = 0; $i -lt $line.Length-1; $i++) {
$n = $counts.($line.Substring($i,2))
}
}
}).TotalSeconds
". hash lookups $secs seconds"

Output:

PS C:> .\versions.ps1
PS Version 2.0
[] hash lookups 0.0284868 seconds
. hash lookups 0.0283505 seconds
PS Version 2.0
[] hash lookups 0.0291108 seconds
. hash lookups 0.0290708 seconds
PS Version 5.1.15063.413
[] hash lookups 0.0339591 seconds
. hash lookups 5.0528303 seconds
PS Version 5.1.15063.413
[] hash lookups 0.0341827 seconds
. hash lookups 5.0992145 seconds
PS Version 5.1.15063.413
[] hash lookups 0.0338455 seconds
. hash lookups 5.0606782 seconds

I am trying to do a query to obtain setting values of RSOP_SecuritySettingBoolean in PowerShell (and WMI) but it returned nothing. The following query I attempted:

E:\>PS E:\> Get-WmiObject -Namespace "root\RSOP\Computer" -Query "SELECT setting FROM RSOP_SecuritySettingBoolean Where KeyName='ClearTextPassword' and precedence='1'"

PS E:\>

For your extra information:

E:\>ver

Microsoft Windows [Version 10.0.14393]

PS E:\> $psversiontable

Name Value
---- -----
PSVersion 5.1.14393.1198
PSEdition Desktop
PSCompatibleVersions {1.0, 2.0, 3.0, 4.0...}
BuildVersion 10.0.14393.1198
CLRVersion 4.0.30319.42000
WSManStackVersion 3.0
PSRemotingProtocolVersion 2.3
SerializationVersion 1.1.0.1

My Windows 10 OS is still fresh, installed about 2 months ago via ISO. Why is it not returning any results? Please help. Thank you.

I'm not sure why this is, but for some reason Get-TargetResource requires not only the 'Key' parameters, but also the 'Required' parameters. My understanding is only 'Keys' should be necessary to find an existing resource and the 'Required' parameters are necessary when you want to create/update/delete something related to a resource.

This really makes no sense and will hinder our ability to build higher level tech on top of DSC. If I have the key values for any piece of data in any system, I should be able to retrieve it without any additional information.

In almost all of the DSC resources I look at, users have their Get-TargetResource accepting a bunch of parameters they never use due to this restriction in the engine.

xComputerManagement\xScheduledTask is a quick example. The only information needed to find any scheduled task is the 'TaskName', all other parameters are unnecessary. However, DSC has forced the authors to include a bunch of extra parameters in the definition which are never even used in the Get-TargetResource codebase.

If some one can explain a logical reason why we are doing this, I will happily accept it, but I can not think of one and this appears to be creating a bunch of unnecessary work on development and testing staff.

Under PowerShell 5.1, the Test-Path command will return a [UnauthorizedAccessException] when you try to test a path the current user does not have access to. Normally this error is uncatchable, but it becomes so if you set the PathType to Container. Despite the name, Test-Path will verify the existence of both Containers and Leafs in this mode. Because the [UnauthorizedAccessException] error is ONLY returned for extant files and folders, a user can use it to confirm the existence of files and folders they should not be able to see or access.

This one-liner allows you to bypass security restrictions:
try{ Test-Path $Path -PathType Container} catch [System.UnauthorizedAccessException] { $true }

Example In Practice:
Say the following Directory Tree Exists and that the Security of the C:\test folder has been modified to disable inheritance and DENY all permissions on this folder, subfolders, and files to User “testUser”.
C:\test
└subtest
└─subfile.txt
└file.txt

In this case, testUser can use verify the existence of each of those files and folders by running the following operation.

$fileList = @(
"C:\test",
"C:\test\test.txt",
"C:\test\subtest",
"C:\test\subtest\subfile.txt",
"C:\test\nonExistentFile.csv")

$fileList |
Select @{Name="Path";Expression={$_}},
@{Name="Exists";Expression={$(try {Test-Path $_ -PathType Container} catch [System.UnauthorizedAccessException]{$true})}}

}

Output:
Path Exists
---- ------
C:\test True
C:\test\test.txt True
C:\test\subtest True
C:\test\subtest\subfile.txt True
C:\test\nonExistentFile.csv False

I discovered recently that the handling of `stderr` from native commands isn't being dealt with consistently between Windows PowerShell and Windows PowerShell ISE.

Steps to reproduce
------------------

```powershell
$errorActionPreference="stop"; try { cmd /c nosuchexe } catch { 'dang!' }
```

Actual ISE behavior (expected)
-----------------

```none
dang!
```
Native commands writing to `stderr` while `$errorActionPreference="stop"` generate a catchable `NativeCommandError` which encapsulates the original error message in a `ErrorRecord`. It is easy to capture, analyze, and reword error messages in context.

Actual CLI behavior
---------------

```none
'nosuchexe' is not recognized as an internal or external command,
operable program or batch file.
```

No `NativeCommandError` is generated, no matter how `$errorActionPreference` is set. The `stderr` from the native command is piped straight through to the default process `stderr`.

This behavior is a serious loss of functionality, leading some to believe that PowerShell can't distinguish between `stderr` and `stdout`. Lots of community confusion generated because of the discrepency. See https://stackoverflow.com/questions/44488202/powershell-streaming-output/44491420#44491420, among others.

Analysis
---------
The difference isn't just the ISE, I think it is related to PowerShell remote runspaces! The full info on the caught error record (in the ISE) demonstrates the underlying exception is a RemoteException like this:

```powershell
PS C:\Users\Burt_> $errorActionPreference="stop"; try { cmd /c nosuchexe } catch { Format-List * -force -InputObject $_ }

PSMessageDetails :
Exception : System.Management.Automation.RemoteException: 'nosuchexe' is not recognized as an internal or external
command,
TargetObject : 'nosuchexe' is not recognized as an internal or external command,
CategoryInfo : NotSpecified: ('nosuchexe' is ...ternal command,:String) [], RemoteException
FullyQualifiedErrorId : NativeCommandError
ErrorDetails :
InvocationInfo : System.Management.Automation.InvocationInfo
ScriptStackTrace : at <ScriptBlock>, <No file>: line 1
PipelineIterationInfo : {}
```

Environment data
----------------
Both powershell.exe and powershell_ise.exe report the same version information:

```powershell
Name Value
---- -----
PSVersion 5.1.15063.296
PSEdition Desktop
PSCompatibleVersions {1.0, 2.0, 3.0, 4.0...}
BuildVersion 10.0.15063.296
CLRVersion 4.0.30319.42000
WSManStackVersion 3.0
PSRemotingProtocolVersion 2.3
SerializationVersion 1.1.0.1
```

It is very annoying and confusing that some cmdlets require the starting brace to be on the same line as the cmdlet, while others do not.

For example, this is valid:

... | ForEach-Object {
$sourcefile = $_.Name
}

but this is not:

... | ForEach-Object
{
$sourcefile = $_.Name
}

yet using this is valid:

foreach ($x in $y)
{
$sourcefile = $_.Name
}

I know that you can use the backtick to make it valid, like this:

... | ForEach-Object `
{
$sourcefile = $_.Name
}

but that's still not intuitive and requires you to remember to do it.

As shown in this post (https://stackoverflow.com/questions/15974729/powershell-v2-prompting-for-value-in-foreach) and this one (https://social.technet.microsoft.com/Forums/windowsserver/en-US/ff25b75d-b6c2-4d2b-a87d-5348cfe8f0de/parameter-prompt-on-foreachobject-in-pipeline?forum=winserverpowershell), it is very easy to get tripped up on this, since some cmdlets/keywords allow it and others do not.

It would be great if you could update PowerShell to simply support both styles as valid syntax.

Also, for a C# / .Net programmer coming into PowerShell, having the curly brace on a newline is the defacto standard, so it's very likely that this crowd will get tripped up on this inconsistent syntax.

Copy and run with -Debug. You'll see...

function Get-ArrayDups([array]$ArrayCheck, $IOI) {
$indices = @()

For($i=0;$i -le $ArrayCheck.Length; $i++) {If ($IOI -eq $ArrayCheck[$i]) {$indices += $i}}
"Variable `$indices = " + $indices
"`$ArrayCheck[0] = " + $ArrayCheck[0]
"`$ArrayCheck[9] = " + $ArrayCheck[9]
}

Function Get-ArrayDups {
[cmdletbinding()]
Param(
[Parameter(ValueFromPipeline = $true)]
[Array]
$ArrayContent,

[int]
$IOI
)
BEGIN { [array]$indices = @()
$Len = $ArrayContent.Count
$i = 0
Write-Debug "Initial Value: `$Len = $Len"
Write-Debug "Initial Value: `$ArrayContent[`$Len] = $($ArrayContent[$Len-1])"
Write-Debug "Initial Value: IOI is $IOI"
Write-Debug "Initial Value: The full passed in array is $ArrayContent"
Write-Debug "Initial Value: Length of `$indices is $($indices.Count)"
}#begin
PROCESS {
foreach ($ArrayItem in $ArrayContent)
{If ($ArrayItem[$i] -eq $IOI){
$indices += $i
} Else {
Write-Debug "*** No Match Found ***"
Write-Debug "The value of `$i right now is $i"
Write-Debug "The value of `$ArrayItem[$i] is $($ArrayItem[$i])"
Write-Debug "The value of `$IOI is $IOI"
Write-Debug "`$ArrayItem type is $($ArrayItem.GetType())"
Write-Debug "`$IOI type is $($IOI.GetType())"
}#if/else

$i++
}#foreach
}#process
END {
Write-Output $indices
Write-Debug "End of processing: `$IOI = $IOI"
Write-Debug "End of processing: `$i = $i"
Write-Debug "End of processing:`$Len = $Len"
Write-Debug "End of processing: `$ArrayContent[`$Len] = $($ArrayContent[($Len-1)])"
}#end
}#function

I'm preparing some "Windows Server 2016" machines. While testing I stumbled across some issues with PowerShell.
I invested some time and narrowed it down a bit.

I also posted the issue on Microsoft Technet Forum and got the recommendation to file a Bug/Request here. Other users were also able to reproduce it quite easily:
(see: https://social.technet.microsoft.com/Forums/en-US/842c2cc2-c7f6-41b7-9561-31b2c65262b0/executionpolicyoverrideproblem-with-gpo-in-place-?forum=winserverpowershell)

Steps to reproduce:

I create a new VM, insert the Server 2016 ISO, boot up and install. After first start I change the network-settings for my environment and join the domain. I move the new computer-object to an OU where the group policy "Turn on script execution" with the setting "Allow all scripts" is in place. I make a restart.

Now I open Powershell ISE and create a new PS1-Script at "C:\Temp" with the content "Start-Sleep -Seconds 10". I close the ISE and open up the folder "C:\Temp" in explorer. I right-click the PS1 and select "Execute with Powershell". Now I get the following Error:

hxxp://www.fotos-hochladen.net/uploads/ps1xw84bh5p7s.png

The Error says:
Set-ExecutionPolicy : Windows PowerShell updated your execution policy successfully, but the setting is overridden by a policy defined at a more specific scope. Due to the override, your shell will retain its current effective execution policy of RemoteSigned. Type “Get-ExecutionPolicy -List” to view your execution policy Settings ...

The Command "Get-ExecutionPolicy -List" shows the following:

hxxp://www.fotos-hochladen.net/uploads/ps297p8i30kvf.png

I did read some content I found from Google, like:

hxxps://powershellpanda.wordpress.com/2013/12/01/override-gpo-for-powershell-execution-policy/
hxxps://absolute-sharepoint.com/2015/03/windows-powershell-updated-execution-policy-successfully-setting-overridden-policy-defined-specific-scope.html

I don't find a way around except removing the GPO. The GPO sets:
Key: HKLM:\SOFTWARE\Policies\Microsoft\Windows\PowerShell
Setting: ExecutionPolicy
Value: Unrestricted

As soon as I remove this setting the script is working fine and without error.

The Command "Get-ExecutionPolicy -List" shows the following after removing the GPO:

hxxp://www.fotos-hochladen.net/uploads/ps3snm5uhl39k.png

It is not the mentioned error only. The issue goes further.
I have a (deployment-)script, where I have "Dot-Sourced" about 10 other PS1-Scripts.
When I run the main-script like mentioned, I get the error as above and I have to confirm the execution of every single dot-sourced PS1.
I am using this in an highly automated Environment and didn't have this beaviour in Server 2008r2 or 2012.

Thank you

Steps to reproduce

Import-Module PSScheduledJob
Register-ScheduledJob -Name 'test' -ScriptBlock {echo 'hello world'}
Unregister-ScheduledJob -Name test -WhatIf
Get-ScheduledJob

Expected behavior

I expect the job to still be there.

It does work with Unregister-ScheduledJob -Id 11 -WhatIf.

Actual behavior

The scheduled job is corrupted.

Get-ScheduledJob : Cannot get the test scheduled job because it is corrupted or in an irresolvable state. Because
it cannot run, Windows PowerShell has deleted test and its results from the computer. To recreate the scheduled
job, use the Register-ScheduledJob cmdlet. For more information about corrupted scheduled jobs, see
about_Scheduled_Jobs_Troubleshooting.

Environment data

> $PSVersionTable
Name Value
---- -----
PSVersion 5.1.14393.1198
PSEdition Desktop
PSCompatibleVersions {1.0, 2.0, 3.0, 4.0...}
BuildVersion 10.0.14393.1198
CLRVersion 4.0.30319.42000
WSManStackVersion 3.0
PSRemotingProtocolVersion 2.3
SerializationVersion 1.1.0.1