Speaking at Philadelphia PowerShell User Group in May

I’ll be speaking at the Philadelphia PowerShell User Group on May 1st at 5pm CST and I’ll be talking about ‘Managing WSUS with PowerShell’. I won’t actually be there and will instead be presenting via Lync. Regardless, it will be a great time!

Be sure to sign up at the link below to register to attend the meeting.

http://www.eventbrite.com/o/philadelphia-powershell-user-group-3079728240

Posted in powershell | Tagged , , , , | Leave a comment

Testing TCP Ports with a Possible Header Response

I wrote a function a while back as a quick means to not only check for an open port, but also to see if a header is sent back on the initial connection. The reasoning behind this was to help troubleshoot an ESXi host by looking at port 902, which would return a header response if a connection was made. Typically this would be done using the Telnet client, but this is not installed by default. Enter PowerShell to provide a better solution to this issue.

Rather than dive into everything that I have done previously, I will direct you to the following blog that I wrote on scanning ports.

The part that I really haven’t talked much about is what to do if there is a response back from the server. First I will make the connection and if there is data available, begin processing it.

$Computer='DC1'
$_Port=21
$stringBuilder = New-Object Text.StringBuilder
$tcpClient = New-Object System.Net.Sockets.TCPClient
$connect = $tcpClient.BeginConnect($Computer,$_port,$null,$null) 
$wait = $connect.AsyncWaitHandle.WaitOne($TCPtimeout,$false) 
Write-Verbose "Bytes available: $($tcpClient.Available)" -Verbose

SNAGHTML66ef46d1

Looks like I have 27 bytes of some data awaiting me at this point in time, but there could be more depending on how much is buffering (there will  actually be 127 bytes in this example).

The first thing that I need to do is connect to the Stream using GetStream(). Once I have that, I want to make sure that I create a byte buffer which is  large enough to hold the data stream.

$stream = $TcpClient.GetStream()
$bindResponseBuffer = New-Object Byte[] -ArgumentList $tcpClient.Available

If I look at the $bindResponseBuffer, it will be nothing but 0s. This is because I have not added anything to it just yet, it is just an empty buffer. To make better use of this buffer, I will begin reading the data via the stream. This is done using the Read() method of the stream object and giving my empty buffer, setting the starting location to the beginning of the stream (0) and then lastly the maximum number of bytes to read from the stream.

[Int]$response = $stream.Read($bindResponseBuffer, 0, $bindResponseBuffer.count) 

Now let’s take another look at the buffer.

SNAGHTML66f769b4

That looks more like it. Although, this really doesn’t help us see what the actual data is being sent from the remote port.

I do this by casting the byte into something more readable by using [char] type accelerator. Let’s just use this on the first byte to see what we get.

[char]50

image

The 50 byte is actually a 2. Now, using my stringbuilder, I will convert all of the bytes and then display the output.

$Null = $stringBuilder.Append(($bindResponseBuffer | ForEach {
    [char]$_
}) -join '')
$stringBuilder.ToString()

SNAGHTML66fdbfa7

As you can see, the output is very similar to what you would see if you attempted to connect to an FTP server using the FTP client.

I’ve got a function which I wrote to make this process a little easier. An example of it in action is below.

Get-TCPResponse -Computername dc1 -Port 21,25 | 
Format-List

SNAGHTML66eaa073

Download Get-TCPResponse

http://gallery.technet.microsoft.com/scriptcenter/Get-TCPResponse-ba1090e9/file/113111/1/Get-TCPResponse.ps1

Posted in powershell | Tagged , , | Leave a comment

Setting Up a NuGet Feed For Use with OneGet

I blogged recently about using OneGet to install packages from an available NuGet feed. By default you can access the chocolatey provider, but you can actually build out your own local repo to host packages on for your internal organization. One of my examples of adding the package source and installing a package from the source were done using a local repo that I had built.

Building the local repo didn’t take a lot of time and for the most part, it didn’t really involve a lot of work to get it up and running. There is is a well written blog about it, but it only covers the Visual Studio piece and nothing about the IIS installation (it will actually use IIS Express by default) as well as downloading and installing the NuGet.server package (both of which I will be doing using none other than PowerShell).

Another reason for doing this is to show just how easy it can be to do something like this. There may be better ways of doing this or more complex ways depending on the requirement, but this does achieve the goal of setting up a NuGet feed on your internal network.

Ready? Let’s get started!

A few requirements before moving forward with this installation:

  • You need to be running PowerShell V5 Preview (for the OneGet Module)
  • Visual Studio needs to be installed

Download and Install NuGet Server Using OneGet

Yes, we will be using the OneGet module to locate this package and install it on the local system. First let’s take a look to see what is out there for NuGet.

