PowerShell.org https://powershell.org Thu, 25 Aug 2016 18:17:30 +0000 en-US hourly 1 https://wordpress.org/?v=4.6 Here's Another Reason to Contribute https://powershell.org/2016/08/24/heres-another-reason-to-contribute/ https://powershell.org/2016/08/24/heres-another-reason-to-contribute/#respond Wed, 24 Aug 2016 11:30:14 +0000 https://powershell.org/?p=51732

Related posts:

  1. Your Weekend Games Report
  2. As Event 3 gets underway, here are some Event 2 stats...
  3. DSC: Must-Have or Just Nice-To-Have?
Jason Helmick and I were talking last night, and we got onto the topic of expertise and respect. Kind of, "once someone really gets to that expert level, and they surpass their teacher in knowledge, you really respect them." I disagreed, and said, "no, I respect them the minute they start contributing to the world, and helping others."

We all, at some stage, get "outsider syndrome," where we think everyone else is so much smarter than us, that we've nothing of value to contribute. But that's never true. First of all, there's this thing called a "birth rate," meaning there's always new people coming into the field. Second, no matter what your level of expertise, you're in it, right then. "Experts" too often forget what it was like to be a beginner; a beginner knows, and can often relate things that another beginner can understand more readily.

Take this wonderful post by Missy Januszco. Missy probably doesn't consider herself an expert, although she certainly held her own at my recent DevOps Camp. And she certainly wasn't the only one writing about open-source, cross-platform PowerShell Core that week. But she did it from a unique perspective, one that a lot of her readers can probably take a lot from. And she did it - instead of just talking vaguely about giving back someday, she just did, and did it well.

PowerShell.org isn't a curated newsfeed for a select few; its yours. So if you don't have your own place to publish and share, email webmaster@ and let us set you up to write. Whenever you solve some problem, conquer some gotcha, or have a perspective on the latest PowerShell news, share. You definitely have something to offer.

https://powershell.org/2016/08/24/heres-another-reason-to-contribute/feed/ 0
Microsoft did WHAT? https://powershell.org/2016/08/23/microsoft-did-what/ https://powershell.org/2016/08/23/microsoft-did-what/#comments Tue, 23 Aug 2016 01:51:05 +0000 https://powershell.org/?p=51548

Related posts:

  1. PowerShell is Open Sourced
  2. Big show coming this Thursday!
  3. Philadelphia Meeting - May 7th 2015
Unless you’ve been living under a rock for the last couple of days, you already know that Microsoft announced last Thursday that the shell/scripting language formerly known as “Windows Powershell” is now supported on Linux and MacOS and that Powershell has been open-sourced. And for days, thoughts of “how can I use this?” or “I wonder if ‘x’ will be supported” have been flying through the minds of every system architect as we internally grapple with the possibilities of what could be, while at the same time trying to understand Microsoft’s motivation for this radical change.

Only the change isn’t so surprising if you think about the changes that Microsoft has been making leading up to this announcement. Separating Powershell Desktop Edition and Core Edition in WMF 5.1. Announcing SQL Server on Linux – after all, IT professionals are going to need a way to administer that SQL instance and it isn’t going to be through a GUI. Supporting Powershell on Linux seemed like a logical next step.

But it is likely just a step along the road to heterogeneous system management. Microsoft Technical Fellow and Powershell inventor Jeffrey Snover isn’t at all secretive over the fact that the vision is built upon Microsoft’s Operations Management Suite (OMS), a suite of automation and management tools that needs to be able to configure, control, manage, monitor, and self-heal a workload that runs anywhere and on any operating system.

From the perspective of a system architect that isn’t typically on the bleeding edge of technology, I am still extremely excited over this announcement. Why? The possibilities seem endless. For one, applications that run on either Windows or Linux or a combination of the two can now be configured by the same language, or maybe even the same set of well-designed scripts. Second, the possibility of using Desired State Configuration (DSC), or third-party tooling such as Chef or Puppet in conjunction with DSC, means I can keep *all* servers in compliance with their configurations using the same tooling. Third, what Devops engineer wouldn’t love having spent a few years learning a scripting language like Powershell only to have its reach extended to other platforms? This change invariably makes us more valuable to the company by being able to take on additional management responsibilities by using the skills we already have. It can then lead to even more cross-platform learnings and opportunities. I definitely plan to learn more about Linux and how I can help build cross-platform tools. If you have similar interests, here are some great resources to get you started!



I haven’t even scratched the surface of thinking about all of the ways I want to take advantage of Powershell on Linux, and I have lots of exploring to do to find out what can or can’t be done – but the energy of the entire Powershell community over these changes certainly carries over to me as well. I’m excited to find out what is possible, to build what may not have been possible, and to contribute back to the Powershell community. So kudos to you, “new Microsoft”, for energizing the entire community of Powershell enthusiasts. I can’t wait to see what’s next.

https://powershell.org/2016/08/23/microsoft-did-what/feed/ 2
Why "Objects," Remoting, and Consistency are Such a Big Deal in PowerShell https://powershell.org/2016/08/22/why-objects-remoting-and-consistency-are-such-a-big-deal-in-powershell/ https://powershell.org/2016/08/22/why-objects-remoting-and-consistency-are-such-a-big-deal-in-powershell/#comments Mon, 22 Aug 2016 20:39:49 +0000 https://powershell.org/?p=51512

Related posts:

  1. PowerShell is Open Sourced
  2. FAQ: PowerShell on Linux/Mac
  3. Why Remoting vs. SSH Isn't Even a Thing
As PowerShell begins to move into a cross-platform world, it's important to really understand "why PowerShell." What is it, exactly, that sets PowerShell apart? Notice that I do not mean, "what makes it better," because "better" is something you'll have to decide on your own. I just want to look at what makes it different. 

