Category Archives: Powershell

Testing if a Port is Open With PowerShell

Ever want to confirm that a port is accessible from one computer to another? There’s a PowerShell cmdlet for that, Test-NetConnection. With the -Port option, this cmdlet will do a quick TCP three-way handshake on the remote system to confirm that the service is available and reports back if it succeeded or not. Check out that last line of output TcpTestSucceeded: False. That indicates that this port is not accessible. You can see, however, that the system is reachable via ICMP (Ping), PingSuceeded: True so we know that the remote system is alive, just not listening on the port we want to access.

This cmdlet is from Windows PowerShell 5.1

PS C:\Users\demo\Documents> Test-NetConnection server1.centinosytems.lab -Port 3389
WARNING: TCP connect to server1.centinosytems.lab:3389 failed

ComputerName : server1.centinosytems.lab
RemoteAddress : 172.16.94.10
RemotePort : 3389
InterfaceAlias : Ethernet0
SourceAddress : 172.16.94.11
PingSucceeded : True
PingReplyDetails (RTT) : 1 ms
TcpTestSucceeded : False 

In PowerShell Core, there’s a Test-Connection which in version 6.0 supports basic ICMP ECHO functionality.  In version 6.1, a -TcpPort option was added for testing connectivity to a port. The current implementation of the v6 cmdlet returns a Boolean based on the reachability of the port.

If you really want to get under the hood and learn how networking…works. Check out my LFCE: Advanced Linux Networking course. In this course, we cover IP addressing, routing, TCP internals and troubleshooting. We use the Linux command line, not PowerShell, but it really shows you how things move around a network. It’s one of my most popular courses.

Linux LFCE Learning Path Available at Pluralsight

I’m proud to announce the completion of my first Pluralsight Learning Path. This learning path is built to advance your Linux knowledge to the system administrator or system engineer level. In this series of courses you’ll learn the theory behind how things work and also practice demonstrations and tips to really nail home the things you need to know to run production Linux systems. 

The learning objectives of this series align with the Linux Foundation Certified Engineer (LFCE) certification “Domains and Competencies” however these courses will be very valuable to your development as a Linux professional even if you’re not interested in certification.

Thanks and good luck with your studies! 

Check out the path here – Linux Foundation Certified Engineer (LFCE)

  • LFCE: Advanced Linux Networking – this course is the network primer for the Linux professional, covering the OSI model, IP addressing, ARP and DNS, IP routing, routing on Linux, TCP internals and what to look for with things go wrong.
     
  • LFCE: Advanced Network and System Administration – in this course you’ll dive into managing network services with systemd, monitoring system performance, advanced package management and sharing data with NFS and Samba.
     
  • LFCE: Network and Host Security – here, you’ll look at security concepts, using iptables and TCP wrappers, firewalld, using OpenSSH and remote access tools and techniques.
     
  • LFCE: Linux Service Management HTTP Services – This course is all about Internet architecture and HTTP services. Installing, securing, SSL certificates and troubleshooting Apache.
     
  • LFCE: Linux Service Management Advanced HTTP Services – In this course you’ll learn how to build scalable Internet architectures with techniques like proxying and caching with Squid, we’ll also cover implementing advanced Apache features with modules.
     
  • LFCE: Linux Service Management Advanced Email Services – In this course, you will learn common email architectures, and you will explore installing Postfix. After that, you will look at common SMTP scenarios and learn how to secure email relay services and provide clients access to email with IMAP.

    Pluralsight logo vrt color 2

Installing OpenSSH Server on Windows 10

So in yesterday’s post we learned that the OpenSSH client is included with the Windows 10, Update 1803!  Guess, what else is included in this server, an OpenSSH Server! Yes, that’s right…you can now run an OpenSSH server on your Windows 10 system and get a remote terminal! So in this post, let’s check out what we need to do to get OpenSSH Server up and running.

First, we’ll need to ensure we update the system to Windows 10, Update 1803. Do that using your normal update mechanisms.

With that installed, let’s check out the new Windows Capabilities (Features) available in this Update, we can use PowerShell to search through them.

Now to install OpenSSH server, we can use the Add-WindowsCapability cmdlet

To confirm it’s installation we can use the Get-WindowsCapability cmdlet again, and this time it’s state is “Installed”

With that installed, let’s take a look at where sshd lives on our Windows system and that’s in C:\Windows\System32\OpenSSH\

On Windows systems, network daemons run as “Services”. We can see with the Get-Service cmdlet, the installer added ssd and also ssh-agent!

