Jason Yoder, MCT

I’m sitting in O’Hare enjoying my 3 hour layover as I get ready to teach a Windows 10 class in Fort Wayne.  I’m actually prepping for my class in Fort Wayne in a few weeks, 10982 Supporting and Troubleshooting Windows 10.  This class is very much like the Windows 7 version that I used to teach so I decided to up the detail quite a bit.  In the GPO troubleshootin chapter, I’m including a demonstration on how to use PowerShell’s Invoke-GPUpdate.  I needed to make sure the environment is set up for me to be able to utilize this cmdlet.  If you read the Notes section on Invoke-GPUpdate’s help file, you will see there are three firwall rules that need to be in place:          Remote Scheduled Tasks Management (RPC)          Remote Scheduled Tasks Management (RPC-ERMAP)          Windows Management Instrumentation (WMI-IN) I decided to create a little PowerShell script to create this GPO and link it up to the domain. Here are the steps to create this GPO and li

This last week I had the privilege of speaking at the PowerShell Summit Asia in Singapore.  After an 11 hour day of speaking, you better believe that I had a lot of attendees asking me questions over the following 2 days.  A really good one that stuck in my head involves how to see the code that was used to write a cmdlet.  Hey, I teach PowerShell so this is a good one. PowerShell cmdlets are actually either a “cmdlet” or a “function”. PS C:\> Get-Command -Name Get-Process, Get-SMBShare CommandType     Name            Version    Source                                                                                -----------     ----            -------    ------                                                                                Cmdlet          Get-Process     3.1.0.0    Microsoft.PowerShell.Management                                                       Function        Get-SmbShare    2.0.0.0    smbshare                                                

I am doing my final checkout of my code for my evening session with Jaap Brasser for next week’s PowerShell Conference Asia.  Microsoft released Windows Server 2016 last week and all of us are rebuilding our test environments and validating our code with the final product.  While doing my thing, I received an email notification from the  IDERA community from someone new to PowerShell.  They were having some difficulty getting the distinguished names of their clients from Active Directory.  First off, for someone who is new to PowerShell, the code they posted is intense: Function Get-ComputerFromAD  {   param(    $ComputerName   )       ForEach ($Domain in $Global:ADDomains)   {    $LdapPath = "LDAP://OU=Computers,OU=GPWS,DC=$Domain,DC=xxx,DC=com"    [System.DirectoryServices.DirectorySearcher]$Searcher = $LdapPath    $Searcher.Filter = "(&(objectCategory=computer)(cn=$ComputerName))"    $Searcher.SearchRoot = $LdapPath    $Searcher

When teaching PowerShell, I use Write-Host often just to display what is going on.  It may be to show the result of an IF or SWITCH construct.  Maybe to let us know that a value incremented.  In practice, I avoid placing text on the screen unless the user specifically asks for it. Write-Host places information directly onto the screen.  Write-Verbose and Write-Information places information in a data stream that eventually ends up on your screen.  This is bad for a few reasons. First of all, the extra screen candy can be frustrating to watch.  Second, it takes time to write anything to the screen.  This is never good.  You should only display information if necessary and give the user a chance to suppress that information.  I decided to do a little test between Write-Host, Write-Verbose, Write-Information, and displaying nothing.  The code below loops 100 times for each command and again where nothing is performed in the loop. Function Test-DisplayHost {     For ( $X = 0

Today I am like a kid playing with Legos. I’m prepped and ready for the PowerShell Conference in Asia so I’m working on Plan B.  Wait, what?  I just said that I was prepped and ready.  I am, but that does not mean that I am going to rest.  I am delivering a workshop on learning PowerShell, but we are using the attendee’s local computer.  My Plan B is to provide everybody with a virtual environment to play in for the day using Azure.  My goal is to take everyone’s email address and create a VM in Azure for them.  I want to provision them live.  The problem with this is that if I do sequentially, it will take more than 4 hours to complete.  So, it is time to use background jobs.  When done sequentially, the task completes without any problems.  When performed using Start-Job, my Azure credentials are not passed into the ScriptBlock parameter of Start-Job.   Azure team member Mark Cowlishaw published a fix for this issue on GitHub .  Here is his solution: $path = ".\prof

I know, I’m opening this can of worms again.  You either love or hate the backtick in PowerShell.  The little thing is so awesome, but so hard to see.  It is no secret that I use it for line continuation.  I have a set of rules that I follow to allow me to use it without issues.  Here they are.   At the end of the line: o    Press SPACE o    Press the BACKTICK o    Press ENTER o    Indent the first continued line o     Do not use it on the last line of the command Here is a command without line continuation: New-ADFineGrainedPasswordPolicy   -Name   "Group1PSO"   -Precedence   10   -ComplexityEnabled   $True   -Description   "PSO for Group 1"   -DisplayName "Group1PSO"   -LockoutDuration   "0.12:00:00"   -LockoutObservationWindow   "0.00:15:00"   -LockoutThreshold   3   -MaxPasswordAge   "10.00:00:00"   -MinPasswordAge   "1.00:00:00"   -MinPasswordLength   8   -PasswordHistoryCount   10   -Re