EDIT: Our Win 2016 server was recently patched with KB4569746 (.NET Framework 4.8 cumulative). Could that be the cause?

Hi, we're getting the following error when trying to connect to Power BI Service using PBI modules MicrosoftPowerBIMgmt:

PS C:\Users\CONAMZ> Login-PowerBI
Login-PowerBI : Failed to populate environments in settings
At line:1 char:1
+ Login-PowerBI
+ ~~~~~~~~~~~~~

+ CategoryInfo          : WriteError: (Microsoft.Power...IServiceAccount:ConnectPowerBIServiceAccount) [Connect-PowerBIServiceAccount], Exception

+ FullyQualifiedErrorId : Failed to populate environments in settings,Microsoft.PowerBI.Commands.Profile.ConnectPowerBIServiceAccount

We also tried connecting via Get-Credential and using registered App credentials. The Powershell script has been working for months.

Here are the things we've tried but to no avail:
1. Re-installing Power BI modules
2. Apply TLS registry settings:
Windows Registry Editor Version 5.00
[HKEYLOCALMACHINE\SOFTWARE\Microsoft.NETFramework\v2.0.50727]

  "SystemDefaultTlsVersions" = dword:00000001

  "SchUseStrongCrypto" = dword:00000001

[HKEYLOCALMACHINE\SOFTWARE\Microsoft.NETFramework\v4.0.30319]

  "SystemDefaultTlsVersions" = dword:00000001

  "SchUseStrongCrypto" = dword:00000001

[HKEYLOCALMACHINE\SOFTWARE\Wow6432Node\Microsoft.NETFramework\v2.0.50727]

  "SystemDefaultTlsVersions" = dword:00000001

  "SchUseStrongCrypto" = dword:00000001

[HKEYLOCALMACHINE\SOFTWARE\WOW6432Node\Microsoft.NETFramework\v4.0.30319]

  "SystemDefaultTlsVersions" = dword:00000001

  "SchUseStrongCrypto" = dword:00000001

Looks like there are others facing the issue:
https://community.powerbi.com/t5/Developer/Connect-PowerBIServiceAccount-Failed-to-populate-environments-in/td-p/1291378

Please help! Thanks in advance.

Microsoft.PowerShell.Utility has Invoke-WebRequest cmdlet (and Invoke-RestMethod among potentially others) which allow JSON to be requested from a remote server.

If the remote server provides a Content-Type header of 'application/json;charset=utf-8' then the WebResponseObject Content is properly parsed. However, if the Content-Type header only sets 'application/json' then ISO-8859-1 is assumed as the encoding by PowerShell 5.

One can manually transform the response content such as:
However such manual work is not helpful for Invoke-RestMethod cmdlet as the data has already been parsed into key-value mappings, and cannot be easily bulk-converted.

RFC 8259 at https://tools.ietf.org/html/rfc8259#section-8.1 clearly says "JSON text exchanged between systems that are not part of a closed ecosystem MUST be encoded using UTF-8."

The UTF-8 encoding for 'application/json' should be respected even without an explicit 'charset' declaration in the Content-Type header. Further more so, PowerShell Core already handles JSON as UTF-8 by default, working around this issue.

Forgive me if this has been posted previously but I cannot locate a ticket for it. When using New-ScheduledTaskAction in PowerShell, 5.1.19041.1, to create an action to call a PowerShell script there are incorrect characters being added to the arguments.

For example, please consider the following script

$action = New-ScheduledTaskAction -Execute "C:\Windows\System32\WindowsPowerShell\v1.0\powershell.exe" –Argument "-ExecutionPolicy Bypass -File `"C:\PathToScript\Script.ps1`""


When added to a scheduled task this action will not execute, further inspection revealed that under ANSI encoding the final "is actually being sent over as the special aE symbol. And if you try to wrap everything in single quotes and concatenate the string you get x94 in its place under UTF-8 encoding.

Am I doing something wrong or is thing a bug with this commandlet?

AzureAD - Cannot properly read System.Byte[] value even when loading the module using "-UseWindowsPowerShell".

Whenever I troubleshoot Conditional Access issues, I use to retrieve the certificate hash of AzureADDevice. Long story short, I retrieve "AlternativeSecurityIds.Key" property of AzureADDevice.

Get-AzureADDevice -SearchString XXXX| fl displayname,deviceid,objectid,@{n='DevCerHash';e={ [System.Text.Encoding]::Unicode.GetString($_.AlternativeSecurityIds.key).substring(21,40) }}

I know that PS7 isn't compatible with AzureAD module, and for this reason I use "-UseWindowsPowerShell" flag to load the module. Unfortunately, in PS5 the byte array is properly read, while in PS7 (-UseWindowsPowerShell) an object of wrong type is returned.

Get-AzureADDevice -SearchString XXXX| select AlternativeSecurityIds |gm

The above command returns "TypeName: Selected.Microsoft.Open.AzureAD.Model.Device" in PS5 and "TypeName: System.String" in PS7 (-UseWindowsPowerShell).

See the attached image.

Bug - Regression in Dismount-VHD
(This is behavior that worked at some point in the last several months.)

To reproduce:
1) Mount a .vhdx file stored on a network share that requires domain credentials.

mount-vhd "\\server\path\to\my.vhdx" -NoDriveLetter

2) Open a Powershell session as a user that does not have domain credentials (such as System, or a local admin account).

3) In the non-domain Powershell session, Dismount the VHD by disk number:

Dismount-VHD -DiskNumber 2

Observe that the command reports error:
"Dismount-VHD: Windows cannot find a mounted virtual hard disk with the specified disk number."

Note: This command does still succeed if run as a user with domain credentials. So, it appears maybe the method of detaching was changed under the hood, and this usage scenario was not tested.