To be better notified of incoming tickets in our ticket system I developed a script that opens a hidden IE instance:

$ie = New-Object -ComObject InternetExplorer.Application
(I tried the respective registry entry and "$ie = new-object -Com InternetExplorer.ApplicationMedium", no better.)

(This input box is too small.)

After some script statements to log in and navigate to the incoming tickets monitor, I do a

$newcalls = $ie.Document.getElementsByName("callid")

(This input box is too small.)

That's working perfectly fine in PowerShell version 4, but in v5 I get

Exception from HRESULT: 0x800A138A
At <path>.ps1:89
char:5
+ $newcalls = $ie.Document.getElementsByName("callid")
+ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+ CategoryInfo : OperationStopped: (:) [], COMException
+ FullyQualifiedErrorId : System.Runtime.InteropServices.COMException

(This input box is too small.)

I started the new powershell instance with -Version 4.0, no difference.

Windows 7, installed WMI 5.1 to get PowerShell 5, fool I was.

Hi there

in this case I have to remove and reinstall an OS while booting from usb stick. But this is only one example - it´s not the first time im seeing this behaviour.

if (Test-path c:) {Get-Volume -DriveLetter c | Get-Partition | Remove-PartitionAccessPath -AccessPath c:\}

In this line the term C is used three times

First time as c: (here would be c:\ also possible)
Second time as c (neither c: nor c:\ is working here)
Third time as c:\ (neither c nor c: is working here)

I´m working with variables - this means I have to create 3 Variables to obey all this rules.

My suggestion - decide for one notation and use this consistently! everywhere!

Hi!

We recently got WMF 5.1 (KB3191566) that included PS 5.
We then began finding differences in the behavior of PS 5 and PS 4 when running our scripts. The result was different.

We didn´t notice this problem since someone wrapped it in a try catch block... So to recreate this issue/bug I made this script and ran it on one host with PS 5 and one VM host on PS 4.

add-type -Language CSharpVersion3 -TypeDefinition @"
public class TestClass
{
public System.Collections.Generic.List<System.Int32> listObject { get; set; }
}
"@

[string]$string = "1"

$classWithList = New-Object TestClass

$classWithList.listObject = $string

