Okay, so I have two o'clock on my computer here, and like I said, we got a lot to get through, so I'm just gonna go ahead and jump right into it.

I do intend for this to be an open session. I want you guys to raise your hands and interject as much as possible. That being said, I have a little less time than I had the last time I gave this talk, and I've added a bunch of stuff since then, and I've got a really fun demo at the end. So if we move it a pretty quick clip, then we can all talk out in the hallway afterwards. I'm gonna be here as long as you guys will be here,

and we can talk about whatever you want. So with that being said, let's jump on in. So we GA'd this little thing called PowerShell Core 6 last January. It's managing your heterogeneous environments in the hybrid cloud.

The phrase we're using here is anything, anywhere, right? We support Windows, Mac, Linux, and Linux distributions. You guys saw the IoT demo yesterday. We work with Azure, AWS, Google Cloud, VMware. Really, the goal is for you to be able to manage everything and anything. Released on January 10th,

and the first thing I have to say is thank you to our contributors, right? We couldn't have done this without our contributors. Approximately 50% of our pull requests came from outside the company, which is huge. We knew that people were gonna wanna contribute. We had no idea what kind of volume was gonna come in, and really, this has evolved from a Microsoft Run project

to a Microsoft-led project to really a shared project very, very rapidly. We also publish all of our metrics around those pull requests and contributions coming from the community as well as usage data publicly in a Power BI dashboard that you can check out right here, ps-github-bi.

Definitely check that out when you get the chance. But the big features that we shipped, again, cross-plot, a big one for me that doesn't get a lot of airtime is that we are fully side-by-side and fully portable. So this is one of the big things when we were starting the PowerShell Core project. These were actually the top tenants, right? We needed to not be able to,

or not have to reboot on an install. You needed to be able to install side-by-side versions so that you didn't have to all or nothing move to a new version and find out that stuff broke and have to roll back, and you needed to be able to drop down installations without an installer technology. So we have xcopy deploy fully portable, drop a folder down, run pwsh.exe, and you're good to go.

I've also got SSH-based PowerShell remoting, so WinRM PowerShell remoting is still in the box. But we have all of the new ps session, enter ps session cmdlets built over SSH as a transport protocol so you can use public-private key pairs, password authentication, port 22, and for a lot of you guys with IT departments

that are pretty secure, I think that this is gonna be a much easier sell than PowerShell remoting in some cases. And in other cases, you'll have your Linux compatriots who are already using SSH and wanna use some shared infrastructure. So this is really, we're trying to jump on the concepts that the Linux world has already embraced so that we're not bringing Microsoft technology to Linux,

but really making sure we integrate well wherever we are. I highly encourage you to check out that link. There's a ton of new features. These are just the sort of big rocks, but we've added all kinds of stuff in PowerShell Core to make your life easier. New cmdlets, parameters, APIs, fixed tons of bugs. So definitely check it out.

Yeah. So when you're going through WinRM, trusted host is still a requirement, and it's still set in the WinRM provider or talking to winrm.cmd.

With SSH, there's a concept of known hosts, which is specific to SSH, and when we're doing the PowerShell remoting here, we're actually shelling out to SSH to do the authentication. So we ask SSH to authenticate, and then once we establish the connection, we do stuff on top of that. So known hosts is a very similar concept

to trusted hosts. You have a file that, fingerprint tied to a host name that you whitelist the first time you connect. We can get into that a little bit later, but yeah, it's essentially the same concept. So coverage for PowerShell Core, this is the big one. PowerShell Core is great, but I want my modules to work on it. And we agree with you, right?

The success of PowerShell Core really depends on you being able to continue using your existing skillset against existing modules with existing assets and workflows and scripts, et cetera. So to that end, we're working with Windows, Azure Office to increase coverage. I had some folks talk to me last night about SCCM,

so I'm adding that to my list of people to reach out to. As you saw yesterday, Aaron Roney gave a presentation. The Azure RM modules are coming along very, very nicely. I highly encourage you to check out the preview on the PowerShell Gallery. At some point in the future, the plan is to have the net core dropped. And we really, I'll say right now,

I don't want to establish a strong pattern of having .net core at the end of the module. It's working great for now as an interim, but we're gonna talk about PowerShell standard in a few minutes, but really, we want all modules to just be universal to Core and Windows PowerShell. So this is sort of a temporary measure, but at some point you should expect that Azure RM will just work on PowerShell Core.

We've also got the Windows PowerShell compatibility pack. This is intended to fix some of the, or introduce some stop gaps where we're not able to bring module compatibility over just yet. One of those is a demo you saw yesterday from Bruce at the Lightning Demos, where we're doing sort of transparent implicit remoting to a local Windows PowerShell instance on Windows

and asking Windows PowerShell to execute the command so that you're able to run the same scripts from PowerShell Core, but we're actually using the Windows PowerShell engine under the hood to get that increased module coverage. We also have a module called Windows PS module path. We're gonna take this functionality and put it in the compatibility pack as well.

All this does is add a commandlet that adds the Windows PowerShell module path to your PowerShell Core module path for the current process. So I put this in my profile, 90% of what I do every day, I never hit any problems with Core. Like I just say, give me all the Windows modules, everything seems to work fine, especially in CDXML land. We're also gonna manage some of the legacy aliases.

We know there's been some controversies around removal of aliases in Windows or removal of a lot of aliases on Linux where the native binaries exist. We're hitting this now with cURL, right? We aliased cURL. We never thought that this would be a problem until we went to Linux and we needed to remove that cURL alias so that people could use cURL on Linux

