Most Windows administrators have at least dabbled with PowerShell to get started on their automation journey, but for more advanced practices, it helps to attend a conference, such as the PowerShell Summit.
For the second straight year, I attended the PowerShell + DevOps Global Summit in Bellevue, Wash., earlier this year. As an avid PowerShell user and evangelist, I greatly enjoy being around fellow community members to talk shop about how we use PowerShell in our jobs as well as catch the deep dive sessions.
This year was a bit different for me as I also presented a session, “Completely Automate Managing Windows Software … Forever,” to explain how I use Chocolatey with PowerShell to automate the deployment of third-party software in my full-time position.
There’s a lot of value in the sessions at PowerShell Summit. Administrators and developers who rely on PowerShell get a chance to learn something new and build their skill set. The videos from the sessions are on YouTube, but if you don’t attend in person you will miss out on the impromptu hallway discussions. These gatherings can be a great way to meet a lot of veteran IT professionals, community leads and even PowerShell team members. Jeffrey Snover, the inventor of PowerShell, was also in attendance.
In this article, I will cover my experiences at this year’s PowerShell Summit and some of the lessons learned during the week.
AWS Serverless Computing
Serverless computing is a very hot topic for many organizations that want to cut costs and reduce the work it takes to support a Windows deployment. With serverless computing, there is no need to manage a Windows Server machine and all its requisite setup and maintenance work. You can use an API to run PowerShell, and it will scale automatically.
Andrew Pearce, a senior systems development engineer at AWS, presented a session entitled “Unleash Your PowerShell With AWS Lambda and Serverless Computing.” Pearce’s talk covered how to use Amazon’s event-drive computing with PowerShell Core.
I have not tried any sort of serverless computing, but it didn’t take much to see its potential and advantages during the demonstration. Pearce explained that a PowerShell function can run from an event, such as when an image is placed in an AWS Simple Storage Service bucket, to convert the image to multiple resolutions depending on the organization’s need. Another possibility is to run a PowerShell function in response to an IoT event, such as someone ringing a doorbell.
Simple Hierarchy in PowerShell
Simple Hierarchy in PowerShell (SHiPS) is an area in PowerShell that looks interesting, but one that I have not had much experience with. The concepts of SHiPs is similar to traversing a file system in PowerShell; a SHiPs provider can create a provider that looks like a hierarchical file system.
Providers have been a part of PowerShell since version 1.0 and give access to data and components not easily reached from the command line, such as the Windows certificate store. One common example is the PowerCLI data store provider to let users to access a data store in vSphere.
You can see what providers you have on a system with the Get-PSProvider command.
Another familiar use of a PowerShell provider is the Windows registry, which PowerShell can navigate like a traditional file system.
Glenn Sarti of Puppet gave a session entitled “How to Become a SHiPS Wright – Building With SHiPS.” Attempting to write your own provider from scratch is a complex undertaking that ordinarily requires advanced programming skill and familiarity with the PowerShell software development kit. SHiPs attempts to bypass this complexity and make provider development easier by writing provider code in PowerShell. Sarti explained that SHiPs reduces the amount of code to write a module from thousands of lines to less than 20 in some instances.
In his session, Sarti showed how to use SHiPs to create an example provider using the PowerShell Summit agenda and speakers as data. After watching this session, it sparked an idea to create a provider for a Chocolatey repository as if it were a file system.
PowerShell Remoting Internals
In this deep dive session, Paul Higinbotham, a member of the PowerShell team, covered how PowerShell remoting works. Higinbotham explained PowerShell’s five different transports to remoting, or protocols, it can use to run remote commands on another system.
In Windows, the most popular is WinRM since PowerShell is most often used on Windows. For PowerShell Core, OpenSSH is the best option for cross-platform use since both Windows and Linux. The advantage here is you can run PowerShell Core scripts from Windows to Linux and vice versa. Since I work in a mostly Linux environment, using Secure Shell (SSH) and PowerShell together makes a lot of sense.
This session taught me about the existence of interprocess communication remoting in PowerShell Core. This is accomplished with the command Enter-PSHostProcess and the main perk being the ability to debug scripts on a remote system from your local machine.
Toward the end of the presentation, Higinbotham shared a great diagram of the remoting architecture and goes over what each component does during a remoting session.
Go to Original Article