The result was indeed different. PS 4 would throw an exception (Exception setting "listObject": "Cannot convert the "1" value of type "System.String" to type "System.Collections.Generic.List`1[System.Int32]".") and PS 5 would add the string as an int.

I know the script is really badly written, but this makes the script not backward compatible.

Is this a known problem?

Do I have to re-write the script or is there a way to make it backward compatible with PS 4?

Thanks!

Best regards,
Lucas Ohlson

Managing registry keys and values on local and remote systems with PowerShell is a pain.

Reviewing the articles, forums and blogs on the Internet clearly shows that new PowerShell users struggle to understand how to use registry provider drives and the cmdlets like New-Item, Get-ItemProperty, New-ItemProperty, and so on. This has prompted the creation of a variety of home-brew modules and functions to deal with the problem, like this one, which is extremely useful, but is not built into PowerShell by default of course:

https://gallery.technet.microsoft.com/RegistryLibrarypsm1-b38a81ba

PowerShell needs a proper set of built-in, dedicated registry cmdlets that 1) are easy to understand and use, even by PoSh newbies, 2) work on both local and remote registries, 3) can handle default values in keys, 4) can create the entire subkey path to a target value in one shot, 5) can create and set a value in one shot, 6) can handle all registry value types, including REG_BINARY, 7) export and import entire branches, 8) query and edit registry key permissions, and 9) which handle problems somewhat gracefully in a way that does not always require coders to write a bunch of tests or Try{}Catch{} constructs.

In general, just as we need a PowerShell version of ROBOCOPY.EXE, we need a PowerShell replacement for everything REG.EXE can do (and more).

For remote registry access, it would be nice to have support for both WSMAN and RPC, but RPC at a minimum (for those who don't configure WinRM/WSMAN on client devices). These registry cmdlets also need a -Credential parameter for connecting to stand-alone boxes in a workgroup that only have local accounts.

It's not enough to just have a nice registry module in the PSGallery, it needs to be built in so that we can rely on it everywhere; for example, these new registry cmdlets should ideally work on Linux or Mac OS machines using PowerShell to access the registry on remote Windows boxes.

REG.EXE is not good enough either: it's not object-oriented, does not support tab completion, does not support -WhatIf or -Verbose or -Recurse, etc. Same for ROBOCOPY.EXE.

And having just a DSC resource module is not good enough either. DSC is too complex or heavyweight for many organizations or scenarios.

Adding new registry cmdlets would not break any existing scripts that modify the local registry. And depending on how the network registry access is implemented, might not require a particular minimum version of WMF/PowerShell at the remote system either (though it may require WinRM to be configured).

Just as others have proposed or written functions for already, the names of the cmdlets might be like:

Get-RegistryValue
Set-RegistryValue
New-RegistryKey
Remove-RegistryValue
Remove-RegistryKey
Export-RegistryKey
Import-RegistryKey
And so on...

As others have already done, the cmdlets might just be wrappers for existing cmdlets, providers, classes or modules, which would be just fine, but they need to be built-in by default in the next version of WMF/PowerShell.

The above suggestion is not new and definitely not my idea, but I was hoping a new post in UserVoice would help to spark discussion about what is (not) needed and attract enough votes to get the ball rolling before the next version of WMF/PowerShell gets feature-locked.

Thanks,
Jason

Drag and dropping any file to a script shortcut split this path before passing the splitted strings as multiple parameters. Here's my detailed Issue Report :

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

1 - Get any script, for example :
[samplescript.psd1] :
```
param([string]$path)
Write-Host($path)
pause
```
or a simpler one-line sample: ```Write-Host($args);pause```

2 - Create a shortcut that runs the script :
[Shortcut Target ] : ```PowerShell "path\to\our\samplescript.psd1"```

3- Drag and drop a file containing spaces in its name to the shortcut
[sample file ] : ```C:\Some file with spaces.txt```

Expected behavior
-----------------

Drag and dropping the file should pass its path to the script as a parameter, (as it does correctly with batch scripts, executables, and other files that accept drag and drop [and shortcuts to these]),
and the script should then open a PowerShell window displaying "C:\Some file with spaces.txt"

Actual behavior
---------------

The file path is split into multiple parameters before being passed to the PowerShell script, which displays "C:\Some", instead of "C:\Some file with spaces.txt"

Workaround
---------------

Well, that isn't brilliant since I'm since starting to have a lot of these, but since this bug is only with powershell I simply create a .bat file which passes the argument to a PowerShell file. Instead of drag and dropping to the script shortcut; I drop it on the bat file [or a shortcut to it] to pass the path to the bat file, which then pass the path to the PowerShell script. Like this :
[dragdrop_for_samplescript.bat]
```start PowerShell -file "path\to\our\samplescript.psd1" %1```

Environment data
----------------

```
> $PSVersionTable

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

There appears to be a bug parsing arguments to EXEs. If you pass a properly-quoted path that has spaces and a trailing slash, the rest of the command is lumped into the same argument. This also happens if you use a PowerShell variable to hold the path string.

To repro, first, install EchoArgs.exe (if using chocolatey: cinst -y echoargs). It demonstrates what arguments would get passed to any exe.

Then run:

PS> & EchoArgs "C:\spaces and trailing slash\" more args

Echo args shows that it all got lumped into one argument:

Arg 0 is <C:\spaces and trailing slash" more args>

If you remove the trailing slash, or the spaces, then it parses correctly ("more" and "args" are separate arguments):

PS> & EchoArgs "C:\noSpaces\Or\NoTrailingSlash" more args

Arg 0 is <C:\noSpaces\Or\NoTrailingSlash>
Arg 1 is <more>
Arg 2 is <args>

I would have liked the default behaviour to be that an array of newline-split strings was returned from Get-ClipBoard. 97 % of the time I end up writing (Get-ClipBoard) -split "\r?\n" | ...... often filtering out empty elements - and that's just boring.

In my own version I used -Raw for a string and nothing for an array/list.

Of course you can't change that now in the 5.x version (or later, sigh, will this be our doom in some distant future), but can you maybe add at least -AsArray or similar? Make it so it can only be used with text, I guess. I see some other stuff in -Format I haven't tried yet.

A sort of implementation of the text part that I'd like is put up here on GitHub and demonstrates some things I'd want as well (I don't mean to start a storm with the little thought piece ;) https://github.com/EliteLoser/Get-Clip

Today I had an issue where getting an element at a certain index in a typed array failed. As I was troubleshooting this issue I found that it was simply because I had used a '.' (dot) instead of a ',' (comma) to separate the elements when I defined the typed array variable.
Okay, that is a clear mistake on my part. However, as I thought about it I would have loved to be alerted by the Powershell engine .

-- Experienced on v5.1.14409.1012 of PowerShell
-- Win7 x64 OS

TO REPRODUCE:

open vscode
create ps1 file
$array = "hej", "hej2", "hej3". "Hej4" $array --> prints = hej & hej2

EXTRA NOTES:

Also happens in Ps Shell.

If I do '$array = 1, 2. 4' --> I get an '...unexpexted token '4' in expression or statement.....'. So it seems to be an issue with [Strings]

There is also an github issue created on this. See more here >> https://github.com/PowerShell/vscode-powershell/issues/188

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

Confirmed that PSDrive is only scope locally in the class method is was called in:

Test Setup:

Mount(): HKU, HKCC, HKCUHKLM in class method. Display PSDrive mounts.
Call Test() within that Mount(), which mounts HKCR; Display PSDrive in method call.
Display PSDrive mounts on Test() return
Display PSDrive mounts on Mount() return
Call Test() method from main, Display PSDrive mounts.
Display PSDrive mounts on Test() return
VERBOSE: Mounting registry drives for use ...
VERBOSE: HKU
VERBOSE: HKCC
VERBOSE: HKCU
VERBOSE: HKLM
Alias C Cert Env Function HKCC HKCU HKLM HKU Variable WSMan (Scope: Mount())
Alias C Cert Env Function HKCC HKCR HKCU HKLM HKU Variable WSMan (Scope: Test())
Alias C Cert Env Function HKCC HKCU HKLM HKU Variable WSMan (Scope: Mount())
Alias C Cert Env Function HKCU HKLM Variable WSMan (Scope: Main)
Alias C Cert Env Function HKCR HKCU HKLM Variable WSMan (Scope: Test())
Alias C Cert Env Function HKCU HKLM Variable WSMan (Scope: Main)
From this testing is looks like the following is True:

Current PSDrive mounts are scoped locally, and correctly inherited with any subcalls from that scope; these locally scope mounts are removed upon method exit.
These are not carried across powershell sessions, unless I misunderstand how they work.

Powershell documentation states that PSDrive mounts exist for the entire powershell session.

https://technet.microsoft.com/en-us/library/ee176915.aspx