and now we actually ship cURL in Windows. So now there's sort of a cURL.exe versus cURL problem on Windows and we really wanna fix problems like that going forward. I don't know that we can fix that one in particular but we're trying to address this legacy alias problem by giving you some abstractions to manage your aliases.

This is one that I'll probably, let's do a show of hands here. So for those of you who are not using PowerShell Core today, who's not using PowerShell Core? Okay, so leave your hands up if that's because of a lack of Windows modules.

Okay, how about Office 365 modules? Azure PowerShell? Less so, System Center? All right, are there any, Office 365, I'm gonna include Exchange Online, SharePoint Online, everybody, yep, included that, okay. Are there any that I missed?

Cool, that's awesome. How many of you are using PowerShell Core today? Great, that's phenomenal. Okay, awesome, thank you guys. So why are we optimistic about this, right? Like you guys, I'm sure, sometimes get nervous when we start saying things like, we're working with partner teams and we're driving it and we want you to file feedback

against those customer teams. All of that stuff is true and it totally does work but there's a few reasons why we think that in particular this effort is going to be successful. One of those is that there's a clear transition path from Windows PowerShell to PowerShell Core, right? We've established this concept of PowerShell Standard for .NET, which again, I'm gonna dive into in a few minutes.

You know, recompile against PowerShell Standard and you get compatibility with PowerShell Core. It's a very clean story, people understand it and we're going and pitching it to our partners as we speak. As for CDXML, PowerShell script, even Win32p invokes native dependencies, all that stuff is just gonna work in PowerShell.

So we've made some very small changes in the PowerShell scripting language that technically count as breaking but by and large, we're not seeing script breakage from five to six, even in the magnitude that we saw from like two to three. The goal here is porting and compatibility, not re-implementation.

So this isn't like a really expensive design decision. We don't have to reach out to teams like we do with commandlet design to say, hey, you gotta make sure you support X, Y, and Z. It's like recompile your thing, run your tests on Core. If it works, we're great. And that's a pretty easy sell to a lot of folks. Many of the hard problems are reoccurring. So we're seeing some issues that one team runs into

like two-factor authentication with Azure PowerShell. It's the same issue that other teams like Exchange Online or Azure AD run into. So a lot of these solutions that we have to some of the tougher problems are reproducible. And the value add is easy to communicate, right? It's cross-platform, you get Mac and Linux, it's performant, like some of the benchmarks I saw

were up to like 60% faster in PowerShell Core. A lot of that's due to .NET Core, but we've been doing tons of cleanup in PowerShell as well. And it's portable, it's just easier to manage. In a CICD world, it's just way simpler to grab a zip off of the internet, slap it down, run some executables. It's how people do things dynamically.

We have container images that start up really fast for PowerShell Core. So a lot of people understand why it's beneficial to get to Core, and it's not hard to have that conversation. Any questions on any of that stuff? Nope, okay, awesome. So remoting, in PowerShell Core, there are three ways to remote.

One of those is the traditional PowerShell remoting over WinRM, WSMAN. All those commandlets are gonna work just the same as they do on Windows PowerShell. We've also got PowerShell remoting over SSH. So these are the same commandlets that you're used to with a new parameter set. You use dash hostname and dash password instead of dash credential and dash computer name.

Those are gonna give you session objects, it's gonna give you implicit remoting, it's gonna allow you to reconstruct sessions, and all of that is happening using SSH as the authentication layer. You've also got plain text SSH remoting. This is really absent of PowerShell, so you can just SSH to a machine,

it's gonna drop you into CMD or drop you into bash, you can execute PowerShell, and now you're in PowerShell. The problem there is you're not getting those rich objects back over the wire, and all of the execution and processing is happening on the server side. And lastly, when you lose the connection, you're going to lose the session, unless you use something like screen or TMUX or something that persists that session on the server end,

as opposed to PowerShell remoting where we persist the session on the client end, and you can reestablish the connection and resume what you're doing. There are some limitations here. Do you have a question over here? Okay. There are some limitations. One of those is that the PSRP server for WSMAN

is experimental on Linux platforms. This uses OMI, and we have not fully tested the scenario. What we found, though, is that by and large, people have SSH servers already running on their Linux machines, they wanna use the SSH stuff that currently exists, and really just adding this one line to their SSH deconfig to add PowerShell support

is much, much easier than standing up the end-to-end OMI infrastructure. This one's a little bit bigger, is that the WSMAN client on Linux and Mac does not support Kerberos. So today, you have to do basic authentication or NTLM authentication. We believe that it's possible to add Kerberos authentication now that OMI client

has added Kerberos support, but it's a little further down in our stack of prioritization. If that's something you really wanna see, we've got an issue on GitHub, you can go and upvote and give us some context around your scenarios. But our hypothesis around remoting is primarily that SSH is the future, and everyone should use it. If you can use SSH, you should use SSH, it's great.

We're gonna do more and more stuff with SSH over time. If you've already got Linux machines, AWS stuff and hybrid cloud, all that SSH is gonna be the way to go and make sure that you really have one authentication authorization pipeline across all of your stacks. But we also know that WSMAN WinRM is very important,

and we should continue to support it. So there's a reason that we did the WinRM client in PowerShell Core, even on non-Windows platforms, and it's because we recognize that you have some older infrastructure, your 2008 R2 machines, you can never put a new service on them, nobody's allowed to touch them, but you still need to get to them from your MacBook to do some remote administration sometimes.