As you can see the state is stopped, so let’s start the Services and also set them to start on boot

We can use netstat to see if we’re up and running

So now that it’s up and running, you should know that the configuration files and host keys live in ProgramData\ssh\ so if you need to change the behavior of SSH you’ll head for the sshd_config file and when finished, restart your service with Restart-Service -Name sshd 

You’ll likely need to open your Windows firewall, which can be done with the following cmdlet on PowerShell 5.1

So let’s test it out, I’m going to ssh from my Mac into my Windows 10 laptop

And that’s it, you can now install OpenSSH server on your Windows 10 system. I can only imagine it’s a matter of time before this hits the server side of things! Bravo PowerShell Team, bravo!

OpenSSH is now Part of Windows!

Today is a big day! The OpenSSH client version 7.6p1 is now part of the Windows 10 operating system! Microsoft released Windows 10 Update 1803 and included in that release is the OpenSSH client, which is installed as part of the update.

That’s right an SSH client as part of the Windows operating system by default! Also included with this update is the OpenSSH Server which is included as an Windows Feature on Demand.

Let’s take a look at what this is all made of!

Start off by updating your system to Windows 10, version 1803. You can do this via your normal Windows Update mechanism.

Here you see I have installed Windows 10, version 1803.

Screen Shot 2018 05 16 at 8 07 53 PM

With that, let’s look at what we got in the update! We’ll search our Windows Capabilities (Features)

Cool, so we know OpenSSH is installed, but where? Let’s check out C:\Windows\System32\OpenSSH\

Let’s look a littler closer at the ssh.exe

So this looks like all of the usual suspects in an OpenSSH installation. But it does look like sshd.exe and ssh_config_default came along for the ride during the update even though we didn’t install the OpenSSH.Server Feature!  More on that in my next blog post…

A big shoutout goes out to the PowerShell team for making this happen, check out the project on GitHub. The code is here and the issues and releases are here!

Distributing SSH User Keys via PowerShell

Folks in the Linux world are used to moving SSH keys to and from systems enabling password-less authentication. Let’s take a minute to look at what it takes to use PowerShell to distribute SSH user keys to remote systems.

In the OpenSSH package there’s a command ssh-copy-id which is a bash script that copies a user’s public key to a remote system. There’s a little intelligence in the script to set things up properly on the remote system for password-less key based authentication. If the appropriate directory and key file aren’t set up, ssh-copy-id will create the directory and key file with the correct permissions on remote system. As far as I can tell, ssh-copy-id has not been implemented in the Win32-OpenSSH port. So that leaves us with implementing this functionality ourselves, in PowerShell.

Since ssh-copy-id isn’t implemented on the OpenSSH port for Windows (because it’s a bash script), I wanted to replicate that functionality so that I could easily copy ssh user keys to systems, consistently and easily. So I implemented this functionality as PowerShell. 

Let’s walk though this…and first up, let’s discuss what’s needed for password-less, key based authentication.

The Components of Password-less Key Based Authentication

For password-less key based authentication to work, you need to copy the user’s public key from the local system you want to authenticate from, to the remote system. On the remote system, this key file has to live in a place where the SSH deamon expects it, and that’s in the file ~./ssh/authorized_keys by default.

Let’s take a second to look at the details of how this needs to be configured on a remote system.

  • authorized_keys – this is the default file in which user public keys are stored. The permissions on this file should be 600. Which is read/write for the owner and no access to group or other/world.

-rw-r–r–. 1 demo demo 412 Feb 18 08:53 .ssh/authorized_keys 


  • ~./ssh – the authorized_keys file lives in a hidden directory in your home directory. That’s what that syntax means, the ~ (tilde) is short for the current user’s home directory and that . (dot) indicates that the directory is a hidden directory. Now, the permissions on this directory should be 700, this means it’s it’s read/write/execute to the owner and no access to group or other/world. The execute bit on a directory gives you access to list the contents of the directory and enter that directory.

drwx——. 2 demo  demo         29 Feb 18 08:53 .ssh

It’s kinda like ssh-copy-id, but in PowerShell

First up, I’m assuming that you have SSH remoting already configured, have generated your ssh user key and that you’re on a Windows, Linux/Mac system and you want to copy and SSH user key to a Linux/Mac system. I plan on covering copying keys to Windows systems in an upcoming post. The only real difference between the two is how you set permissions on the .ssh directory and the authorized_keys file. 
 
