Transcript

Yeah. So thanks for inviting me. I’m very happy to be here. I’m going to be focusing on PowerShell 7, but I want to cover some of the history. First if you don’t know who I am, just a bit about me. As introduced, I’m the engineer manager for our PowerShell team. I’ve got 11 engineers on the team, so not a huge team, but I do work with four different program managers, some of whom you may be familiar with on Twitter, like Joey, Sydney, Danny who also does OpenSSH work with me, and our new PM, Jason Helmick who’s pretty well known within the PowerShell community.

I’ve actually been at Microsoft for almost 20 years. My actual anniversary for 20 years will be in January. I’ve been at Microsoft for a long time. I’ve only been on the PowerShell team about, I’d have to figure out backwards but maybe about four or five years. Before then, I spent a lot of time on WMI. My first project at Microsoft was actually Internet Explorer for UNIX. But shortly after that, I worked on the WMI team doing an Out-of-band deliverable for NT 4. So that, kind of really dates me. But I was there when we first started the Win Rm project. I was there when we wrote that spec for the [inaudible 00:01:11] and all of that stuff. But I put all that behind. So I’m really focused on PowerShell these days.

In terms of what I actually own, or what my team owns, we own everything from the GitHub, for PowerShell, the PowerShell Gallery. And our services work on VS Code, PSScriptAnalyzer. I do own the OpenSSH project which isn’t directly related to PowerShell. But we do have PowerShell remoting over SSH these days, PSReadLine and PowerShellGet. So one thing that is no longer on this list for me is actually Windows PowerShell. That has been handed off to another team within Windows to own servicing. And I’ll talk a little bit more about that later. Finally, as mentioned I don’t tweet a lot. I’m not really big on the social thing. But I do respond to questions. And I do provide updates, where I think it’s interesting about what’s happening within the PowerShell team.

So let’s first go a little back in history. So Windows PowerShell 5.1 which is probably where you started. This is the latest version. There are no plans to update the version that’s in Windows. That means that there’s no expectation that there’ll be Windows PowerShell 5.2 or Windows PowerShell 6 or 7 or anything like that. Windows PowerShell 5.1 is the latest. If you’re on Windows 10, there are small changes that may happen in Windows PowerShell 5.1 for compliance reasons or [inaudible 00:02:29] reasons.

Also, I want to make clear there’s no current plan to remove Windows PowerShell 5.1. It’s kind of like the Windows Terminal team cannot remove cmd.exe. There’s just too many people depending on it. [inaudible 00:02:41] part of the Windows operating system. So you can expect that it will be there for indefinitely like there’s no plan to remove it. But it is fully supported but supported here means that if you have a critical issue, you can go through support, and also there’s critical bug fixes that go in. But there’s definitely no new feature work. All the things that we’re doing in PowerShell Core or PowerShell 7 have no plans of going back to Windows PowerShell 5.1.

The way you should think about it is Windows PowerShell 5.1 is complete. It’s done. One of the features, I guess you can think about it, is it’s very stable, because there are no changes happening within the Windows PowerShell 5.1. So my recommendation is if you have existing business workloads on Windows PowerShell 5.1, there’s no reason to roll it off of 5.1. If you’re producing new automation, and you want leverage some of the new stuff, then you can use it side by side. And we’ll go over some of those details later.

Okay. Let’s talk about what’s happened since Windows PowerShell 5.1. I pretty much joined the PowerShell team when the idea of taking PowerShell Open Source and also cross platform came about. It was originally announced [inaudible 00:03:49] it was announced in over three years now. So we announced it back in August 2016, that this was even happening. The big change really is moving from .NET Framework, which is shipped in Windows, to .NET Core, which at the time was a very new thing. At the time, we were doing PowerShell Core 6. I believe .NET Core was on version 1.1 or 1.2. And they’ve come a long way since.

One of the big things is really providing PowerShell as an information platform and also a shell for beyond just Windows. Windows PowerShell obviously started within Windows. And one of the things we wanted to say or do is how can we attract new customers to PowerShell? And the way to do that is look beyond Windows. And one of the key things that we decided early on is if you want Linux adoption, then you have to be Open Source. And if we’re Open Source, we can also get contributions from the community which has actually provided a lot of great features and bug fixes in PowerShell Core.

Then following this timeline, we GA’d the first version of the Open Source PowerShell, PowerShell Core 6.0, January 2018, so almost two years ago now. So before I move on, I just want to see a quick show of hands, how many of you have actually used PowerShell Core 6? So most of you. That’s good. How many of you are playing with PowerShell 7 at this time? Not many. Okay, thanks.

So I can go through a history, PowerShell Core 6 Roadmap. 6.0 was Open Source the first, really the big feature set of PowerShell Core 6.0 was making it Open Source. It was a ton of work because we had a lot of, for example, tests in the Windows data on the first repo. We had maybe something like 100,000 tests. The problem is all of those were… the best way to put it is they only worked against a proprietary test framework that was never planned to be made Open Source.

Also, when we did a bunch of analysis early on, there was a lot of redundancy in the test cases. So for example, if you do code coverage, we found that certain part of the code was actually hit by five different tests. So there was a lot of redundancy. One of our early decisions was actually to write a bunch of new tests in Pester and make those Open Source as well.

Six months later… back in the PowerShell Core 6 timeframe, we kind of shipped new minor versions every six months. So for 6.1, the focus was really, now that we have a base platform that was cross platform, it was Open Source, we really want to focus on Windows PowerShell compatibility, so that people who are using it could use it on Windows and have a great experience. A lot of the effort was actually not so much in PowerShell Core 6.1 by itself, but taking resources from my team and actually working with partner teams in Windows to really validate that their inbox modules worked with PowerShell Core 6, and making changes on their behalf, and submitting Core requests to those teams to get [inaudible 00:06:42]. I believe, and there’s a blog post by Joey on this, I think we hit something like 60 maybe up to 70% compatibility with a lot of the modules that shipped with Windows.

On the 6.2 timeframe, this would be six months after 6.1, we focused a lot of the team’s effort on release automation. So this is where we moved off of AppVeyor, and we moved entirely to Azure DevOps. One of the reasons is that we didn’t want to maintain two different CI systems. It made sense to kind of use Azure. We’re also Microsoft, so it made sense to do that. But Azure DevOps at that point had matured enough that we could actually rely on them for our releases and also for our CI. We had to spend a lot of effort to automate a lot of our testing, because we released a ton of Linux distros, different versions of Windows, things like that.

So we spent a lot of effort. And we basically reduced a release… Because we release previews every month, it took about five calendar days approximately with like three engineers working on a release down to about, depending on if there’s issues, about two calendar days with like one and a half engineers. So it was a significant effort. My plan is to eventually maybe at PowerShell Summit have some of the engineers who worked on this to kind of talk about their experience. Because, we use PowerShell a lot to do the automation. So they can hopefully show you guys how you guys can do that yourselves for your own projects.

All right. So now we’re moving to the future here, we’re talking about PowerShell 7. So the first thing you notice is that we dropped Core from the name. Similar to what .NET Core is doing, they’re dropping the Core name from .Net Core with the next release which is .NET 5. So the big thing here is really, if you have been using PowerShell Core 6, you should not think of this as a new version that has like a bunch of breaking changes. This is really conceptually PowerShell Core 6.3. But we really wanted to drop the Core name, because I think it caused a lot of… Some of the feedback we got from customers is that, when they see the name Core, it means smaller. And when they say smaller, it means like a sub part of the capability of PowerShell. So really we want people to think of this as the PowerShell. So now it’s just known as just PowerShell, PowerShell 7.