So yeah, if that hypothesis is wrong, or you don't think SSH is the future, you think WinRM is amazing and you wanna use it forever, please come talk to me afterward. Okay, so support lifecycle. So PowerShell Core is supported under what Microsoft

is calling the modern lifecycle policy. So this is sort of the as-a-service philosophical shift that we've had over the last couple years. You guys hear about Windows as a service. When you're with Azure, you're sort of making sure to stay up to date on the latest Azure APIs. A lot of Box products are going in the same direction.

So that includes us here. We're basically saying that when we move to a new minor version, 6.1, 6.2, 6.3, you have six months to move to that minor version. So you'll see here from the chart, you get about six months of overlap, right? You come out with 6.1, and by the time 6.1's halfway through its life, we're expecting

that you'll have moved off of 6.0, and maybe even on to 6.2 by then, right? So we don't think that this is really going to be an issue for a lot of people currently. I actually expected it to be more of an issue. But folks are actually getting more hung up, I think, about the version number. So I'll just say this.

Don't worry too much about the version number. I love semantic versioning. Does anybody know what semantic versioning is? OK, so the basic concept of semantic versioning is that when you introduce breaking changes, you rev the major version, right? If 6.1.0.0, that's like an a.b.c.d format.

When you make breaking changes, you rev a, right? If you don't make breaking changes, you can rev b when there's new features. And if it's a bug fix, you rev c, right? We have 6.0.1 that we came out with. The problem is that with something that's as large as PowerShell, sometimes the magnitude of a breaking change really isn't high enough to justify revving your major version all the way up

to like seven or eight or nine, right? Some people have said, why don't you take a Chrome-based approach? We can be on PowerShell like 42 by 2020 or something. It's just a little bit too confusing, I think, for people. We want to validate that the fix-forward thing works for some period of time. And there's some branding that gets

established around the major version of your platform. When it comes to modules, the story is completely different. Modules should absolutely follow semantic versioning. There's very clear definitions of what a breaking change entails in a module. You delete a parameter. You rename a cmdlet without aliasing it. Those sorts of things absolutely should require a major version rev.

And we're sticking to that as much as we possibly can within PowerShell modules. But PowerShell itself, if you go look at our breaking changes document, I would really be interested to find out if any of you were genuinely impacted by some of those breaking changes. And if you are, from 6.0 to 6.1, excuse me.

In 6.0, we made some set of breaking changes we're OK with. And that's a major version change. So we reserve our right to do that sort of thing. But with 6.1 and 6.2 going forward, we're really trying to take the only really small stuff that we think might technically qualify as a breaking change, but that really isn't going to be impactful or doesn't have a large surface area where we think

people are using stuff. We go out to GitHub, and we go out to poshcode.org, and we try to find people that are using a certain piece of functionality or something. And a lot of this stuff is very, very esoteric. So again, don't think too hard about the version number. It's the Uber point there.

Yeah, so this is what people ask me. And the answer is, I made a statement at the MVP summit a few weeks ago about, we may never do a PowerShell 7. And a lot of people reacted to that. And I think a lot of people project their hopes and dreams onto what a 7 might look like.

The reality is, I want to talk about what kind of PowerShell you need, and then we can make a decision about how to brand it and what version it needs and that sort of thing. But yeah, we might never do a 7, but I don't know that that matters. It doesn't mean that we're not doing PowerShell anymore. It doesn't mean that 6.12 won't look totally different

from 6.1. And if everybody's like, I'm really bored of 6, sure, we can rev it up to 7. But again, it just doesn't matter. It's just a number. So it's more about the management of the version and the support lifecycle and the compatibility and the breaking changes. And having a dependable contract with you guys is really the higher level point.

So we get some other questions, too, around, this is going to really make my life a little tricky as a module developer. You're saying you're going to rev the version every six months? I've got to retest? My matrix is going to grow. This is going to be a pain in the butt, right? Well, not really. It turns out fixed forward, at least as far as we see it, is actually good for developers.

One of the problems that we see out in the wild today is you module developers having to maintain support for PowerShell 4.3, god forbid 2. That's really the sort of thing that increases the burden, is when we leave things in support for a very long time and we have large breaking changes, large changes between PowerShell versions.

The goal here is to say, A, we don't think we're ever going to be really introducing enough in a minor version of 6.0 to break you guys. The goal is you shouldn't really have to retest at all. If these things are really, we're not taking any large breaking changes, your stuff should continue working in a fixed forward world. But also it means that you don't have to worry

about 6.0 a year from now, right? So you get to update your stuff and tell people, well, you're not supposed to be using 6.0 anyway. Microsoft says that's out of support, so I say it's out of support. And maybe that's not going to work in the long run. We're playing it by ear here, but this is our general hypothesis in the model that we're working off right now.

Yeah, so I'm getting into the stuff about Windows PowerShell in a little bit. Today, the PowerShell core support lifecycle is totally independent from any other products because we're not shipping it as part of Windows. Windows PowerShell is getting it to just a couple slides here,

but I'll talk about the support model there. But in terms of PowerShell core, we might need an LTS of some kind. I haven't seen a strong justification for it yet. And to be honest, there's been less demand for it than I even expected. But if people make the case and we get to 6.3 and we're like, man, this is really stable,

our test coverage is great, people are rocking on 6.3, and some folks say, whatever you're doing in 6.4, I can't take it. I need you to support 6.3. We can start having that conversation then. But right now, you've got the Windows train, and you've got our train for core that's fixed for it.

Is that mostly covered on support? It's good there? So what about some limitations of PowerShell core? So we've talked about all the good stuff. Some modules are going to be incompatible. Again, we're working on that. We're getting there. We totally recognize that it's one of the number one problems. A few of the built-in cmdlets are missing from PowerShell core that we've traditionally shipped.