Find-Package -Name NuGet.vs

 

image

Now that I know there is a package available to download and install, I will just pipe this into Install-Package to put this on my system.

Find-Package -Name NuGet.vs |
Install-Package -Verbose

image

Success! NuGet.vs has been installed and will be ready for us when we get further along with our configuration using Visual Studio.

Installing IIS and ASP.Net 4.5

Next up on our little journey is to setup the IIS server which will be hosting the feed.

Install-WindowsFeature -Name Web-Server,Web-Asp-Net45 -Verbose

image

image

I installed ASP.NET 4.5 after finding that once I moved over from IIS Express that my package feed no longer worked.

Note that a reboot is not needed after installing IIS. Now that was pretty simple, right? Now we get to move on to the non-PowerShell portion and start working with Visual Studio to build out our local feed.

Use Visual Studio to Create Web Application

I am using Visual Studio 2013, so your mileage may vary on matching up my examples to what you might be seeing.

Once you have Visual Studio open, create a new project by going to File/New/Project

image

Make sure you select Templates/Visual C#/Web/Visual Studio 2012 and then choose ASP.NET Empty Web Application

image

image

I will give this a more useful name as well as changing the from the default location in the Visual Studio folder on my profile to another drive. Once that is done, click OK to bring up the next screen.

Add the NuGet.Server Package to the Project

In the empty project, expand the LocalRepo project and locate References. Right click on References and select Manage NuGet Packages…

image

First thing to do is click on Settings so we can verify that the package source we need is available.

image

In the settings, ensure that https://www.nget.org/api/v2 has been checked and click OK.

image

Now in the search bar on the right, type NuGet.Server and wait for the package to display. Click Install to begin the installation.

image

Accept the license (if applicable)

image

Wait for it to complete the installation.

image

You can also verify if the installation was successful via the Output box in Visual Studio at the bottom.

image

Configure your packages

We can also see that there are a lot more things now under the localrepo project as well. The main piece that we are concerned about is the Web.config file. Let’s go ahead and open that up.

image

In the AppSettings portion of the Web.config file, look for a setting called packagesPath. This is where we can specify a different location (Default is the path of your project) for our packages if we wanted to host them on a different drive/location.

image

I am doing to adjust my location just a bit to keep it outside of this instance.

image

This is now going to be your location to drop any NuGet package (.nupkg) files off so they can be found by OneGet.

I am going to throw a couple of the packages that I downloaded and installed via OneGet to this location,. Building a package is beyond the scope of this article, but if you wanted to give it a shot, then the following link should have all of the information that you need: https://github.com/chocolatey/chocolatey/wiki/CreatePackages

I’ll just use PowerShell to copy the existing packages over to my own local repository.

Get-ChildItem C:\Chocolatey\lib\ -Recurse -Filter *.nupkg | 
Copy-Item -Destination D:\Packages -Verbose

image

If you want to build your own packages, the following link should get you on your journey: https://github.com/chocolatey/chocolatey/wiki/CreatePackages

Complete the Build

Ok, I have installed the NuGet server, configured and added some packages to my repository. All I really have left to do is to decide how this is going to be hosted. By default, this will use IIS Express, but I want to use my own IIS instance that I installed earlier to be the host for my feed.

We will need to get into the settings and make this change. Right click on the localrepo and select properties.

image

Select Web and take note of the Servers section. Here is where you choose how it will be hosted (IIS Express, IIS or External Host) as well as defining a url and creating a virtual folder on the IIS server.

image

 

I’ve made my changes and clicked the Create Virtual Directory button to add this to my IIS server.

image

Now I can right click on localrepo and select Build.

image

Based on the Output Window, it appears that the build was successful!image

Testing the Site

I can type in the url that I specified in Internet Explorer (or any browser of your choosing) and I should get a webpage that says I am running a NuGet.Server instance.

image

I can go to the packages link and see what is already there waiting for me.

image

Ok, that is nice and all, but we are really doing this for the sake of OneGet, right? Let’s add the package source of our new local feed. Note that I am not using the packages portion of the url that I used on Internet Explorer.

Add-PackageSource -Name LocalRepo `
-Location http://xorp-ms-1/LocalRepo/nuget `
-Provider Chocolatey -Trusted -Verbose

image

Ok, it is there, so let’s really verify everything works (at the time of this blog there is no verification check of the location when using Add-Package).

Find-Package -Source localrepo

image

We can see all of the packages that I copied over are available on my local repository. The final test of this is to actually download and install a package. Before I do that, let’s take a look at what is actually installed vs. what is available on the local repository.

image

Looks like I will be downloading and installation dotPeek and sysinternals.

