PowerShell for Windows Admins

August 3, 2015  10:46 AM

PowerShell Summit NA 2016 – Call for Topics

Richard Siddaway Richard Siddaway Profile: Richard Siddaway

The PowerShell Summit is the number one conference where PowerShell enthusiasts gather and learn from each other in fast-paced, knowledge packed presentations. PowerShell experts from all over the world including MVP’s, Guru’s, community leaders and PowerShell team members, will once again join together for a few days in Bellevue, WA. to discuss and learn about maximizing PowerShell in the workplace. If you want to share your PowerShell expertise or story, then this is your official call to submit presentations for selection!

PowerShell Summit North America 2016 will be held 4-6 April in the Meydenbauer center, Bellevue WA.

Topic Areas – What we are looking for

We are looking for 45-minute presentations covering a wide aspect of PowerShell expertise. We have two main topic areas that may assist you in building an abstract.

PowerShell Internals – A deep look into the inside workings of PowerShell and practical solutions that are built from them. These presentations are typically more directed to the PowerShell development community that is building extensions and solutions relating to PowerShell.

PowerShell Features Deep Dive – These presentations are a deep look into configuring and working with PowerShell features and capabilities such as Remoting, Desired State Configuration and more. These presentations tend to be more IT Pro focused.

We are open to presentations across the entire ecosystem that has been built around PowerShell; so don’t hesitate to send an abstract for your particular area of expertise. This includes Microsoft platforms and products that have PowerShell-based management tools as well as 3rd parties such as VMware. New topics will be preferred over recycling of older topics – look to see what’s new in PowerShell 5.0 and use the questions on PowerShell.org to spot areas of confusion that could supply a good session for the Summit.

We may consider double length sessions, but only in exceptional cases. Please contact us – summit@powershell.org – with your idea before spending too much time developing such a session.

 What kind of sessions get selected?

We’re looking for sessions that go beyond – way beyond – “beginner.” If you want to see examples of the depth we’re looking for use the recordings on the PowerShell.org Youtube channel from the PowerShell Summit Europe 2014, or PowerShell Summit NA 2015 as a guide. We look for an abstract that’s compelling and makes us salivate to see your session – so spend time writing a punchy abstract! We want sessions that offer real-world usability combined with “wow, nobody talks about THAT” awesomeness. If in doubt aim high, very high. Remember, Summit sessions are recorded, so if you’ve previously presented a topic at a Summit, we’re less likely to choose it for another Summit. We want sessions that are challenging, and that ideally present things that simply aren’t explained or documented elsewhere. New modules, new techniques, and crazy approaches are all welcome. Discussion-format sessions are great, too, especially if you plan to turn them into a community deliverable (like a “best practices for writing DSC Resources” session that gets turned into a free e-guide later). Think community, deep dive, engaging, and amazing as keywords. We want attendees to finish each day with information leaking… just a little bit… out their eyeballs. Help us make it happen.

If you have any doubts about the suitability of a particular session please contact us – summit@powershell.org – we’re always happy to discuss proposed sessions.

We do have some goals for speaker selection, too. We obviously have, and appreciate, the great involvement we get from the product team. We aim to have a certain number of sessions from well-known members of the community, simply because they’re well-known for a reason – they do a great job! But we also set aside slots for newcomers who’ve never presented before, or who’ve maybe only presented once or twice before – the audience will judge you on content not style. We want to create opportunities for more folks to become engaged and active in our community, and the Summit is a great way to do that.

We aren’t looking for soft-skills sessions, like “how to get a new user group running,” although contact us via email (summit@powershell.org) if you’d like to do something like that as an extra evening thing after the main content wraps for the day.

Please note all sessions are to be delivered in English. Presenter will provide all equipment needed to deliver session(s), including a laptop or other computer. Presenter must be able to provide video by means of HDMI, DVI-D, or DisplayPort connectors – VGA is NOT supported. Presenter must be able to manually select an appropriate screen resolution for video output. Typically, 1024×768 or 1280×720 are preferred.

How to submit abstracts of presentations

Presentations will be 45-minutes in length and the submission should include the following:

Presentation Title

Presentation abstract – a description of the presentation and the topics covered. 250 words or less and suitable for marketing.

Go to https://eventloom.com/event/register/PSNA16/Speaker?preregister=1.

This is the only valid URL for pre-registration. Provide your e-mail address, password, and confirm password. You’re creating a new account, even if you’ve attended past Summit events.


Click Abstracts on the top menu


Enter Title and Description.


Provide a title and description; descriptions must be 50-250 words. Set the Status to “Ready to Review” when you are ready to send your session to us for consideration.

To return to the site at a later time, go to https://eventloom.com/event/login/PSNA16

