Windows PowerShell 2.0 Deprecated in Windows 10 Fall Creators Update

Windows PowerShellAccording to the Microsoft KB article* entitled “Features that are removed or deprecated in Windows 10 Fall Creators Update“, Windows PowerShell 2.0, which shipped out of the box in Windows 7 and Windows Server 2008 R2, will be deprecated.

On platforms earlier than Windows Server 2016 and Windows 10 Build 1511, customers are advised to migrate applications and components to PowerShell 5.x.

Deprecated = not in active development and might be removed in future releases.

* Article ID: 4034825 – Last Review: Jul 24, 2017 Revision: 20

#powershell Non US Locale Culture (Thread)

Windows PowerShellIn an environment where US English is not the language locale selected during installation of the Windows OS or as defined in Control Panel*, operations in PowerShell may behave differently or fail altogether (where dependencies on this setting may not be obvious e.g. COM object interaction with Microsoft Office Suite of products).

To avoid nasty surprises in PowerShell, consider saving both the current culture and UI culture values for the present (current) thread, set them explicitly to “en-us”, perform the needed tasks then revert back to the original system values.

The static threads we are looking for are:


* Region and Language > Formats > Format / Location > Current Location

Speaker PowerShell Conference 2017 Asia – Singapore 26-28 Oct 2017

The PowerShell Conference 2015, Asia (Singapore 18-19 Sep, 2015)

For the third time in a row I shall be a Speaker at the (3rd) PowerShell Asia Conference 2017 this time talking about “Working Faster & Smarter with PowerShell”. This will once again take place in Singapore from Fri 27 to Sat 28 Oct 2017 with a great line-up of speakers, excellent food, conference party and a popular pre-conference day (Thu 26.10.2017).

Singapore Night Scenery

More information and registration here. Do not miss out this wonderful opportunity to stay over to travel around and explore Singapore and the amazing South-East Asian countries. See you soon!

#psconfasia #ITPro #PowerShell #Singapore

Follow me for all the buzz -> @_leedesmond (Twitter)!

#powershell: Fun with Switch Statement Part 2


switch ($d) { { “default” } { “d” } { “others” } { “o” } }
$d = “Default”
$d = “others

Basically, the odd script blocks {namely “default” and “others”} are the actual criteria to be tested in the #powershell switch block. In this instance, there is essentially nothing to check for hence whatever criterion given to the switch block will always be deemed as valid matches regardless of values or object types.

Unless each incoming object needs to be processed and not just a “simple” match, represented by the special $_ variable, …

Continue reading “#powershell: Fun with Switch Statement Part 2”

skype4b: Get-CsUserDatabaseState – Show SQL Database Servers

Here’s a quick tip to display the names of associated backend SQL primary and mirrored (if any) database servers of a Standard or Enterprise Edition Lync/Skype for Business Server 2015 Front-End pool:

Get-CsUserDatabaseState -RegistrarPool

The result lists the Identity, Mirror and Online status of the SQL database servers of the specified FE registrar pool. This works since only this pool type houses the user store (database) which keeps key user related information like presence and routing data.



Get-CsPoolFabricState – UserServices not installed

On Skype for Business Server 2015, you may encounter:

Get-CsPoolFabricState: UserServices is not installed on this machine

Ensure that the value set to the -PoolFqdn parameter of this cmdlet indeed points to a Front-End Standard or Enterprise Edition Pool and not just a node’s FQDN in the server pool. All other pool types like Mediation, Edge or Persistent Chat are not valid (for obvious reason).

Still no change as reported in my last blog post on this very topic – the Get-CsPoolFabricState cmdlet does NOT generate any objects or allow its output to be captured. One workaround is to explicitly run the cmdlet as follows:

powershell.exe Get-CsPoolFabricState -PoolFqdn > out.txt

… and process the saved result with Select-String for instance.

RE: Skype for Business for Android – Exchange Settings (still) “Lost” v6.16.0.9

UPDATE (10 Jul 2017)

Microsoft publicly released on this day the Android version of Skype for Business

The two Exchange settings “Skype for Business Anmeldeinformationen verwenden” and “Server automatisch erkennen” are now by default enabled regardless of previous states. A user must explicitly override the latter (off) to get EWS to work if auto config is not desired.

Likewise a user interface quirk as last reported, if “Skype for Business Anmeldeinformationen verwenden” is activated, the UI disables it when you revisit the config page. The option “Server automatisch erkennen” now correctly remains off with the given URL if configured as such before. As long as you hit Cancel and do not logoff, all should continue to function.

Note that IMs received over the Android mobile client remain on the main page until deleted. To do this, press and hold to pick the delete menu option. Simply trying to swipe away does not (yet?) delete an IM from the list.

Skype for Business for Android Mobile – Exchange Settings “Lost”


Like previous releases, the current version ( of Skype for Business for Android mobile devices exposes 2 Exchange configuration options namely “Skype for Business Anmeldeinformationen verwenden” and “Server automatisch erkennen”.

If you disable the latter option, specify manually the “Exchange-Webdienste FQDN oder URL” and press OK to save the changes, the settings should take effect in an instance or so. The appearance of a list of upcoming skype4b meetings on the main and Calendar tab confirms that Exchange Web Services (EWS) connectivity is functioning as expected.

Nevertheless when you revisit the same Exchange configuration settings, you find that the “Skype for Business Anmeldeinformationen verwenden” is deactivated unexpectedly. Additionally, “Server automatisch erkennen” is now mysteriously re-enabled. By turning it off again, you see that the previously entered EWS FQDN/URL is still intact.

This is apparently a User-Interface only issue; from a functional perspective, everything should continue to work as normal until Microsoft fixes this UI quirk. Otherwise, you may have to logoff and sign-in to have the EWS settings take effect (or toggle the switches explicitly).