It's the Objects

Folks often say that Linux is a text-based OS, whereas Windows is an object-based OS. That's a convenient simplification, but it isn't exactly accurate. And to understand why PowerShell is different, you need to understand the actual differences - and how Linux and Windows have actually come closer together over the years.

*nix - including Unix, macOS, and Linux - is based on very old concepts. "Old" isn't "bad" at all; much of Linux' current flexibility comes from these old concepts. Core to the Unix ethos is the fact that OS configurations come from text files. There's no Registry, there's no database, it's just text files. Kinda like, um, Windows was, back in the old days, with .ini files (and where do you think the idea for those came from). Text files are super-easy to view, search, modify, and so on. Heck, when I wrote my first Point of Sale system, it was largely text-based, because text files were super-easy for us to troubleshoot remotely, compared to a complex ISAM table structure.

Windows, on the other hand, is an API-based operating system. When you want to query an OS configuration element, you don't just look in a text file - you run code, and query an API. When you need to make a change, you don't just change a text file and hup a daemon - you run code, and submit your changes to an API.

When you need to pass data from one hunk of code to another, you need to have an agreed-upon structure for that data, so that the code on both ends understands the data. These structures are called objects. Traditionally, Unix didn't really have structured data. The file format used by Apache for its configuration was different from the format used by Iptables. Which is totally fine, by the way, because those two things never need to talk to each other. But when you start considering all the things the OS can do - users, file permissions, groups, ports, you name it - you started to end up with a lot of different formats. Indeed, the main reason that Unix had (has?) a reputation for being a complex OS to administer is largely because all of its data is scattered hither and yon, and all in different formats.

That's been changing, though. You're starting to see more and more new projects pop up that rely on structured configuration data, often using JavaScript Object Notation (JSON), although in other cases something like XML. This is a big deal for *nix administration. Why?

Traditionally, re-using the output of a Unix command was complex. Output was pure text, sent to your console via the stdout "channel." Commands typically formatted their output for human eyeball consumption, so if you wanted to send that output instead to another command, you had to do a lot of text parsing. "Skip the first two rows of output, and then for each remaining row, go over 32 columns and grab 5 columns worth of text." Or, "skip the first row, and then in each subsequent row, look for text matching this [regex] and return only the matching text." Unix admins tend to own regular expressions for this reason.

But the problem with all that is that your workflow, and your tooling, becomes very version-bound. Nobody can ever improve tools like ps, because so many scripts rely on the output being exactly as it is today. Instead, you create entire new versions of those tools - which people then take dependencies on, and which can then never change, unless they provide some backward-compatibility switches to force old-version output. The end result is a highly fragmented landscape of tooling, a very high learning curve for incoming administrators, and a high amount of overhead in automating business processes.

When you code a command-line utility in 1973, it's easy to imagine it'll never need to change. On the other hand, when you start building APIs in the 1990s, it's much more obvious that change will be constant. By passing objects - structured data - between themselves, APIs provide a kind of inbuilt forward-compatibility. If v1 of an API outputs objects that have 10 properties, v2 can easily add five more without breaking anything downstream. Anything consuming those objects won't care if there's extra data, so long as the data it was expecting is all there. Object-based data doesn't have any sense of "ordering," so it doesn't matter if the "first" property is Name or if the "first" property is Size. Consumers refer to properties by name, not by position, and the magic of the API itself makes it all match up.

Objects also lend themselves to hierarchies of data. A computer object can have a Drives property, which can be a collection of Drive objects, which can have a Files property, which is a collection of File objects, and so on. Structured data like XML and JSON handle these hierarchies with ease, as do object-oriented APIs; textual output - which is essentially a flat-file at best - doesn't.

So what sets PowerShell apart from other shells is the fact that its commands pass objects from one to another. When you reach the end of a "chain," or pipeline, of commands, the shell takes what's left and generates textual output suitable for human eyeball consumption. So you get the advantages of a text-based command - easy to read output - and the advantages of working with an API. For example, in PowerShell for Linux, Microsoft ships a command that wraps around the Cron feature. Cron is configured from a text file; Microsoft's command "understands" the text file format, and turns it into objects. That means nobody will ever have to grep/sed/awk that text file again - instead, you can deal with structured data. That's a really good example of taking something PowerShell is good at - objects - and applying it to something Linux is really good at - Cron. It's not forcing Cron to look like the Windows Task Scheduler in any way; it's simply applying a new shell paradigm to an already-solid OS component.

This concept of a shell passing objects - again, just structured data - was unique enough that Microsoft was granted a patent for it (the patent also includes other innovations).



The parent also touches on remoting, which was equally innovative. Yes, I know that Unix has forever had the ability to log into a remote machine, first using things like Telnet, later SSH, and even later still more things. But that's remote logon, and it's not Remoting.

With remote logon, you're essentially turning your local computer into a dumb terminal for a remote computer, a concept literally as old as computers themselves. It's a 1:1 connection, and it was fine when a given company didn't have more than a few machines. But modern, cloud-based architecture involves thousands of machines, and 1:1 doesn't cut it. Remoting enables 1:many connections - "here is a command; go tell these 1200 computers to run it individually, using their own local resources, and then send me the results - as objects." Going forward, PowerShell can use either WS-MAN or SSH as the low-level transport for that conversation, but the protocol isn't important. It's the idea of running one command locally, piping that output to another command which runs remotely, and then taking that output and piping it to yet more commands that run locally. This mixing-and-matching of computing resources and runtime locations is huge. 



And finally, the one argument that's the toughest to make. Plenty of *nix admins, and plenty of old-school MS-DOS command-line admins, take great pride in their mastery of obscure command-line syntax. It sets them apart from lesser humans, provides a veneer of job security, and proves their dominance of their field.