The first thing that we want to do is to create a PSSession to our host. We’ll reuse this session a few times to execute the required commands on the remote host. This demo user is the user we will want to setup key based authentication for. This session creation will ask for our password. Hopefully this is the last time you have to type it ;)
 

$s New-PSSession -HostName “172.16.94.10” -UserName demo


Then, we’ll read in our public key from our local system into a variable. It’s imperative that you read the public key, id_rsa.pub. The other file, id_rsa is your private key. That needs to stay on the system you want to authenticate from and needs to stay secure.

$key Get-Content -Path ~/.ssh/id_rsa.pub


Next, we’ll want to check to see if the .ssh directory exists in the home directory of our user on the remove system. If not, create the .ssh directory.

Invoke-Command -Session $s -ScriptBlock { If(!(Test-Path -Path ~./ssh)) { New-Item ~/.ssh -ItemType Directory} } 

 
Now, with the directory in place, let’s be sure the permissions are set properly, and that’s 700 in octal notation.
 

Invoke-Command -Session $s -ScriptBlock { chmod 700 ~/.ssh  }  

 
After that, we can copy our key to the remote system’s authorized_keys file. We’ll take advantage of the Out-File cmdlet and use the -Append switch to handle file existence on the remote system and append our key to an existing file or create a new file if it doesn’t exist yet. All that fancy syntax around Invoke-Command is so we can pass a local variable into the Out-File cmdlet over our remoting session.
 

Invoke-Command -Session $s -ScriptBlock { param([string] $key) Out-File -FilePath ~/.ssh/authorized_keys -Append -InputObject $key } -Args $key

 
Now, with the file on the remote system, let’s ensure the permissions are set properly.
 

Invoke-Command -Session $s -ScriptBlock { chmod 600 ~/.ssh/authorized_keys  }

 
..and with that let’s take it for a test run and see if we can open a PSSession without a password using Enter-PSSession
 

PS /Users/demo> Enter-PSSession -HostName server1 -UserName demo
[server1]: PS /home/demo> 

 
Now, there’s a few things I want to point out. This code here is to highlight the needed steps to configure key based authentication. I certainly could (and should) make this code more production ready…but I’ll leave that up to you as the reader. What I really want to highlight here are the steps required for proper key distribution to remote systems, such as directories, files and the required permissions. Oh, if you’re like why don’t you just use ssh-copy-id…fan out remoting. We can use this technique to easily distribute our keys to many systems.

I hope this helps you get an understanding of how key based authentication works, how to configure it and also how to get those keys out to your remote systems!

Speaking at PowerShell Summit 2018!

I’m proud to announce that I will be speaking at PowerShell + DevOps Global Summit 2018 on the conference runs from April 9th 2018 through April 12th 2018. This is an incredible event packed with fantastic content and speakers. Check out the amazing schedule! All the data you need on going is in this excellent brochure right here!

This year I have two sessions!

On Tuesday, April 10th at 2:00PM – I’m presenting “OpenSSH Internals for PowerShell Pros

Here’s the abstract

In PowerShell Core we can use OpenSSH as the transport layer to carry our remoting sessions between our systems. In this session we’ll look at OpenSSH architecture, Authentication methods, including key authentication, sshd configuration, and troubleshooting methods when things go wrong!
  In this session we’ll cover the following: 
                – OpenSSH Architecture
                – Authentication methods
                – Key based authentication
                – sshd Configuration
                – Troubleshooting OpenSSH 

On Wednesday, April 11th at 9:00AM – I’m presenting a workshop with none other than Richard Siddaway on PowerShell Remoting – Installing and troubleshooting in a Multiplatform environment

Here’s the abstract

PowerShell Core is about choice and the transport layer for remoting is one of those choices. In this session we’ll look at remoting in Multiplatform environments, configuring both OpenSSH and WinRM based remoting and how we can leverage remoting to really scale up our administrative capabilities.

I look forward to seeing you there. If you’re on the fence about registering, don’t wait! Click here and do so now. It’s selling out fast!

PowerShell Summit

Warning Handling in dbatools Automation Tasks

So I’ve been using dbatools for automated restore tasks and came across a SQL Server Agent job that I wrote that was reporting success but the job was actually failing.

What I found was the function I used, Restore-DbaDatabase, was not able to access the path that I was trying to restore databases from. The Restore-DbaDatabase function, and all dbatools functions according to the dbatools team on Slack, will throw a Warning rather than an Error by design.