The wmiv1 cmdlets, the perfcounter cmdlets, eventlog cmdlets, and local accounts. Some of this is because .NET has dropped some types that they supported in framework that they no longer support in core or standard. A couple of these have been added back with the Windows .NET

framework Windows compatibility pack, I think. And so we may investigate bringing some of these cmdlets back. But by and large, like wmiv1, we really don't want you using any more, like the wmiv2, like the getSomeInstance all work pretty great. perfcounter or eventlog were actually around, and local accounts as well, were around some private APIs

that got used that we were allowed to use in Windows that we're not allowed to use outside of Windows. I think a lot of these modules are going to work just fine if you import them in PowerShell core from the Windows PowerShell module directory. So if you really need local accounts, you can explicitly import it.

It's using Win32 APIs to call stuff. But unfortunately, we can no longer ship it as part of PowerShell. On non-Windows platforms, we have a couple more modules that are missing. Some of these use Windows specific APIs. Some of them use Microsoft.management.infrastructure, which has not been fully ported to Linux yet. This is like the stuff that deals

with SIM and the SIM adapter and CDXML cmdlets. We've also removed, as sort of legacy features, PowerShell snap-ins, which we just don't want you using anymore, and workflows, which is primarily due to .NET's dropping support for the workflow framework, or whatever it was called, Windows Workflow Foundation. Heyman should know back there.

OK, what about Windows PowerShell? All core, right? What's happened into Windows? First of all, it's still fully supported and serviced. It's not going anywhere. Jeffrey talked about this the other day. CMD was deprecated in, what did you say, 2007? Yeah, so it's not going anywhere.

Windows PowerShell is going to be the same. It will never be replaced by PowerShell core within Windows. So for some period of time, we're probably not going to have PowerShell core in Windows at all. But at some point, we might bring it into Windows. And if that were to happen, we would still give you these two options. It's one of the big reasons we went with PWSH versus

PowerShell.exe, so you can deterministically call one versus the other. And really, it's actually a feature, not a bug, that we are not introducing new innovation into Windows PowerShell. This was a hard sell for me for a while, because I really wanted SIX to be everywhere, and for the path to be that your universal module,

like if it works on SIX, it should work on SIX full CLR or whatever. What we realized in working through this problem is that because Windows PowerShell is a singleton on the machine, because you have to update it

and in place and do the reboot, and all your SMA.dll gets updated in the GAC and all that stuff, we wanted to make changes in PowerShell core that would have broken workloads on Windows PowerShell. So some of the improvements that we've made, while technically constituting breaking changes, would have introduced some risk and some churn

into the Windows PowerShell world. And what we want to make sure more than anything is that the workloads that you have today that you currently depend on to do your business will continue working in Windows PowerShell. So where we're falling short in PowerShell core, we're not leaving you with no options. And we're not saying, in this world where, hey, I use

Exchange, but if I update my machine to WMF5, they tell me that I'm not supported anymore. We don't want to have those kinds of situations with SIX. So Windows PowerShell is there. It will work forever. You can depend on it. PowerShell core is where the new fun stuff is going,

and then we're going to have this Venn diagram that will overlap as much as possibly can, but will never fully overlap, if that makes sense. Yeah. Right. So the comment was, hey, I want to make sure that you're not leaving things, if I'm capturing it correctly, leaving things to Windows PowerShell as the only engine that

can manage certain parts of the system. And I think that's absolutely our goal, is to make it so that PowerShell core can manage everything and anything on your system. What we have as an explicit non-goal is that 100% of your scripts will work as drop-in replacements.

We want 96% of your scripts to work as drop-in replacements, and the 4%, you're going to have to do some refactoring and some modernization into the new world. But it's not to say that we don't want modules that support everything in Windows working with PowerShell core. Does that make sense? Cool.

We do have a label for tracking some backporting stuff, because we do have to do servicing fixes. There are a certain bar of bug fixes and security fixes that is the work we have to do as part of when we say we support something. So you have a Premier contract or some kind of support contract with us, or you submit a security bug to MSRC,

we're going to go and service those things. There may also be a couple tactical things that we need for internal teams, but we're really trying to limit those as much as possible. Yeah, so this is just, I didn't mention the includes PSRP over SSH,

but I know that there was some talk for a while. People were saying, can you just slip this one feature in so I can do my remoting? And we don't currently have a plan to do that. So I just, yeah, make sure I call that out, but thank you. OK, so PowerShell standard, right? We keep hinging all of our hopes and dreams on this thing. What is it? Why did we do it?

It's essentially a universal API that exists between both Windows PowerShell and PowerShell Core. The analog on the .NET side is something called .NET standard, which we've implemented in PowerShell standard. .NET standard is this idea that if you build a binary against .NET standard, it will work in .NET frameworks down to 4.6.1.

And if you load it in .NET Core, it will work in .NET Core 1.0 or 2.0 or whatever the .NET standard version matches up to. So we have a very similar thing. The minimum version number, we're saying, of PowerShell standard snaps to the minimum compatible version.

So you'll see we've got a PowerShell standard 3 and a 5.1. 3 is going to work against Windows PowerShell 3 through 5.1 and 6.x on the PowerShell Core side. 5.1 will only work against Windows PowerShell 5.1 as well as PowerShell Core 6.x. We think people are going to use a lot more of the second one because it has a whole ton of APIs