Click Log In. You can then re-visit Abstracts.

Note that you must set your abstract status to Ready for Review or we won’t see it. If you leave it in Pending, it won’t be considered.

You can submit multiple presentations in the same topic area or for different ones. Be aware that even though the session length is 45 minutes we prefer to have at least 10 minutes set aside for questions. Summit presentations are intense and intimate often with plenty of audience interaction. You must expect questions and discussions. This is not a “lecture to the audience” event. Also because of the session length, generally co-presenters are unnecessary, but that is not a requirement.

Presentation submission deadline – When you should send it by

Start sending your presentation submissions immediately! The selection committee will start selecting presentations as soon as they arrive so you don’t want to miss out. The last day we will accept presentation submissions will be Thursday 1 October 2015. This is a hard deadline – no sessions will be accepted after this date.

When you will know you’ve been selected

The selection committee will start reviewing submissions immediately and begin the selection process. You will be informed if one or more of your presentations have been selected and notified by Thursday 15 October 2015.

You will need to log back onto the event site and complete your registration with the code we will provide in the notification email. This will have to occur before 31 October 2015 so that we have a completed agenda in time for attendee registration.

Speakers, with accepted sessions, will be given free admission to the event, including attendance at all official Summit activities. However, AWPP membership is not included. Speakers may not bring guests to the day sessions or evening events. We have a limited budget, and the number of speakers selected will be partially governed by that budget.

Pre-registering does not guarantee you a place at the event. Pre-registration is until 1 October 2015. Final session selections will be made by 15 October 2015, and you will be notified of accepted/unaccepted sessions.

If at least two sessions are accepted, you will be asked to immediately make a reservation at our speaker hotel. You will be given our group code, and we will directly pay for up to 3 nights’ lodging. Any additional nights are your responsibility as are travel and other costs.
If any sessions are accepted, you will be asked to immediately complete your Summit registration using a free promotional code. If you do not complete your registration by 1 November 2015, then we will assume you do not wish to present and your sessions will be cancelled, and the slots offered to another speaker.
If no sessions are accepted, then your pre-registration will be deleted. Beginning 1 November 2015 and through 4 March 2016, you are welcome to create a new account and register as a standard attendee on a space-available basis.
The final agenda will be announced and posted on PowerShell.Org on, or about, Sunday 1 November 2015.

We look forward to your submissions and your help in making PowerShell Summit North America 2016 the most valuable IT/Dev conference of the year building on and surpassing the previous Summits!

August 2, 2015  3:40 AM

Windows 10 upgrade–network instability on Surface Pro 2

Richard Siddaway Richard Siddaway Profile: Richard Siddaway
Windows 10

One thing I noticed after performing the recent upgrade to Windows 10 was that my network connection had become unstable. It was losing the DNS server configuration on an irregular and intermittent basis. Renewing the DHCP lease on my wireless connection would correct the issue.

My Windows 8.1 install had Hyper-V enabled which modifies the network connections. Removing Hyper-V seems to have resolved the issue as I haven’t had any further problems.

If you’re upgrading a Surface Pro 2 you may want to think about removing Hyper-V before the upgrade, then re-install after the upgrade.

August 1, 2015  4:05 AM

Scripting Games July 12015 thoughts on the solution

Richard Siddaway Richard Siddaway Profile: Richard Siddaway

The July 2015 puzzle can be found here:


Write a one-liner that produces the following output (note that property values will be different from computer to computer; that’s fine).

Write a one-liner that produces the following output (note that property values will be different from computer to computer; that’s fine).

PSComputerName ServicePackMajorVersion Version  BIOSSerial
————–         ———————– ——-  ———-
win81             0                       6.3.9600 VMware-56 4d 09 1 71 dd a9 d0 e6 46 9f

By definition, a one-liner is a single, long command or pipeline that you type, hitting Enter only at the very end. If it wraps to more than one physical line as you’re typing, that’s OK. But, in order to really test your skill with the parser, try to make your one-liner as short as technically possible while still running correctly.


•Try to use no more than one semicolon total in the entire one-liner

•Try not to use ForEach-Object or one of its aliases

•Write the command so that it could target multiple computers (no error handling needed) if desired

•Want to go obscure? Feel free to use aliases and whatever other shortcuts you want to produce a teeny-tiny one-liner.

By definition, a one-liner is a single, long command or pipeline that you type, hitting Enter only at the very end. If it wraps to more than one physical line as you’re typing, that’s OK. But, in order to really test your skill with the parser, try to make your one-liner as short as technically possible while still running correctly.


•Try to use no more than one semicolon total in the entire one-liner

•Try not to use ForEach-Object or one of its aliases

•Write the command so that it could target multiple computers (no error handling needed) if desired

