PowerShell Module Test-TCPConnection

I have this love versus disappointment relationship with PowerShell. It can provide a lot of great stuff for us in automation, but sometimes the thing that looks likes the best ever since sliced bread can be a bit of a disappointment. Take the cmdlet “Test-NetConnection” for example. It’s absolutely wonderful in what it does. It assists you in doing a network diagnosis with just a single command. Much more than you could ever get out of just a simple icmp ping. However, the latter is just the problem with this PowerShell cmdlet. You cannot run it without it using a ping. The real downside to that is when the port is not available, blocked by a firewall or something else is blocking it, you have to wait for it to get a time out. And that takes time, a lot of time. If it was just for one host, I could live with it, but if you need to figure out if 200 servers are reachable, you are going to be in the office for a while. Hence the creation of my ever first cmdlet!

Based on my disappointment for the “Test-NetConnection” cmdlet and my desire to learn more on PowerShell I created my first cmdlet that does exactly what “Test-NetConnection” does with respect to a port query but without the icmp ping involved. I have dubbed it “Test-TCPConnection”, because, well that it what it does. Being the nerd that I am, I have included a full help in the module itself but I will list on my site as well. Use “help Test-TCPConnection –Online” to connect to the online help page.

To make the “Test-TCPConnection” module work, extract the folder and place it in your PowerShell Modules folder. Use the following command to see your individual module path’s.

$env:PSModulePath -Split ";"

After reloading your PowerShell environment, the module will be loaded automatically. You can check the commands the module exposes with:

Get-Command -Module TestTCPConnection


Getting the syntax is easily accomplished with:

Get-Command Test-TCPConnection -Syntax


Any feedback is always appreciated. Use the comment option down below or send me a message using the contact page.

Download version from the PowerShell Gallery:

PowerShell – Help

Last year I had the opportunity to self-educate myself on Microsoft PowerShell. Having had just too little experience with it I thought it was about time to dig in and at least learn the basics. So I bought a book and got started. In the next couple of blog posts I will share my experiences and notes that I took over the month’s that I had my first try at learning PowerShell. Although the language can be very complex, it all starts out with having the basic skills to understand the language. After that it’s getting the experience that counts. Today I’ll start with a very important topic. Getting help…

Tip! Always start the PowerShell command-prompt or the Integrated Scripting Environment (ISE) elevated. Throughout the blog post I’ll use the ISE as much as possible. It has far better and more modern way of working.

First things first

The beauty of having PowerShell is that is a modern language integrated with not just local resources but also online repositories. The help functionality is no different. Although Windows ships with an up to date help file for PowerShell, things can change very quickly. So it’s always A good idea to update the local help files every now and again. Here’s a few tips on how to do it.

Update local help files
Use the following Cmdlet to update the help content.


Download help content
Suppose not all your systems are Internet connected, use save-help to store help files locally.

Save-help -path <path>

Use the -SourcePath on the target system to update the help files

Update-Help -SourcePath <path>

Tip! man & help are wrappers for get-Help cmdlet

After the help files are updated it’s time to make use of them. In a command-line environment it’s really not that hard. First you need to figure out what command you need help on. That can easily be done be done with Get-Command. Suppose we want to do something with Windows Services. We could use something like this:

Get-Command *service*

The output will look something like this:


Tip! Use the following to list only the Functions and CmdLets

Get-Command *service* | Where {$_.CommandType -eq "Cmdlet" -or $_.CommandType -eq "Function"} | select Name

Or use the “Commands” Window in the ISE. That will bring up a list of only the Cmdlets (PowerShell Commands) and functions that you can use. Getting help from the ISE is also very easy. Just click on the little blue icon with the question mark to get the help overview.


To get the same output as available in the ISE and more on the command-line, use these parameters after the get-help Cmdlet. Let’s use the Get-Service CmdLet as an example.

Quick help

Get-Help Get-Service

Detailed Help (without parameter details)

Get-Help Get-Service -Detailed

Full information (I always use this)

Get-Help Get-Service -Full


Get-Help Get-Service -Examples

Up-to-date online information

Get-Help Get-Service -Online

That’s all for this post on the PowerShell help system.




5 Steps to get started with Azure DSC

In our never ending quest to improve our production environment we are currently looking into the possibilities that Microsoft Azure can offer us. One of offerings that has our interest is state enforcement management with Windows PowerShell, also known as “Desired State Configuration”. I was already deeply impressed with the capabilities that are offered when running DSC on a local box, via PowerShell remoting or using the pull method on-premise. Only thing that was a bit challenging is deploying the configuration in a world wide, loosely connected, non domain environment, Microsoft Azure to the rescue.