One of the big efforts that we’re focusing on PowerShell 7 is to say legitimately that we believe this is a viable replacement for Windows PowerShell for your daily needs. And I’ll show some demos and talk about some of the things that we did to make that happen. We are relying, and one of the reasons we’re able to make this claim is that .NET Core 3.1 is what we’re actually going to be shipping with. It has actually brought back a lot of the .NET APIs. So it’s actually much more compatible with .NET Framework modules. Otherwise, it would have been that much harder effort on our part.

And we also spent a lot of effort bringing back a bunch of the old Windows PowerShell cmdlets. And I’m going to have demos on all that. And also some work still within Windows, so we kind of looked at the remaining set of modules that we weren’t able to validate in the PowerShell Core 6.1 timeframe and do some additional validation and working with those teams, and get those modules in Windows 10 marked as Core compatible. So again, you’re not going to get that if you’re on a down level of Windows. When I say down level, I mean like Windows 7, Windows 8, 8.1, stuff like that. But you need to be on Windows 10 or Server 2019 to get the native Windows in-box modules to work with PowerShell Core or 7.

Okay. So let’s talk about the PowerShell 7 roadmap real quick. Hopefully everyone saw the Preview.6, which is our last preview for PowerShell 7. It was released last month. The plan is to have a release candidate released probably next week, maybe like mid next week or so. We’re working on that right now. Well just [inaudible 00:10:32], we haven’t started release yet. We’re getting some last minute changes in, before we actually kick off to release. We’ll probably start the release process on Monday. And if anyone in the room has been contributing to the repo, it means that anything that’s [inaudible 00:10:45] is not automatically in PowerShell 7 at this point. We actually cherry pick specific changes that get approved. Then our current target is to have general availability next month, which will be January.

So one of the big changes with PowerShell 7 is actually the support life cycle. So with the PowerShell Core 6, we were aligned with what Microsoft calls the modern life cycle. That means that after a release, then the previous release… So after release 6.2, then 6.1 was on a six-month life cycle. So that means after six months, we will not support it anymore, which means that you’re not going to get any updates at all.

So with PowerShell 7, this will be our first LTS, long term sourcing. So this is because it’s also based on .NET Core 3.1, which itself has Long Term Servicing. Long term here means three years. That means that if you deploy PowerShell 7 in your environment, you will be guaranteed three years of support [inaudible 00:11:39] .NET Core. So technically, because .NET Core 3.1 shipped this month, it will be three years minus one month. Because, it will be one month behind.

[inaudible 00:11:48] will provide security fixes. If there’re critical issues that prevent you from using PowerShell 7 [inaudible 00:11:53], we’ll look at that. We’ll provide those fixes. So you can depend on that for the next three years. And that also means because PowerShell Core 6 was on the old modern life cycle, then 6.2 will end support. That’s after PowerShell 7 GA. And if we GA in January, barring any critical problems, that means that we will no longer support 6.2 in July. July will be the last time that you might get an update.

So let’s talk a bit, before I hop into some demo stuff, what it’s going to look like after 7. Our current plan, and everything’s subject to change, we’re going to align with .NET’s yearly release cycle. That means that the next release will probably be called PowerShell 7.1. And it will be based on .NET 5. And then the one after that will be 7.2. And that will be based on .NET 6. So currently .NET’s team’s plan is to have every other year be an LTS release. So we’re going to align with that, because for us to have a long term servicing support, we need .NET to also support it Long Term Servicing.

So that means that if you’re on 7.0, then you can stay on that for the next three years, but I expect that most customers should probably move to 7.2, which should be two years after that [inaudible 00:13:05] three years again, starting from that point. [inaudible 00:13:09] unless .NET team changes their plans, we’ll probably stay on this plan. There’s currently no plan barring any major breaking changes, something like that, to have like a PowerShell 8 at this point. We’re not going to align with .NET’s versioning, jumping to major versions all the time.

So one thing I’ll mention here is that there’s also currently no plan to ship PowerShell 7 in box in Windows. And the reason for that is not because we don’t want to. There’s no technical problem. It’s really about support. .NET Core Long Term Servicing, the longest support they provide is three years. Windows Long Term Servicing is actually five plus five. So we have five years. And then they have five years extended. So three years is much less than 10 years. So currently, we can’t close that gap. We’re still working with the .NET team, seeing how we can resolve that. Because I know for a lot of customers, it’s very difficult to be able to install something in their Windows environment, even if it’s signed and produced by Microsoft.

Now in terms of actual Windows PowerShell compatibility within PowerShell 7, as I mentioned, some of the modules that are shipped in box, we’ve done the validation, where we’ve worked with those teams to make sure they actually work with PowerShell 7. So those will just work. But then we have this new feature that came in Preview.6, which is, if you try to import a module that is in Windows, so it’s under System32, and it is not marked as Core compatible within the module manifest, there is this compatible PS editions that indicates how it’s compatible. I’ll show them [inaudible 00:14:42] later, make it more clear. The idea is that we can actually leverage an existing PowerShell technology called [inaudible 00:14:47] remoting. That way we can actually call out to Windows PowerShell to actually invoke that cmdlet within PowerShell 7.

So for those of you who are familiar with the Windows Compatibility Module that we shipped… To be honest, I don’t know exactly when we shipped it. I think it was in the 6.1 timeframe. That uses Win Rm remoting. So the big change here is actually this is not a separate module. It’s changes that we made in the PowerShell engine, and it’s using the PowerShell jobs infrastructure. So it’s actually talking to another process and doesn’t require a Win Rm to even be enabled.

So before I jump into a bunch of demos, I just want to see if there’s any questions so far on any of the content I’ve already provided. Let me just [inaudible 00:15:33] PowerPoint real quick. Let me go into Windows. I use a MacBook as my regular daily to self host, the non-Windows built. All right. [inaudible 00:15:56] so much about VS code on the left. That’s just to help me remember what I plan to demo.

All right. So in PowerShell 7, Preview.6 here… So the first thing that a lot of people will notice the very first time they use PowerShell 7 is errors look different. So actually, before I show… [inaudible 00:16:22] Windows PowerShell real quick [inaudible 00:16:25]. So if you have an error, then it’s -childitems… This is not a good one. [inaudible 00:16:38]. I think this whole… Yeah. Okay. So you get these errors. And one of the complaints or the feedback we get from customers is there’s just too much red on the screen. It’s like there’s a lot of information here that just doesn’t help them. So one of the big changes we did is we really just made it a lot more terse. So it’s more concise. This is a new view that you can change if you want the classic one.

Right now by default it’s going to be in concise view. But if you really want to go back to the old style, you can go to normal view. Like if I do the other one, ChildItem -foo. You can kind of see, like you have an error message. It tells you exactly what the problem is. And again, if we have bad error messages, you can just tell us, we can fix those things. You don’t have to worry so much about all the other information that you would normally see like here. Most users would not actually find it useful. They actually find it confusing.

Now if you’re a developer, and you actually want to get more rich information, then we have a new cmdlet get-error that actually gives you a lot more information. So this is actually more than what you’d normally get under normal view. You get stuff like the Stack Trace, the C# Stack Trace. You can also get the PowerShell script Stack Trace. So this will make it easier to debug what the problem is. And let’s see, if I do… multierror. So the script has a bunch of errors in it. And you can kind of see also, when it’s a script, we have coloring, which I believe helps. Because, not everything’s just red now. But it also tells you this is on line three. There is this thing. Here’s the error, what the problem is.

Again, if I were to run get-error, or I can do the alias gerr, then it tells me what is the last error. But of course, if you just look at… This will also work if you want to look at that particular error. So this will be probably one of the first things that people notice right away that is different in PowerShell 7. Again, you can always go back to the old behavior if you prefer that one, [inaudible 00:18:43] because I’m not going to remember it.

