>> Welcome to taking your automation to the next
level with PowerShell 7. I'm Joey Aiello, Program
Manager on the PowerShell team. >> Howdy, I'm Jeffrey Snover,
Microsoft Technical Fellow. Let's talk about what we're
going to talk about today. First, we're going to talk about the evolution of PowerShell
and our sacred vow. We're going to talk about
PowerShell 7, 7.0, 7.1. Then what we're going to do for 7.2, that's going to be an LTS
release and beyond that. Then talk about some
of the innovation that we're doing in PowerShell. But first, let's stop back
and take a look at COVID-19. Wow, what a strange time, lots of drama everywhere. But if you think about it, the details will vary. But here's the reality. The reality is the
world always has been, the world is, and the world
always will be a messy place. In this time, what it's
really highlighting are these values which have
always been more important, always will be important. But this period of time are really highlighting how valuable
these qualities are. Qualities like adaptability, resilience, robustness,
and automation. Now why is automation on that list? Really, and we're going
to talk about that. Really this is what I
call the F5 moment. The hit refresh moment. This is a time you want to stop. Think about what things
are serving you. Think about what things
are not serving you, and then invest in
the things that serve you and drop the things that don't. Remember, you can't just
keep adding to things. You got to drop things in order to create bandwidth
to take on things. Now we're going to point
out how PowerShell is really something you
should have invested in. How if you did, how it's paying off and how if you haven't invested
in it, you really should. First a story, and you might have heard of the thing
called Microsoft Teams. Teams has had explosive adoption
during this period of COVID-19. This is from a while ago, but you might have seen the CNN
article about how Teams usage went up by 12 million daily
active users in a week, up to 44 million. Now that number is in fact
gone much higher than that. But imagine one day your boss taps
you on the shoulder and says, "Hey, next week we're going to have 12 million more users
every single day." What would you do for that? I'll tell you, boy, it
was just an amazing time. During this time, they tap
me on the shoulder and said, "Hey, Jeffrey, we need your help, we need you to be an
executive incident manager for the European expansion of Teams." So that meant getting up
at three in the morning, showing up and help the teams out. Here's the thing I noticed. PowerShell was everywhere. They were using it for diagnostics, for operations, per
provisioning, for repair. PowerShell was everywhere,
and I will tell you that PowerShell
verbosity and clarity, were just gifts in these stressful periods and you're
stressed to be able to open up a script and see what it
does and know exactly what it does with clarity was such a gift. Now the point of this
is we are automating up and automating down real, yes, we're bindings many x86
servers as we could, but in fact that wasn't fast enough. What we had to do was we
had to tear some things down and use that capacity for Teams. The point was PowerShell
was been used everywhere. We're automating up and we're automating down and things just work. It was a wild success
and why was that? The answer was, we were prepared
and we were using PowerShell. Now, Clausewitz, the famous historian once said to secure peace
is to prepare for war. Well, for IT pros, I've got a variation on that
and for me what I say is, hey, to secure calm is
to prepare for drama. Why did this Teams expansion
work with relatively no drama? The answer was, we were
prepared for that drama. Here, I'm highlighting the point that PowerShell 7 and
PowerShell in general has been this 20 year story of
preparing you for drama. Now there's a recent book about this, Don John's recently wrote the
origins story for PowerShell. It's a fantastic book. He went and talked to a bunch of
the members of the original team, got their stories and
included in this book. I strongly, encourage
you to give it a try. But in it, you'll see
throughout this 20-year story, we have had this idea
of a sacred vow. Now how many technologies
out there or products out there
make you a sacred vow? I don't think they're many. Here's our sacred vow. Our sacred vow is this look, I know you're busy, your hair's on fire, and I'm asking you to stop
and learn PowerShell. Our sacred vow is
learn PowerShell and your value will continue
to appreciate over time. That we will continue to
invest in PowerShell, and then we will
invest in you and make your skills more valuable
year-after-year. I think you'll see that through
the rest of this presentation. PowerShell is a story of
continued investment. This is not something we've run
hot on and then run cold on. We continue invest in you. >> Yes. Let's talk a little
bit about the evolution of PowerShell over the history.
Thanks so much Jeffrey. When PowerShell first
got started back in the Windows PowerShell
1.0 and 2.0 days, IT management on Windows was
extremely messy as we talked about. It's always going to be
messy to some extent. But in the Windows world, we had all these different ways that you
can manage your IT workloads. You had COM, Win32 APIs,.NET APIs, WMI, the registry files
floating around everywhere. PowerShell was really built as this way that you can weave all
of these different types of APIs together in single scripts in a very task oriented
layer of abstraction. Instead of me having to worry
about which technology I have to use because I'm interacting with the storage layer versus
the networking layer. I'm able to just use
PowerShell to call all of these things from a
single logical flow. But it's also meant that people had to do a
lot of things themselves. They had to weave
these APIs together. When the PowerShell 3.0-5.0 days, we focused more on adding modules
for specific roles and features. Instead of you having to
figure out that half of the storage APIs are in one
place and half are in the other. We glued them together inside
of the storage modules, so that you can really use them without having to do all that
additional heavy lifting. Additionally, we added
WinRM remoting because as we grew PowerShell, you're going to need to grow the scale of the systems
that you're managing. Having that ability to
remote into number of machines and do that fan out
of automation was critical. Now, obviously, four, five years ago, we decided to open-source PowerShell. With PowerShell Core 6.x, this meant that we had ubiquity. This was all about
bringing PowerShell to more than just Windows
and Windows Server. But bringing it to the
rest of the world. The macOS admins out there that
we're managing Windows Server. The Linux admins out there that maybe had mixed environments
between Windows and Linux. So putting PowerShell in all of these newly disparate places where in the past we had
these disparate APIs, we now had disparate
operating systems, container technologies,
rest APIs, etc. But of course this came with a price. Which was that, as you can see
some of this Venn diagram here on the outside was actually stuff that no longer worked
in the Windows server days. We took a step back on a few
of those roles and features. But with the introduction
of PowerShell 7, we've brought all of this back. In addition to a bunch of native
modules working just great, we've also got these Windows
compatibility layers that allows us to call back
into Windows PowerShell. Everything is working from afford just like you would expect it to. >> Now why do we call
it PowerShell 7? The answer is this. First we had Windows
PowerShell and so what was it? Windows PowerShell enabled
simple automation and management of Windows
servers and clients. >> Then we had this separate
thing, PowerShell Core. So you had Windows PowerShell and
then you had PowerShell Core. So what was PowerShell Core? PowerShell Core was this great universal automation
and management system, works across operating
systems and Clouds. But then why was it PowerShell Core? The answer was, it's
qualified, and the answer was, it couldn't do everything that
Windows PowerShell could do. So now, we just call it PowerShell. We drop Windows, we drop Core, it is PowerShell 7. PowerShell 7 is the tool that
works across all environments, there's no modifier,
there's no qualifier, there's no caveat, this
is the one you want. So PowerShell 7 enables automation, management, deployment,
on-Cloud, on-premises, hybrid resources at large
scale and complexity, manages our stuff, manages the other people's stuff,
anybody's Cloud anywhere. Now, PowerShell 7 is the tool to
manage anything from anywhere. Joey, has this been successful? >> Absolutely. We've had explosive
growth over the last year. So you can see here back
in September of 2019, we were actually sitting
at 20 million startups of PowerShell per month and
this has 5Xd since then. So you see a nice little jump
as the release candidates for 7.0 start to come out and then this GA in March where
we've got a ton of usage, and this big chunk you see, we'll dig in a little bit
here on the next slide. But all of this orange
right here is all Linux. You'd expect a lot of folks talk
about how PowerShell really is, so Windows technology, traditionally, Windows PowerShell shipped
as a component of Windows. But you can see here, the majority of the growth that we've
experienced here from PowerShell 6 and 7
were really there on Linux. So this idea of heterogeneous
environments where you're automating against multiple
operating systems is very real, and the value prop here, people have really
understood this a lot. But we've also got Windows
growing at a steady clip too. So this is folks who had been using Windows
PowerShell in the past, but they find that
there's enough benefit in PowerShell 6 and 7 to move forward to leverage that
on Windows as well. >> Yeah, I have to say, I think we always knew people
would get the Linux support. I think we were shocked
at how quickly and how enthusiastically people
have adopted Linux. >> Yeah, it's been
really awesome to see. Similarly, this Cloud-first world where we're in this more
of a fixed forward state, we're seeing people
upgrade very quickly. So this is PowerShell 6 and 7
by version, same usage graph. But you can see here, this
explosive upgrade from the blackish grayish 6.x usage
to the orange 7.0 usage, where we now have 90 percent of
our overall users on PowerShell 7. So it's just been phenomenal
to see people adopt as we move forward and
we're hoping to see something similar
with PowerShell 7.1. So PowerShell 7, we are talking
about the sacred vow before. PowerShell 7 absolutely fulfills
the sacred vow in making your investment in learning
PowerShell more valuable over time. So with 7.0 LTS, we added features like
ForEach-Object-Parallel, where you've got real-world
improvements of piping the ForEach-Object of
2-100 times speedup. This is if you're doing
large fan-out operations, or you're doing things
against multiple disks, or multiple SQL databases, where you're suddenly
going to be able to do multiple enumerations and automations against a pipeline in parallel. Similarly, Jeffrey was talking about how a PowerShell
really provided a lot of the diagnose-ability in
managing the scale-up of teams. In PowerShell 7, we've added a
number of features that make it easier than ever
to diagnose errors. We have a Get-Error
cmdlet that gives you an expansion of your entire
error stack and we've also simplified error messages
at the command line so that only the pieces that you really
care about are available to you. >> Yeah, this is one
of those subtle things that people don't notice, when they start using
it and they just notice that things
just feel easier, feel more productive,
feel the flows easier. >> Absolutely, yeah. You almost
don't notice it at first, but then these things start to
accrue and you start to realize just how much of a better
experience PowerShell 7 provides. As we talked about before as well, this was all about bringing back the qualifiers that
we had to tack on, the 6.x, so we've got more
native compatibility than ever. You can go to
aka.ms/PSModuleCompat to get the information on exactly which
Windows modules work and how. Then, for those that aren't
natively compatible, they're going to magically
work on their own within Windows environments
by calling back into Windows PowerShell
secretly under the hood. So all of your scripts now you
can really just run them in PowerShell 7 and trust that they're going to work
exactly as they did before. >> Yeah, this is some
amazing stuff and in fact, this misses one of my
favorite features of 7.0, which is what dozens, perhaps even hundreds of small little fixes that we've
added through the community, added on our own. It really just has this
nice fit and finish. It's one of those
things, once you use it, you don't want to go back. >> Yeah, and for instance, some of these new operators
that we added here, just quality of life improvements. The ternary operator, no conditional operators
that allow you to do things in a little bit of a cleaner syntax for those
more advanced users. But as Jeffrey was saying, with 7.1, we really focused on those under the hood improvements
in the long tail. You might not notice
some of them at first, but it really brings the
whole experience together. I can say when you've
used PowerShell 7 for a long time and then you go
back to Windows PowerShell 5.1, you really realize how much
stuff is missing there. All of these parameters
that we've added and error messages that have been
improved, better stability, better debugging, SSH based remoting, all of these things
that really just make the entire product so
much more cohesive. In 7.1 specifically, this was
a community release for us. We focused on a lot of the issues that had been
filed from the community, of which about 95
percent are filed from folks like you out
there and we were able to close over 1,000
community issues since 7.0 was released back in December. We've also added ARM64 support on Windows for those of
you in the IoT space, as well as, this is a
really big one for me, the ability to install and update PowerShell from
the Microsoft Store. So this is, if you're
a Windows 10 client, you're able to go into
the store now and grab a fully featured version
of PowerShell 7 preview, the 7.1 will be available very soon and we'll be adding
7.0 there as well. So definitely check that out, it's doing to make
installing and updating PowerShell on your
clients that much easier. >> Yeah, Joe, you mentioned the
performance just yesterday, I was getting ready for this, and I did some
side-by-sides comparison, I was just shocked by how much
faster even DER was. >> Yeah, the file
system improvements, that's been massively improved. The JSON parsing
improvements are huge. The ability to pipe
to convert to CSV. All of these things really are
just so much faster and I'm seeing real-world improvements out
there where a script that took an hour on Windows PowerShell is taking five minutes
on PowerShell 7. So this is really phenomenal. >> Is that with or
without Parallel.ForEach? >> That is with Parallel.ForEach. Yes, so that was a huge one, but even then some of the csv stuff, it's getting cut in half just from improvements to the csv cmdlets. Let's talk a little bit
about the innovation and tooling happening in
the PowerShell space. One of the things that's really important to us is that we maintain the stability and performance of the PowerShell language,
runtime, and package. Everyone out there is depending on automated scripts that
often are left in fully automated headless
environments and they want to make sure that those scripts continue working after PowerShell
gets updated. So one of the things that we've
done in the PowerShell engine is added this concept of
experimental features. So experimental features
get turned on by default in preview versions and then get turned off in GA
versions of PowerShell. What that allows us to do is try new things like breaking changes or changes to the language
runtime that may ultimately make the PowerShell
experience much better. Maybe we're not sure
whether or not this is going to impact the
PowerShell user base, and we want people to be able
to try this in a safe way. So we've got this
Get-ExperimentalFeature and Set-ExperimentalFeatures
and we've added new language
operators through this and features that may
be subject to change, parameters that may
change in the future. But generally speaking,
we're also trying to do a lot of the innovation
outside PowerShell. So anything that we can
encapsulate as a module, we'd much prefer shipping pre-release modules
onto the gallery floor. So some of these things include new innovations
happening in PSReadLine, the SecretManagement module we'll be talking about later,
PowershellGet 3.0, PowerShell Notebooks,
UnixCompleters, which is a better tab completion for
native Linux applications, and native tool cmdlet generation. All of these things are new
innovations happening in PowerShell, but we're able to do them
safely in modules that ship on the gallery instead of shipping them as part of the
PowerShell package. >> Let's talk about
Secrets Management. As you know, never put
secrets in your scripts. Just all sorts of bad. We got that religion early on and that's why we
support PS credentials. PS credentials have
served us extremely well. However, in modern world, there are more secrets and people don't realize
that they're secrets, these API keys, there's lots of
places that use these things, and people don't crack
that they are secrets, but they really are. So we haven't had a real
good way to be able to manage those secrets and now we do, and that's our new
secret management model. The idea here is that you can put your secrets in
any Key Vault you want, ours will have a default one, etc., and then you write the scripts, you retrieve the
secret from the vault. Joey, let's demo this. >> You can see here that I've
already connected to Azure using the Connect AzAccount commandlet
built into Azure PowerShell. The next thing we're
going to do is use the new Register
SecretVault commandlet to go ahead and register a new
local vault called AKV vault, along with our AKV vault extension that integrates with
Secrets Management. You can have these for
other Clouds as well. Then some vault parameters
we're going to pass in, including the name of the
AKV vault on the remote end, and a subscription ID that we've specified as an environment variable. We're going to go ahead
and register that, and you'll see right off the
bat that we do it now have a local AKV vault command or a vault that we've accessed using
the Get SecretVault commandlet. Now, we're going to check to see
if a TestSecret secret exists. You'll see here that we
get no return output. This has actually gone to the remote server to look for this thing. This time, we're going
to go ahead and generate it here in the Azure portal. We've got a value here, this is super secret. Once that secret has been created, we can flip back to Visual
Studio Code and click into check out this secret again. This time we run the same commandlet, and we do see that that
TestSecret secret now exists. This is something you should
not do in production, but just to show you that in
fact the value is correct, we're going to run this directly at the console with the
AzPlainText parameter. What that's going to do is output the plain text representation
of that secret. But, again, we don't want to
have that stored in the logs, so do not do this in production. You can see ThisIsSuperSecret, is in fact the value of that
secret that we retrieved from AKV. But, again, this could be
any secret stored in AWS, or HashiCorp Vault, or wherever. Next thing we're going to do is find the
TestGalleryPublishKey secret, which is a NuGet API key
that is going to allow us to publish a test module to
the PowerShell TestGallery. Again, we've in-lined
this Get Secret as a value passed to the
NuGet API key parameter. Because we've specified it there, it will not show up in our logs. Again, with that AzPlainText, because that doesn't need a
text representation of the key, and we're going to go ahead
and install that module to make sure that it was in fact successfully published
to the gallery. We're able to run Install Module, just going to go and grab it. Again, this script, really the value-add that we
have here is that we can take this script and publish it in a way that the vault
name is parameterized. If I put this script up on
the PowerShell gallery, I'm able to download that thing and pass in a different vault name for a different vault extension
that I've registered. This could be a local vault, you could be using
KeePass, HashiCorp Vault, any of these different
vault technologies that you've set up beforehand, and that Get Secret is
going to work uniformly against any of those vault providers by going through the
secret management module. It's a really cool way to really grow the ecosystem and the shareability
of open-source artifacts that use different vault
technologies under the hood without having to hard code that
into those shareable artifacts. For people who haven't picked it up, this is Visual Studio code, but showing in PowerShell ISE mode, one of my favorite things. Let's talk a little bit
about PowerShellGet 3.0. This is a brand new version
of PowerShellGet that's been available as a pre-release
module for about a year now. Some of the top benefits, one of the things we've heard from customers a lot is that PowerShellGet 2.0 is sometimes difficult
to get modules to install, you have to start tacking on these additional
parameters like DashForce, AllowClobber, all these
additional parameters. We really wanted to simplify
the commandlets surface area. We're going to make it a
lot easier to just get modules when you want them
from the PowerShell gallery. Additionally, we've ported
everything to C# to improve the performance and
stability of the modules. We've seen some customer issues transient transient error
messages happening, or sometimes modules taking
too long to install. We've also got full
compatibility with NuGet 3.0 for those of you that have your own hosted artifact
feeds that have moved to v3. Similarly, we've got
this new version syntax that has been often requested, that allows you to specify a maximum or minimum version
with a range syntax. Here, at the end, you see this
example with the square bracket 3.0 to the four with the
closing parenths. What that basically says is, "Hey, I want all the modules
from 3.0 and up, but not anything 4.0 and up." That's great because if modules
are following semantic versioning, you're going to make
sure that you snapped to a module that is going to maintain the same commandlets surface area without breaking changes as
you might experience in, say, the 4.0 version. Of course, we're going
to add some aliases for backwards compatibility with
PowerShellGet 2.0 for those of you that have really large
scripts that you don't yet want to update to meet
the new surface area of 3.0. Again, this is available now
in the PowerShell gallery, you can install it with PowerShellGet
2.0 using this command here, and this will be the
default in PowerShell 7.2. As soon as we ship our
first preview of 7.2, this is going to be
available right in there, and you can start
testing to make sure all your CI/CD scripts are going to continue working as you expect. >> Another exciting
area is notebooks. I'm just wildly excited
about notebooks. Notebooks are interactive documents that mix script and documentation, so the documentations in Markdown, and then there's a script. The nice thing about it
is you see the code, and then you can run the code. Here's document, here's the code, you run it, see the results, and then you can go and modify
the code, and rerun it. These are fantastic for
tutorials, how to learn, how to document things,
really like Runbooks. I was pointing out that
Teams would've been great to be able to have
these Notebooks for that environment where it
documents the environment, and then watch it through the steps, and then has some examples of what
to do when you see this, etc. The great thing about these
Notebooks is that they can combine multiple languages
into a single file. There are two types of notebooks. There are.NET Interactive Notebooks, you can find out a lot
about that at this URL. Then there's this notebook mode in PowerShell Visual
Studio Code extension. Joey, why don't you
give a demo of this? >> Absolutely. Yeah, we've got a.NET Interactive Notebook queued up, ready to go to show
you some of the mixing of both Markdown and PowerShell
in a single notebook. Yes. We're going to move right
into Visual Studio code here to show you a.NET Interactive
Notebook that's going to show the new ForEach
object parallel feature as a piece of interactive documentation in a.NET Interactive Notebook. >> Here we've opened up a.NET
interactive notebook that contains both Markdown and PowerShell
code in the same notebook. This particular notebook
was created as a piece of interactive documentation
to demonstrate the dash parallel
parameter that we added as a performance optimization to for each object in the
PowerShell 7.0 release. Right up here, we've got
a standard Markdown title followed by some plain
text written in Markdown, that's going to frame the script that we want to run directly after that. Just below that, we have a
piece of PowerShell script. It's going to pass an
array of the numbers 1-5 into for each object, sleeping for one second after each number is
written to the console. If we go ahead and
execute this script, you'll see that we
get all of our output in line just below the
cell that we executed. In fact, we get an execution
time of 6.3 seconds, which is each of these
numbers sleeping for one second plus a
small amount of overhead. We go just below that, and were able to mix
Markdown back into the notebook in order
to frame the next cell. Here, we've actually introduced
the dash parallel parameter, which is going to execute
this much quicker. In fact, we're able to
finish in 1.1 seconds. Again, we get this interactive output directly in line as
part of the notebook. Now if we want to
edit a Markdown cell, we can actually click
straight into it, and edit it in real time. If I go ahead and add some
asterisks around the Word larger, and revalidate the cell, I'm going to see that italics pop into the Markdown just as I'd expect, so I get this rich editing
experience directly in Visual Studio Code to actually
edit these individual cells. Of course, I can do this with
longer running scripts as well. I'm not going to execute this one today because the
GitHub API rate limits. I can guarantee you that
this does in fact work, and will again give me output showing all of the repositories
in the PowerShell, Microsoft and.NET
organizations on GitHub. You can use this
notebook feature with long running scripts both
to demonstrate things educationally as well as to run semi manual tasks in a long-running workbook
in your IT environment. >> Awesome. Definitely stay tuned
to the PowerShell team blog for more information on how notebooks are going
to evolve over time. There's a lot of changes coming in. It's a really exciting space
that we really hope to have a lot more
shareable notebooks out there for the ecosystem
for all these purposes. >> Yeah, it's crazy, cool stuff. >> Really cool. What's next? What's next for PowerShell? First, we've got a bunch of
things that are going to be generally available; GA very soon. PowerShell 7.1 release candidate
should already be out now. The generally available release
will be coming in November. PowerShellGet 3.0 will be
coming later this year. You should see a GA release of that, and it will be making its way
into PowerShell 7.2 preview, which will be out right
after PowerShell 7.1 GAs. The secret management will
be TBD based on feedback. This is a place where
security really matters. We want to make sure that all of our command surface area
and security concerns are totally buttoned up before we tell people to take a production dependency on that. Again, expect that 7.2 preview
right after the 7.1 GA. >> But you'll also
tell me what LTS is. >> Oh, yes. The long-term
servicing branch. LTS release is a
PowerShell supported under the.NET core LTS lifecycle, which means that they're
supported for three years, while non LTS builds are
supported for one year. If you really care about
stability and you don't want to be updating your version
of PowerShell every single year, you can definitely snap
to 7.0 or 7.2 and that LTS is going to keep you supported
for that three-year lifespan. We'll also be uploading PowerShell
7.0, I mentioned before. We now have it available
on the Microsoft Store, which is really great
for Windows 10 clients. But for those of you that are
not in client environments, you want to deploy PowerShell
7.0 to your Windows servers, or maybe you're not
using the Windows store and you want to deploy
using SCCM or WSUS, we're going to be
uploading PowerShell 7.0 and all of its updates to the download catalog
so that it works with Microsoft Update, WSS, and SCCM. So expect that pretty
soon here as well. Finally, we're going
to be making a ton of interactive improvements
in PS read lines. This is dynamic help, better tab completion,
smart predictions. They give you
suggestions on the kinds of stuff that you might
want to run, and more. Definitely, check out Jeffrey's doing another session with Jason Helmick. PowerShell unplugged
where they're going to be going into some of
these in more detail. What can you do now? Well, first of all, you can download
and install PowerShell 7.0. You can go and grab it at
aka.ms/Get-PowerShell. We've got the 7.0 LTS, 7.1 release candidates already out, 7.2 preview's coming soon, and then file issues. Tell us what you liked, tell us what you don't like. You can even contribute
documentation, tests, or even product code into PowerShell if there's
something that you really think deserves to be there in the package and you've
got some great ideas. Come tell us about
them, come help out. This is all open source and we have so many contributions
coming from the community. It's really awesome. I got a million other projects
available at github.com/PowerShell, a ton of different modules, other experiments that were running. There's just tons of code flying through the air,
so come check it out. Additionally, definitely
make sure to check out our PowerShell team
blog at aka.ms/PSBlog. For those RSS lovers out there, feel free to subscribe. PowerShell team on Twitter,
that's @PowerShell_Team. Follow us there for
the latest updates. We post blog updates there, module updates as well. Definitely for all the latest
stuff, check us out there. Then at Ignite, like I said, check out that PowerShell unplugged
with Jeffrey and Jason as well as the ask the
experts that we're going to be doing with
the PowerShell team. We've got bringing in people from the product
team, engineers, PMs, bunch of us will be there, so
come in and ask your questions, and talk to us there. >> Great. In summary,
PowerShell sacred vow. PowerShell sacred vow
is learn PowerShell, and over time, you will become
more valuable. Why is that? We continue to make
you more valuable. PowerShell 7.1 is the
release that now you can manage anything from anywhere. We've been in this 20 years, we've been investing in
this for over 20 years. Really, the journey has just begun. [MUSIC]. >> Thank you for all
your contributors, thank you for all your feedback. We do this product for you and your feedback telling
us where we've done well, and more importantly, where
we haven't done well, where we have gaps to do, are the reason why
this is a great tool. Continue to give us that feedback. Thank you for that, and I hope
you have a great Ignite 2020. >> Thank you so much everyone.
Have a great Ignite. [MUSIC]