for crawling the AST and doing PowerShell classes and stuff with DSC and all sorts of other things. So we're looking at download numbers there to understand what the demand is for compatibility down to 3, but we're really seeing a lot less demand than we expected from the get-go.

The table might not be, but we do have a PowerShell repository at github.com slash PowerShell slash PowerShell standard, and it should have at least a description of what I just said in the readme there.

It's also on nuget.org as PowerShell standard dot library. I'm going to be showing that in just a few. Keep cranking here. PowerShell Core 6.1 roadmap. So release plan for late June, early July. Check out the RFC repo. This is where we're effectively specs. RFCs stand for Review for Comment.

We heavily borrowed from standards-based committees like DMTF for this sort of thing as well as our friends at Chef who gave us some great tips on managing community stuff. We know we're not perfect here yet in our process, but all the meat and potatoes of all the fancy new features that you want to talk about and give feedback on before they're shipping, before they're even implemented,

they're all going to be here. So definitely check out that repository. All these features I'm about to list, I've deep linked to the discussion on the PowerShell RFC repo so that you can hop in when you get the slides and go yell about whichever your favorite feature is. So one of those is experimental feature flags. The goal here is we really want

there to be a way for you to opt into experimental features that are in a stable build. So instead of having to wait for the entire RFC process to finish and an entire perfect code review to finish and a final design sign off to finish on shipping a new commandlet or a new language feature, we'd like you to be able to flip a flag,

opt into that feature, play with it, tell us it's terrible, and then we can go and fix it without having to try and think of all the ways that it's terrible before people actually use it. So this is a way that we can sort of blend the experimental aspects of preview builds with more stable builds. We're still not totally sure if, when I say experimental features and stable builds,

that we want to ship an experimental feature in an actual stable production build. It may be that we still have preview builds. I don't know if any of you use Chrome Beta or Dev Channel or whatever. You go into Chrome flags, and there's just like 300 flags of fancy stuff that they're working on. Some of that stuff may still only be in the preview builds. But we still want there to be a way for you to sort of check

out the new stuff and then go, oh my god, that's totally broken. I'm rolling back here. The other thinking is that the same infrastructure could eventually be used to allow you to opt into deprecation or removal of features. Python's got a concept like this where you can import futures and sort of find out what it's going to be like in the next version or whether your stuff's going to break. We'd like to do the same sort of thing,

but we haven't figured out what the workflow or time span looks like on removing a feature over three versions or whatever. We demoed this yesterday, but we're making a bunch of improvements to the help system, native markdown rendering with color highlighting and all that stuff. We're also refactoring the help system as a module.

We're trying to thin down PowerShell and really make it a core engine that you can then take some of the interactive pieces and pile on top as you want. And this is really our first step in starting to experiment with taking stuff out of system.management.automation, putting them into their own namespaces, own modules, and starting that effort.

Another big one, I think Jeffrey showed this one, was device guard app locker parity with Windows PowerShell. This was just a thing that we missed on 6.0 and definitely needs to be there for 6.1. We've got native concurrency. One of the paths that we may take here was Paul Higginbotham's demo on thread jobs yesterday. There's also a bunch of other modules

out in the community that do this, posh rs job, invoke parallel. I'm sure I'm missing a few that people love and use. Definitely chime in on this thread. When we first started this RFC, we thought that we wanted to build something from scratch. And in looking at a lot more of the community modules out there, we think that there's a great bunch of stuff

out there and we don't necessarily have to reinvent the wheel. So please come and tell us what's important to you. And if it wasn't clear, this is about essentially being able to execute parallel operations in PowerShell, having multiple run spaces, doing multiple things so that you can do tasks faster.

Yeah. Yes, so this was, I had three software engineers on a couch last night knee deep in a Stack Exchange article talking about this because I almost put parallelism on the slide and I knew that Bruce would chew me out if I did that. So it's concurrency, technically,

but we can get in. Yeah, for those of you that want to have that fun conversation afterwards, we can totally do that. But it's concurrency, yeah. Concurrency is about saying, I want to do a bunch of stuff and having it execute, let me back it up.

Let's say you have multiple threads, they're all running on one core, right? The execution is happening in the same time period, but execution is never happening at identical periods of time. You're sort of switching between one and the other. With parallelization, you're doing multiple tasks on multiple cores. They're all executing at the same time in real time.

Yeah, we're talking about concurrency here. I don't know that, but I know that the goal is concurrency and that I think it's kind of hard to do parallelization until you have a good model for concurrency. And then you can say, hey, instead of doing that on one core, do it on four.

But again, yeah, we can get into this afterward. I don't want to. Yeah, yeah. Awesome. Windows PowerShell compatibility pack, we talked about this a little bit before. It's doing all the stuff we said. PSReadLine 2.0, this is one that we actually probably will backport to Windows PowerShell,

particularly for accessibility issues. The big change, I mean, there's tons of cool functional changes. You have VT100 codes for colors, and the tool tips look amazing now and give you inline descriptions of parameters and stuff like that. But the really big one is that this uses some new APIs that allow screen readers to finally work. So for those of you that use screen readers

or know somebody that does, PSReadLine before, you type a character, it'd read the entire line from the beginning. Now it doesn't do that. So kind of a big deal. The IoT module, we had a demo of that yesterday, turning on some lights, manipulating GPIO on a Raspberry Pi I2C.

Here I've got the continued ML experiments struck out. This is not struck out forever. This is struck out in 6.1 due to some of the coverage work that we wanted to take on. We still have an RFC out there for having ML-based suggestions in IntelliSense, but we're not doing any investment there until after 6.1 is released.