When scheduling PowerShell scripts using dbatools in SQL Server’s Agent, we need use the SQL Agent Subsystem CmdExec so we can load in additional modules.  So we’ll have a SQL Agent job step that looks like this.

SQL Agent Job - cmdexec

 

Now, you see that line “Process exit code of a successful command” and it’s set to 0, we’ll that’s the first thing that I tested. I wanted to see if the warning generated by Restore-DbaDatabase returned a non-zero value…it didn’t it returns 0.  You can check this by checking %ERRORLEVEL% when running the PowerShell script defined in this job step’s command box at the command line.  

These scripts are very small, most only do one thing…restore a database. So I want them to report failure when something goes wrong, so how can we get that warning to cause the SQL Agent job to report failure?

We have to options here

Our first option is to adjust how our session handles warnings, we can do that with 

Doing this will cause the script to stop executing when it hits the warning and then the job will report failure.  

Our next option is to use the -Silent parameter on our Restore-DbaDatabase function call. The -Silent parameter cause the warnings in our script to report as errors. 

Both of these options cause the return value of our CmdExec subsystem’s call to the powershell.exe to return 1…which will cause our Agent job to report failure. This is exactly what I want!

One other thing I tested, both of these options cause the script to stop at the point of the error. When using -Silent, the function returns what it tried to do to standard output. When using $WarningPreference I did not get that output.

Thanks to Friedrich Weinmann and Shawn Melton for helping me sort this all out!

T-SQL Tuesday

Thanks to SQL DBA with A Beard for this event – https://sqldbawithabeard.com/2017/09/05/tsql2sday-94-lets-get-all-posh/

PowerShell Remoting in Multi-Platform Environments – Use Cases

In our previous post we discussed how to implement OpenSSH (the plumbing) as the transport layer for PowerShell remoting. In this post, we’re going to leverage that configuration and look at some common remoting use cases. This is one of the core things I use everyday when I work with PowerShell. Remoting gives me the ability to administer scale up and administer large collections of systems. So like I said in my very first post about my PowerShell journey, it’s become a part of my every day life and techniques like this are at the core of how I use PowerShell. So let’s get started…

We’re going to look at the following

  • Entering a remote command line interface on a server
  • Using sessions
  • Executing commands against one remote system
  • Executing commands on a collection of remote systems

This is going to be awesomeness…Yep, I said awesomeness, when I’m finished you’ll agree that’s about the only way to describe this.

I do want to point out that we’re using Beta software here, things change. The version of PowerShell I’m using here is Version 6 Beta 2.

Remote Command Line Interface

Up first, let’s cover the simplest remoting case, where we use remoting to get a command line interface to a remote system.

Nothing special here, simple syntax, but the seasoned PowerShell remoting pro will notice that we’re using a new parameter here -HostName. Normally on Windows PowerShell you have the -ComputerName parameter. Now, I don’t know exactly why this is different, but perhaps the PowerShell team needed a way to differentiate between OpenSSH and WinRM based remoting. Further, Enter-PSSession now has a new parameter -SSHTransport which at the moment doesn’t seem to do much since remoting cmdlets currently use OpenSSH by default. But if you read the code comments here, it looks like WinRM will be the default and we can use this switch parameter to specify SSH as the transport.

Once we execute this command, you’ll have a command prompt to the system that passed as a parameter to -HostName. The prompt below indicates you’re on a remote system by putting the server name you’re connected to in square brackets then your normal PowerShell prompt. That’s it, you now have a remote shell. Time to get some work done on that server, eh? Want to get out of the session, just type exit.

Using Sessions

So, in PowerShell, when you exit from a remoting session your session goes away. So any work, variables or program state you had will disappear. But what if we wanted to keep our session’s state, log out and log back into that session again? We can leverage sessions to help us persist our remote sessions. We can create a session connect and disconnect from it at will. So let’s check that out.

We create a new session by calling New-PSSession. This will start up the remoting session just like we did with Enter-PSSession, via SSH, but we won’t attach to the remote terminal. The output we do get from New-PSSession shows us the details of the session created. We use Get-PSSession to get a list of all current sessions.

We can connect to an existing session with Enter-PSSession. If there are multiple entries in your session list…just use the correct Id from the session list to identify the session you want to connect to.
Now, when you exit from this session with the exit command, your session will persist. Let’s use Get-PSSession to see.
Cool, our session is still there, let’s reuse it. This time we’re going to assign it to a variable this time. This will keep our command line syntax simple in the upcoming examples.

Executing Commands Against One Remote System

