Hello Community

I hope that i have finally hit the correct place to post my question, since i have been unable to find it so far. Here is my situation:

I have been developing a Powershell script using Powershell ISE, and for the most part i am very happy about it, however i have encountered what i believe to be a bug in the call operator (&).

When i use the call operator followed by a "pure" string everything works as it should, the command works and ISE runs as usual, but when i use the call operator followed by a variable, the command executes correctly, however ISE will no longer use the intellisense function to automatically show a drop-down list of possible variables when using "$". It is still possible to press ctrl + space to force the drop-down to appear. This error will disappear when you delete the call operator or the variable.

Here is an eksample:
(This courses the problem)
$c = 'C:\Path\To\Script'
& $c

(This does not course the problem)
& 'C:\Path\To\Script'

I hope someone is able to help me understand what is happening here, and if it is a bug then give me an alternative solution to executing a script on the local PC though a script.

I use Powershell version 5.1.17763.503

On some of our servers, when using cmdlet "Add-MpPreference", we got error of "Provider load failure", after some investigation, we found following issues for WMI to create files? Did anyone experience similar issues before?

wmiprvse.exe 7488 CreateFile C:\Windows\System32\wbem\NCObjAPI.DLL NAME NOT FOUND Desired Access: Read Attributes, Disposition: Open, Options: Open Reparse Point, Attributes: n/a, ShareMode: Read, Write, Delete, AllocationSize: n/a
wmiprvse.exe 7488 CreateFile C:\Windows\System32\wbem\wbemcomn.dll NAME NOT FOUND Desired Access: Read Attributes, Disposition: Open, Options: Open Reparse Point, Attributes: n/a, ShareMode: Read, Write, Delete, AllocationSize: n/a
wmiprvse.exe 7488 CreateFile C:\Windows\System32\wbem\wbemcomn.dll NAME NOT FOUND Desired Access: Read Attributes, Disposition: Open, Options: Open Reparse Point, Attributes: n/a, ShareMode: Read, Write, Delete, AllocationSize: n/a
wmiprvse.exe 7488 CreateFile C:\Windows\System32\wbem\bcrypt.dll NAME NOT FOUND Desired Access: Read Attributes, Disposition: Open, Options: Open Reparse Point, Attributes: n/a, ShareMode: Read, Write, Delete, AllocationSize: n/a

Set the color for control panel/Text Background is useless, whatever you set, it stil the default color(Red:1,Green:36, Blue:86).

there are 3 items regarding the ConsolePane and 2 items regarding the ScriptPane for editing theme. I am not sure "ConsolePaneTextBackgroundColor" is needed as "ConsolePaneBackgroundColor" is existed.

My understanding is when we edit color for ConsolePane, we need to make sure "ConsolePaneBackgroundColor" and "ConsolePaneTextBackgroundColor" the same, in order to aligned, but it is work for other color. only the default color(Red:1,Green:36, Blue:86) works.

<string>ConsolePaneBackgroundColor</string>
<string>ConsolePaneForegroundColor</string>
<string>ConsolePaneTextBackgroundColor</string>

<string>ScriptPaneBackgroundColor</string>
<string>ScriptPaneForegroundColor</string>

please find my version information below.

PS C:\WINDOWS\system32> $PSVersionTable

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

Currently there is no built in or easy way to have credentials stored to map persistent Drives via a script.

If you are mapping a drive for the same domain that the system is on then it will pass-through the current user's credentials, and it will save alternate credentials for the mapping in the current user session. However if you are trying to map a persistent drive for a share from a different non-federated domain, a workgroup computer, or for something on the same domain using different credentials, the password is not saved through logouts or reboots. Not only is the password not saved, but unless you manually put the credentials in Credential Manager (currently no native PS commands to do this, if you're scripting need to use the old Cmdkey commands) it will lockout the username specified in the credentials by trying to login with a blank password several times.

See here for a more detailed explanation of the mechanics and issue:
https://www.bloggingforlogging.com/2018/11/22/windows-mapped-drives-what-the-****-is-going-on/

I suggest that the New-PSDrive command be updated so that it adds the credentials to Credential Manager if both the -Persist and -Credential options are specified.

This would result in the expected behaviour of the drives being persistent through logouts and reboots, mirror the current behaviour when the drive is mapped via the GUI, and fix the account lockout issue that this can cause.

# Steps to reproduce

# Must use the format username@domain for username and be mapping share from different non-federated domain to reproduce
$Cred = Get-Credential
$Path = 'Path to the share'
New-PSDrive -Name 'P' -PSProvider FileSystem -Root $Path -Persist -Credential $Cred -Scope Global

# Expected behavior

The $Cred.username value gets stored in the registry under HKEY_CURRENT_USER\Network\P
in the UserName string value without alteration.

# Actual behavior

The domain of the system running the commands gets appended in the front of the username from the cred object when stored in the reg key.

For example if $Cred.Username is 'username@Domain1.com' and the computer running the command is on Domain2, the value stored in the reg key is 'Domain2\username@Domain1.com'.

This causes issues with persistence when mapping drives from another domain due to the system trying to authenticate against the wrong domain.

This behaviour only happens when mapping a drive using credentials from a different domain with the username in the format 'username@domain.com' being passed to New-PSDrive as a credential object. It does not happen when the credential object has the username in the format domain1\username, when specifying the username in the command and entering it into the popup, or when using a credential object for the same domain the system running the commands belongs to.

Since May 2019 Security Rollup for Windows Server 2016, access to .net object via powershell is very slow, when a powershell variable breakpoint is set in the powershell.

For example loading speed of [System.Environment] takes over ten times with breakpoint set against no breakpoint set.

Since the behavior only occurs with latest security updates installed (May 2019 (KB4494440) or June 2019 (KB4503267)) i think it is related to the update.

Did some troubleshooting with procmon until now. For me it looks like when PSBreakpoint is set, there are multiple reads from HKLM\System\CurrentControlSet\Control\Session Manager\Environment\__PSLockdownPolicy can't repoduce this when there is no breakpoint set and can't reproduce this effect without one of the updates installed.

Following powershell code runs more than 10 times slower when i install Windows Security Rollup update Mai / June 2019 on my Windows Server 2016.

$measure1 = measure-command{
foreach($i in 1..10000){
[System.Environment]
}
} |select -ExpandProperty TotalSeconds

Set-PSBreakpoint -Variable "test" -Action {$null}

$measure2 = measure-command{
foreach($i in 1..10000){
[System.Environment]
}
} |select -ExpandProperty TotalSeconds

Write-Host "First measurement took $measure1 seconds, Second measurement took $measure2"

>>First measurement took 0.0482474 seconds, Second measurement took 0.8722697

Tested on:

PSVersion: 5.1.14393.2969
PSEdition: Desktop
PSCompatibleVersions: {1.0, 2.0, 3.0, 4.0...}
BuildVersion:10.0.14393.2969
CLRVersion:4.0.30319.42000
WSManStackVersion:3.0
PSRemotingProtocolVersion:2.3
SerializationVersion:1.1.0.1

Can anyone observe this behavior as well?

Do you have any suggestions to workaround this problem?

Is it related to some settings or installed software?