Basically PowerShell DSC is a state enforcement platform, much like Group Polies are. With the increased usage of the cloud it’s become clear that group polices via Active Directory are not the way forward anymore, especially for non-domain type systems. We need a way to do remote state enforcement whenever we need it, on demand without the requirement to make use of a self-hosted on premise environment. Introducing Microsoft Azure Desired State Configuration. Follow the steps below to make your first DSC Configuration document, Create an Automation Account, Assign the Document and configure a server to use DSC.

On this page:

  1. Creating the Automation Account
  2. Import the Configuration
  3. On-boarding the target
  4. Apply the meta-data configuration file
  5. Assign the configuration
  7. Reference

Creating the Automation Account

Azure DSC makes use of an automation account. Follow these steps to first create that account.

  1. Login to the Azure portal at https://portal.azure.com
  2. Select “More Services
  3. Type “Automation”, click “Automation Accounts
  4. Click “Add” next to the large plus sign
  5. Add the appropriate data in the ‘Add Automation Account” page. Click “Create


Wait a few moments for the account to be created

Import the Configuration

Once the Automation Account has been created we can start to configure desired state. Click on your just created automation account. The blade for configuring the account will open. Click on the “DSC configurations”, located in the “Configuration Management” section. The DSC Configuration node is the store where your configuration documents are saved. These documents dictate the state of your machine. Click the “Add a configuration” on the top of the page. In the “Configuration file” click the folder icon and browse to your configuration file. In my case I’ve created a document that tells the system to install the default Web Server (IIS) role and remove SMBv1, but you can basically configure your entire system this way. Click “OK” to return to the previous blade.

Give it a second to import the file.

What we need to do next  is tell Azure to convert the configuration document to a .mof file that it can deploy. To accomplish that just click the configuration that you just imported. The blade that opens allows you to convert the ps1 script to a .mof file. Click on the “Compile” button on the top of the page. Read the message and click “Yes”.


Close the blade after the compile action successfully completes .

On-boarding the target

Now that the main configuration is done we need to on-board the server that we want to target with DSC. Microsoft made that a really simple task with providing an on-boarding script. This script is available at:


Just in case that location ever changes, you can easily locate the url again by browsing to your “Automation Account” blade, clicking “DSC Nodes” in “Configuration Management” and click on “Add on-prem VM”. Browse to the “Generating DSC metaconfigurations” section and copy the script content.

The only basic things that needs to be changed in the script are the “RegistrationUrl”, “RegistrationKey” and the “Computername” value. Just for fun we’ll also change the state enforcement policy by setting the “ConfigurationMode”. You first need to get the values for “RegistrationUrl” and the “RegistrationKey”. These are located in the “Automation Account” blade, “Account Settings” select “Keys”. You can use either the primary or the secondary key.

Once updated the code in the script would look something like this:

ComputerName = @('localhost');
RegistrationUrl = 'https://we-agentservice-prod-1.azure-automation.net/accounts/5eb0794a-a035-406e-8181-ece99172d6fa';
RegistrationKey = 'qLVkKkhBe4+RfVEkuIl2TicZSvzUEj+1jPXvdd0SkDM662zwolUcyVx2KzvSoUsSHZpK7FvlzkF4WuxZh4G8CA==';
ConfigurationMode = 'ApplyAndAutoCorrect';

In the example above I apply the configuration to the localhost instead of an individual hostname. That’s just the situation I’m in. Your situation could be very different. Once the script is ready, it needs to be executed to generate the meta-data configuration .mof file.

Apply the meta-data configuration file

Applying the configuration meta-data file can be done multiple ways, by using PowerShell remoting or just apply it locally on the box. In this demo I’ll use the latter.
Copy the “DscMetaConfigs” folder to the local box. Open an elevated PowerShell ISE or PowerShell Command console and use the following command to configure the system.

Set-DscLocalConfigurationManager -Path .\DscMetaConfigs

In case you want to check the configuration that’s been applied, use:


Assign the configuration

Last step we need to take is assigning the appropriate DSC configuration to the server. Obviously we need to do this in Azure. Select your “Automation Account” and click on the “DSC Nodes” under “Configuration management”. The Server that we used the on-boarding script on should be listed here. Click the Server name, next click the “Assign node configuration” icon at the top of the screen. On the “Assign Node Configuration” blade that opens, click the generated configuration document (If you used my script it will show “MyFirstConfiguration.MyServerRole”). Click “OK”.

And that’s really all there is to it. After waiting for about 15 minutes the configuration will be applied on the selected server.


Tip! Just in case you don’t want to wait, use the cmdlet:

Update-DscConfiguration -Wait –Verbose

To force the consistency check on the target server.


MyServerRole PowerShell Script



Windows PowerShell Desired State Configuration Overview


Azure Automation DSC Overview


Getting Started with PowerShell Desired State Configuration (DSC)


Hybrid IT Management Part 3: Automation