All right. Let’s start over here. So in PowerShell Core 6, we made a lot of investments besides making it Open Source and cross platform, to make it a great experience to use in cloud workloads. And the way we’re thinking about it is really calling like REST APIs and importing or working with JSON. So here, I can show it from the Windows PowerShell. Let’s clear this. So invoke-rest method, and I’m [inaudible 00:19:19]. In this case, this should fail, because I’m not authenticated. So you’re going to get this error message. And there are going to be a lot of scenarios where you want to be able to handle this error and do something with it. There may be information within this http error response that tells you what you need to do. So in Windows PowerShell you’ll probably have to do something like you have to wrap it in a try, or actually you can also do a -ErrorVariable e, I can do it like this.

I should have, this is a Terminator or there’s still this up, but anyway, you can kind of see, it becomes difficult to manage the situation. So one of the changes in this, I came from the community that if I spell it, right. You had to -SkipHttpErrorCheck. So it takes me what’s happening. The web commanders, both invoke web requests and also invoke Rest Method, have a code internally where if the response is a failure, I mean the http status code indicates a failure. Then it will turn that into a [inaudible 00:20:39]. So this will suppress that behavior. So again, if I, this is my buffer and now you don’t see the red because it’s not an error, right? So it’s an HTTP error, but it’s not a PowerShell error. So I can also do stuff like, what is it… Like I can get a -StatusCodeVariable s. -ResponseHeadersVariable h

So now if [inaudible 00:21:24] I can see that this was a 415. Um, I don’t recall exactly what that means, but it’s an error in HTTP. And, I can also look at all the headers that was returned. So basically I can now have more advanced groups where it can handle, error conditions when I’m calling Rest Methods.

Let’s talk about some of the language features. So one of the things we did with the PowerShell 7 planning, is we looked at all the top issues that were voted on by the community, in the GitHub repo. So we looked at stuff where people gave a bunch of thumbs up to issues that were open. And these language features were really that some of the top voted ones. So the first one is a no conditional number, property and method axis. Um, this one is actually gonna have a [inaudible 00:22:07] in PowerShell 7, but basically the idea here is, right now Darson 8 doesn’t contain anything. Let me go back to Windows PowerShell show this whole [inaudible 00:22:18] I actually need to get, okay. So let’s say, let me get up [inaudible 00:22:26]

So this is a method access. So if I do this, it’s not going to work because a is null so you can’t call two string on it. With the new syntax and I know some people would not like a requirement to have braces, but it is required. And this won’t fail because now following, if you see a C# in syntax, this will say only call this method if this part is not null. So if I set a = equal something.

And now if I close this again, then this will actually work because now this is not null. So basically the idea here is you can not, you don’t need to have a bunch of checks against null. I mean, you still have to be careful here because you could have other logic in your script that does bad things. So it should be [inaudible 00:23:17] the idea here is that you don’t need to now explicitly check if a is null or not null before you call its method. Similarly you can also put for a raise. So if I do something, I have to do a new verbal like this, right. Then it won’t work because b right now is null. If I do again, the raises is required because in PowerShell, you can have a variable that has a question mark on the end.

So I could actually do something like, you can argue whether or not you should do that, but there are other languages like rust that actually recommend anything like a question mark at the end. So rather than doing something like $isadmin = $true or something like that in rust, you would do something like $admin? = well if type it right but it’s now null is all because [inaudible 00:24:09]. The idea is here we didn’t want to break customers who were already using variable names that have question marks in it. So it requires some braces and just so you know this is not new. This is the existing PowerShell [inaudible 00:24:20] that you may have already been using or not. But if I now make b this and that works right? So again, previously nothing happened because the theme was null, but now that I can find it [inaudible 00:24:41] index zero. So I get the second element.

So let’s talk about null coalescing and assignment now. S.imilarly you know, a lot of this is really about making it potentially more readable. I think if you get used to the syntax, it actually makes it more readable. But if you’re new to it, it can actually be a little bit confusing. Here again, so b is already used, so I’ll use c now, so c is null. I want to do something. If c is not null this or in c is null here. So in this case, if it is null it’s gonna do that. If I set it, then it’s going to return that value. So the idea here is that if c is null, then it’s going to return wherever this other part is. But if c is not null it’s going to return a value, that means I can do, let me see. What’s the real world case would be something like $isadmin = $user ?? “no user”

This is just made up here of course. But $user right now is null. So then $isadmin is going to contain no user, right? But if I then set $user = to something else, I run that same code now, because $user is not null then $isadmin shouldn’t be “me”. This is gonna ideally save you some checks against null. So similarly, assignment works very similar. So let me pick another thing. So here, because d was null at the time is going to equal “hello”. I’m gonna change this to “bye”. So now because it’s not null, then it shouldn’t be a sign. So now d should still be hello, right? So the idea here is only assign it if it’s null, otherwise don’t change the value.

Ordinary was a popular request. So let me see in this case, it’s gonna be a little bit different, I can do something like, so we know that’s true. This equal to hello. Say yes, otherwise you can say no. And we know, of course it is. So the idea here is if this condition that you’re checking is going to be true, then OB you’ll return to this first thing otherwise you’ll return to the second thing. And you can also e equals the [inaudible 00:27:33] and of course it should be the first one because d right now is still set to hello. Again, this is very popular in other languages and you don’t have to use it. It’s just an option. Extended Unix file system info means I have to actually hop back.

Right. Those screen there. So this is, if you’re a Linux user, a bit bigger. All right. And then if I can, I don’t know if I have.. Gimme one second I think this will start PowerShell 7. I actually want to start 6.

So this is PowerShell 6.3. If I do a dir here, what you’ll see is this is exactly what you would get on Windows, right? So you got this mode information and some daytime information and some Linksys file name, but a lot of Linksys are accustomed to doing the long format of LS. This is a native executable on in this case, on my Mac iOS. It gives you a lot more information about the user group and who owns the file and all that. So one of the changes that Jim made is equivalent and PowerShell. So again, this is [inaudible 00:29:12] item, and now he’s calling some native APIs on unique systems. So this only shows up on Unix, but it shows you like the user information, the group information, basically the equivalent of what you do with LS-S.

Oh, okay. So let’s have completion. So, one of the things that bothered me for a while, was I’ll go into Windows PowerShell to demo. So if you want to change your action preference, right? And you want to know, “Hey, what are all the options available?” You have to use something like this. And then you have to look at the error message and it tells you, “Hey, these are the allowed values. You can’t just put in this garbage.” So one of the things we changed is actually, you can tap complete on that now.

Oh, This works for any variable whose type is an enum. It also works if you add constraints to a variable, I do something like that. And if I do, $i =… this is what happens when I do a live demo. I’m missing something here. Ah I forget my Syntex. All right. Rather than try to get that working right now, I’m going to actually show a different one. Enum it can be animals–’tiger’, ‘lion, ‘bear’… I shouldn’t do things live. I know.

All right, I have to think off the top of my head. All right. I know. Believe me it works., I can’t remember exactly what that enum, Syntex and PowerShell right now. Let me skip ahead. Oh, actually I want to show you error action preference break. Let’s go to that again. All right so again, $ErrorActionPreference. So this is a new one that was added by Kirk Munroe, actually. So now here is you have a script and actually I do have a script because I have that multi one, but this one, all this does is actually have a bunch of errors in it. Then if I were to run it and it’s actually going to break into the command line debugger immediately, so you don’t have to add like a [inaudible 00:32:27] debugger, things like that. Right so this actually makes it a lot easier to debug your script. I want to put it back to, I want to continue, I want to silence.

