Advanced Windows PowerShell Scripting Video Training

Thursday, September 19, 2013

This morning I had a question come in on LinkedIn about installing the SNMP service on 20 remote servers. The first person who responded recommended using Enable-PSRemoting on all servers and the downloading some tools from Sysinternals. He was on the right track. The problem is that process would require either traveling to the remote sites or providing admin credentials to local users to do it for him. Also, the full power of PowerShell remoting is not utilized since the instructions were to utilized other software.

Using the Invoke-Command cmdlet, you can execute commands on the remote machines. You first need to import ServerManager on the remote machines (Unless your remote servers run PowerShell V3) and then add the feature. This importing of ServerManager is actually being done on the remote servers. Look carefully, that is a semi colon “;” after ServerManager.

Monday, September 9, 2013

First off, I want to thank Gaby Kaplan from Microsoft and the PowerShell team for helping find this path to success.

I needed to find a very simplistic way of creating conceptual help files for my PowerShell modules. Some of this code gets sent to my students after my PowerShell classes and I like to provide as much information as I can. You will recognize conceptual help files because they start with About_. So, here we go.

Step 1. Create a text file in the same directory as your script module. Mt module is stored in my user account’s Documents\WindowsPowerShell\Modules\PSV3. PSv3 is the name of the module that I will be sending to my class.

Step 2. Name the file correctly. The syntax is About_NameOfYourConcept.help.txt.

Step 3. Add the content to the text file and save it.

Step 4. Import the module. Whoa!!!! Wait a second. in PowerShell V3, we had auto loading of all of our modules. That is true and this is what kind of messed me up a bit. Thanks to Gaby’s time and patience, she was able to find the reason for this. You will need to import the module manually. In PowerShell V4, you do not. This is what the PowerShell Project Manager sent to Gaby:

Prior to PowerShell 4.0, the module must be imported into the current session in order for Get-Help to find the topic. This is because Get-Help only looks in $pshome and loaded module folders for About topics. We improved this in PowerShell 4.0 so that the module no longer needs to be imported / loaded. Get-Help will look in all module folders under PSModulePath for a matching About topic.

The PowerShell PM also noted that if you store your help file in the $PSHOME folder, it will be deleted during servicing.

So, in walks Hyper-V and some virtualization. Utilizing a preview copy of Windows 8.1, I gave this a try. Like I said, preview copy. This capability is not there just yet, so I’m going to wait for the full release.

Friday, September 6, 2013

Just the fact the I’m using PowerShell to create BAT files is odd enough. This pesky little problem cost me many hours of precious time. Essentially, I’m writing some PowerShell code to look at some BAT files and then reconfigure them according to my scripts logic. That all works flawlessly. The problem is some extra bits added to the beginning of each line. I was using the Out-File cmdlet to save the new paths to the BAT file. Take a look at this one line:

"Dir"|Out-File –LiteralPath "J:\PSTest.bat"

Simple enough. It created a BAT file call PSTest with only one command, “DIR”. This is what happens when you run it.

What is the mysterious character in front of the “D”? I tried to implement this in several different ways. File redirection using “>>” did not work. It yielded the same results. I also tried the –encoding parameter of Out-File. Same result. Using Get-Content in PowerShell, Type in DOS, or even opening the file in Notepad would produce a normal looking file. No signs of the mysterious character. I finally settled on Add-Content.

Add-Content will add a line of text to a text file. Since this file would be changing often, I had to include code that would test for the existence of the file and remove it if it was already there:

# See is a configuration file already exists.

# Make sure it is empty.

If (Test-Path-Path"J:\PSTest.bat")

{

Remove-Item"J:\PSTest.bat"

}

Now I can add as many commands as I want by calling Add-Content.

Add-Content-Path"J:\PSTest.bat"-Value"DIR"

Now the mysterious character is no longer present and the batch file will execute normally.

Monday, September 2, 2013

Being a Microsoft Certified Trainer, I work with a lot of different clients spread over 11 different time zones. I sometimes need a little help when it comes to looking at contracts from my clients. The old saying “All is fair in love and business” is something that all business owners needs to remember. Fortunately for me, from client to client, contracts are fairly identical. I still like to look for anything that has changed from a previous contract with a client, but this can be time consuming.

Below is a little script that I use to highlight any changes. I just simply save the contents of the contracts into a text file and feed the new contract and the previous one into this script. This script will highlight any differences in each line. This helps to quickly direct my attention where it needs to be. In most cases, the contracts are 99% identical from one to the other. This just helps to make sure that I do not miss that 1%.

One thing to note is the use of Write-Host in this code. The design of the code is note to be used in the PowerShell pipeline. It is to be displayed utilizing colors.