Unfortunately, it's bad for the planet.

Look, maybe your country is in fine economic shape (ahem, Norway), but here in the United States we have a fairly precarious hold on Biggest Economy in the World. We aren't a manufacturing powerhouse. We basically have two experts: information technology and Hollywood, and we're sometimes sorry about the latter. But for our economy to thrive in this century, we need all hands on deck when it comes to IT. That means a high barrier of entry, and the need to memorize arbitrary and obscure syntax, ain't gonna cut it. Computing is hard enough without making it artificially more obscure through syntax.

chmod ugo+rwx sample.sh

Yeah, see, that's too hard to teach a 12-year-old.

Set-FilePermission -FileName sample.sh -Permissions Read,Write,Execute -Principal User,Group,Others -Action Add

See, you still need to know what's going on in both cases, but the syntax is much easier to read and understand without having to look it up. The command syntax becomes less obscure, and more self-documenting. More maintainable. Obviously, this is just a bogus example, but it illustrates the pattern of PowerShell - meaningful command names, meaningful parameter names, and meaningful parameter value enumerations. And I use meaningful in the correct way, as in, "full of meaning."

PowerShell still allows for a shorthand syntax, if you're just in a hurry -

sfp sample.sh -p r,w,x -for u,g,o -a add

- but you're not forced into it, and it's easier to figure out what those things mean (again, this is a bogus example meant to show the shell's syntax pattern, not an actual run-able command).

So... that's the big deal

And so that's what makes PowerShell different. It's not going to obviate Bash on Linux anytime soon, although it's happy to let you run your same old text-based commands, and even integrate their output as best it can into its object-based pipeline. But at least now, anyone approaching PowerShell for the first time can understand what makes it different, and decide for themselves if they think that's worth an investment to learn to use PowerShell well.

https://powershell.org/2016/08/22/why-objects-remoting-and-consistency-are-such-a-big-deal-in-powershell/feed/ 1
Create Custom Monitors with PowerShell https://powershell.org/2016/08/21/create-custom-monitors-with-powershell/ https://powershell.org/2016/08/21/create-custom-monitors-with-powershell/#comments Sun, 21 Aug 2016 23:44:53 +0000 https://powershell.org/?p=51381

Related posts:

  1. Working with the WSUS API and the SUSDB Database using PowerShell
  2. Summit Session Change
  3. Microsoft Publishes DSC Resource Kit in GitHub
Sometimes, as a developer, you want to be be able to keep track of free space on a drive, the size of a log, the load on your CPU, the number of users logged in, etc. With PowerShell, it is typically just a matter of finding the right cmdlet amidst the large (and rapidly growing) pool of cmdlets provided by Microsoft and by third parties. Then you just run Get-Foo to check details about the foo resource. And then you come back 5 minutes later and run it again because you want to see how it changes over time.

But wouldn't it be nice if you could just have it run automatically at regular intervals in a separate window that you could just keep in the corner of your screen? Well, I found the barebones of just such a utility sometime ago (authored by Marc van Orsouw,  aka ‘thePowerShellGuy’). His original post is no longer available, but I expanded upon his code and, over time, added features, bug fixes, and enhancements, making it more useful and more user-friendly. Here are a few screenshots of the Monitor Factory in action.

Monitor the size of a database

Start-Monitor -AsJob {
    Invoke-Sqlcmd 'DBCC SQLPERF(logspace)' |
    Select-Object 'Database Name','Log Size (MB)','Log Space Used (%)',HasErrors

Database Size Monitor

Monitor drives on a system
Drive Capacity Monitor

Monitor longest running DB queries
Long-runnning DB Query Monitor

Build Your Own Resource Monitor in a Jiffy reveals how quick and easy it is to get started with the Monitor Factory.

https://powershell.org/2016/08/21/create-custom-monitors-with-powershell/feed/ 1
Episode 316 - PowerScripting Podcast - Jeffrey Snover from Microsoft on Open Sourced PowerShell v6 https://powershell.org/2016/08/19/episode-316-powerscripting-podcast-jeffrey-snover-from-microsoft-on-open-sourced-powershell-v6/ https://powershell.org/2016/08/19/episode-316-powerscripting-podcast-jeffrey-snover-from-microsoft-on-open-sourced-powershell-v6/#comments Fri, 19 Aug 2016 21:54:51 +0000 https://powershell.org/?p=51253

Related posts:

  1. Episode 306 - PowerScripting Podcast - Rob “Barkz” Barker from Pure Storage
  2. Episode 312 - PowerScripting Podcast - SQL MVP Chrissy LeMaire
  3. Episode 314 - PowerScripting Podcast - Matt Davis from Red Hat on Ansible

In This Episode

Tonight on the PowerScripting Podcast, Jeffrey Snover from Microsoft on open source PowerShell


Slack Chatroom




Chatroom Highlights

<jaykul> ## What about ARM?

<jcotton> is ## for questions?

<gavin> ## @halr9000 did you find a goat to come on the show as a special guest?

<jcotton> ## jsnover needs more edge in his life

<jaykul> ## PowerShell is dating bikers.

<sqlvariant> ##Jeffrey, where were y'all hiding Ken Van Hyning all these years?

<itadder> ##jeffrey where did you get inspired to bulid powershell?

<halr9000> ok, if you have q’s, then as sqlvariant has shown, please add ## to the front!

<jaykul> ## Is that all?

<jaykul> ## ARM support?

<jaykul> ## SSHRM

<jcotton> ## remember OneGet and the legal team? :stuck_out_tongue:

<jcotton> juneb: prefix questions w/ ##

<juneb> ## Please tell us more about the governance model.

<itadder> ## how did legal allow MIT license?

<pscookiemonster> ## Were there lessons learned working with legal/folks unfamiliar with OSS?  I know Chef offers a webinar for legal folks, it seems like it would be helpful for large orgs like Microsoft to help sell and teach this

<juneb> ## Will the roles of team members change?

<jaykul> ## How can I get paid to work on open source powershell? 😛

<jaykul> ## I second Rich's question: what's with the release timing?

<juneb> ## When will core help be open-sourced?

<jaykul> ## wait, is that why CIM?

<kilasuit> ## Can we get an explaination on the Powershell RFC Process for changes ##

<jcotton> ## since we're now taking comments, is the team aware that some nuget packages (like Microsoft.Management.Infrastrucutre) are missing XML doc files?

<ngetchell> ## For bugs should we still use uservoice, connect, or github issues now?

<FoxDeploy-Stephe> ### We noticed version 6 on PowerShell for Linux, when can we expect ver 6 on Winders ###

<beefarino> ### is there any PowerShell features that don't work in PS Core?

<powerschill> ## For Linux services would you expect to use Get-Services or a new cmdlet like Get-LinuxServices?

<sqlvariant> ##This is why we need Out-DataTable to be in PowerShell core!!  :slightly_smiling_face:

<texmandie> ## when might we see remoting to Azure/Office 365 tenants from Mac/Linux?

<itadder> ## will powershell run hurd

<FoxDeploy-Stephe> ###I need mah winforms in Linux, can we get System.Windows.Forms ports to linux plz

<jcotton> ## my thing about XML doc files

<jaykul> ## yeah but what about rasbian

<gavin> ## Raspbian!

<bitzbyte> ## Yes, it was around Raspbian/linux

<gavin> ## NEED ARM!

<jcotton> ## need xml doc files in all the nuget pkgs

<richprescott> ## Sooooo, how do I get PowerShell on my Chromebook?

<juneb> ## Do we use UserVoice or GitHub issues?

<beefarino> ## will we be able to organize assets in our modules for different platforms?  or will module authors be required to manage that on their own?

<bladefirelight> ### will script block loging work with syslog?

<sqlvariant> ## Well SQL Server is on Linux so they have a business case :champagne:

<jim> ## will we be able to organize assets in our modules for different platforms?  or will module authors be required to manage that on their own?

<richprescott> ## what is next for Snover and team?  e.g. Drawbridge, rewriting kernel, on-premise DSC mgmt system

<beefarino> ## e.g., right now I have to manually load 32 or 64 bit native dlls in my modules; will I need to manually load linux vs windows as well?

<dougfinke> ## any thoughts on deeper PS integration with Python etc, beyond strings?

<itadder> ## will get a restapi  for AD, and will we get Join domains cmdlets for powershell on mac

<dagryph> ## OOH. DSC using powershell on linux, instead of the separate DSC package???

<JasonMilczek> ##Have there been any advancements in DSC on Linux?

<kilasuit> ## DSC will we see a revamp of the DSC for linux to kill off python ##

<JasonMilczek> ##Are you aware of any other vendors writing psmodules for Linux right now?

<richprescott> ##Snover, was PSDirect one of the drivers for PSnix?  Being able to manage Win/Nix on Nano server Hyper-V with one language

<JasonMilczek> ##or MAC?

<itadder> ## will we see modules to manage bind9 or dhcpd or other services or MYSQL?

<JasonMilczek> ##Forgive me if this was already answered, but can we now powershell remote to Linux?

<itadder> ## do we require !#/usr/local/bash

<organicit> ## will there ever be a means to #! powershell in a script

<itadder> ## what about text enconding

<dougfinke> ## what can we expect in the next 6, 12 months

<jim> ## Yes, upcoming roadmap??

<itadder> ## what about an update to the conhost terminal in windows ? Will it support more then 256 colour?

<richprescott> ## ONE MORE!  What's next for Snover and team?

<sqlvariant> ##Ask about Ken Van Hyning (SQL Tools team) where were they hiding him?!?!

<Vern_Anderson> ## What question is he up to? One thing on an island?

<Vern_Anderson> ## Oh you guys don't ask the last question any more?

<FoxDeploy-Stephe> ###Whats next, will they take DIR away from us?

<richprescott> ## As of PS5+, does Write-Host write to stream or no?

<FoxDeploy-Stephe> ###Found it

<jasonmorgan> ## Is the redirect operator modified in linux or does it behave as per normal?

<bitzbyte> ## Wouldn't this be the role of .NET Standard??

<<@UNJM7|jonwalz>> jonwalz uploaded a file: Pasted image at 2016-08-18, 8:51 PM https://powershell.slack.com/files/jonwalz/F22RNF6UQ/pasted_image_at_2016_08_18_08_51_pm.png and commented: Anyone else seeing PowerShell as the top trending topic on Facebook?

<halr9000> https://github.com/PowerShell/PowerShell/blob/master/docs/community/governance.md

<jaykul> https://github.com/PowerShell/PowerShell/tree/master/src/Microsoft.Management.Infrastructure.CimCmdlets

<juneb> Governance model: https://github.com/PowerShell/PowerShell/blob/master/docs/community/governance.md

<beefarino> btw PowerShell going open source is trending on facebook 🙂  https://www.facebook.com/topic/Windows-Powershell/109314949087498?source=whfrt&position=2&trqid=6320345599904818250

<itadder> @foxde https://github.com/PowerShell/PowerShell/blob/master/docs/installation/windows.md#msi

<<@UPLLB|halr9000>> halr9000 uploaded a file: Untitled https://powershell.slack.com/files/halr9000/F22S025RC/-.pl

<gavin> https://www.reddit.com/r/PowerShell/comments/4yb5yb/who_is_the_mystery_guest_tonight_and_what_might/d6mgixw

<halr9000> https://stedolan.github.io/jq/

<FoxDeploy-Stephe> @whatevergeek https://developer.microsoft.com/en-us/windows/iot/getstarted

<pscookiemonster> I liked this thread in hacker news: https://news.ycombinator.com/item?id=12314653 - nice demonstration of why, even if you *can* use text, you might prefer objects

<ebekker> Linus actually is cool with systemd:  https://linux.slashdot.org/story/15/06/30/0058243/interviews-linus-torvalds-answers-your-question

<jaykul> https://gist.github.com/Jaykul/15a6982aad9b6197a537f1ce5a786723

<kilasuit> regarding Aliases there is an open issue here at  https://github.com/PowerShell/PowerShell/issues/929

<jcotton> here's the PR @jsnover mentioned https://github.com/PowerShell/PowerShell/pull/1901

<kilasuit> I've suggested this as a resolution https://github.com/PowerShell/PowerShell/issues/929#issuecomment-239697927

<powershellnerd> ARM!!! https://media.giphy.com/media/HJN39I1q6EBKE/giphy.gif

<r_keith_hill> @itadder the hard part is that other than ASP.NET http://ASP.NET Core there is no presentation stack for .NET Core.  VSCode gets a pass because it uses Electron / Chromium / Html / JS

<ebekker> http://electron.atom.io/apps/

<ebekker> And you can actually write Electron using C#:  https://github.com/kexplo/electron-edge

<juneb> https://youtu.be/2WZwv7TxqZ0

<dougfinke> possible alternate to ogv, don't know if works on the new stuff yet https://github.com/dfinke/PowerShellSlackathon/tree/master/ExportDataTable

<r_keith_hill> http://redhatloves.net/

<kilasuit> also https://github.com/Pash-Project/Pash/issues/429

<ebekker> Is .ps a TLD?  RedHat should get RedHatLoves.ps http://RedHatLoves.ps

<ebekker> First book should be written in the open on https://www.gitbook.com/

<jaykul> https://github.com/PowerShell/PowerShell/issues/1103

<jaykul> https://github.com/PowerShell/PowerShell/issues/1390

<organicit> https://cloud.google.com/tools/powershell/docs/

<itadder> dereksonthejob  http://prnt.sc/c7jmuo

<ebekker> Explor .NET API Catalog:  http://apisof.net/catalog/System

<<@URXAA|dereksonthejob>> dereksonthejob uploaded a file: Screen Shot 2016-08-18 at 10.41.10 PM https://powershell.slack.com/files/dereksonthejob/F22SKJQLR/screen_shot_2016-08-18_at_10.41.10_pm.png and commented: here we go

<sqlvariant> @jonwalz Can you include in the show notes that SQL Server got 3 new cmdlets, and people can get the new SqlServer module by installing SSMS 16.3 http://sqlps.io/dl

<<@URXAA|dereksonthejob>> dereksonthejob uploaded a file: @r_keith_hill https://powershell.slack.com/files/dereksonthejob/F22SRLC02/screen_shot_2016-08-18_at_10.41.10_pm.png and commented: I have it now, thx to @itadder

<halr9000> https://github.com/PowerShell/PowerShell/issues/1621

<halr9000> https://github.com/PowerShell/PowerShell/issues/706

<FoxDeploy-Stephe> https://github.com/PowerShell/PowerShell/issues/1273

<sqlvariant> Oh, here's a video we did last month if people need to catch up to speed on what's going on with SQL PowerShell in 2016: https://youtu.be/rc6lwiTE9GI

<adil> http://unix.stackexchange.com/questions/695/where-does-mac-os-x-come-from

<<@UNNCY|r_keith_hill>> r_keith_hill uploaded a file: RE line endings: https://powershell.slack.com/files/r_keith_hill/F22SHCYDB/pasted_image_at_2016_08_18_08_54_pm.png and commented: Just a LF but concerns me the default encoding is unicode for out-file still

https://powershell.org/2016/08/19/episode-316-powerscripting-podcast-jeffrey-snover-from-microsoft-on-open-sourced-powershell-v6/feed/ 2
Why PowerShell on Linux is Such an Accomplishment https://powershell.org/2016/08/19/why-powershell-on-linux-is-such-an-accomplishment/ https://powershell.org/2016/08/19/why-powershell-on-linux-is-such-an-accomplishment/#comments Fri, 19 Aug 2016 15:36:08 +0000 https://powershell.org/?p=51171

Related posts:

  1. PowerShell is Open Sourced
  2. PowerScripting Live tonight with Jeffrey Snover about PowerShell Open Source!
  3. Episode 291 - PowerScripting Podcast - Garrett Serack from Microsoft on OneGet
Yesterday, Microsoft announced that Windows PowerShell - which I suppose we'll just call "PowerShell," now - has been open-sourced, with PowerShell Core builds being made available for various Linux distros as well as macOS.

This is a big deal, but not exactly for the reasons you might think.

That .NET Shell Guy

PowerShell's genesis goes back to 2002 - and even earlier, really - when Jeffrey Snover wrote "The Monad Manifesto." He was trying to take a top-down approach to solving a long-standing problem with Windows administration, one that VBScript and other approaches had failed to fully address.

Problem was, Snover was proposing an administrative shell, and scripting language, built on top of the .NET Framework. That's not inherently a bad thing; tens of thousands of line-of-business applications have been written in .NET, and along with Java, it's probably one of the most popular business software frameworks on the planet. Thing is, Snover was suggesting this at a time when .NET Framework-based projects were failing left and right inside Microsoft. This was in the "Longhorn" timeframe, when projects like WinFS - touted as the very basis of a new generation of Windows - had epically failed to deliver. Microsoft wound up "decoupling" Longhorn from .NET, and now there's this loudmouth running around trying to build a shell on it?

I won't say that Jeffrey was a pariah internally for a period of time, but he certainly had his battles to fight.

And he won.


The PowerShell Era

Launching in 2006, PowerShell 1.0 was in many ways the "minimal viable product" the team could have shipped. Notably, it lacked Remoting, something which would hold PowerShell back until 2.0 shipped a couple of years later. But Snover and his team, with 1.0, still accomplished the near-unimaginable: they convinced the Exchange Server team to go all-in, and build an almost model implementation of how to use PowerShell for administration. Exchange Server 2007 built its very GUI on top of PowerShell, just as Snover had imagined in his Manifesto. It's perhaps hard to imagine, a decade later, how incredible an accomplishment this was for Microsoft. Exchange Server was very much the flagship product of the time. Pretty much everyone bought Exchange Server, and to make this big a flip was a big deal.

To be sure. the Exchange Server team wasn't without their worries. In fact, the team hedged its bets in a big way. Rather than instrumenting the server directly in PowerShell, the team built an entire abstraction layer, and wrote PowerShell commands to that. That way, they reasoned, if this ".NET Shell thing" was a flop, they could rip it out and replace it with something else, and do so fairly quickly.

PowerShell wasn't a flop.


In Lockstep with the Vision

Few realize it, but every version of PowerShell up to, and including, 4.0 were created in lockstep with the original Manifesto. While each version introduced a bevy of new features, the "headline" feature in each was taken straight from the Manifesto:

  1. A composable command-line shell and scripting language
  2. Remoting
  3. Workflow
  4. Desired State Configuration

Snover and the Windows Management Framework (WMF) team - of which PowerShell and its supporting technologies are a part - kept marching firmly in the direction he'd outlined. And that's not to in any way suggest it was a one-man show. Luminaries like Bruce Payette, who led much of the core language development, helped make PowerShell accessible to newcomers and familiar-feeling to programming pros. Guys like Lee Holmes not only helpd move development forward, but more recently gave the shell a stronger security focus. Dozens of unseen and unsung heroes helped make sure PowerShell was meeting the needs of its audience (I'm reminded by one exercise at a Microsoft MVP Summit, where MVPs helped reproduce and categorize filed bugs so that the team could start working through them, and another incident where Program Manager Dan Harman read through hundreds of suggestions in Microsoft Connect to help bring as many of them to life as possible). There are team members who've been with the product for a decade, something that's nigh unheard-of in Microsoft.


The Role of Community

The team knew at the outset that PowerShell would flop if people weren't using it, and becoming passionate about it. Numerous team members began to engage with the community on a regular basis to help that community come to life. The PowerShell MVPs - honestly, one of the most engaged and critical groups of MVPs within the MVP program - encouraged people to learn the shell, poke at it, and complain about any shortcomings they ran across. This vocal community made a serious impact. An early build of PowerShell 3.0 included a ReadMe file listing some 80-odd new features and changes, along with the names of the people who'd suggested them. Snover himself remains a regular conference guest. Payette and Holmes wrote bestselling books. Numerous team members appeared at Microsoft TechEd and Ignite.

And the team supported independent community efforts whenever possible. Managers like Kenneth Hansen, Angel Calvo, Erin Chapple, and more made sure community leaders had access to answers and resources when they needed them (scarce as those resources could be, at times), and the entire team worked to give as much of their time as possible to helping the independent community thrive. Sites like PowerShell.org and PowerShellMagazine.com,  the PowerScripting Podcast, and conferences like PowerShell Conference Asia, PowerShell Conference Europe, and the PowerShell + DevOps Global Summit would have been impossible without the generous support the team gave.

And that community thrived. Perhaps the biggest "wins" came with Advanced Functions (affectionately called "script cmdlets") and Desired State Configuration, where we no longer had to rely on Microsoft to provide us with the tools we needed, but could instead code them up ourselves.

And that was a turning point.


Baby Open Source Steps

Understand that open source had long been the enemy at Microsoft. The company's attempts to fight back against Linux and establish a Windows-only datacenter created a culture that deeply distrusted open source, and in many ways regarded it as the opposite of what Microsoft was all about. But many within Microsoft regarded open source as a way to better provide customers with what they actually needed, and a way to empower customers to create their own solutions, rather than relying entirely on what Redmond could produce.

The PowerShell team's first step into open source was to simply release the Desired State Configuration Resource Kit on GitHub. It wasn't a big step, as the Kit modules were all script anyway, making the source "open" kind of by default. That happened at almost the same time the company released an open-source (!) Local Configuration Manager implementation for Linux (!!). Satya was in charge now, after all, and he'd made it clear that Microsoft Loves Linux. 

Not long after, Desired State Configuration's documentation was open-sourced (!!!) as a set of Markdown (!!!!) documents, allowing anyone to contribute and make corrections. That was quickly followed by all the PowerShell core documentation being open-sourced (!!!!!). Haters gonna hate, of course, and Microsoft was quickly accused by some as simply "taking advantage" of the community for "free bug testing and documentation writing." Which, of course, is the whole point of the OSS movement. Customers were now empowered. We didn't have to wait for Microsoft to fix a typo, or file an expensive support incident. We could fork, fix, and submit a PR.

Snover made it clear as far back as 2014 that the open-sourcing of PowerShell itself was "inevitable," although he could never comment on a timeline. The blocker, he felt, was that .NET itself - which PowerShell runs on - was closed-source, making an open-source PowerShell fairly useless.


The Dominoes Begin to Fall

Of course, Microsoft recently open-sourced .NET Core, bringing it - and things like ASP.NET Core - to Linux and Mac. Suddenly, Snover's "blocker" wasn't a block. Well, kind of. PowerShell needed a lot more than .NET Core.

Except for PowerShell Core, which was designed to run on the extremely stripped-down Nano Server version of Windows Server 2016. PowerShell Core ran on .NET Core. .NET Core was open-sourced.

And so, yesterday, PowerShell itself followed into the world of open source. It's hosted on GitHub, for pity's sake, which is about the most non-old-school-Microsoft thing I can imagine. And the first pull requests have already been submitted.

But I want you to look back at where PowerShell has been these past 10+ years. It began as a simple document, and nearly didn't live, thanks to the negative internal feelings on .NET at the time. But it did live, thanks in part to a strong vision, and in part to a passionate team of designers and developers who knew their ".NET shell" would make a difference. Today, PowerShell is deeply embedded into nearly every Microsoft business product, and is becoming more so every day. All of this happened in about the same time it took VBScript to become widely accepted by administrators - but PowerShell, in that time, has come leagues further.


Sure... but on Linux???

Of course, none of the forgoing in any way explains why PowerShell on Linux (or macOS) makes any sense. These operating systems are inherently text-based, and their existing shells have been getting the job done for decades. So why PowerShell? Why now?

First, I think it's telling that PowerShell on *nix (which includes, for me, macOS, based as it is on BSD) is respectful. On Windows, we have Unix-like aliases - ps, ls, and the like - which run PowerShell-equivalent commands. Not on *nix. Run ps and you'll get the same ps you've always run; ditto with ls, man, and all the others. PowerShell isn't here to trample the commands you know. But it can integrate those commands into its pipeline, feeding them objects-as-text, and consuming the text they output. "Objects" simply being a defined data structure, many familiar Linux command-line compositions can be done more easily and in a more readable sense in PowerShell, since text manipulation is less critical. Command-lines become less fragile, too, since these data structures can remain the same even when the underlying command is updated. Leading up to the release of PowerShell on *nix, I had the opportunity to work with many die-hard Linux admins who, once they agreed to keep an open mind, started to really appreciate what PowerShell could do for them.

And don't forget that Microsoft Loves Linux. Having a single shell experience, and cross-platform shell connectivity, makes it easier to run Windows and Linux together. It'll make it easier to manage Linux in Microsoft's Azure cloud. It gives us, the IT community, options, where before we didn't have any.

And I think, tellingly, PowerShell on *nix represents a sea change at Microsoft. You're no longer being asked to buy into a single-stack solution. Microsoft's happy to let you mix and match as needed. Most importantly, they think you'll use their products - like PowerShell - because they're the best tool for the job. In other words, Microsoft's willing to compete, and have you use their products because you choose to, not because you've been locked into them. That's a wonderful thing. There's the implied risk of losing the competition, but it's a risk Old Microsoft has tried to mitigate and remove as much as possible. Now, we have the option to use Office wherever we want - not tied to Windows. PowerShell is no longer tied exclusively to Windows. We're seeing that attitude work both ways, too, with Bash on Windows, SSH on Windows, and more. These products can compete for your attention, and that will make them all better products in the long run.

So congratulations to Jeffrey Snover, to all the members of the Windows Management Framework team, and to Microsoft itself. And congratulations to PowerShell itself - and to the global community that brought us to this inevitable new beginning.

https://powershell.org/2016/08/19/why-powershell-on-linux-is-such-an-accomplishment/feed/ 1
FAQ: PowerShell on Linux/Mac https://powershell.org/2016/08/18/faq-powershell-on-linuxmac/ https://powershell.org/2016/08/18/faq-powershell-on-linuxmac/#comments Thu, 18 Aug 2016 21:02:51 +0000 https://powershell.org/?p=50994

Related posts:

  1. PowerShell is Open Sourced
  2. Why is Remoting Enabled by Default on Windows Server?
  3. PowerShell <3 SSH
Be sure to check back often, as we'll add to this.


So does this mean I'll be able to run [add your favorite module name here] on Linux/Mac?

Likely not. PowerShell on Linux/Mac is, at present, "PowerShell Core," which is a subset of the total Windows PowerShell product. Similar situation to PowerShell on Nano. So any module that requires something outside Core, won't run.

And further, most modules have dependencies on underlying technologies in Windows. The SMBShare module, for example, depends on CIM classes that only exist on Windows.

So many add-in modules won't, in fact work on Linux - because they're designed to manage Windows machines. Over time, I'm sure we'll see modules that only run on Linux and/or Mac, because they're tied to dependencies on those operating systems.

Ideally, of course, you can always remote to the OS of your choice and run whatever commands it has. And from The Register:

Vendors with PowerShell libraries for their products will be able to port them to the new Core version, and early examples are AWS (Amazon Web Services) and VMware. Steve Roberts, AWS Software Development Engineer, has shown the AWS Tools for PowerShell running on a Mac; and VMware's Alan Renouf has done a similar demonstration using vSphere PowerCLI. "We’ve got commands that will manage every aspect of vCenter administration already," said Renouf.


Snover's blog post mentioned Remoting over SSH. So does that mean I can Remote into any Linux box?

No, not exactly. It's worth understanding, first, how the existing Remoting over WS-MAN works. In Remoting, you type or compose a command on one node. It is packaged into XML, and transmitted as text over the WS-MAN protocol. The receiving node unpackages it, runs the command, and serializes the resulting objects into XML. That XML is sent back, again over WS-MAN (which is based on HTTP), to the originating node. The originating node deserializes the XML to recreate the original objects.

Remoting over SSH will work exactly the same way, except that SSH will be used to transmit the XML text back and forth, rather than WS-MAN. This isn't the same as a simple SSH session where you're just sending keystrokes to the remote machine. A "plain" Linux machine's SSH daemon wouldn't know what to do with the XML-packaged traffic used by Remoting. Remoting over SSH will require both nodes to be running PowerShell. SSH isn't the end-game, here; it's merely being used to get text from one place to another. This isn't "PowerShell SSH-ing into a remote machine," either. PowerShell isn't an SSH client or server, in that sense.

Microsoft has already said they plan to release an SSH server and client for Windows. That will get you the plain-Jane SSH interactive sessions that you're used to. SSH, in that scenario, works a lot like encrypted Telnet (it's based on Telnet, after all, as is nearly every other Internet protocol). You press a letter on your keyboard, and it's sent to the remote machine, which then echoes it back to you, so the letter also appears on your local console. When you hit enter to run a command, the text output is sent to your console. "Plain" SSH is a purely text-based thing - while PowerShell's strengths come from its use of objects, rather than text.

So it's important to differentiate, in your mind, "using SSH the way I'm used to" and "Remoting using SSH as a text transport." There's actually precedent for what Remoting is doing: SCP. SCP encodes binary files as a text stream (vaguely like SMTP does), and uses SSH to transmit that text. It's then decoded into the original binary on the other end. But although SCP uses SSH under the hood, we certainly don't think of it as "using SSH" the way we do when we have an interactive SSH login on a remote box.

https://powershell.org/2016/08/18/faq-powershell-on-linuxmac/feed/ 8
PowerScripting Live tonight with Jeffrey Snover about PowerShell Open Source! https://powershell.org/2016/08/18/powerscripting-live-tonight-with-jeffrey-snover-about-powershell-open-source/ https://powershell.org/2016/08/18/powerscripting-live-tonight-with-jeffrey-snover-about-powershell-open-source/#comments Thu, 18 Aug 2016 16:37:45 +0000 https://powershell.org/?p=50946

Related posts:

  1. Up Next: Rob Reynolds brings us Chocolatey News!
  2. Tonight on the podcast: Jeff Wouters is hands-on with #windows10 & #nanoserver
  3. PowerScripting Podcast, now recorded live on UStream
PowerShell goes OSS & Cross-Platform!No more teasing, we can now announce that tonight's guest on the PowerScripting Podcast is none other than the inventor of Windows PowerShell: Jeffrey Snover! The topic: PowerShell has been open sourced and is available NOW on Linux and Mac OSX!

Want to jump in right away? Here's the code: github.com/powershell/powershell!

Join us live at 9:30 PM EDT / 6:30 PM PDT, streaming live on the PowerScripting YouTube channel with live chat in the #live-podcast room in the Slack PowerShell team (join here)!

Last but not least, if you are like us and want an invite on your calendar, click here or here. 🙂

https://powershell.org/2016/08/18/powerscripting-live-tonight-with-jeffrey-snover-about-powershell-open-source/feed/ 2
PowerShell is Open Sourced https://powershell.org/2016/08/18/powershell-is-open-sourced/ https://powershell.org/2016/08/18/powershell-is-open-sourced/#respond Thu, 18 Aug 2016 16:05:46 +0000 https://powershell.org/?p=50943

Related posts:

  1. FAQ: PowerShell on Linux/Mac
  2. PowerScripting Live tonight with Jeffrey Snover about PowerShell Open Source!
  3. Up Next: Osama Sajid from Microsoft talks about CIM!
For those of you that have been at PowerShell Summits over the last few years you’ll have heard Jeffrey Snover state that he wanted to take PowerShell to other platforms.
Now its happened
Jeffrey has announced that an ALPHA release of PowerShell is now available for Linux and Mac.  Currently available for Ubuntu, Centos, Red Hat and Mac OS X with more to come
The announcement is at
Also see PowerShell blog
Some  points to note:
ISE isn’t available as part of the alphas release but VSCode is available for Linux and Mac giving an consistent editor across the platforms
PowerShell remoting will be extended to use Open SSH as well as WSMAN
Planned enhancements include:
Additional Linux Distros covered – parity with .NET Core.
Writing Cmdlets in Python and other languages
PSRP over OpenSSH
WSMan based remoting to downlevel versions of Windows and WSMan based PSRP on Linux.
Editor Services and auto-generated GUI
Unix-style wildcard expansion
Increasing test code coverage for Windows and Linux editions
Continue increasing cmdlet coverage for Linux and Windows
REMEMBER this an ALPHA release – there’s still a lot to do and its a open source project so community effort is required
https://powershell.org/2016/08/18/powershell-is-open-sourced/feed/ 0
Live on PowerScripting Podcast Thursday Night: A Special Guest https://powershell.org/2016/08/17/live-on-powerscripting-podcast-thursday-night-a-special-guest/ https://powershell.org/2016/08/17/live-on-powerscripting-podcast-thursday-night-a-special-guest/#comments Wed, 17 Aug 2016 19:03:02 +0000 https://powershell.org/?p=50861

Related posts:

  1. PowerScripting Podcast, now recorded live on UStream
  2. PowerShell v2 Virtual Launch Party!
  3. UP NEXT: Tome Tanasovski on regular expressions.
podcast-logoWe are pleased to...well, "announce" isn't the right word. Tease! That's the one! We are excited to share with you, dear viewers and listeners, that Jonathan and Hal will be joined by a "Very Special Guest" this Thursday, Aug 18th @ 9:30 PM EDT / 6:30 PM PDT at our usual place: live.powerscripting.net.

Here's the rub:

  • We can't tell you who the guest is
  • We can't tell you what the topic is

But we can say that this will be a pretty big deal!  Look for this post to be updated tomorrow with more details, if at all possible.

Facebook Event link

.ical Calendar invite: PowerScripting Live - Aug 18th, 2016

https://powershell.org/2016/08/17/live-on-powerscripting-podcast-thursday-night-a-special-guest/feed/ 1