The –ComputerName parameter in Get-Service and Set-Service permits targeting a remote machine without relying on Windows PowerShell remoting in 5.1.x. This parameter no longer exists in the new PowerShell 7.0.0.
Next to this change, the following parameters of the Get-Service cmdlet now accept wildcard characters by default:
Despite unexpected hiccups which resulted in the more than one month+ delay, it was announced earlier today by the PowerShell Team blog on Wed 4 Mar 2020 that the latest open-source, cross-platform* PowerShell 7.0.0 (based on .NET Core 3.1) has finally gone RTM and is now generally available for download on GitHub.
Read all about it from the official source or from independent sources (here and in German here), including important end-of-life (EOL) information concerning the previous version of .NET Core 3.0 over here.
See also What’s New in PowerShell 7.0.
* Windows, Linux, macOS (x64 and ARM platforms)
Except for February, it is possible to hard-code the last day of each month since the number of days is fixed. However, you still have to determine the day of the week separately.
Rather than doing this manually, the code snippet below should do the trick:
#determine the last day of the first quarter of the year 2020 including the day of the week (Jan to March)
$date = Get-Date "2020-01-01"
$qtr2 = $date.AddMonths(3)
#Mittwoch, 1. April 2020 00:00:00
$qtr2FirstDay = Get-Date -Month $qtr2.Month -Day 1 -Year $qtr2.year;
#Mittwoch, 1. April 2020 23:56:43
$qtr1LastDay = $qtr2FirstDay.AddDays(-1);
#Dienstag, 31. März 2020 23:56:43
PowerShell Core 6.x (6.0, 6.1 and 6.2) is Microsoft’s initial attempts to bring the veteran Windows PowerShell outside of its core Windows ecosystem to Linux and macOS based platforms. It is designed to run side-by-side (SxS) when installed on supported Windows operating systems where the feature set is not on par with Windows PowerShell due to its high dependency on Windows specific components and the full .NET Framework stack.
This has not stopped PowerShell enthusiasts from writing scripts that already utilize new PowerShell Core functionality (but often not properly “labelled”). Besides breaking backwards compatibility, such code may pose a real risk if not closely inspected first for suitability of use. This is because many are either delivered with sparse or incomplete documentation and neither follow good software development practices nor have security baked right in i.e. lack of safety nets* due to “fire fighting” nature in the real world, for instance.
Although it now looks like the planned January 2020 GA of PowerShell 7 per the PowerShell team has slipped – with a possible yet unannounced Release Candidate 2 (RC2) – you can start preparing for the transition to the “harmonized” P7 version based on the .NET Core 3.1 LTS by working on the last Release Candidate v7.0.0-rc.1 (2019-12-16) posted on GitHub.
* version check, try/catch blocks, advanced functions, etc.
Announced as a “go live” PS 7 Release Candidate by the PowerShell Team blog on Mon 16 Dec 2019 PST, the General Availability, GA of PowerShell version 7.0 is expected to be unleashed sometime in Jan 2020.
Read how “awesome” PowerShell 7 has come of age, particularly its tight .NET Core and SDK Docker image integration, and improved performance, not to mention its cross compatibility with Windows PowerShell 5.1 and Linux systems.
To regain access to your missing “legacy” contact list after the forced migration or upgrade to Teams in the Office 365 cloud, click on [ Go to Teams ] in the Skype for Business application and navigate to the Chat tab on the left hand pane. Note that you may have to sign-in (again) to Microsoft Teams.
Surprise surprise! The contact list is completely blank!
If you happened to click pass the dialog that appeared, you have definitely missed the important
“We’re importing your Skype for Business contact groups… This could take a while. To organize your contacts in the meantime …”
dialog box which exactly explains this strange phenomenon.
Depending on your Skype for Business tenant’s region, it can take several hours before your contact list finally appears in Teams itself.
For your convenience, note that your contact list is also accessible under Calls > Contacts.
On an Office 365 tenant running Skype for Business, you may be “randomly” selected to upgrade from Skype for Business to Microsoft Teams. You will not miss this strategically placed violet coloured notification when you start the Skype for Business (desktop) application.
It is possible to ignore this upgrade prompt for an unknown duration until one fine day where you are “forced” migrated automatically in the cloud. This is evident when the all-too-familiar Skype for Business interface is replaced with “Your organization is now using Microsoft Teams” banner when you successfully sign-in as illustrated.
From this moment on, you are blocked from accessing all your PIM information from contacts to history list and key functionality such as the meeting calendar and voice phone dialer within the Skype for Business app. Administration of existing Skype for Business meetings prior to the upgrade to Teams can continue to be done using Outlook though.
So what now then? You can click on the “Questions? Learn more” (Switch to Teams from Skype for Business) or “View past conversations, calls or voicemails” (FAQ) link to learn more in the meantime.
Updated information with regards to the PowerShell 7 Road Map (including the first PowerShell 7 preview) after the initial announcement of the new version 7 by the Microsoft PowerShell team.
Following the March 2019 release of PowerShell Core 6.2, the Microsoft PowerShell team announced that Windows PowerShell 5.1 and the PowerShell 6.x Core version will converge into a single version known as PowerShell 7.
Apart from automation across Linux, macOS and Windows, a very high degree of compatibility with existing Windows PowerShell (5.x) modules can be achieved with the next release of PowerShell 7 by leveraging changes in .NET Core 3.0 (such as the return of Out-GridView in Windows).
Unlike the current PowerShell Core support lifecycle, PowerShell 7 will have both LTS (Long Term Servicing) and non-LTS releases which aligns closely with the .NET Core support lifecycle.
PowerShell 7 in Windows is planned to ship as a side-by-side feature with Windows PowerShell 5.1. No information around the PS7 release date in a future version of Windows 10 or Windows Server is available though as the release timelines of .NET Core and Windows do not align.
According to Microsoft, May (2019?) is the likely first Preview release of PowerShell 7 with the generally available (GA) some time after the GA of .NET Core 3.0.
Besides the common -Identity parameter, most cmdlets from the Active Directory Module for PowerShell support the -Filter parameter.
If you encounter the following error even though the syntax is correct,
PS C:\> Get-ADGroup -Identity *
Get-ADGroup : Cannot find an object with identity: * under: ‘DC=swissitpro,DC=com’
At line;1 char:1
+ Get-ADGroup -Identity *
+ CategoryInfo : ObjectNotFound: (*:ADGroup) [Get-ADGroup], ADIdentityNotFoundException
simply replace -Identity with -Filter and try again. Obviously this makes sense (and is the only way) to get a list of all defined active directory security and distribution groups in the organisation.