It's just experimentation. So we're learning as much as you guys are in this space. What's that? ML is machine learning. So we wanted to essentially collect a lot of data on how people use PowerShell and then try to give you intelligent suggestions at tab completion time based on usage patterns.

So instead of sorting by alphabetical or whatever the parameter set was in, maybe you sort by most used. That's a very basic example, but that sort of thing. And keep your eyes peeled for new RFCs. Submit some of your own. I know we've not been the best at responding at them, but we are working on it. And actually, on that note, here

are some things where we have room for improvement. One of those things is the committee transparency and openness. So for those of you that don't know, we have something called the PowerShell committee that I sit on along with six or seven other folks. We make all the decisions on breaking changes, new designs, whether or not we approve an RFC. And a lot of those decisions have been made with a very

quick little summary of the PowerShell committee talked about this and said no. They talked about this, and yeah, it's great. And we really would like to, A, give you a little bit more exposition. We've been talking about doing something more akin to the PowerShell core community calls for general committee meetings.

So maybe we record our meetings or output some kind of meeting notes. We had an experiment where we tried to record a meeting one time and see how much of it would have to be redacted. It wasn't a great experiment. We redacted a lot and decided that it probably wasn't a great thing to put up. So we might do meeting notes in the future or something like that. I swear a lot.

Yeah. And you also crack jokes on people that may be a little more personal than you would otherwise. When you open up a room to the world, there are ways that you censor yourself that you maybe don't want to when you're having heated design discussions that have some kind of output.

So we're trying to figure out how to get there. We totally understand the concern. Hopefully, even in the last two weeks, I've been trying to make a best effort whenever we say we approve something or deny something to have a lot more exposition and explanation. We're going to be doing more of that. But just expect to have more calls, more meeting notes, more all that stuff. We're doing our best. This goes hand-in-hand with RFC responsiveness.

We're working out our patterns here. But a lot of this for a while was around the fact that the committee was a little short on folks. We had a couple of people go on vacation. We had a couple of people leave the team. We think we've backfilled that pretty well now. But yeah, you should hold us honest.

And if we're not being super responsive here on RFCs, let us know. Part of this, though, is that we will affirm that the RFCs that no one has committed to implement are going to be our lowest priority. And actually, if you see the pattern that our team generally follows, they'll submit an RFC. And then they'll go start implementing.

And then we'll come back with some feedback. And the implementation is already there. And we can kind of play with it. And you can give feedback on the implementation that drives whether or not you end up accepting the RFC. There's a couple rounds of revision. It's a much easier thing to do than say, hey, I don't want this feature. But it'd be great if you did it. So everyone debate this five-page RFC

that no one plans to implement, those are going to be at the bottom of our stack, generally speaking. So if you tell us you're going to implement it, it'll be a higher priority. Breaking changes, same sort of thing. We talked about this feature flags, the ability for us to sort of signal breaking changes in the future. That's one thing we want to start looking into.

But also, we just need to be a little clearer on what constitutes a breaking change, what doesn't. We do have a pretty good breaking changes document in the PowerShell repository. But now that we've moved to 6.1, we want to make much smaller breaking changes than we were willing to make in 6.0. So we haven't really figured out that criteria yet.

If you guys have any thoughts, please let us know. But definitely, I want to do a better job at communicating what kind of criteria we're using to make these decisions. Lastly, reference documentation. This is absolutely not a call out to the documentation team. As the engineering team, we have taken ownership

of the reference documentation. We know that we've not been doing a great job there of documenting new features, parameters. There's even some stuff from 6.0 that's missing from the documentation. We are taking steps to address that. And we have a couple of new doc writers that are happy to backfill some of that for us.

We've got Bobby sitting up here in the front. I don't know if David's in the room, but no. But yeah, no. We're trying to do our best there. And definitely, if any of you can help out with documentation, we're always happy. But we do know that it's our burden to bear, and we should get that fixed. Quick call to action.

Please use PowerShell Core on non-Windows platforms. Use it on Windows too, but especially use it on non-Windows, because we want bugs, and we want to know about your scenarios and where you're hitting stuff and all that good. File issues. Contribute code. Contribute docs. As we showed yesterday, you don't have to be a Git Pro or a C Sharp guru or whatever to contribute.

Sometimes it's fixed in typos. Sometimes it's an off by one bug or whatever. There's all kinds of ways that you can contribute. So the repo has a lot of these up for grabs issues that you should definitely check out. Join the PowerShell Core community call. We do this the third Thursday of every month. Unfortunately, we do have to cancel it next week.

And I need to send that out due to the PowerShell conference EU. But generally speaking, we do a call. It's an hour long, 9.30 Pacific time. The whole committee is usually on it. We take questions. We talk about stuff we've been working on the last few weeks. We have design discussions. It's a very two-way conversation.

Has anybody in here joined the community call before? Cool. Awesome. Do you guys like it? Yeah, OK, cool. Yeah, so we think it's great. The PowerShell RFC repo has a community call folder. And if you hop into there, we've got links to YouTube where we've had past community calls, chat transcripts from the Skype meeting, that whole thing.

So definitely check that out. And please, please, please port your modules to PowerShell Standard. File issues, upload them to the gallery. Universal modules are going to be what helps us all succeed and make the PowerShell ecosystem grow to its new platforms and new CLRs and all that.

So definitely give that a look. And give feedback to the product teams that own PowerShell modules, that don't support PowerShell Standard. I know we always say this. I'm really not saying this as a backup. We need this in addition to all the efforts that we're doing internally. But the more they hear it from you guys