We can use PowerShell remoting to execute a command against a remote system, so let’s look at the simplest case…just one command. Here you can see, we’re using the Invoke-Command cmdlet to execute the Get-Process command on the remote system and it’s output returns to our console. Here we have the top 5 processes by CPU on the remote system.

Executing Commands Against a Collection of Remote Systems

Now, let’s add one more session to our list of sessions. With a new session to server2.
New-PSSession just returns the session created, so let’s get a list of all of the sessions with Get-PSSession. There you can see our two remoting sessions are currently opened the new session has a new Id.
This time, let’s take both our sessions and save them to a variable. We’re going to reuse $s.
Now to the amazing part…let’s run a command against a collection of remote systems.
This example brings up a very interesting point in PowerShell remoting, everything inside the curly braces of the Invoke-Command call happens on the remote system. This means, all the sorting and processing is remote, the remote systems deal with all the computational aspects and less data has to traverse the network. There’s a deeper topic of serialized objects we’ll cover in a later post. Now the output from these systems comes back to your console as fast as it comes back, so there’s really no order here. So you might get a list of data that’s all commingled. But we can control that by sorting locally. Let’s look at that.
Now, let’s say you want to get the top 5 processes across all the systems in your sessions list, easy enough.

We move the sorting to the pipeline on our local system, notice the Invoke-Command call is going to return the entire process list from all machines, then it will sort the data locally and output to the local console. So you can see in this list here we have the top 5 processes across our two systems. Imagine you had a web farm of servers and you needed to chase down a bad process fast, this would be useful, right?

When we’re all finished, you’ll want to clean up your sessions. We can do that a by passing the $s variable into Remove-PSSession

And that’s it, so like I said in my very first post about my PowerShell journey, it’s become a part of my every day life and techniques like this are at the core of how I use PowerShell.

PowerShell Remoting in Multi-Platform Environments using OpenSSH

So in my last post I told you about how I started my journey on learning PowerShell, let’s keep going down that path together. In this post I’m going to introduce PowerShell Remoting in Multi-Platform Environments, specifically using OpenSSH. We’ll discuss WinRM in multi-platform systems in an upcoming post.

Have you ever had to execute a command against one system or a collection of systems? Have you ever wanted a remote shell on a Windows system? Using Remoting you can you can do all of these things, very, very easily.

The Plumbing

So for our first stop, let’s talk about how remoting works. Essentially what’s occurring under the hood is a PowerShell process on one system is sending commands to a PowerShell process on another system then the remote system sends the output back. Easy enough, right? Let’s dig into to how it exchanges information.

The PowerShell processes exchange messaged defined in the PowerShell Remoting Protocol (PSRP). PSRP defines semantics of the communication and types of message being exchanged. Now these messages need a transport layer, for that we have WinRM and OpenSSH. Let’s look at both.

By default, Windows PowerShell systems Remoting connections communicate using WinRM which uses HTTP/S endpoints. WinRM is an implementation of the WS-Management industry standard. WS-Man defines the semantics of the interactions between the systems and data transfer. PowerShell encapsulates its PSRP messages and uses WinRM to transport them between systems.

On Linux systems, well…they don’t communicate with WinRM, by default, so we need something else…that’s where OpenSSH comes in. PowerShell encapsulates it’s inputs and outputs as PSRP messages and it uses SSH to securely exchange the messages between systems.

The PowerShell team has implemented WinRM over HTTP remoting on Linux and already has a port of OpenSSH on Windows. The key idea going forward is…we will have a choice, we can use WinRM (HTTPS) or we can use SSH regardless of OS. For the rest of this post, we’re going to talk remoting over OpenSSH, even on the Windows side of things. We’ll discuss WinRM in multi-platform systems in an upcoming post.

The Installation

For starters, go ahead and install PowerShell Core your systems if you haven’t already, its pretty straightforward check out this link here.

Next, on Windows we need to install OpenSSH and the PowerShell team has developed a Win32 port of OpenSSH. So go check that out here. I’m going to be honest, the installation isn’t easy. But I’m going to let you in on a secret, Darwin Savoy wrote a killer Chocolatey package that does the hard work for you. Check that out here. You’ll want to use the following syntax to install OpenSSH as a service.

If you’re on Windows verify OpenSSH is up and running

Now on Linux, just about every distribution includes an OpenSSH installation their default setup…so we’re not going to cover that here.

The Configuration

Wether it’s Windows or Linux, we need to tell OpenSSH about PowerShell and we can do that with a subsystem configuration.