•Want to go obscure? Feel free to use aliases and whatever other shortcuts you want to produce a teeny-tiny one-liner.

Initial thoughts.

One liner is a mis-nomer that has caused more problems than enough for the PowerShell community. The requirement is correctly stated as a single pipline.  One pipeline can spread over many lines but is called a one-liner. This is one line of code:

get-service; get-process;

but is not a one-liner because the semi-colon is a line termination character so you’ve combined 2 lines but into 1 but they’ll execute as 2 pipelines.

Obviously need to use CIM (WMI) to retrieve the data. Standard approach would be Win32_OperatingSystem & Win32_Bios

£> Get-CimClass *Bios

NameSpace: ROOT/cimv2

£> Get-CimClass *OperatingSystem

NameSpace: ROOT/cimv2


If you want to shave off a couple of characters you could use the CIM_OperatingSystem class as Boe suggests http://powershell.org/wp/2015/07/29/2015-july-scripting-games-wrap-up/

Be aware that the CIM_ classes adhere to the standard definition from the DMTF – http://www.dmtf.org/standards/cim and Win32_ classes are the Microsoft version from when WMI was introduced. The win32_ classes are often subtly different to the CIM_ classes so check carefully with Get-CimClass before using.

My first though was to use Get-CimInstance

Get-CimInstance -ClassName Win32_OperatingSystem |
select PSComputerName, ServicePackMajorVersion, Version,
@{N=’BIOSSerial’; E={(Get-CimInstance -ClassName Win32_Bios).SerialNumber}}

But for the local machine that won’t return the PSComputerName attribute unless you use the –ComputerName parameter and point to the local machine or pipe the computer name to the cmdlet

Get-WmiObject doesn’t have that problem

Get-WmiObject -ClassName Win32_OperatingSystem |
select PSComputerName, ServicePackMajorVersion, Version,
@{N=’BIOSSerial’; E={(Get-CimInstance -ClassName Win32_Bios).SerialNumber}}

The trick here is to use a calculated field to get the BIOS serial number

I prefer using Invoke-Command to get the data from a remote machine. I get the RunSpaceId as well but that can be filtered out.

The last part of the puzzle was to shrink the code to the smallest number of characters possible. I’ve never seen the point of that in production use so never bother – if I wanted to write something unreadable I’d use Perl. The time taken to shrink is never regained and I can use tab completion to get my code input quickly and working. Boe has done an excellent job of showing that could be done so I’ll point you in that direction

July 29, 2015  7:30 AM

Windows 10

Richard Siddaway Richard Siddaway Profile: Richard Siddaway
Windows 10

Went through the Windows 10 upgrade procedure this morning. Fairly quick process – just over the hour including download on a slow broadband link. Most of my settings from Windows 8.1 were saved.

So far impressions are reasonable to good.

PowerShell 5.0 is installed

£> $PSVersionTable

Name                           Value
—-                           —–
PSVersion                      5.0.10240.16384
WSManStackVersion              3.0
CLRVersion                     4.0.30319.42000
BuildVersion                   10.0.10240.16384
PSCompatibleVersions           {1.0, 2.0, 3.0, 4.0…}
PSRemotingProtocolVersion      2.3

The Edge browser (IE replacement) is missing functionality for managing favorites and doesn’t appear to incorporate an RSS feed reader. IE is still available – hunt through program files to get to the exe.

The Mail app doesn’t supply a unified view across all mailboxes.

The big improvement over Windows 8/8.1 is that you get a unified view of applications. No more metro style or desktop. Everything runs on the desktop though the lack of a left and bottom border on the PowerShell console is weird.

So far nothing leaps out as a show stopper.

July 28, 2015  11:23 AM

PowerShell Summit NA 2016–call for topics warning

Richard Siddaway Richard Siddaway Profile: Richard Siddaway

A conference organiser’s work is never done. The dust has just settled from PowerShell Summit NA 2015 and we’re gearing up for PowerShell Europe 2015.

We also need to start thinking about PowerShell NA 2016! A post on powershell.org


serves as a warning to start thinking about topics for PowerShell NA 2016 which will be in Bellevue (Seattle) again. The official call for topics will go out next week all being well.

Don’t worry about PowerShell Europe 2016 – we haven’t forgotten about that – the call for topics will occur towards the end of the year.

July 28, 2015  5:26 AM

WMI dates

Richard Siddaway Richard Siddaway Profile: Richard Siddaway
CIM, Powershell, WMI

Dates as reported by WMI still seem to cause a lot of problems. If you use the WMI cmdlets

£> Get-WmiObject -Class Win32_OperatingSystem | select *date* | fl
InstallDate   : 20131205101649.000000+000
LocalDateTime : 20150728121320.002000+060

