It's not an idea, it's a bug.

Lithuanian keyboard is known to use the right Alt as AltGr.

As a top keyboard row in the Lithuanian keyboard layout is Lithuanian characters, holding AltGr allows all the top row to become an English US keyboard again.

This way, holding AltGr enables to type numbers: 1, 2, 3, 4, 5, 6, 7, 8, 9, 0. But not in Powershell, that ships with Windows 1809. Be it Windows Server 2019 1809, or Windows 10 1809.

Starting with this Powershell, typing AltGr+9 and AltGr+0 does nothing and this is wrong.

Typing numbers in Powershell with Lithuanian keyboard on a notebook computer becomes nightmare.

Windows PowerShell.exe supports a -Version command-line switch, which aligns the current PowerShell session to a particular version of PowerShell, e.g. powershell.exe -Version 2.0 will get you a PS shell which uses .NET 2.0 and PowerShell v2. This is still useful, because I still have to write scripts that work in older environments, even though I am running WinPS 5.1 myself.

However, semi-recent Windows Updates have added configuration to powershell.exe.config (I think to support newer TLS ciphers), which are incompatible with powershell.exe -Version 2.0.

The following simple code is a minimal test point:

$wc = New-Object Net.WebClient

$wc.DownloadString(&#39;<a rel="nofollow noreferrer" href="https://www.google.com&#39;">https://www.google.com&#39;</a>)

In native, current powershell.exe, this executes without issue. In powershell.exe -Version 2.0, this throws an exception Configuration system failed to initialize which, if you traverse the inner exceptions, gets you to Unrecognized configuration section uri.

Since powershell.exe.config is a TrustedInstaller-owned file, it is artificially difficult to change this, and one could reasonably expect any changes I make to be overwritten by another Windows Update.

For posterity, the current content of powershell.exe.config is:

<configuration>

  <uri>

    <schemeSettings>

      <add name="http" genericUriParserOptions="DontUnescapePathDotsAndSlashes"/>

      <add name="https" genericUriParserOptions="DontUnescapePathDotsAndSlashes"/>

    </schemeSettings>

  </uri>

  <runtime>

    <AppContextSwitchOverrides value="Switch.System.Net.DontEnableSystemDefaultTlsVersions=false" />

  </runtime>

</configuration>

As such (if no current option exists), I propose allowing for the powershell.exe application to read from version-specific .config files, depending on which version is targeted by the -Version command-line parameter.

(I am undecided whether this should also be influenced by Set-StrictMode, but this may also need to be considered.)

(EDIT: UV is mangling my simple test case above; it should be $wc.DownloadString("A URL"))
(EDIT2: Oh, the irony...)
(EDIT3: Added current content of powershell.exe.config for posterity; UV has mangled the XML tags, though)

BUG: Get-DnsServerResourceRecord returns incorrect objects with the FQDN name in the hostname field if the parent zone contains a subzone with the same name.

Reproduction:

Setup:
Create a DNS zone:

 testzone.fake.domain.zzz

Create a sub zone:

 testzone.fake.domain.zzz 

 (subzone fqdn: testzone.fake.domain.zzz.testzone.fake.domain.zzz)

Create an A record:

 Zone Name: 

      testzone.fake.domain.zzz (the parent zone)

 Record Name: 

      testrecord

 Data:

      10.1.2.3 

Create an A record:

 Zone Name: 

      testzone.fake.domain.zzz.testzone.fake.domain.zzz (the subzone)

 Record Name: 

      testrecord

 Data:

      10.3.2.1

Test:
Get-DnsServerResourceRecord will return these records:
Item# HostName______________________________________________________ RecordData RecordType

1 testrecord                                                     10.1.2.3   A

2 <various>                                                      <various>  <various>

3 testzone.fake.domain.zzz                                       10.1.2.3   A

4 testrecord.testzone.fake.domain.zzz.testzone.fake.domain.zzz   10.3.2.1   A

5 <various>.testzone.fake.domain.zzz                             <various>  <various>

Item 1 correctly returns the host name and record data.
Item 2 correctly returns other host names and record data.
Item 3 incorrectly returns a duplicate object from the parent zone but with the FQDN in the HostName field
Item 4 incorrectly returns the object with the hostname containing the FQDN name of the object
Item 5 incorrectly returns various duplicated objects with the hostnames containing the FQDN names.

Continue setup:
Delete the record in the sub zone (10.3.2.1).

Continue test:
Get-DnsServerResourceRecord will return these records:
Item# HostName______________________________________________________ RecordData RecordType

1 testrecord                                                     10.1.2.3   A

2 <various>                                                      <various>  <various>

Item 1 is correctly returned with the correct host name and record data.
Item 2 is correclty returned with the correct host names and record data.

Continue setup:
RE-Create the record in the sub zone (10.3.2.1)
Delete the record in the parent zone (10.1.2.3)

Continue test:
Get-DnsServerResourceRecord will return these records:
Item# HostName______________________________________________________ RecordData RecordType

1 (left blank to keep Item numbers consistant)

2 <various>                                                      <various>  <various>

3 (left blank to keep Item numbers consistant)

4 testrecord.testzone.fake.domain.zzz.testzone.fake.domain.zzz   10.3.2.1   A

5 <various>.testzone.fake.domain.zzz                             <various>  <various>

Item 2 correctly returns the correct host names and record data.
Item 4 incorrectly returns the object with the hostname containing the FQDN name of the object
Item 5 incorrectly returns various duplicated objects with the hostnames containing the FQDN names.

Also see:
https://www.briantist.com/errors/get-dnsserverresourcerecord-returns-duplicate-records-when-sub-domain-matching-zone-exists/

I have a Powershell script to duplicate the shares from one machine onto another that is in the process of being mirrored. I am testing my script, including it's error handling by attempting to recreate all shares when half the drives have not been populated on the new machine. This should generate loads of "cannot create share, path not found" errors.

Thus, this code within the loop:
Try {
New-SmbShare -Name "$($line.{Share Name})" -Path "$($line.{Folder Path})"
echo "Created share $($line.{Share Name})" >>$logFile
} Catch {
Write-Error -Message "Exception Creating Windows share $($line.{Share Name}). Error is $_" -TargetObject $line
echo "FAILED creating share $($line.{Share Name})" >>$logFile
}

The placement of the echo commands SHOULD generate my log file with one line for each success and a different line for each failure. It does not.

When I run this code, I get a Get-SmbShare-like output of all of the individual Set-SmbShare calls, with a ton of red error messages about paths that could not be found interspersed. These messages do not resemble the message in my code above.

When I look at my log, I see a success line for every share, even the ones that failed.

Apparently New-SmbShare is handling it's own error, spitting out a useless error message (taking 6 lines to tell me path not found without identiying the path), and returning success to the calling code.

Is there a parameter I can use to tell this command to pass errors to me to handle?

TPM isn’t the only workable option for disk encryption and in fact, is almost guaranteed to provide the user with a false sense of security.

Sure, some encryption is better than none, but considering the fact that Microsoft has broken the trust it had with it's customers, when they were caught red-handed with their hands in the cookie jar, as well as their brazen Win10 campaign tactics that literally upended several businesses and that of the lives of so many other end users who woke up one morning to find all their files were gone because their computers were automatically upgraded to Win10 without user consent-------Do we really think we should trust Microsoft with our Data after all that **** that they caused to so many countless customers?!-------I mean really?!-------Talk about kicking the customer while their down?!

Just because Microsoft made a brand new shiny little OS and decided to make it their , with all it's overblown and overzealous glitter and gold, does not mean they deserve any sort of reprieve for any of this that they have caused to happen to so many loyally paying customers! Microsoft and all it's ******!

There are plenty of other encryption solutions out there that don't have to involve Bitlocker and the TPM...

I love to use Powershell. But some of its default color is too dark so that I cannot read them. I submitted comparison screenshot with CMD.

The posted screenshot is, as you see, 'ls' command from a remote server logined by CMD and Powershell each. You may see that right one's 'ls' output is too dark. I changed background but it was same cause it's the problem of font color itself not the background color or font size.

Some of internet post guided to change bash setting to change output color of 'ls', but that is just temporary fix only for 'ls' command.

Is there anyway to change default color itself brighter?

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.

How to reproduce:

With this Azure pipelines yaml snippets:

The special character are all encoded. And when I attach a file I get 500 error. Please see https://gist.github.com/chenbojian/6fcb3a8c3bbe42cc2851a1eefe9f4324

- job: win2019

  pool:

    vmImage: windows-2019

  steps:

  - powershell: |

      $PSVersionTable

      cmd /c 'echo this will crash powershell 1>&2'

      cmd /c 'echo this will crash powershell 1>&2'

      cmd /c 'echo this will crash powershell 1>&2'

- job: win2016

  pool:

    vmImage: vs2017-win2016

  steps:

  - powershell: |

      $PSVersionTable

      cmd /c 'echo this will crash powershell 1>&2'

      cmd /c 'echo this will crash powershell 1>&2'

      cmd /c 'echo this will crash powershell 1>&2'

The win2019 job will fail at the second command. The win2016 job will succeed with 3 lines of messages.
Here I use cmd to write stderr stream just for demo the bug. In my real case, I need this to work because git and yarn and other tools will write warning to stderr.

I also tried with my custom windows 2019 image. It is better. It will fail at the first command. At least it have a consistency behaviour. The different between custom 2019 and microsoft hosted 2019 is the .net framework 4.8.

There is an issue https://github.com/microsoft/azure-pipelines-image-generation/issues/1436 said that this is a powershell bug. I do think this is a powershell's bug.

When you map a network drive to your computer and look at the available storage, the GUI shows you the storage available as set by any hard-quotas configured in File Server Resource Manager. However, when you run any sort of PowerShell script to query the drive, you get the result of the drive without any quota in place.

It'd be great to have a query which shows the storage available and used with the quota factored in.

As an example, I just had to write a script which emails me our share sizes once a day but instead of simply being able to query each share, the script invokes "get-fsrmquota" on every file server, stores the data and then has to pull data out of it instead if a quota exists.

I hope this makes sense, if you have any queries don't hesitate to shout.

In PowerShell console in Windows 10 there is a serious problem that prevents entering capitalized letters (i.e. pressing Shift+Letter does nothing). This happens with most but not all letters and depends on the keyboard layout that was active when PowerShell console was started. If PowerShell console is started with English (US) keyboard layout, than typing in English works without problems (only Shift+Space not work, but I see another issue about it). After switching to Russian keyboard layout, most letters with Shift not work. Only ЦУШЩХЪФЫСТ can be typed. But when PowerShell console is started with Russian keyboard layout, it is even worse. Only ШЩХЪЫЯСТЬ can be entered in Russian keyboard layout and no capital letter at all can be entered in English layout.

If you run the Test-ModuleManifest cmdlet more than once against the same manifest the "Tags" property returns different results each time.

For example, I have a module that contains the following tags in the psd1 file:

Tags = "tag1","tag2"

You can see below that if run the Test-ModuleManifest more than once it returns more copies of the tags each time it's executed:

$m = Test-ModuleManifest .\tagtest.psd1
$m.tags
tag1
tag2
tag1
tag2

$m = Test-ModuleManifest .\tagtest.psd1
$m.tags
tag1
tag2
tag1
tag2
tag1
tag2

$m = Test-ModuleManifest .\tagtest.psd1
$m.tags
tag1
tag2
tag1
tag2
tag1
tag2
tag1
tag2

$m = $null
$m = Test-ModuleManifest .\tagtest.psd1
$m.tags
tag1
tag2
tag1
tag2
tag1
tag2
tag1
tag2
tag1
tag2

The problem appears to be confined to Windows Powershell, it does not occur in Powershell Core.

It does not actually change the contents of the manifest, it just seems to be persisting some data somewhere and appending to it rather than reprocessing the manifest again.