We've been lucky, from what I'm gathering from web searches! Until December last year, Exchange Online Powershell cmdlet help was available using Get-Help in the shell. However, after the Christmas break, the only response we get is:

Get-Help : Exception calling "Invoke" with "0" argument(s): "Cannot find path '' because it does
not exist."
At line:1 char:1
+ Get-Help Get-Mailbox
+ ~~~~~~~~~~~~~~~~~~~~~~~~~~~
+ CategoryInfo : NotSpecified: (:) [Get-Help], MethodInvocationException
+ FullyQualifiedErrorId : CmdletInvocationException

It's the same issue irrespective of the cmdlet.

Consequently, I'm forced to contend with painful searches of the documentation website for information of the relevant cmdlets.

Raised this question on the Github Exchange documentation site (https://github.com/MicrosoftDocs/office-docs-powershell/issues/2440) and Chris Davis, who noticed the issue since June, suggested I raise a support case. So not sure this is the right place to do so.

Powershell 5.1 on both Windows 7/10

# Steps to reproduce

In File Explorer on an NTFS volume, create the file: [abc].txt

Following this run:

PS> ls '[abc].txt'

# Expected behavior

Directory: C:\Users\Dave

Mode LastWriteTime Length Name
---- ------------- ------ ----
-a---- 2019-05-06 12:07 AM 0 [abc].txt

# Actual behavior

No output displayed.

# Environment data

Name Value
---- -----
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

# Additional Cases and Information

The file name can be displayed using tab completion, but the brackets are preceded by back ticks, which indicates that Windows can see the file and assumes that the brackets are special characters. When attempting to list the file using the `ls` command, the following error is generated:

ls : Cannot find path 'C:\Users\Dave\`[abc`].txt' because it does not exist.
At line:1 char:1
+ ls '.\`[abc`].txt'
+ ~~~~~~~~~~~~~~~~~~
+ CategoryInfo : ObjectNotFound: (C:\Users\Dave\`[abc`].txt:String) [Get-ChildItem], ItemNotFoundExceptio
n
+ FullyQualifiedErrorId : PathNotFound,Microsoft.PowerShell.Commands.GetChildItemCommand

Other commands generate no output or errors as well.

PS> Get-FileHash '[abc].txt'
# Generates no output

PS> 1 | Out-File '[abc].txt'
# Generates error stating that the wildcard path did not resolve to a file

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?

Dear Friends,
I am running all commands in windows powershell as an administrator.

I am trying to configure gMSA on win 2016 server. I am able to run the below command to create the gMSA.

New-ADServiceAccount -Name "rassonline" -ServicePrincipalNames "host/rassonline", "host/rassonline.omnitel.it" -PrincipalsAllowedToRetrieveManagedPassword "rassonlineHosts" -DnsHostName "rassonline.omnitel.it"

After this I am running

"Test-ADServiceAccount -Identity rassonline"

Getting the below warning as the result of execution of above command.

"WARNING: Test failed for Managed Service Account MSA. If standalone Managed Service Account, the account is linked to another computer object in the Active Directory. If group Managed Service Account, either this computer does not have permission to use the group MSA or this computer does not support all the Kerberos encryption types required for the gMSA. See the MSA operational log for more information."

I dont understand what should I do in this situation. I have seen the description of the error message in other portals as below.

Description: "Test results returned if MsaInfoCannotInstall"

What should I do now to configure gMSA? What am I missing ?

Appreciate any kind of suggestions.

Thanks,
Sajitha Chandran
Sajitharnair@gmail.com

When calling PowerShell from CMD and specifying a script file that contains an extra "extension" (extra dot) in the base name, the script is not run but the file is mysteriously deleted:

Example (run in CMD):

powershell -file c:\temp\script.txt.ps1

The same issue when called like this:

powershell -command "& c:\temp\script.txt.ps1"

This has been reproduced by me and others on different machines with different paths.

The same issue exists when called from inside PowerShell like this:

. "powershell.exe" -file c:\temp\script.txt.ps1
Start-Process "powershell" -Arg "-file, "c:\temp\script.txt.ps1"

Note that these will work just fine:

powershell -command "& 'c:\temp\script.txt.ps1'"
powershell -command ";& c:\temp\script.txt.ps1"
powershell -file "c:\temp\script.ps1.ps1"

Could this be an optimization bug?