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.

OS: Windows Server 2016 1607 (14393.1593)
PSVersionTable:
Name Value
---- -----
PSVersion 5.1.14393.1532
PSEdition Desktop
PSCompatibleVersions {1.0, 2.0, 3.0, 4.0...}
BuildVersion 10.0.14393.1532
CLRVersion 4.0.30319.42000
WSManStackVersion 3.0
PSRemotingProtocolVersion 2.3
SerializationVersion 1.1.0.1

PSDscResource module: v2.8.0.0

Take a look at this configuration:
Configuration DependentConfig
{
Import-DscResource -ModuleName PSDscResources -Name Registry

Node MyNode01
{

File SetupScript
{
DestinationPath = 'C:\Scripts\hello.txt'
Contents = 'somecommand'
Type = 'File'
Ensure = 'Present'
DependsOn = '[Registry]regCheck'
}

Registry regCheck
{
Key = 'HKEY_LOCAL_MACHINE\SYSTEM\SomeKey'
ValueName = 'SomeValue'
ValueData = 0
ValueType = 'DWord'
Ensure = 'Present'
}
}
}

DependentConfig -OutputPath C:\DependentConfig

This requires PSDscResources module version 2.8.0.0 from the gallery and the file resource from the PSDesiredStateConfiguration in-box module. However, compiling this configuration will fail with a message that File resource cannot be loaded. If we remove -Name File from the first import command, you will see an error that Registry resource cannot be found. We have to use -Name with PSDscResources since PSDesiredStateConfiguration already exports the same resource.

So, the only work around at this time is to remove the PSDesiredStateConfiguration import completely from the configuration so that we can at least compile this. Here is something that works.

Configuration DependentConfig
{
Import-DscResource -ModuleName PSDesiredStateConfiguration
Import-DscResource -ModuleName PSDscResources -Name Registry

Node MyNode01
{

File SetupScript
{
DestinationPath = 'C:\Scripts\hello.txt'
Contents = 'somecommand'
Type = 'File'
Ensure = 'Present'
DependsOn = '[Registry]regCheck'
}

Registry regCheck
{
Key = 'HKEY_LOCAL_MACHINE\SYSTEM\SomeKey'
ValueName = 'SomeValue'
ValueData = 0
ValueType = 'DWord'
Ensure = 'Present'
}
}
}

DependentConfig -OutputPath C:\DependentConfig

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!

I got some weird data when running below cmdlet

Get-MessageTrace -StartDate "09/11/2017 00:00:00" -EndDate "09/15/2017 00:00:00" -PageSize 10 -Page 1 | Get-MessageTraceDetail | Select-Object Date, MessageTraceID, Event, Data, Detail | Out-GridView

It seems the last event of the first MessageTraceID keeps repating itself and was added next to last event of the next MessageTraceID. And its data keep growing. Please see below image for the clear representation of the issue.
https://1drv.ms/i/s!AtOz2sztWjOapgIwkbjyq-sy4_jm

Below image is the correct MessageDetail of MessageTraceId 2b87f940-0eee-4c39-71a9-08d4f9757430
https://1drv.ms/i/s!AtOz2sztWjOapgPFCL102diF6jRz

And below image is the correct MessageDetail of MessageTraceId f602c9c7-2a5b-4a5a-1256-08d4f8e9ba58
https://1drv.ms/i/s!AtOz2sztWjOapgSFXfJiKurb23w0

Can you please check why it is happening?

Thanks in advance.

===================
> $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
================================

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

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

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
```

Hi,
Recently I am working on a Telegram Bot creation with power shell, everything working fine except uploading the images via API.

If I use cURL, it is working fine using following command, So, technically it should work with native PowerShell commandlet.

curl -s -X POST "https://api.telegram.org/bot11111111:Mykey/sendPhoto?chat_id=-123456789&quot; -F photo="@D:\MyPic.JPG" -F caption="Test"

I have already tried following, but none worked. As per the API Guide (https://core.telegram.org/bots/api), we have to use multipart/form-data for uploading any file, for cURL, without specifying this also works.

Invoke-RestMethod -Uri "https://api.telegram.org/bot$MyBotKey/sendPhoto?chat_id=XXXXXXXXX&quot; -Method Post -InFile "D:\MyPic.JPG" -ContentType "multipart/form-data"
Invoke-WebRequest -Uri "https://api.telegram.org/bot$MyBotKey/sendPhoto?chat_id=-XXXXXXXXX&quot; -Method Post -InFile "D:\MyPic.JPG" -ContentType "multipart/form-data"

For Invoke-RestMethod, I have got this:
{"ok":false,"error_code":400,"description":"Bad Request: there is no photo in the request"}

For Invoke-WebRequest, I have got this,
The remote server returned an error: (400) Bad Request.

For Invoke-WebRequest without content type, I have got this,
{"ok":false,"error_code":400,"description":"Bad Request: there is no photo in the request"}

I guess this might be a Bug.

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>

If you utilize Smart Cards with certificates that are not directly linked to users (no suitable user DN in Subject and no UPNs in SANs), you are able to link a single certificate to multiple accounts dynamically with the caveat that users need to provide explicit user name hints during logon in order to log on.

User name hints need to be enabled via GPO or registry settings ("X509HintsNeeded"), after which all standard credential dialogs in Windows support them, except PowerShell's Get-Credential. This effectively prevents using PowerShell remoting with such Smart Cards / certificates if different credentials are required.

In today's landscape where Microsoft recommends explicitly tiering your infrastructure and user accounts and using secure methods of administration such as PowerShell Remoting, the omission of this feature is a big letdown. It also reinforces bad habits because Remote Desktop fully supports this scenario while PowerShell does not.

This feature should be implemented.

The ErrorAction parameter on Stop-transcript doesn't work.

for instance with SilenlyContine:

PS G:\> Stop-Transcript -ErrorAction SilentlyContinue
Stop-Transcript : An error occurred stopping transcription: The host is not currently transcribing.
At line:1 char:1
+ Stop-Transcript -ErrorAction SilentlyContinue
+ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+ CategoryInfo : InvalidOperation: (:) [Stop-Transcript], PSInvalidOperationException
+ FullyQualifiedErrorId : InvalidOperation,Microsoft.PowerShell.Commands.StopTranscriptCommand

Or with stop:
Script: Stop-Transcript -ErrorAction Stop; write-output "This message sould not be printed"
Result: Stop-Transcript : An error occurred stopping transcription: The host is not currently transcribing.
At home\Untitled4.ps1:1 char:1
+ Stop-Transcript -ErrorAction Stop
+ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+ CategoryInfo : InvalidOperation: (:) [Stop-Transcript], PSInvalidOperationException
+ FullyQualifiedErrorId : InvalidOperation,Microsoft.PowerShell.Commands.StopTranscriptCommand

This message sould not be printed