that they need Exchange Online working in PowerShell Core, the more we're able to actually make that happen. I had large scale customer reach out. I need AD on PowerShell Core. I couldn't find the ADPM who owned that thing until that came in as a customer request via support. Came to me, OK, we're motivated.

We want to do this. How do we make it happen? So those are the sorts of conversations that I want to have. And I can only have them when you guys are yelling at the teams that actually carry the workloads on this stuff. So I'm at 2 43. I think I'm supposed to stop at 2 45. Is that right?

Excellent. All right, so I know people will want to get to 3 o'clock sessions, though. So with the 15 minutes, would we rather go over high level roadmap of OpenSSH or PowerShell standard demo? SSH?

Standard demo. All right, we're going to do SSH really fast and then we're going to do standard demo. All right, who knows what SSH is? Awesome. So for those that don't, OpenSSH is a suite of tools that lets you do public private key pair management. This is, you know, I've got a public key that I share with everybody and a private key that's

basically my password. Remote authentication administration, right? This is PowerShell remoting before it was PowerShell remoting, right? I connect to a terminal on a server. I can run commands in that terminal. I really don't like that microphone. Whacking it. Secure file transfers as well. We support SCP, SFTP. This is how you securely send and receive

files with public private key pairs for authentication. I also got to give a shout out thanks to the OpenBSD Foundation, the OpenSSH, and LibreSSL projects. You know, everything that we're doing here with OpenSSH in Windows is all derived from their code base.

It's 20 years old. It's done a phenomenal job. LibreSSL is awesome. Response to OpenSSL with the whole Heartbleed thing. These guys are great. We love them. Do they? They have a great sense of humor too.

So Win32 OpenSSH includes this list of binaries. It's pretty much everything you'd see in a typical OpenSSH package. We've got an agent that runs as a service for managing your keys and memory. So definitely check that out. All this today is on a GitHub repo, PowerShell slash OpenSSH.

But we are now shipping all of those bits inside of Windows. So in the next major release of Windows Client and Windows Server, you will see a client, an SSH.exe, that is turned on by default. So fresh, whatever

the next creator's update. I don't know what they're going to call it. But you get one of those machines. It's RS4. I'm not supposed to use the RS terminology, but it's on Wikipedia. So it's the next one. It's the next one that hasn't come out yet.

I know everybody knows the RS. It's like Ars Technica, whatever. Yeah, it's soon, the soon one. Client will be on by default. You'll have SSH.exe from CMD, PowerShell, everywhere. We made sure to put that at the end of the path so that we won't break any of you that are already using other SSH implementations.

The server will still be optional. So most people's dev machines, they don't want to just have SSHd installed and or running on their machine. So you do have to install that as a feature on demand. It's pretty easy to do. The instructions that I had for fall creators update

when we shipped this as a beta, about 80% of that can be thrown out the window. So it's just the 20% of install the binaries, start the service, and you're going to be good. It will not be beta. It will be production and supported. So that's the big, yeah. We take the beta out. Thank you.

Both will be production ready. What we don't have plans yet to do is to support the GitHub binaries downstream. So today, we're saying those are community supported. We're still firmly committed to testing against Windows 7 and Server 2008 R2. We know that we work down to those operating systems.

But we don't have a strong servicing channel yet. So even with PowerShell, we built an MSI. This is going to work through Microsoft Update so that if we have a critical security fix, you're getting it through your typical update channels, SCCM, WSUS, Windows Update, et cetera. With these GitHub builds, we don't have an installer technology yet that enables us to do that.

So I've been talking with Darwin Sanoy, who owns the Chocolaty package. We want to figure out how to get to that point. But today, just know that if you're picking up the GitHub bits, you can't pick up the phone and call us for support. The only one that we're currently supporting is the one shipping in Windows that doesn't have that beta next to it.

Both of these are optional features on demand, though. So if you do want to use the GitHub ones on new machines, because the GitHub binaries are always going to be a little bit more up to date than the ones shipping in the OS, you can uninstall the client and server features on demand so that you can install the GitHub builds.

So our next plan is there. Get upstream is a huge goal. We don't want to own a fork. We want to work with OpenSSH upstream, make sure that all the goodness that they give, we get, and all the goodness that we give, they get. And we want to investigate filling out this longer tale of unsupported features. There's a couple weird esoteric SSHD config keys that don't work today.

I saw the other day, like, SFTP truthing doesn't work right now. So some of this stuff, we're starting to fill in over time. We need the servicing model for downloadable platforms. Do any of you guys have features that you need, absolutely, on Windows SSH? So yeah, so I'm making NRPS session basically take the same UPN kind of format that SSH takes.

File merged? Oh, holy crap. This is Mark Kraus, everybody. He's way ahead of me. Awesome. Definitely check out Richard Sidaway and Anthony and Santino's talk on SSH tomorrow.

Unfortunately, you were in here with me during Anthony's other talk on SSH internals. So since you missed that one, definitely check it out on YouTube as well. I have a survey here. If everybody could please write this down, take a picture. This just went up. Just some basic stuff about PowerShell. I swear it won't take you more than five minutes. It's like four questions. Three of them are radio buttons or checkboxes and stuff.

So please just take five minutes and help us make PowerShell better. Now, let's do it. OK, any more questions before I jump in on the demo? All right, so this is kind of a weird demo in that I decided about three hours ago

that I was going to try and get a random community module working with PowerShell standard on PowerShell Core. So I went ahead and cloned the, how many of you are familiar with Posh SSH? I cloned the Posh SSH repository. And I pulled up a blog that a Windows developer

