Windows sys admins have long relied on the very wide range of tools that Windows, especially its Server versions, made available to manage the operating system. Unlike many think, such tools were not black boxes but they have been built on APIs that were available to developers, in most cases, so that they could write their own tools and access the very same information that Microsoft tools have been providing and also perform the same actions. But the tools themselves were good enough so that admins have been using them in a way or another, even when implementing their own.
Microsoft also provided Server Manager, a tool that in its latest versions allowed to manage multiple servers at once and provided access to many information and actions to perform on to local or remote servers. It also acted as a container for other administration tools when it didn’t provide the capability to perform actions on its own. At some time, Microsoft probably thought about converting its desktop tools into plugins for the newer versions of Server Manager and also started such work by integrating some of them. That was no easy task because of the wide range of utilities that Microsoft provided over time but the effort made sense.
When Core (or Nano, as of Windows Server 2016) versions of Windows Server were introduced, sys admins had to rely on Powershell to perform the same tasks since no UI was available in Core versions of the OS. Actually, some of them were quickly converting Core versions into Desktop one when they needed to perform extensive maintenance actions, reverting back to Core when done. The reason for that is oh-so-simple: performing complicated tasks using the command line is way less productive than using graphics tools, whatever Linux sys admins would like you to believe. That’s the reason why the button you must pay attention to is red, the button to do a safe action is green and you have a wheelchair icon on a reserved parking instead of printing “This parking space is reserved to people with disabilities so you are forbidden to park here unless you have a disability your own. You will receive a fine if you park here abusively.”. Metaphors. We discovered that our mind is better at metaphors long ago. Well, not all of us. We are still waiting for Linux admins to evolve but we’re confident.
Yesterday Microsoft announced Project “Honolulu”, a new way to manage Windows systems through a new shell, this time a Web-based administration shell. I had the privilege to contribute to the design and testing of the tool and I will try to describe why I loved it and why it can become very relevant for Windows sys admins.
What Honolulu is
Honolulu is a Web-based Server Manager that can be installed on both desktop and server machines and provide access, that is to say “graphical access”, to one or more servers in your environment. The first thing to notice is that Honolulu doesn’t require anything “more” than you already have on your systems. There is no agent to install, no software, nothing special because the tool will leverage on Powershell for both connection and administration of your servers. Powershell is installed everywhere and the only thing you need to care about is having PS v5+ running on your servers, which is by default on Windows Server 2016 while v5 must be installed on older systems down to Windows Server 2012 and desktop installations, down to Windows 8.1.
[blockquote right=”pull-right”]Honolulu is a Web-based Server Manager that can be installed on both desktop and server machines and provide access, that is to say “graphical access”, to one or more servers in your environment.[/blockquote]
The other requirement is enabling Powershell remoting, something that you probably already did if you manage a Core or Nano installation and something you could do on Desktop Experience version of server systems. Powershell Remoting is the way you can connect on remote machines and perform tasks by using the command line. The good thing about this is PS Remoting use HTTP(s) transport so it needs no special management other than opening relevant ports. Honolulu cannot use HTTPS yet but, as we will see later, can be deployed to overcome this limitation. HTTP traffic usually has no specific limitations and it doesn’t require changes to your network.
Once Powershell Remoting is enabled, you can connect to your servers by adding the server to your list of machines, start administering it and enter the flowerish world of Honolulu. The security of such connections is nothing different than standard PS connections to remote machines, everything will run into the context of Powershell so Honolulu will not add a layer that you must account when dealing with security, for example by using an agent that might then have bugs and so on. Honolulu is transparent, which is the best thing you would expect from a tool like that.
What Honolulu can do
The tool runs in a browser so it doesn’t need special clients as well. It has been tested with Microsoft Edge and Google Chrome but it will probably run with any modern Web browser. Unfortunately for someone, Internet Explorer is not supported though. While still at preview stage, the tool already allows managing many relevant part of your servers. It will provide a glance of server status by displaying CPU, memory, disk and network metrics and an overview of most relevant details like memory and cache utilization, paged and non-paged pools, free disk space and information about processes and services, list of devices and many more information, all of them well organized and easily accessible, all of them updated in real time so you can quickly understand what’s going on.
There are currently already 17 source of information, including details about events, certificates, firewall, local users and groups, registry and status of updates for the machine.
Then you can start performing actions and that’s where the tool shines even more. You have lots of actions available with each tool (that’s how Honolulu extensions are called. More about that later), totalling to tens of them for each server, including some of those that were only managed via Powershell so they had no UI counterpart.
You can browse disks, upload, download, uncompress, rename or delete files. You can manage users and groups, manage firewall rules, terminate processes or start, stop and restart services, install or remove roles, access and edit the registry or start Windows update installation optionally rebooting the server once done.
[blockquote right=”pull-right”]With 17 tools already available, you can access thousands of information and perform tens of tasks through an easy to manage UI and, most of all, turning lengthy command line operations into mouse clicks. [/blockquote]
Under the cover, it’s all good ol’ Powershell running on your server, leveraging on system commandlets that knows what they are doing. With 17 tools already available, you can access thousands of information and perform tens of tasks through an easy to manage UI and, most of all, turning lengthy command line operations into mouse clicks. Honolulu also unifies the management experience through the various edition of Windows, something very handy.
Advanced features
The power of Honolulu is already very clear. But the new management tool won’t stop at easy tasks like starting or stopping services or enumerating shares ! Already built in are extensions to manage virtual machines and virtual switches on Hyper-V hosts, storage replica features and hyper-converged deployments in a graphical and easy way while providing real time information about their status.
Storage Spaces Direct (S2D) deployments can be monitored with up-to-date real time information like average latency, IOPS, throughput, disks status and many more information so you can quickly diagnose performances or possible problems and perform remediation.
While still at preview stage, such functionalities already provide big hints on how important could Honolulu become for Windows sys admins and how the tool can provide access to both information and actions even for complex deployments, especially on Core and Nano installations where it would be hard and tedious to keep all those information under control. UI-less deployments will undoubtedly play a predominant role in future Windows Server deployments and sys admins will need a way to replace the old tools with a modern way to manage such deployments in an efficient way, being forced to type commands only when actually needed.
The fact that Honolulu can manage complex deployments like Hyper-V failover clusters, hyper-converged deployments, S2D, storage replicas and all those enterprise features that Windows is bringing to the public, already shows its huge potential.
And believe me or not, there’s more !
Extensions: the “wow” after the “ohhh”
What we saw is already impressive, especially when considering that Honolulu is still at preview stage, but there’s more to see. I already hinted at the fact that Honolulu “tools” are in facts “extensions” and some of you might already have understood what the term “extension” might mean.
And yes, Honolulu have been developed to add new extensions to the basic tool by a mechanism that is similar to nuget in Visual Studio. And I think it will precisely rely on nuget but this is just my feeling. That means sys admins will have a way to look for and install new extensions that will be published on a remote repository and thus adding new functionalities or improving the exiting ones by updating extensions that have already been installed. That alone means that new extensions will pop-up, provided by Microsoft and the community, to enrich Honolulu and constantly evolve it.
But the bombshell drops when the team confirms that private extensions can be developed and installed. Each administrator or team can thus develop their own extensions that will work on their own environment and perform those tasks that are meaningful for them. For example, I might need to perform management tasks for a custom application that we internally developed so I could package those tasks into an extension, install into Honolulu and manage my custom tasks the same way I can manage system tasks. That’s extremely exciting for administrators that know how many custom tasks they need to perform on each machine and that probably deployed lots of custom scripts to accomplish that. And if such scripts are Powershell-based, it will probably be very easy to integrate them into Honolulu.
[blockquote right=”pull-right”]Each administrator or team can thus develop their own extensions that will work on their own environment and perform those tasks that are meaningful for them.[/blockquote]
I’m personally very excited about this feature and I can’t wait to put my hands on Honolulu SDK that Microsoft will (hopefully!) make available later this month at Ignite.
Deployment options
In the past paragraphs I briefly hinted on Honolulu deployment. The tool doesn’t need the Internet and it has been designed to be deployed into your own network, unlike other tools like Azure Server Management Tools (SMT) that has been retired. That’s the reason why HTTPs connections are not available, yet. However, there are two different type of deployments that you can actually perform. The first one is on a Windows desktop computer. In that case, Honolulu will act as an application, albeit running in a browser, and you can add (even bulk-add) the list of servers to manage and start working like that, provided that you can authenticate on to such servers. Authentication can rely on AD, LAPS deployment or individual accounts that you can manage on the fly by providing your username/password combo.
When installed on a server, Honolulu will act as a gateway machine, providing access to machines inside your environment. In such cases, you will access Honolulu via browser at a port that you can customize during installation and enable all of those security features that you would commonly enable for Web-based tools in your environment. Since it is “just” Web, they can be secured the way you prefer. The server you installed Honolulu on to will act as a gateway to other machines and in that case you will need to perform additional configuration (a few Powershell commands) to allow that server to authenticate to remote machines on your behalf.
The team knows that I personally wait for being able to use HTTPS transport as well, just like we do with usual PS Remoting, but I understand that such task is not as easy as it sounds since it would probably cause problems with self-signed certificates that are widely used with PS Remoting. I’m sure the team will have a surprise for me in a near future, with a brilliant idea to solve this problem.
Conclusion
We all know that Windows Server development is taking two different paths: the first one will keep providing a user-interface with every deployment while other deployments, especially in the cloud and especially when dealing with scale-out services, will be UI-less. Powershell is constantly expanding its set of commandlets to provide more functionalities and more options to manage such UI-less deployments but, as I said, command line management is hard, tedious and – as such – prone to errors and less productive. You can wrap-up your tasks into PS scripts and new commandlets but that doesn’t solve the problem.
UIs will always play an important role in quickly providing information and in guiding you into performing actions with extra checks that will make this less likely to go wrong. Dashboards, graphs and so forth will always help you work better and control more things at the same time.
On the other hand, expanding commandline management and scripting capabilities is crucial for automation and for AI.
[blockquote right=”pull-right”]UIs will always play an important role in quickly providing information and in guiding you into performing actions with extra checks that will make this less likely to go wrong. Dashboards, graphs and so forth will always help you work better and control more things at the same time.[/blockquote]
With Project Honolulu, Microsoft probably found a way to start replacing its vast arsenal of graphical tools and expand it to UI-less server deployments, without reinventing the wheel but leveraging on a standard transport protocol (HTTP, easy and well-accepted) and without affecting the Powershell investments that most companies did in past few years. Plus, given PS capabilities to make calls into .NET code, even custom .NET code that have been developed during the years can join the party.
I’m very excited with Honolulu Project and its potential. While some details must be finalized or sorted out, it is already morphing into The Next Big Thing for server management of Microsoft environments.
Did I say Microsoft only ?? Hmm… never say never…
