For me, Network Switch management from within PowerShell is HUGE. This is taking us closer towards full datacenter automation. By investing in Network Switches that are Certified for Windows, you will be able to make more of your investment in PowerShell to manage your infrastructure. Let’s think about what that really means:
• Your Microsoft Admins will be able to configure network switches and examine their configuration using their standard PowerShell processes – Networks teams can outsource some tasks to Level 1 Ops teams with minimal retraining
• Your Network Admins will have a reason to learn PowerShell – if they are able to manage network infrastructure using the same engine (PowerShell) as you’re managing servers with, it drives more consistency into your platform and how it is automated
• You can build Network Management tasks into System Center Service Manager, Orchestrator and other such products and take care of a number of tasks using automated workflows

Those are just the few benefits that come to mind immediately. But what does this mean to Network Administrators and Network device manufacturers? For Network Admins, it means their role can start to change. Change doesn’t have to mean bad, it also means positive. As I mentioned, it means that there are a number of tasks that they can outsource to Level 1 teams or to Automation engines and self service technologies. This frees them up from the mundane and enables them to do the more interesting work. Does this mean a Windows Admin can take over the job of managing Network Infrastructure? Only in a small shop might it be ok but for larger companies with more complex networks then most certainly not. Managing switches is just a small part of what a Network Admin or Network team do but it can be a burden and a drain on time. This can now be removed in part. It also means that as the capabilities are developed further there will less of a need for specialized network device management skills and training, the manufacturers can cut down on the development of their own management tools and drive down their development costs, especially as we move more towards a world of Software Defined Networking. Note that the role of a highly skilled Network Administrator will always exist, but they can leverage PowerShell Web Access to do the configuration tasks and examination that they might get called out for, rather than using the Network vendor tools. This does mark a change in the way they work but to me this is the evolution of the datacenter.

There is a lot of ongoing discussion in the community about Chocolatey; an application that you can install on your Windows machine (originally built for unix) where you can run installers for a number of popular packages. Chocolatey uses an online repository where kind folks in the community have created and uploaded automated application install packages so that you can run a single command on your machine and have an application deploy rather than having to sit through a number of boring wizard screens. The issue with this is Trust. If you use Chocolatey to install Adobe Reader for example, the package is not coming from Adobe, it is coming from the repository. By running the installers you are trusting that the person who created it is honest enough to have used the original content from the manufacturer and not modified it in any way. You are also trusting that they are only running the install and not doing anything else to your system. For this reason, Chocolatey is not something that should be used in Production environments, however, it can save you a lot of time in Labs and on Crash-and-Burn machines where you are trying to stand up an environment for a limited use.

What OneGet actually does is take this Chocolatey goodness and brings it into PowerShell. PowerShell is basically Orchestrating it underneath. What does this mean? There is potential for someone who doesn’t know about Chocolatey and NuGet to do themselves some harm. When you first run the Get-Package cmdlet, you are prompted to Download and install NuGet. By clicking Yes, PowerShell goes off and gets the NuGet client, installs it for you then runs the Get-Package command to tell you there are no packages installed. Why is this an issue? Well, in a Production environment at a company I think its less so. In order for this to work you need permissions on your system to install Software. If users have this, whether OneGet is making it easier to get potentially risky packages onto a system is neither here-nor-there. The problem already exists that users can install software from anywhere. Yes, they might download packages from official, trusted websites, but they also might not, so in my view there is limited-to-no additional risk. Further, in Enterprises, you can control the trusted sources for your PowerShell users somewhat, or even put some restrictions onto running the cmdlets in the first place. Where this does present a risk is to the user using their own machine at home or to the small business. Perhaps they are learning PowerShell, perhaps they are a casual PowerShell user or a casual Admin. They have heard about this easy package management stuff and start giving it a go. They may never have heard about Chocolatey before or even cared, they would have always downloaded a package from an official website but now its easy to do it through PowerShell why not? It’s Microsoft after all right? Must be trustworthy? Unfortunately, that cannot be guaranteed. I think its these scenarios where an additional risk is introduced and it’s hard to predict how big those numbers might be. When you do install a package, if the Source is not Trusted i.e. like the Chocolatey repository by default then you do get all the relevant prompts and questions that ask you to accept the risk. This is putting it completely in your hands, so if you choose to continue then you accept whatever the end result is. I do want to be careful not to paint Chocolatey in a bad light. I am not sure if there have been instances of Malware being installed with legitimate software, but there is a potential for this to happen due to the way the system works. So, we should all be aware.

Putting the security concerns aside for one moment, OneGet gives us something that is very interesting. On the one hand, it opens up a way to automate what a number of folks are doing already anyway – automated application deployment from different sources including the Internet, on the other is provides a new way for inexperienced users with Admin rights to potentially get themselves into a spot of trouble. Jeffrey Snover has said that this will be an area for future development as they add more package sources and learn how people manage and use these application repositories. I’m certainly excited to see how this develops. The very fact that you can now automate the installation of different applications from known repositories through PowerShell opens up a ton of possibilities, particularly now that Desired State Configuration also allows you to make sure packages are present (or not present) as required. Getting code onto machines has become a whole lot easier.

All in all, PowerShell 5 adds a couple of really great new tools to the box – of course there are lots of bug fixes and stability improvements in this release but we will let the official Microsoft documentation cover those. In the meantime, I am off to build my own NuGet repository in Azure!