wrote on converting your CS Proj from .net framework to .net core, .net standard. And it basically said, hey, go and delete all this stuff. So I popped open a CS Proj. I mean, this is literally all I did. Opened a CS Proj, changed this top line to use project SDK equals this. I changed the target framework to .net standard 2.0,

whereas before, you'll see on the left here, it was target framework version V4.5. And then I just went and deleted all this stuff that this blog told me to delete. Delete, delete, delete, delete, delete. All this stuff. Yep.

The only thing that I didn't add myself were these lines over here. So there was, Carlos was using SSH.net sitting right in the repo. I decided to actually delete those and use the .net CLI to add references to the NuGet packages. So if we actually go to NuGet.org.

Of course I'm not on the wifi. And this is, oh God. This is gonna pop my default browser, isn't it? Of course it is. It's probably gonna start playing music in a second.

Summit 2018, yep. So if we go to NuGet.org, right, you'll find a package like SSH.net. So all you gotta do here to find out if your dependency's working is you look at the dependencies

and basically if there's a net standard that is 2.0 or lower, you're good to go. So I take this .net CLI command and I run it from the directory where my solution file is located, or my CS Proj file is located.

And of course, okay, of course. I installed .net after I started VS code. So if we go to, thank you.

That leading slash, okay. So if I do this, it'll probably say something like, oh, you already have that or whatever. But basically, when you add this, it adds this line to your CS Proj and now you'll automatically go get

all of the dependencies when you use .net. So after that, all I had to run was .net restore. This goes and gets all of the dependencies that I need for my build. And then I run .net ms build. This compiles my whole build. I did this the first time

and it complained that I was missing references to Win32 registry. So if we actually look in this file, there's a call out of using Microsoft.Win32. I did the same exact thing. All I did was go up to nuget.org. I searched Microsoft.Win32, because that's the name space.

I only needed the registry type, so I took that one and I just added it. That was it, right? It had .net core app 2.0 and .net standard 2.0, so I was good to go. And again, I have never done this before. And actually, Rob, peeking in the room right here, was helping me out a little bit.

But it's like four .net commands and like a little squiggly and you go to nuget and you add one more and then you run your MSBuild and you get this thing. I did a .net publish and that takes all of the build gobbledygook and it puts it into one folder here. So I go to bin, debug, net standard, publish.

I had to copy a couple files that were needed for the overall module, because it's a hybrid module, so it has a PSM1 in the root of the directory, a couple PS1s that get used for functions, the PSD1, so I just took those. I know this is not the best way to do a build

and we can make this all work in MSBuild, but I did it at noon. So, copied those files over and then I just imported the PSD1. And it told me that it couldn't find this thing, of course. Because I'm rnc.ssh.net.

So .net core can't unload DLLs in memory,

so there may have just been something weird where I had something screwed up in that session. Keep that in mind when you're doing this. .net core cannot unload DLLs in memory, so if you've already started a thing, you did an import module, it loaded a DLL, and then you rebuilt the DLL, you need a new PowerShell session in order to test.

So it's just kind of a gotcha. It is, it's unfortunately a design principle of .net core. But bin publish, bin debug, net center 2.0 publish.

Oh, you're killing me. Just when in doubt, keep running .net restore.

I swear to you guys, I was so excited that this worked.

It probably is, yeah. It's probably literally the PSD1 that is complaining about this required assemblies.

Oh, because it's in assembly slash whatever, okay. It does, we don't really respect that right now. There you go. Boom, imports, okay. So now we can get command dash module posh SSH.

So now here's the really cool thing. I can use posh SSH with a new SSH session. Thank you. I only yelled at everyone yesterday during the lightning demos and didn't do it myself.

So there you go, there's all the modules. They all imported just fine. And if I actually do this with local host, this is running, so this is win32 open SSH. New SSH session posh SSH is using SSH.net, a completely independent SSH stack,

which means that we are fully interoperable. Of course I put the wrong password. You guys are very patient people.

Demo gods are screwing me, man. I did this three times in my office.

It should be, it probably would make the whole, the whole thing work better. Maybe I need capital?

Absolutely it will. No, nope, that's SSH saying you're trying too much. I'm making you wait longer.

Sorry guys. I am sad. Oh man, I even closed the window where it worked. I swear to you, I had a local host, made the connection, didn't invoke SSH command

against that guy, and I was getting command line output from my local thing. That sounds like a good plan. Let's try, maybe local host is like overridden on this network.

Sometimes that happens, right? I was reading, no, IPv6 local host is like, when local host only resolves the IPv6 and you're somewhere where IPv4 is needed, like all kinds of stuff happens. Ubuntu VMs alone, apt-get, crap.

Local host. You are absolutely right. Poor. But I will say, the magic part was that

I recompiled it three times in front of you guys, and I'll tell you, if you try to compile it everything is net standard with no modifications. The point I'm trying to show here, this thing clearly works, right? It just found the fingerprint, it's loading this DLL, everything is net standard compatible the whole way down. This was 20 minutes of refactoring.

Like, the promise that we're bringing with PowerShell Core and with that net standard of you being able to just do the recompile and have your stuff work is real. I didn't pick pasta sage ahead of time. I went into GitHub and sorted my popular PowerShell that has C sharp as the primary language. That was it.

So, if this is going through Win32, network APIs, cryptography, and establishing a connection, like, it's one of the most complicated sets of libraries that you can deal with, so just try out standard. We think it's gonna make your life happy. Little anticlimactic, I apologize, folks, but hopefully this session has been informative

and I appreciate you all coming. Thank you so much.