On a Windows system we’ll need a line like this in SSH daemon configuration file C:\Program Files\OpenSSH\sshd_config. Find the subsystem section and add this line.

On a Linux system we’ll need a line like this one in /etc/ssh/sshd_config. Find the subsystem section and add this line.

Basically what’s going on here is we’re telling OpenSSH to invoke a PowerShell process when it receives a message from a remote system that’s says it’s going to use the PowerShell subsystem. So SSH is just the conduit for these two PowerShell processes to communicate their inputs and outputs.

When you’re finished editing these files, you’ll want to restart the SSH daemons on your system…Windows or Linux.

On Windows that’s Restart-Service -name sshd on Linux that’s systemctl restart sshd

Now here’s the thing…before you move on…test your SSH connections. You will absolutely go crazy if there’s an issue with your SSH configuration and you try using PowerShell Remoting right away. If there’s an issue, PowerShell will happily swallow OpenSSH’s errors and you’ll get no feedback. Simply grab your favorite SSH client and try to connect to the systems right now and verify you can connect and get a command line. Things will be a lot easier for you before you try to use remoting.

Up next in this series we’ll look at some remoting use cases, specifically using a command line interface, executing commands against remote a remote system and executing commands against a collection of remote systems.

Why PowerShell?

Why do I use PowerShell?

Well, here’s a little back story…last year I was involved in a Pluralsight Play by Play with Jason Helmick and Jeffrey Snover for launch of Open PowerShell on Linux and Mac. Before this video, I didn’t take PowerShell seriously. Basically, if I Google’d a problem and found a solution in PowerShell I would grind my teeth and copy and paste the text into the foreign blue console and cross my fingers.

Fast forward a bit to PowerShell Summit this year, Jason and I were slated to do a session together on…PowerShell on Linux. I had to miss the trip to Seattle this year, but during the session Jason told a story a story about me learning PowerShell…check it out here around 28:27. Its pretty funny. 

Pipelines similar but different

If you don’t want to listen to Jason’s story, it goes like this. I needed to learn PowerShell…FAST. I had only a few weeks to build my skills enough so that I could sit at a table with the inventor of PowerShell and an industry recognized expert and have a meaningful conversation and oh yea, record a 5 hour training video. So as Jason says I “did the Don Jones/Jeff Hicks thing” (there’s a newer version available now) .

Well, having a UNIX background I understood the concepts of a pipeline. UNIX processes have had pipelines for a long time. Byte streams can move data from one command to the next allowing you to build more complicated commands. PowerShell can do the same, but it moves objects…rather than text/byte streams. 

Well, while learning PowerShell I built a PowerShell cmdlet pipeline to get the top 10 processes on a system sorted by CPU.

And to do the same in bash, we need to do something like this…

So, I worked through these examples and I fired up my email client and sent an email to Jason and said hey Jason…here’s two commands that do the same thing. One in PowerShell and one in native bash commands. I asked…hey, which one do you think I like better? 

As we learned in the PowerShell Summit video, he expected me to answer with my crotchety, suspenders wearing UNIX guy answer…well he was in for a surprise. I told him I liked the first one better…the PowerShell version.

I actually don't own suspenders...neckbeards are another story

Now hear me out, I’ve been using Linux/UNIX since 1997, I manage large internet commerce sites through the holiday season, I’ve done PhD level research on topics like IO, CPU scheduling and memory management…literally my fingers can type the bash commands to get the top 10 processes without even thinking…muscle memory to the max. BUT, the PowerShell version of this literally reads like a sentence. Get-Process, Sort-Object, Select-Object, pretty straight forward stuff here. No surprises. the commands do exactly what they say. This means, I can put stuff like this in a script, and other people can read it without 20 years of experience. 

What’s next?

Well, since the Play By Play, PowerShell isn’t the Google the answer…copy/paste solution anymore for me…I’ve decided to really take this seriously and PowerShell is now a go to tool in my toolbox. I’m not telling you this because I’m a Microsoft MVP, I’m not telling you this because I did a video with THE PowerShell gurus…I’m telling you this because I really use PowerShell now…every day.

This post is the first post in a series I plan on bring to you that will document my discovery process of using PowerShell on Linux. We’ll discuss the techniques and technologies I use to solve some real world problems in a multi-platform world!

Now, there’s two things I really consider special about my first go with PowerShell…asynchronous job posting via Remoting and Desired State Configuration (DSC). We’ll cover these topics in this series.