So Slick string, So this also came from the community. So to show you again, what it looks like in Windows PowerShell, have some text here, “this is a sentence” select the word “is,” here. Basically, if you’re actually, usually you would use like [inaudible 00:33:15], like a text file, they have a lot more content, but here, it’s actually an object if you’re not aware.

It tells you this is what’s selected here’s a pattern, but, basically this output isn’t as useful. So the big change here, I’m just going to type it again. They add emphasis. So it actually hit the first “is” I forgot about this one. If I add a spacer, I should do the second one. But the idea here is that nowwe can, because Windows now has GT 100 support. We can actually use that to show exactly where it is. This is the object. [inaudible 00:33:51]

Again, you can get the actual content, to do in your automation. And if you don’t want to see that, and then there is also a -NoEmphasis it should get back to previous behavior. But you know, one of the things you already saw, especially like GetError, we’re adding a lot more color and kind of highlighting. And I think it really helps to, help see information. So in this case, all the green are all the member names and all the, uh, stuff in the current color would be the content and all this is, user settable. So you can set these colors.

Hey Steve?

Yeah.

Are these features turned on out of the box or are they experimental or what?

Great question. So our policy has been that in preview releases, all experimentals are on by default, unless you have a setting style that disables something. Um, so that means that in preview six, if you never mess with the PowerShell configuration JSON file, then you would get all the features by default, because we want people to try them and give us that feedback. With the release candidate, that’s coming up probably next week. It is not a preview, but it’s not final either. But in that release, we are turning off experimental features by default. So a bunch of these features. So for example, the concise view and error get error is going to be stable so that won’t be experiments on them. So they’ll just be there by default. This was not an experimental feature. Anyways, the second one, the skip is we checked where the language features a ternary operator will be stable, no call [inaudible 00:35:27] assignment will be stable, the no conditional member property and method axis, which required the braces is going to stay experimental.

That means that, you can’t use it by default, but you can always enable the experimental feature if you want to use it. Just one clarifying thing here, experimental doesn’t mean its buggy, experimental only means that the design is not considered complete. It means that if we make changes to the design, it’s not considered a breaking change. Um, so that means that you should not depend on experimental features in production because we could change the design. But it does mean that you can use it because it is you know, fully tested and all that stuff. So it is intended to be stable from a bug perspective, but not stable from a design perspective. Let me see what else. So the extended Unix file system, if I believe this is going to stay as experimental, there may be more work to do there to improve the performance.

The variable tap completion is going to be stable or action preference [inaudible 00:36:25] stable, a selection emphasis is stable. The next one I’m going to talk about invoke DC resources is actually going to stay as experimental. There’s more work to be done there. But the idea here is we’re trying to continue to add some level of support to DSC. So just to be clear, DSC is its own team. I don’t own DSC at this point in time. So there is a whole other team that owns DSC. We have not had a lot of time to address some, but one of the things that my team did [inaudible 00:36:57]

There’s some quotes in there, Steve.

Oh excellent. I know it’s because these are like those funny quotes in vs code. Anyway, all right. So what are you complaining about now? I’m missing the equal sign too and the dash, I’m missing all the dashes. Any case, what’s happening here is that we may change this to invoke dc resource, so you can actually invoke it. And this will work on Windows and non Windows and it doesn’t require the local configuration manager to be on that system. We deliberately did this, so that people can actually use dsc resources directly and they can also use it on Linux. And Mac OS. In this case, what does it complain about through, and you can see, [inaudible 00:37:55] oh, come on.

[inaudible 00:38:06] given module specification. There should be on the system. It shouldn’t be case sensitive. Just something real quick here. I don’t have any resources because I didn’t install that one. Which is what [inaudible 00:38:32] module. All right. What happened to my Windows box? I’m going to give on this demo, but the idea anyways, for those who are more fancy than I am, is that you can use this method. I just commanded to call into a dc resource that you can call it test set get.

Let’s continue. The next feature is coming from the community as well. I don’t know if you’re familiar, but there is this thing called Azure Data Studio. It looks a lot like Visual Studio and it was just a Visual Studio Code. And basically it’s intended for working with databases like Microsoft SQL and stuff like that. So there are a number of PowerShell users that really do a lot of stuff with databases. I’ll go back to a Windows PowerShell difference here.

DBNull. So this will be false because these two things are not exactly the same. So the idea here is that if you were to query like a SQL table, then you can differentiate null meaning that it doesn’t exist versus DBNull. Meaning that it’s explicitly set to a null value. So the requests from the community is actually for them to treat those two as the same thing. So that in your scripts, you don’t have to worry about treating DBNull differently, a small change, but this is something that helps the community. And NullString is a similar, I need the value as well. You don’t have to check for these things. If you happen to have those in your scripts and you can just check it directly [inaudible 00:40:34]

Split with negative values is kind of cool. So I can do, “this is another sentence” so if you’re [inaudible 00:40:45] split, I’m basically just going to split the string, and I can split it by the spaces and I get a bunch of elements or strings and I can say like two. So this splits it into two strings where the first occurrence of the white space and then the rest of it. But then if you want a split it from the other side, so rather than doing it from the left side of the string, now you can do like negative. Now it does exactly what you would expect, which is split into two strings, but it starts from the right hand side of the sentence versus the left. Pretty cool little change for each parallel. This is a highly requested,[inaudible 00:41:28]

A highly requested feature. So this, this really came from PowerShell workflow, which is not supported because workflow is not supported in .NET Core anyways. So we couldn’t even enable even if we wanted to. But our feedback from the community is a lot of people use PowerShell workflow, really only for making it easy to run cautious groups concurrently. So, and the change here is really a great example here, but it’s going to show one to five, but if I add a sleep in here, that’s not going to help either.

These are actually all running on Parallel, right? So if I didn’t have Parallel here, it would all be running serially. So then each one is going to take its own half a second. You can kind of saw previously it was a lot faster because each of them are starting in Parallel. I think one of the key things to your end, the engineer who wrote this on the team, Paul had a blog post about this, that you should not just use this everywhere. It just doesn’t make sense. There’s actually a cost of starting up a thread in [inaudible 00:42:38] space. So if you just start putting everything as Parallel, you might actually, you could potentially have worse performance. What you really need to do is look at where you have, maybe you’re under utilizing the number of Cores on your system, or if you’d make it like a network request where it’s mostly waiting on something definitely makes a ton of sense to do it in Parallel. Otherwise you really should think about whether or not, doing it serially makes sense. So it’s not for every situation.

Steve question. Can you do that on [inaudible 00:43:09] hosts or is it local as to one host?

I’m sorry, can you repeat the question?

Can you, run up a little like with the run spaces, you can run it on multiple hosts

Computers, you mean?

Yes, yes.

So normally you would do something like invoke command to do it remotely, like [inaudible 00:43:32]. It doesn’t have a dash computer or dash [inaudible 00:43:35] session forever, but within the loop here, you can always do something like, invoke-command -session let’s say that this is a list of sessions instead of [inaudible 00:43:52], and then in here you could do your own script block here, right? Whatever this is. So you can certainly do it.

But it’s not part of the, for each object, command [inaudible 00:44:01] itself. Does that makes sense? You’d be trading a local run space for each invocation and the, each of those run spaces can actually invoke something remotely. If that’s what you’re asking,

The default throttle is five.

So the throttle limit by default is five. You can set it yourself, to have her. So, you know, we can’t guess what your system is capable of or what your scenario is, where it makes sense to have the number of threads spin up. So you can set it to wherever you want and you can set it, like MaxValued kind of thing, if you really wanted to. And again, it may or may not make sense for your specific scenario because it depends on what you’re actually doing in a number of Cores and number of [inaudible 00:44:43] on your system, but definitely play with that. You can always use measure command as a way to validate whether or not it’s providing you the benefit that you think is going to provide.