That format is year, month, day, hour, minute, second then fractions of a second after the decimal point with the final +nnn indicating an offset from Greenwich Mean Time  (UTC) for time zones and daylight saving time.

You can read the date presented by WMI but its not intuitive.

The PowerShell team added a ConvertToDateTime() to the object output by WMI so that you can easily perform date conversions

£> Get-WmiObject -Class Win32_OperatingSystem | select @{N=’Install’; E={$_.ConvertToDateTime($_.Installdate)}}, @{N=’Lo
calDate’; E={$_.ConvertToDateTime($_.LocalDateTime)}} | fl
Install   : 05/12/2013 10:16:49
LocalDate : 28/07/2015 12:16:26

Though my preferred solution these days is to use the CIM cmdlets as they convert the date for you without any extra effort

£> Get-CimInstance -ClassName Win32_OperatingSystem | select *date* | fl
InstallDate   : 05/12/2013 10:16:49
LocalDateTime : 28/07/2015 12:17:29

July 25, 2015  7:44 AM

Self signed certificates for testing

Richard Siddaway Richard Siddaway Profile: Richard Siddaway

A question on the forum


indicated a problem when using a self signed certificate for testing code signing.

According to the about_signing help file

To create a self-signed certificate in use the New-SelfSignedCertificate
cmdlet in the PKI module. This module is introduced in Windows PowerShell
3.0 and is included in Windows 8 and Windows Server 2012. For more
information, see the help topic for the New-SelfSignedCertificate cmdlet.

To create a self-signed certificate in earlier versions of Windows, use
the Certificate Creation tool (MakeCert.exe). This  tool is included in
the Microsoft .NET Framework SDK (versions 1.1 and later) and in the
Microsoft Windows SDK.

However the cert produced by New-SelfSifgnedCertificate only appears to function as a SSL self signed cert. It isn’t accepted as a code signing cert.

You can still get the makecert utility for Windows 8.1 from


and Windows 8 from


The makecert utility can be found in

C:\Program Files (x86)\Windows Kits\8.1\bin\x64

C:\Program Files (x86)\Windows Kits\8.1\bin\x86

for the 64 & 32bit versions respectively

While you shouldn’t use self-signed certs for production they are useful for testing. My recommendation is to use the makecert utility rather than the PKI cmdlet


July 23, 2015  11:26 AM

Devops Tools

Richard Siddaway Richard Siddaway Profile: Richard Siddaway

DevOps is the fusion of development and operations practices to give you faster, more reliable, roll out of functionality to your organisation.  Its a growing area and while much of DevOps practice is cultural rather than technical you will need at least some tools to get the job done.

There are a growing number of tools available and finding what you need can be difficult. I stumbled across this site:


which functions as an aggregation point for a significant number of the current tools. Even if you don’t need them now its worth knowing what’s available.

Don’t forget PowerShell and in particular Desired State Configuration in all of this though.

July 22, 2015  8:23 AM

PowerShell documentation and more

Richard Siddaway Richard Siddaway Profile: Richard Siddaway

PowerShell has a new home.  This site on MSDN https://msdn.microsoft.com/en-us/powershell is the centre for Microsoft’s PowerShell documentation. Book mark it now!

July 22, 2015  8:04 AM

Using parameters instead of read-host when getting AD replication data

Richard Siddaway Richard Siddaway Profile: Richard Siddaway
Active Directory, Powershell

I’ve seen a lot of scripts recently that use Read-Host to get input data.  This is generally not best practice – I tend to only use Read-Host if I want to get a password and obscure the text on screen.

A better practice is to use parameters – either in a function or a script. As an example consider this function that gets AD replication metadata

function get-ADReplmetadata {
param (


[string]$server = ‘server02’
Get-ADObject -LDAPFilter “($ldapfilter)”  -Properties $attribute |
Get-ADReplicationAttributeMetadata -Server $server -Attribute $attribute


Get-ADReplicationAttributeMetadata  is awkward to use because it only accepts a distinguished name or a GUID for identifying the object you want to access. Remembering distinguished names or GUIDs  is a pain so I use get-AdObject with an LDAP filter and pipe it to Get-ADReplicationAttributeMetadata .

The $server parameter defaults to server02 but can be overridden if you want to use another domain controller

I make the ldapfilter and attributes mandatory so I get prompted if I forget

This example pulls back meta data for just the Name

get-ADReplmetadata -ldapfilter ‘samAccountName=Richard’ -attribute Name

This example pulls back all metadata

get-ADReplmetadata -ldapfilter ‘samAccountName=Richard’ -attribute *

Forgot Password

No problem! Submit your e-mail address below. We'll send you an e-mail containing your password.

Your password has been sent to: