UpdateServices Module, cmdlet Get-WsusUpdate. This cmdlet does not allow filtering by updates' "ReleaseDate". It also does not return value of updates' "ReleaseDate". GUI tool (WSUS mmc) does show "Release Date" column when showing updates, and allows updates sorting by "Release Date". I would ask that UpdateServices Module includes "UpdateReleaseDate" both as input (filtering) value and output value. Thanx.

Hi

When you use the sort function in a pipeline it will work in ISE but not when you run the script direktly (see attached logs). By run it dierktly it sorts the objects wrong.

Greetings from Germany

It will be fantastic if powershell have a simple or basic module for statistics and data analytics ..... calculating average and min , max is not enough .... please more data analytics functions would make powershell able to meet the new technology expectations

موهتءحشنسةءهءتشكشءاءخنشخششخاءاءنءنءتءءخ

Add-ADPrincipalGroupMembership
[-WhatIf]
[-Confirm]
[-AuthType <ADAuthType>]
[-Credential <PSCredential>]
[-Identity] <ADPrincipal>
[-MemberOf] <ADGroup[]>
[-Partition <String>]
[-PassThru]
[-Server <String>]
[<CommonParameters>]

The user reported an issue of Convertto-json cmdlet.
Here is the details. Please take a loot at it.

https://github.com/Azure/azure-powershell/issues/10216

Trying to create a script to Add Always On VPN connections for remote users. The available scripts are so convoluted. I could easily do what I need if I could simply add the -AlwaysOn switch to Add-VPNConnection.

Get-WmiObject and Get-CimInstance are unable to find the CDPUserSvc service.

Get-WmiObject -Namespace root\cimv2 -Query 'SELECT * FROM Win32_Service WHERE Name="CDPUserSvc"'

Get-CimInstance -Namespace root\cimv2 -QueryDialect WQL -Query 'SELECT * FROM Win32_Service WHERE Name="CDPUserSvc"'

The presence of this service can be confirmed with the Get-Service cmdlet:

Get-Service -Name CDPUserSvc

However, it works fine with other services.

This behavior appears on a Windows 2019 server with native Framework and native PowerShell.

Windows version: 17763.1.amd64fre.rs5_release.180914-1434
PS version: 5.1.17763.316
.Net Framework version: 4.7.03190

Start-Job seems to sometimes cause the calling thread to hang. If you create a loop in ISE and spin off a bunch of jobs, inevitably it will hang. This has only been tested using a ScriptBlock.

As a workaround, you can use threads to do the heavy lifting and so if they fail to start the job, just recreate the thread.

I am finding that the AzureAD cmdlets do not show me the same list of attributes for a user as the MSOL cmdlets you are deprecating. For example; our sharepoint people need to see the PreferredDataLocation value for content controls, this was available in MSOL and not easily in AzureAD. (I have included 2 user exports to show you what I mean) How do I make the AzureAD cmdlets do what MSOL does?

The -ScheduledTask commands that modify state should support the WhatIf parameter. They don't appear to currently as of Server 2016.

Specifying -WhatIf to Disable-ScheduledTask says the parameter is unknown.

If there is an unresolved SID in a local group the cmdlet Get-LocalGroupMember (and maybe others) throws and error.

Module: Microsoft.PowerShell.LocalAccounts

Get-LocalGroupMember : Failed to compare two elements in the array.
At line:1 char:1
+ Get-LocalGroupMember -Group 'RDS Endpoint Servers'
+ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+ CategoryInfo : NotSpecified: (:) [Get-LocalGroupMember], InvalidOperationException
+ FullyQualifiedErrorId : An unspecified error occurred.,Microsoft.PowerShell.Commands.GetLocalGroupMemberCommand

If the SID is removed, the cmdlet once again works as expected.

When I attempt to run the Cmdlet below with the following parameters, it fails:

$AutomationAccountName = "CZEU1-INF-NP-0faa84be-AAA-01"

$ResourceGroupName = "czeu2-app-np-rgp-01"

$vmStartTime = (Get-Date "08:00:00").AddDays(1)

$vmStopTime = (Get-Date "18:00:00")

$timeZone = [TimeZoneInfo]::Local.DisplayName

$vmStartupScheduleName = "Startup VMs 08:00 Daily Weekdays:

$timeZone"

$vmShutdownScheduleName = "Shutdown VMs 18:00 Daily

Weekdays: $timeZone"

[System.DayOfWeek[]]$WeekDays = @([System.DayOfWeek]::Monday..[System.DayOfWeek]::Friday)

New-AzAutomationSchedule -AutomationAccountName $AutomationAccountName -Name $vmStartupScheduleName -StartTime $vmStartTime -WeekInterval 1 -DaysOfWeek $WeekDays -ResourceGroupName $ResourceGroupName -Verbose

The error is: New-AzAutomationSchedule : Exception of type 'Microsoft.Azure.Management.Automation.Models.ErrorResponseException' was thrown. At line:1 char:1 + New-AutomationSchedule -AutomationAccountName $AutomationAccountNam... + CategoryInfo : CloseError: (:) [New-AzAutomationSchedule], ErrorResponseException + FullyQualifiedErrorId : Microsoft.Azure.Commands.Automation.Cmdlet.NewAzureAutomationShedule

.

Repro: using the following script:
function Test
{
[CmdletBinding()]

Param(
[string]$name,

[Parameter(Mandatory = $True, ParameterSetName = "Set1")]
[Parameter(Mandatory = $True, ParameterSetName = "Set2")]
[string] $P1,

[Parameter(Mandatory = $True, ParameterSetName = "Set2")]
[string] $P2

)

Write-Output ($name + " - " + $PsCmdlet.ParameterSetName)
}

#The following Fails! e.g. Powershell doesn't resolve to ParameterSet "Set1"
'aaa' | Test -P1 x

We have been using automation script for our deployment. We are using the latest version of System.Management.Automation.

System.Management.Automation, Version=3.0.0.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35

We have few modules referred in profile.ps1 which automatically loads when we execute the ps1 files. This works fine if we have enabled Windows Powershell 2.0 engine.

If we disable Windows Powershell 2.0 Engine this doesnt load the profile.ps1 in $pshome and scripts throws functions not found error.

This seems to be weird behavior as all our scripts still works with Powershell 5.1

Would need your attention to help fixing this or provide a solution to fix this.

There appears to be a bug when using this Cmdlet, where the -ResourceGroupName parameter incorrectly states that the parameter value for the resource group exceeds a length of 90 when a variable is used, i.e. $rgName (string length is actually 19 <CZEU2-APP-NP-RGP-01>. When the hard coded value of: "CZEU2-APP-NP-RGP-01" is used however, the Cmdlet works as designed.