Microsoft Project Honolulu shows promise but needs work
Microsoft Project Honolulu is still in the technical preview stage, but it needs to resolve a number of issues before it's a viable alternative to manage production machines.
Microsoft Project Honolulu is still in development, but the remote server management tool is already causing waves among administrators.
Project Honolulu is a new application that houses a number of infrastructure administration tools currently accessed through a number of Microsoft Management Consoles in one web-based interface. Honolulu works with Windows Server 2016, 2012, 2012 R2 and the Windows Server Semi-Annual Channel releases, both on premises and in cloud platforms.
Project Honolulu is in technical preview and not meant for production use, but Microsoft needs to address several issues and supply missing functionality before Honolulu can take its place as an administrative tool of choice.
Editor's note: In April 2018, Microsoft changed the name to Windows Admin Center and made the tool generally available.
Setting up the Microsoft Project Honolulu gateway
A Project Honolulu gateway runs on a Windows Server 2016 or Windows 10 system. Administrators manage servers with PowerShell remoting and Common Information Model calls from the gateway.
Project Honolulu is available on the Windows Server Insider page or Microsoft's evaluation page. The installer prompts for a port to use and defaults to port 443 if there is no Secure Sockets Layer (SSL)-based functionality on the server. The installer also requires a certificate thumbprint.
I used port 50000 because it's a dynamic unused port. To find the SSL certificate of the machine, run the following commands as an administrator:
PS> cd cert: PS> Get-ChildItem -Path .\\LocalMachine\ -SSLServerAuthentication -Recurse
Select a port and certificate during the Microsoft Project Honolulu installation process.
If you need a certificate, Microsoft Certificate Services in Windows Server creates SSL certificates for the domain, so you don't need to pay a third party.
Honolulu trusts any machine the administrator connects to with PowerShell remoting and adds an asterisk to the trusted hosts list on the administrator's computer. This blanket acceptance is not a good idea. The trusted hosts list should consist only of specific, non-domain machines.
Add the servers to manage with Microsoft Project Honolulu in the application's Server Connections section.
The administrator adds machines to manage from the Server Connections page when connecting to Microsoft Project Honolulu from a Windows 10 machine. After installing the agent on the server, selecting the machine displays an overview page containing server information and performance details. You need to install the agent even though Honolulu uses PowerShell remoting.
Overview page of a Windows Server machine in the Project Honolulu dashboard.
The Microsoft Project Honolulu overview page also lists its administrative tools. Honolulu manages Hyper-V, but it lacks the functionality to manage a number of items currently handled by Remote Server Administration Tools, such as Active Directory, Domain Name System, Dynamic Host Configuration Protocol, Windows Server Update Services and failover clusters.
Project Honolulu features a PowerShell console, but it won't open if you use a nonstandard port. The application confuses a nonstandard port with a local host. The same issue affects the remote desktop option. Microsoft Project Honolulu should prompt you if the gateway machine needs the default SSL port (443).
A walkthrough of Microsoft's server management tool
You handle server management from Project Honolulu's overview page. Click Add on the Server Connections page and supply the name of the server, then the domain credentials. You will need to reauthenticate each time you connect to the server.
When accessing another machine through the Project Honolulu gateway, Remote Desktop and PowerShell are both available. The PowerShell console will ask you to authenticate again. The need to reauthenticate is a hindrance that Microsoft needs to remove before Honolulu is ready for production use.
After authentication completes, you've effectively entered an interactive remote PowerShell session to the server. Your profile isn't run, and there doesn't seem to be an option to set it up, but you can run the profile manually after connecting.
Installing Project Honolulu on a non-domain machine will prompt you for the port and certificate thumbprint even though it appears the trusted hosts list controls access to non-domain machines. Access to the tools on the non-domain machine works well.
Pros and cons of Microsoft Project Honolulu
If we look at the administration scenarios posited in the first article in this server management series, how does Honolulu stack up? There's no advantage to manage a single server with Honolulu -- just use the standard tools or PowerShell.
When managing multiple servers -- for single or multiple tasks -- Microsoft Project Honolulu has the same problem as standard GUI tools: You have to switch between the systems you're managing and the tools you're using.
When Microsoft expands the Honolulu feature set to cover common administrative tasks, organizations that use Server Core systems will benefit from using Honolulu.
However, Honolulu makes managing non-domain machines easier. If its functionality set increases, it could be a viable option for administrators.
There is no option to install Honolulu on non-Windows machines. I haven't seen any discussion of this possibility, but the ability to manage Windows and Linux machines from Honolulu would be a big step forward.
Where Microsoft Project Honolulu shines is with Server Core management because those installations don't have GUI tools. When Microsoft expands the Honolulu feature set to cover common administrative tasks, organizations that use Server Core systems will benefit from using Honolulu.
Microsoft Project Honolulu needs improvements
In addition to the aforementioned issues, there are other problems with Honolulu in its present state.
First, managing servers in a different domain from the gateway requires a modification to the trusted hosts list. Automatically trusting the remote machine without Kerberos verification from inside the domain is not good from a security standpoint.
The recommended way to secure PowerShell remoting to non-domain machines is to use certificates to authenticate those remote systems. Honolulu requests an SSL certificate during its install, so why can't it use SSL for PowerShell remoting? If Honolulu worked with PowerShell Core, then you could use Secure Socket Shell remoting in these situations. That feature will hopefully arrive in a future release.
Second, Honolulu doesn't support Internet Explorer. Many organizations use a jump off server to perform administration. Unless you install Google Chrome, you can't access Honolulu from these servers. It's absurd that a Microsoft product does not support the browser Microsoft ships with its servers.
Third, Honolulu is very slow and has moments of instability. Microsoft should address these issues as the product gets closer to a release version.