So the temp drive. So this is a small one. I’ll just Get-PSDrive here. And one of the things we added is basically temp will map to your temp folder on your operating system. So if you’re on Linux that maps to that temp folder if you’re Mac OS to that temp location. So now you can just [inaudible 00:45:15] see there’s a bunch of temp files in here. One thing that it doesn’t do, if you’re familiar with the test drive in pester, it doesn’t auto clean up. This is literally just mapping a shortcut to the temp drive. So you have to do your own cleanup if that’s what you want. A nice little thing.

How about abbreviation expansion? So, let me see I think I have Azure commands are very good examples of this use case. So let’s pick something like this one, a Wait-AzureRmRecoveryServicesBackupJob. So let’s say that you’re very familiar with that command but you don’t want to type the whole thing. So one of the things you can do is you just type all the uppercase characters, this case it’d be W you have to put the dash A R R S B J and then if you tap complete is actually going to expand it to the very verbose cmdlet. So this is intended for interactive use only. So if you actually type it like those a r r s b j and you hit enter, like if you put that in your script it’s not going to find it because we’re not going to expand it at runtime. It’s only expended for IntelliSense.

Because we already don’t want you to use aliases in scripts. It makes it less readable. We certainly don’t want like this to show up in a script. You don’t know what that means for the most part, unless you’re using something all the time that has, this very long cmdlet name. So let’s jump into the Windows side of things.

I don’t know if these are going to be very interesting demos, but you know, the clipboard commands are back. So I had that in my clipboard. I can also put stuff into my clipboard and if I right click then hello shows up. [inaudible 00:47:10] people may not be aware but in PowerShell Core 6, we actually didn’t have the clipboard commandments because they did pin it on windforms and windforms was not in .NET 2.X but they were added back in .NET 3. So we’re able to do this, and these are across platform yeah, as I mentioned, but they only work with text. So in Windows PowerShell that you could actually have, like files in there that is not supported in PowerShell 7 clipboard counter cmdlets. So this is again, back, this was not there before. And the reason it wasn’t there as it was using some private API. So we cleaned that up. So now we’re, we’re only using publicly documented APIs. You can work with the [inaudible 00:47:48] counters again, in PowerShell 7, the recycle bin.

This just clears the recycle bin yes. So not that interesting, but it wasn’t there before out printer as well. Get-HotFix is also back, I guess I don’t have any hotfixes because I probably just got a new update of Windows 10 on this machine. But the idea here is we wanted to add back as many of the cmdlets that were owned by the PowerShell team that existed in Windows PowerShell that was not in PowerShell Core 6. So we got most of them. There’s a few that are still not there like local counts is actually not shipped as part of PowerShell 7 because it’s not using publicly documented APIs. However, if you import that module, Microsoft.PowerShell.LocalAccounts.

There’s a different problem it’s because it’s using an assembly. I don’t think [inaudible 00:48:43] Yeah, it wasn’t imported. I think if I start a new session, because this one preview. I’ll make this bigger. Microsoft.PowerShell.LocalAccounts. Now there’s a conflict. I think it’s, unfortunately that’s not going to work, but local accounts is not there. There’s one that I never used before which is control panel is also not there because that’s using some [inaudible 00:49:19] necessary documented, and a few others. The [inaudible 00:49:25] commands are by design because we won’t [inaudible 00:49:26] use as some cmdLets. And the event log command is not there because they got, superseded by the win event cmdlets the old event log has only worked with the system application program logs. They don’t work with all the [inaudible 00:49:40] logs to [inaudible 00:49:42] even does. So we’re pretty close. There’s a few that are still not there.

Show the import when PS modules.

So Steve, you, you skipped the most important one.

Which one?

Grid view?

Uh, Oh, you’re right. Sorry. Okay. I don’t know if everyone, okay… so first I’ll mention, it does pop up behind them with the new Windows terminal that is a bug or an issue in the Windows terminal. If you actually do something like this, it doesn’t matter what it is, it’ll pop behind. So that’s something that they need to fix. All right. So don’t, that’s not something we can fix. If you don’t use that grid view, let me just explain what this is. Basically, this is kind of like format table, but it allows you to select items. Actually, I didn’t do the [inaudible 00:50:28] which makes this more interesting let me do that.

What a lot of people use this for is for two things. One is it can quickly, you know, be able to find something here. So, um, I don’t know if there has w and, and these are processes, or, there’s other criteria can use filtering, so it’s going to be redundant, but I’m going to do process name contains and all of these have a w and contain when but here, like I can select these and then if I hit, okay, then these get passed through to the rest of the pipeline. So I could actually have this in a script where I could tell someone, Hey, I could do like a get service. I could pipe it to out grid view, and then I could pipe that to stop service.

I probably wouldn’t recommend that, but the idea is that you can actually interact with select, objects to enact the rest of your script with and that’s what people use that grid view actually a lot for. That’s why there’s this PassThru. And this one isn’t available in PowerShell Core 6, because windforms and [inaudible 00:51:30] was not there but now it is. And I might [inaudible 00:51:35] have a separate, I’m going to do this first, before I do the, win PS module one. I have this WPF script here.

And basically it’s very simple. It’s just a little bit of XAML is going to bring up a photo that you’ve seen before, probably. It popped up behind it. The sad Joey. [inaudible 00:52:04] , it’s going to close it, but you know, if you had scripts that leverage WP for windforms, you can use it [inaudible 00:52:10] PowerShell 7. So then quickly, I don’t want to take up all of your guys’ time. So let me just show [inaudible 00:52:19] real quick, and I’ll get to, the more interesting one, this path.

Steve the WPI only works on Windows not Linux, right?

Right that is very important, WPF, which is provided by .NET Core is only on Windows. If we have time, there’s a different demo I can give on Avalon or Avalonia which is a cross platform solution for that. But anyway, about reparse points so if you’re familiar with symlinks on Unix [inaudible 00:52:49] NTFS, reparse points can be symlinks, but they’re not all symlinks. So basically, these are all [inaudible 00:52:56] stuff that I happen to have installed on my system here. And if you’re in CMDA you would not see this because it doesn’t support this kind of rendering. But let me get to the more interesting thing about Windows compatibility. I can use this window fine. Actually, I can’t use this one. I need to use my VM that I already have.

I’ll use this server machine. There are still some modules in Windows that basically will probably never work in PowerShell, or I’m going to start with 6 here. So super manager is one of those. That’s why I have to have this VM because it has to be on server. So here it says, Hey, this module doesn’t support Core. So it’s not going to work. You can try to use Skippy [inaudible 00:53:45] check. And if you do this then PowerShell Core, will try to load it, but it’s not going to work because this other assembly isn’t supported in .NET Core.

What we did in PowerShell 7, which is going to be this window here. I kind of explained earlier, we’re [inaudible 00:54:04] if we know that it’s not [inaudible 00:54:06], we’re going to load it in Windows PowerShell. So we actually started a Windows PowerShell [inaudible 00:54:13]

Right. So this is actually started. I didn’t start Windows PowerShell. This has started on behalf of the child process of my PowerShell 7, process. Now server manager module is loaded so I can get command module sever manager. You know, you can see like, these are all functions because these are all proxy functions, but we’re not using one-arm remoting. We’re using, the job infrastructure to do remoting between these processes running in this, my user session here. If I get Windows feature. I’ll just type it because it’s too long. Sure. Then it’s going to work, but you kind of notice there’s one difference in this whole left side is blank. There are small differences. Like if I run this in Windows PowerShell.