Find-Package -Source localrepo -Name dotPeek,sysinternals | 
Install-Package -Verbose

image

Once it has finished, we just need to verify that the package has been installed.

image

Perfect! I now have a working NuGet server hosting some packages in my internal environment that I can use.

Posted in powershell | Tagged , , , , | 3 Comments

What Else is New in PowerShell V5

I’ve already gone over OneGet and its inclusion to Windows Management Framework (WMF) 5, but what else was added with PowerShell V5 that everyone can use?

Besides OneGet, there are some improvements to Desired State Configuration (DSC) to include performance improvement, bug fixes and other general optimizations.

L2 Network Switch Management

The other “big ticket item” with V5 is the ability to now manage L2 Network Switches. The module, NetworkSwitch, contains 19 functions which are available to manage a switch. Those functions are listed below:

image

I do not have a switch that would work with this on me, so I will point to the following article that shows a little more information about using this module.

New Cmdlets

Besides that, there are a couple of new cmdlets that I have found which you can use:

Get-ItemPropertyValue

image

This cmdlet lets you get down to the actual value of an item. Very useful for working in the registry.

Let’s look at one of the properties and see what is available.

Get-ItemProperty -Path HKLM:\SOFTWARE\Microsoft\.NETFramework

image

Ok, I want to see the value of InstallRoot.

Get-ItemPropertyValue -Path HKLM:\SOFTWARE\Microsoft\.NETFramework -Name InstallRoot

image

Using this cmdlet, we can now get the value under the property. Pretty cool, but oddly enough, there is no Set-ItemPropertyValue (or a Remove-ItemPropertyValue). Maybe in the next preview release.

Debug-Job

This is an interesting cmdlet that has been added to the latest version of PowerShell.

image

The only parameters that it has are concerning the way to attach to an existing PSJob. Let me kick off a job so we can try this out.

Start-Job -Name Demo -ScriptBlock {
    While ($True) {
        For ($i=0;$i -lt 10; $i++) {
            Write-Verbose "Iteration: $i" -Verbose
            $i
            Start-Sleep -Seconds 1
        }
        Write-Verbose "Resetting" -Verbose
    }
}

image

Per the nature of the job, we cannot see anything. Let’s see what happens when we hook up Debug-Job to our currently running job.

Debug-Job -Name Demo

image

What I notice immediately is that it runs through all of the streams that have already happened prior to getting to the final point of actually going into the PSJob via the debugger.

image

Looking at the help, I can see what my available debugging options are:

image

I can explore the job just like I would when I explore a script via the *-PSBreakPoint cmdlets in the console or ISE.

image

image

Typing (q)uit will completely stop the job and exit the debugger. Instead, I want to use ( c )ontinue instead.

image

Now we can see that the operation will continue on and provide the status of the streams had used in the job. Unfortunately, there is not a way to just exit the debugger without the output continuing to run. I tried Exit and it behaved much like using Continue. Only a Ctrl+C would stop it displaying the debugging info and still keep the background job running. Possibly a bug.

To finish out, I did find a few more “new cmdlets”, but believe that these are actually bugs with the new release.

image

There are an additional 11 functions for ServerManagerTasks module which are basically the same functions (minus the “SM” prefix on the noun) which do not work at all and actually act as though they do not exists

Then there is the Get-StreamHash function which serves as a helper function for Get-FileHash but was made public. It doesn’t work by itself even though I tried to match what it was looking for in the parameters. It still needed a variable which was available in Get-FileHash.

I posted Connect items here on those to make sure that they are resolved by the time the main release is available.

https://connect.microsoft.com/PowerShell/feedback/details/847348/wmf-5-preview-get-streamhash-helper-function-for-get-filehash-is-publicly-available-and-throws-errors-when-used-on-its-own

https://connect.microsoft.com/PowerShell/feedback/details/847358/wmf-5-preview-servermanagertasks-module-duplicate-missing-sm-prefix-on-noun-functions-appearing-and-not-usable

So that is it for now. As I find new things with this and the future preview releases, I will be sure to write about them to share what I have found. If you happen to find something that I missed, but sure to drop a line in the comments!

Posted in News, powershell, V5 | Tagged , , , | 1 Comment

Hey, Scripting Guy! Post on a WPF Clock Widget

image

I’m talking about using Windows Presentation Foundation (WPF) to build a clock widget. Something a little fun this time around Smile and I also have another PowerTip as well. Check them out and let me know what you think!

  1. Weekend Scripter: Build a Clock Widget by Using PowerShell and WPF
    1. PowerTip: Use PowerShell to Display Known Colors
Posted in powershell, WPF | Tagged , , , , , | Leave a comment