The Ultimate Guide to Hyper-V Remote Management with PowerShell

字体大小 | |
[系统(windows) 所属分类 系统(windows) | 发布者 店小二04 | 时间 2016 | 作者 红领巾 ] 0人收藏点击收藏

The most common complaints that I see regarding Hyper-V are somehow related to management. When it comes to GUI tools, our options are all just barely on the high side of awful. Hyper-V Manager is capable, but lacking in scope for anything more than a handful of hosts, and it’s version is locked to its windows version. Failover Cluster Manager can fill in many of the gaps missing from Hyper-V Manager, but its focus is failover clusters, not Hyper-V, and it is also locked to its Windows version. System Center Virtual Machine Manager’s sole redeeming quality is that it is not named “Microsoft Bob” ― a fact which does not help VMM users in any way, but for which Microsoft Bob will be eternally grateful.

The Windows Azure Pack is too complicated for most regular administrators to have time to learn how to use, with a feature breadth to match. Azure Stack will require specialty hardware with more horsepower necessary to run itself than half of the world’s businesses need to run their entire operation, and it’s not yet released for production use anyway. Most egregiously, I cannot use any one of these tools by itself even for a typical day of Hyper-V Management.

What we do have available to us is PowerShell. Whereas Hyper-V is embarrassingly lacking in GUI management options, it is the undisputed king in command-line control. The more that I use PowerShell with Hyper-V, the better I feel about Microsoft’s virtualization stack overall. No matter how powerful a GUI is, it locks you into the mindset of the person(s) that developed it. With a well-designed command-line interface, you can routinely push a product to do things that even its engineers didn’t even conceive. So, while I can certainly agree that there is great value in a well-designed GUI and will continue to fight alongside everyone else attempting to push Microsoft toward doing the right thing, PowerShell is where serious administrators go to do serious work.

Most of us started out using PowerShell on our local systems. That’s just the beginner’s level. PowerShell works just as well against a remote system as it does locally. It is truly masterful at controlling multiple systems from a single console. What I like best about this ability is that using PowerShell to control remote machines is so simple that most people don’t even realize that the technology is involved enough to have its own name: PowerShell Remoting . There is quite a lot going on behind the scenes that we never see or need to be involved with.

Benefits of PowerShell Remoting

There are several positives about PowerShell Remoting:

Inherently secure Source and remote machines validate each other as well as the initiating user Traffic is always encrypted Uses a single well-known port (5985 for standard PSRemoting, 5986 for SSL PSRemoting) Custom endpoints can be created to limit what any given remote user has access to Any supported version of Windows can use PowerShell Remoting on any other supported version of Windows PowerShell is not locked to its Windows version PowerShell Remoting works perfectly well when your local machine does not have a required PowerShell module but the target machine does Many PowerShell modules work perfectly well when your local machine does have a required PowerShell module but the target machine does not PowerShell Remoting allows for one machine to command several remote computers simultaneously (one-to-many) PowerShell Remoting is Secure

I’m fortunate enough to work with a security department that is both practical and well-studied, so I’ve never had to make the case for PowerShell Remoting. From what I’ve read of the experiences of others, I am apparently in a minority. If you need to convince someone else, here’s all of the resources that you’ll ever need . If I had to pick a favorite part of that article, it would be the bit that points out that sites that avoid PowerShell Remoting over security concerns will joyfully leave open a number of other attack vectors that are far easier to exploit. These are usually the same sites that run Hyper-V in workgroup mode.

What’s not mentioned in the article that really helps change a lot of people’s minds is that PowerShell Remoting is built on top of WSMan, which is a non-Microsoft technology. Even though Microsoft has made unbelievable progress in making security into a top priority in their products, they have not done nearly so well at repairing their poor reputation (how’s that Secure Boot thing coming along?). So, if you’re facing resistance simply due to Microsoft being the owner of PowerShell, it might help to point out that the “W” in “WSMan” is for “web”, not “Windows”. WSMan is a standardized, vendor-neutral transport and management mechanism governed by the Distributed Management Task Force .

PowerShell Enables Any Version of Windows to Remotely Manage Any Other Version of Windows (and Hyper-V)

A very common complaint, and sometimes an outright problem, is that Hyper-V Manager can only fully control versions of Hyper-V that are running on the same code base. Hyper-V Manager in Windows 7 can’t control anything after the version of Hyper-V that released with the Windows 7/Windows Server 2008 R2 code base. Windows 8 or later was required. Starting in Windows 8/Server 2012, Hyper-V Manager can usually manage down-level hosts, but some people have troubles even with that.

With PowerShell, there’s no problem. PowerShell Remoting was introduced in PowerShell 2.0, and since then, PowerShell Remoting has worked perfectly well both up-level and down-level. The following is a screenshot of a Windows 7 installation with native PowerShell 2.0 remotely controlling a Hyper-V 2012 R2 server with native PowerShell 4.0:

The Ultimate Guide to Hyper-V Remote Management with PowerShell
PSRemoting Different Versions PowerShell is Not Locked to Its Windows Version

A great deal of pain has been created by the locking of Remote Server Administration Tools (which is where we find Hyper-V Manager and Failover Cluster Manager) to a specific version of Windows. That locking is the reason that Windows 7 can’t manage anything after Hyper-V Server 2008 R2. Windows 10 has reduced the pain somewhat, but we still had to suffer through several years where some version of Windows 8 was necessary if we wanted a dedicated management workstation to manage the newer releases of Hyper-V.

PowerShell has never had that problem. Just go to Microsoft’s download page and search for Windows Management Framework . The version of the Management Framework indicates the version of PowerShell that it will install. Upgrade your clients as desired. I am somewhat more hesitant to recommend that Server systems be updated, but it is usually OK. I know that upgrading PowerShell caused a fair amount of havoc on Exchange systems in the past, so Exchange admins need to do a bit of research first.

PowerShell Modules Can Be Different Between Client and Server

If your target system has a module that you need, you can open a remote PowerShell session to it and call it almost as if it were local. A remote module can’t run against your local system, though. I will demonstrate that later in this article.

If your remote system has a module that you want to operate against the target, you might be able to use it. The module must support

本文系统(windows)相关术语:三级网络技术 计算机三级网络技术 网络技术基础 计算机网络技术

tags: PowerShell,Windows,Hyper,Remoting,version
本文标题:The Ultimate Guide to Hyper-V Remote Management with PowerShell

技术大类 技术大类 | 系统(windows) | 评论(0) | 阅读(190)