Then what you should see is actually this kind of like tree view. So this rendering is in a formatter that doesn’t work over remoting, which is what’s happening here. But basically functionally it does work. I mean, if you want to like add features, remove features, meaning Windows features, you can use these cmdlets because from PowerShell 7 is going to call into Windows PowerShell and do that on your behalf. But this will work on a number of, multiple Starship and Windows that don’t work directly with Windows PowerShell. Let me start with PowerShell 7. But it is kind of, there are some caveats. So for example, here, if I store the results, look at the first one, get member here. It is de-serialized cause it is going through the remoting channel. So just like any other case where you’re doing PowerShell remoting, it is not a live object.

That means you can’t call methods on it. You can call these local methods cause these exist on any object, but if there’s a method on this feature for like an install or something like that, you can’t call it because it doesn’t exist on the local copy. It only exists on the remote side. So you just have to be careful about that. But otherwise if you’re doing some basic cmdlet invocations then it should just work, that is the extent. I feel like I kind of ran long on this. I want to give time for Q&A. I don’t think I had anything

else in here. So I’m open for any questions you have about anything that I talked about or anything that I didn’t talk about. And I’ll wait until like, I guess Doug kicks me off.

I have a question. You might want to unshare your screen, Steve, so we can see you.

Okay.

Cool so one of the questions I had was around kind of [inaudible 00:56:54] and how you, basically could [inaudible 00:57:00] central location or as a function or [inaudible 00:57:09]

I missed part of that question, can you repeat it?

Yes, so for instance [inaudible 00:57:14] how do you kind of configure [inaudible 00:57:17]

Um, sorry, I’m missing the middle part.

Okay. And so now [inaudible 00:57:33]

Yeah it’s going to be available on Windows. [inaudible 00:57:38] where do you kind of specify which operating systems it can run on?

So if you, okay, so, if I understand the question, so like for example, out printer is only available on Windows currently, you’re writing some scripts and you want to make it work cross-platform right? So currently you probably to be safe would have to do like a get command on out printer to see if it’s available. There is work that we plan on doing in the post 7 timeframe to make some of those cmdlets cross platform, out printer, may be one of those. But for example, there has already been a couple of pull requests to make stop computer and restart computer work cross-platform. So that won’t make it in time for PowerShell 7, but those will show up in PowerShell 7.1. For out printer that’s actually probably pretty easy to make cross-platform cause there’s Linux native commands we can just call into to do that capability.

But other ones like clear recycle bin, for example, which I wouldn’t necessarily expect to see in your automation, requires calling some native API. So that’s a lot more work, so that probably isn’t going to happen. But in general, if your concern is about what cmdlets are available on Windows versus non Windows that you probably need to do checks to see if you know, [inaudible 00:58:53] that’s not available, then you can do like is Linux, is Mac SS those are default, variables that are defined. Otherwise you can always do a Get-Command, like in our build scripts in PowerShell, we always do a Get-command if certain commands are not available then we’ll [inaudible 00:59:10] to install something.

Maybe we can rephrase. And maybe this is what you were asking. If you’re offering a module and you want to make sure that certain functions are only available on certain OS’s, what should you do?

If you’re offering a module that requires using something, in PowerShell Cmdlet like, I think the answer is the same, whether it’s a PowerShell cmdlet or if you’re relying on a, let’s say you’re building a module on Linux, but the different Linux that shows have different commands available, right? They’re not all the same. So you’re going to have to probably do a runtime check to say, Hey, here’s my dependencies and if anything’s not there, then you have to provide a meaningful error to the user.

But I guess the opposite though, but the opposite is if I want to make sure that my function only works on one OS, I think you have to specify that in the manifest, and that is probably a per module tag.

So module manifest doesn’t have a OS check. So you would have to do… well if you only care about Windows, I mean, you could always require five one. I mean, that’s a cheat around that. But I think what we’ve been doing is in your, even if you have a binary module, you can still have a PSM one, and that can do a runtime check, and error out. In the gallery though, we do have specific tags to indicate what operating systems are supported. So we don’t have to support in PowerShell Get yet. I want to have it added and PowerShell Get V3, which I didn’t really talk about here. So that if you’re trying to install a module that is not applicable to your operating system, it should give you a good error message. Today it will still install it and it just won’t work. But we do have those tags in the gallery to indicate that this is on Linux. This is on a Mac OS and Windows. We don’t have the granularity that this is for red hat versus [inaudible 01:00:56] bunch of stuff like that.

So, Steve, you just mentioned PowerShell Get V3, which was going to be my question. So what can you say that you guys think you are addressing on V3 as opposed to 2.exe at Pryor?

So PowerShell Gallery and PowerShell Get are two projects that I took over fairly recently, like about six months ago, but one of the first things I wanted to do, and once I took ownership of PowerShell Get is to fix, in my opinion, a lot of the wrongs that were maintained for backwards compatibility sake. So for me, one of the big user experiences I want to fix is, you don’t have to do all these switches, you’ll do, I want to install like the latest piece [inaudible 01:01:42] or something like that. That’s maybe not a great example, but you want to solve the latest module. And it says, Hey, these functions aren’t exported and you have to do like allow Clobber, or this version is already installed, but maybe there’s a different publisher because we have one that’s inbox versus like pester.

You have the Pester 1 on his inbox versus the one you want stuff from the gallery. So do like skip publisher check. We have to do like [inaudible 01:02:01] and all this stuff. [inaudible 01:02:02] can I make it much easier for users? Like, Hey, we know that you want to install this thing. Let’s just make it install, so you can use it. So that [inaudible 01:02:10] big user experiences, there’s other user experiences, like we want to adopt a new get versioning syntax. So if you want, so for example, let’s say that you have a module and your development environment, and you require Pester 3, right? But you want to use the latest version of 3. You should not be using version 3 by the way, but let’s say you wanna use the latest version of 3 and you don’t wanna use the 4 because it’s a breaking change. Then today you kind of have to say, Mac version 3.999999. Like, you can’t go to 4. So using the new get syntax, you could actually say, Hey, minimax three to four, where three is inclusive and four is exclusive. So we can do the right thing there. So that we can manage dependencies much easier.

From a user experience those are some of the things that we want to do in addition to stuff like you should go to just install an arbitrary, new get package from newget.org and use those so you can call those APIs. We want to light all those scenarios up. From an engineering standpoint, one of the big things I really want to do is actually remove a dependency on package management, and also move the script module to a C# based module, which actually makes it easier for us to maintain because it’s a very complex module.

So that’s, the big effort is really removing package management. Also known as one get. That’s also something I owned and I think the reality is one get, did not fulfill its initial vision. And it doesn’t make sense to continue to invest resources in that at this point in time. So I’m moving away from that right now. And also basically improving the user experience for PowerShell Get so that it’s more similar to like Apt things like that. So another thing that we’re doing is having a local cache. So now you can do, one of is I want to hook into is if we have a local cache finds [inaudible 01:03:54] way much faster, but also if you try to use a command that is not installed in your system, we can detect that until you install this module to get this command.

So there’s some cool things we can do to light that up. Unfortunately PowerShell Get 3 is a very complex project to kind of basically re-write PowerShell Get from scratch. So, I wanted to have like a preview to try out this calendar year. It’s not going to happen. We’ll have a preview probably first quarter of next year to try that out and it’ll be side-by-side with V2. Cause it won’t be complete.

Steve a question on PowerShell and performance. So you want to discuss 5.1 versus 7GA whatever is [inaudible 01:04:35], performance just, engine performance and the load time and, the first run kind of thing.

Yep. So I don’t have any numbers to share with you right now. I had other blog posts before on just, performance improvement. So not .NET Core itself has invested in a lot of performance improvements that were done at framework. We’ve also made some targeted and also community has made some targeted performance improvements in PowerShell. So from a runtime perspective, in general, your scripts will just run faster in PowerShell 7 versus Windows flash or 5.1. It’ll also take less memory and stuff like that. So there’s a lot of goodness there. I don’t have any numbers to tell you, like it’s gonna be a 100%, whatever. I think that’s something we’ll probably have as a follow-up, blog post when we get closer to GA. As far as startup though, that is something that is very difficult to solve.

So I can tell you right now, PowerShell 7 will start slower than Windows PowerShell 5.1. It’s a technical reason, which is, in .NET framework and Windows. When we ship Windows PowerShell, ship it as MSIL. This is the intermediate language is not compiled for your architecture. When you, first time you run it in Windows, a thing called engine is executed and it’s going to compile Windows PowerShell, intermediate .NET language into the native code for your processor. So that’s a one-time hit. So that’s a cold start. But after that, you’re basically getting an optimized, manage assembly as native code all the time.

It’s different for .NET Core, for various reasons one of the reasons they don’t have a GAC anymore, a global assembly cache. But what we do is we do things called cross-gen. The coss-gen will compile parts of our code from managed code to native code, but it’s not complete, when we do engine pretty much everything’s native code.

So we have this, ceiling limiting factor with .NET Core where we can only be so fast. We know that there’s some other things that we could do on our site to make it faster. Again, I don’t have numbers in front of me, but I think that those PowerShell was probably around, if you don’t have a profile so it was probably around maybe like 300 to 400 millisecond startup. And then PowerShell 7 is probably closer to like 600 to 800 milliseconds depending on your system. So that’s something we want to look at in a PowerShell 7.1 time frame to see if there’s other things that we’re doing during startup that we can not do, which we can improve that. But it’s going to be hard to get parity with Windows PowerShell without having more just native code in there.

Also, is it different across always distros or [inaudible 01:07:05] Windows one, two or rail?

It is different because the cross shin compilation code is different for .NET Core. I know that in the past they had some bugs where it was slower on Mac, but, again, that’s all kind of outside of our scope. We’re just leveraging their tools. In general, I mean if you were to compare for example on Linux, a PowerShell startup versus batch, we’re going to lose every time because we just do a lot more stuff on startup and batch does. That is one of the things that we do know is a potential pain point for customers. And we’re trying to figure out interesting ways to reduce that startup time.

Thank you.

It’s not going to happen in PowerShell 7 GA. Any other questions?

Is rebound available on vs code yet integrated console yet?

Good question. So [inaudible 01:07:59] line is a project that my team took over from Jason Shirk, who is still involved, but he just doesn’t have the time to be the primary maintainer anymore. So the way it works is that whenever we ship a new editor extension, [inaudible 01:08:11] we do ship a new version of [inaudible 01:08:15] line of it’s available. So I expect that we should have a new drop of the extension either tomorrow or next week. I have the Beta. It’s Beta 6. I can’t remember now that the latest Beta that we have are, we should have the release candidate for [inaudible 01:08:34] line two, in that release. So we’re getting close to a GA of the [inaudible 01:08:38] with GA and the, the target is to, have a general availability of [inaudible 01:08:39] 2.0 and [inaudible 01:08:42] the target is to have a general availability of [inaudible 01:08:48] in January, right before PowerShell 7 that way PowerShell 7 can pick it up.

And our plan is to check that back into Windows. So that Windows PowerShell 5.1 will have [inaudible 01:08:58] 2.0 GA that should address the fleet, any remaining issues on the Windows PowerShell side. Short answer. Yeah it [inaudible 01:09:06] time we pick up a new version of [inaudible 01:09:08] when it’s available with the extension.

Can you tell us a little bit about, what’s happening with remoting, cross platform? Right. So on the Windows side we’re used to win rm, remoting from, let’s say PowerShell 7 on Linux to Windows or vice versa. Should we all switch to SSH now? Or is that?

The answer is yes, but let me provide a little more detail there. So in PowerShell Core 6.0, one of the things we did and I didn’t mention earlier was we did do the, PowerShell remoting over SSH and so if you just use SSH, and you want to remote to another machine and start PowerShell. You can still do that, but that doesn’t involve PowerShell directly. What we did is we plumbed PowerShell remoting protocol over SSH, so that if you make that connection, you can actually get objects and not just text back to your client machine. So the big difference between when I’m remoting and SST running at this point in time is that, SSH warnings is cross-platform [inaudible 01:10:08] remoting is partially cross platform supported, what that means is that if you’re on Linux or Mac OS and you’re trying to use WCM based remoting, there are things that work and things that don’t work.

For example, Kerberal support is not really there until, and [inaudible 01:10:23] support is not really there. There’s potentially a ways to make it work on Linux, but the ideas is or the reason is that those are not native concepts on Linux. Those are native things on Windows. So we don’t have to write that code. There was this other project I don’t want to go into a ton of detail called OMI, “Open Management Instrumentation and Infrastructure”. Not really sure don’t remember now, but it’s basically like an Open Source version of WMI. And [inaudible 01:10:47] ] remoting of leverage to that and that OMI project is no longer funded. So there are no longer Microsoft engineers working on that project. So all the limitations that we have where I know customers are complaining like, Hey, I want a Mac book. I want to remote to exchange online via wspan because they don’t support SSH today. Sorry, when it worked, it worked, but there’s no one supporting the OMI projects. So we’re not going to get those bugs fixed.

So our future from the PowerShell team is to say, Hey, you should really be using SSH remoting it’s actually a lot better than [inaudible 01:11:19]. There’s a lot more authentication methods you can use, you can do two factor, you can do all this cool stuff. There’s some, I’ll mention that even in PowerShell 7.1 timeframe, one of the things I want to leverage is SSH remoting so that from a local vs code, you could actually do PowerShell debugging to let’s say, Azure devOps container, right? Which you can’t do today. And the hard part about that is that the Azure DevOps container doesn’t have incoming ports open by design.

It can only do outgoing ports. And then on your local laptop, you probably don’t want to have incoming SSH ports either. But using both outgoing, SSH connections, there’s a technique in SSH in reverse tunneling. We went through like a middle fashion server that you can actually connect through. So those are some scenarios we want to light up and it just leverages SSH. The reality is SSH is the protocol in the industry, and we’re going to continue to make investments in there. The only thing that is not supported yet in SSH that is supported in WINRM is JEA. I don’t know if you guys have used JEA or know about it. It’s Just Enough Administration. The idea is you can have a constrained, end point or remoting end points. So if somebody’s on your enterprise or, you know, business, let’s say they’re the printer admin. Then you can give them access to a set of constraint Cmdlets even parameters that were parameter values. So they can only do stuff against that printer service.

So that is something we highlight and PowerShell for Windows PowerShell. It can also do it with PowerShell 7 on Windows using [inaudible 01:12:48], but you can’t do it with SSH. That’s something we want to look into in the future, but it’s a very hard problem. It’s that there’s a lot of work involved to make that happen.

And SSH on Windows. Open SSH is that a, is that production ready yet?

It has been production ready for at least since 1903 I think, but it is a feature on demand on Windows 10 and server 2019. My team, and to be honest, it’s really like one and a quarter engineers. We do regular merges of upstream changes of open SSH into the Windows fork and then we check those back into Windows. But it’s not something that happens very quickly and it’s not something that you guys can get very quickly. I think that the alternative is if you’ve heard about this new thing called Azure arc, that was announced that Ignite basically allows you to attach your onprint computers to Azure and manage it that way there. We already have this thing in Azure called the Azure openness extension, which makes it easy to install open SSH on Windows. So that might be another way for you to install open SSH, even on non Win10, like those will work on Windows server 2012 R2 and above, something like that. I don’t remember exactly the versions, but we are still supporting open SSH, but you know, it’s hard to support a down level, because it’s just a lot of work to be honest with very little resources.

Any other questions?

Do you know any plans for the intune module? Is there any objectives for that or?

I don’t have any knowledge about that specifically about Windows Intune. What I would recommend is if you, if you’re on Twitter and you’d send me a message, I can find out the appropriate people to talk to you if you have a specific question about that. But if you already know about the Intune folks on Twitter, you can just talk to them directly about PowerShell. Like my general thing is if you, as a customer talk to those teams directly, it is much more impactful than having someone from the PowerShell team talk to them because they’re pointing and saying, Oh, it’s just another PowerShell team ask versus this is a real customer with a real, real pain point.

[inaudible 01:15:02]

So I’m going to cover that in two different ways. So in Win10, and this would have been in the last October update of Windows 10 and with the PowerShell Core 6.1, if you’re using Win10, I forget what they called it, but it was the October refresh, whatever, with PowerShell Core 6.1, the active directory module just worked. Like we, we made changes in that module, in the Windows code base. There was a bug in there in .NET Core. So if you use it with PowerShell 7, actually that works better, but that should just work. After talking about like a Windows 7 or Windows 8 or the equivalent server and the changes that we made in the inbox version of that module won’t go down level.

I mean, those won’t meet the servicing bar, but if you use the new, Win PS, I don’t know, to show what we call it, a Win PS rapper, or, we do the import module then that should work for you. So that’s the way on downloadable [inaudible 01:15:58] to use active directory module Win PowerShell 7.

I guess the difference will be, you know, if you’re on the latest Windows 10 version, you get the true objects, but if you go on earlier versions, you guess you have to serialize ones, right?

That’s correct.

Thank you.

I have a question about kind of the whole process, right? Of getting the PowerShell 7 out what was the most heated debate or contentious change or difficult conversation in your memory?

If you’re asking about from a technology standpoint it was probably some of the, the language changes. So just so you know, like, we have this thing called a PowerShell committee, which is primarily myself, Joey Dombo, who is one of the engineers on the team, and Jim, who is one of the original PMs and now an engineer on the PowerShell team, but we also have, Bruce [inaudible 01:17:01] and Kenneth Hanson who is at AWS on the committee as well. And we don’t always agree and I won’t name any names here, but you know, when we introduced the language features, some community members asked just like, why have this? Like people can do, if statements, it’s like, you’re adding complexity. And the argument is, yeah, we are adding options, but it’s really the user who decides what they want to do.

And the feedback from the community is they want these language features. So, in this case it was a majority kind of rules kind of situation. But that, there’s been some other, I don’t know… this is recorded, so I don’t want to call out a specific [inaudible 01:17:41] stuff because the people I mentioned, I don’t want to mention to people if I mentioned the issue they’ll know who they are. But there…

We’ll edit it out

Let me just say this. There’s been some [inaudible 01:17:54] issues raised by the community on things they want to see changed. And they’re always good suggestions in a vacuum, but when we look at it from a, Hey, is it consistent with the PowerShell philosophy? Does it make sense? Then we can’t, we don’t always say yes. And that’s always been a painful conversation. Because partly right now the committee is a closed group of folks. I’ll just say that one of the things we’ve been discussing in the committee is actually make it more open. When I say openness, we also want to invite more community members into the committee and probably have a separation of a technical committee versus like a board. That kind of one is more technical and one is more strategic, but we haven’t kind of closed on that structure. But I know that there’s a number of PowerShell MVPs that would be interested in joining that, but, there’s some challenges there to figure out. Like how do we get people into the committee and how do we get them out of the committee and stuff like that. So it’s a direction we’re trying to head, but we haven’t closed on that specific yet.

And I’ll mention the other thing about a process, one of the most difficult things is really, and we feel kind of bad about this because we know like when we opened up the PowerShell [inaudible 01:19:05] repo, we wanted the community to submit a bunch of stuff we could review. And we recognize that we’re kind of way behind on reviewing those RFCs because we are a small set of people and we only have two meetings a week because we have other things that are part of our jobs that we have to do. So it can feel kind of bad that we’ve always prioritized our own RFCs ahead of the community’s. So that’s something we’re also trying to figure out how to change and make it more optimal.

Part of it is getting more people in the committee so that we have more people involved. Part of it is also maybe making it a little bit lighter weight. We recommend people open issues to discuss it before you can spend the whole time [inaudible 01:19:38] an RFC and stuff like that. So we’re all just trying to figure out how to make things easier for both us and also for the community so that we can actually together have a much better product.

Questions?

Steve, you mentioned that you bring out some of your team members to talk about the work done on this, you know, CICB pipeline stop to summit. I don’t think I saw that on the agenda. Is that going to be like a side session?

Currently, I’ll give you some insights on like a PowerShell summit PowerShell conference, uh, Europe and PowerShell conference Asia. Usually what happens is that we will get a number of sessions reserved for the PowerShell team, and we will not decide on what those topics are until much later. So we have a different, it’s kind of unfair maybe, but we have a different process versus the open call process. So we have not closed on what our topics are. Part of the reason is like, as we’re moving past PowerShell 7, like there may be something more interesting to talk about than what we planned to talk about right now. But we’ll have a number of sessions at each of these conferences. I think for PowerShell summit, I do want some of the folks on my team, it would have been like Jim was involved and [inaudible 01:20:49] was involved and Travis was involved, and really bringing up a very comprehensive CICD.

And it’s not just CICD, but also just a release system, that really reduces the amount of man hours that we put into getting a release out. And a lot of it really leverages not only the Azure dose, but also PowerShell script. So I really want them to talk about that. So hopefully you guys can learn from that and use it for yourself. So I’m not committing them right now to that topic, but even if they don’t do that, we will probably at least maybe have some blog posts, or I know that Jason Helmick is having his own video series. We could do it there as well. So there’s a lot of different avenues where we can talk about that.

Having just on that point, I use a lot of the stuff I saw on the getting up for PowerShell pieces. I use it a lot of that stuff from my modules that I do in Azure dev ops. So a super, super helpful and getting more details would be great. But I also have a question on PowerShell Azure functions.

Oh go ahead.

Can you just talk to PowerShell Azure functions? I know that they’re moving to a new, another release. I don’t know there’s durable functions that might be coming. I don’t think it’s part of your team anymore, but just some general stuff would be great to hear.

Sure so one thing that you mentioned about the team aspect. So when Azure functions 2.0 wanted to have PowerShell support because they did their own, Windows PowerShell support for the 1.exe release. We were not involved with that. They want to talk to us like how do we get PowerShell Core 6 in there, to the people on my team, Tyler who does a lot on the streaming stuff and also Dombo, they were involved in actually offering the PowerShell language worker for Azure functions 2.0. So one of the things we’re really focused on is actually having a great PowerShell experience. So we didn’t want to just say, Hey, you’re already familiar with writing an Azure functions C# app, here’s how you do it in PowerShell. We were really like, Hey, you’re a PowerShell scripter, or here’s how it should look like in Azure functions.

So we shipped that and once we had the public preview, we handed that ownership over to the Azure functions team. So they own it now. We also had a prototype for durable functions. We had some reservations about that because to be honest, [inaudible 01:22:53] functions as a concept is very complicated. And I don’t know if users are ready for that. But I believe that is a highly asked thing. And I’m comfortable saying that the Azure functions team will be able to deliver that. What I can also say is that we’ve continued to have conversations with them, and I expect that they will move to PowerShell 7 fairly quickly. I don’t know if they will be able to get there, by RC timeframe, but at least by GA, I would hope that they will be able to offer PowerShell 7 in Azure functions around the time we have GA in January.

All right. I guess that’s everything thank you very much, Steve. It was wonderful.

Thanks Dave, for having me. You guys have good night. I’m gonna hang up now.

All right. Thanks very much.

Bye.