Today, we are thrilled to unveil the next step in our journey for Windows Server graphical management experiences. In less than two weeks at Microsoft Ignite, we will launch the Technical Preview release of Project “Honolulu”, a flexible, locally-deployed, browser-based management platform and tools.
Project “Honolulu” is the culmination of significant customer feedback, which has directly shaped product direction and investments. With support for both hybrid and traditional disconnected server environments, Project “Honolulu” provides a quick and easy solution for common IT admin tasks with a lightweight deployment.
I’ve never managed any servers, so it’s difficult for me to gauge how useful of popular tools like these are. What is the usual way people manage their servers?
I spent several years working in IT at the National Park Service, which is an all-Windows affair. We did occasionally use AD, but normally we used a (paid) replacement called Hyena since AD was very annoying to use for some very common operations.
Hmm, interesting. Could you elaborate in more detail what were you using AD for? And how? And what problems you had with it?
We were primarily using it for managing users and machines. Mostly changing and setting passwords, adding and removing users and machines, and changing OUs of users. We used it occasionally for other things (I think some WSUS and DC configuration, but I was less involved in that).
We attempted to automate some these operations with PowerShell (which was new at the time), but the poor error reporting and lack of documentation meant we couldn’t get it to work.
Hyena made these tasks much faster, enough so that we bought licenses for it.
Understood. Seems like a fairly simple usage. Yes, Microsoft’s management tools for Active Directory, Group Policy and everything related to it (and there’s a lot related to it) are laughably basic. If you need something more flexible with automation capabilities, the only way is to bolt onto it some 3rd party product, such as Quest Active Roles Server (former Dell Active Roles Server, former former Quest Active Roles Server… it’s a funny story). Unfortunately, QARS/DARS is yet another can of worms with it’s own issues… But the ideas behind it are awesome, just technical execution somewhat lacking.
Edited 2017-09-15 16:53 UTC
When I was managing several hundred workstations and a couple dozen servers, AD was more than up to the task– Granted, that was with the (then) newly released Group Policy Preferences– tools that most people never figured out, so they bought third party packages.
We were deploying everything from drive maps, firewall rules, printers and software applications via GPO’s, and it worked fine.
We even had remote assistance working correctly on Windows 7 (with UAC enabled).
Orchestration was largely done with powershell.
Now I’m primarily a linux admin, so I edit puppet manifests and YAML, and wait for the magic to happen, and I use mcollective for orchestration.
I used to work as Active Directory specialist in a company with thousands of servers and hundreds of thousands of workstations across the globe with different AD sites being connected via all kinds of connections, including high-latency satellite links. The Active Directory architecture and technologies are mostly up to the task and handle everything no problem, but unfortunately their management tools are very rudimentary and just plain inadequate in situations like these.
I would have thought the distributed nature of your tree would have been more of a challenge, but I suppose they’ve improved AD synchronization. Always felt clunky by comparison with NDS.
I keep hearing the tools weren’t/aren’t up to snuff, but we never ran into a problem we couldn’t handle with native tools except inventory (ran an open source package via GPO’s to handle that).
We were distributing some very complex firewall rules (all admin / remote access was locked down to our admin stations and the DC) and if we needed to add a package to a system, or a group of systems, we just added them to the group for that software.
Printers, drive mappings, workstation policies– these were all relatively simple. The only real complaint I had was that you couldn’t add group policy objects to actual groups– You had to add it to an OU, and use groups to filter whether it was applied or not. That’s silly.
I’ve seen packages that aim to replace all that with a unified engine (LAN Desk is used at my current enterprise), and frankly, other than having a custom interface, I’m seeing very little I couldn’t do from within a well designed AD environment.
Those who know me should be amused, since for a long time, I argued against the Microsoft infrastructure– but then I transferred to a job where the entire ecosystem was Microsoft, and I hate reimplementing the wheel, so I dug in, and learned the Microsoft way.
It does take a fair amount of work to learn– and it’s not as straightforward as it could be. Some additional command line tools were required for bulk operations (sysinternals, primarily), although PowerShell eliminated most of the need for those.
I suspect most people who complain about the lack of capability in ADuc/GPO/GPP/etc never really learned how to take maximum advantage of the available tools. Adding PowerShell to the mix made it even more powerful.
Every operating system has it’s own paradigm– treating a windows desktop like a linux desktop would be disastrous, but equally, treating a linux desktop like a windows desktop would be ridiculous.
It’s worth learning the Microsoft Way(tm) if you’re going to manage Microsoft systems on a large scale.
Personally? I’m happy to be back in the land of unix/linux system administration.
You’re talking mostly about Group Policies here… Those are relatively fine in regards to management tools. Could be better, of course, but I could get by using only MS tools for managing Group Policies… The real problem was the scale of Active Directory itself… The amount of users, computers, servers, permissions, custom processes that need to be implemented for their provisioning, decommissioning, movement, self-service stuff, simple reporting… And even when troubleshooting and debugging, in many cases MS tools were just not up to the task, they simply did not have the capabilities required. And it wasn’t about learning Microsoft way… We did have Microsoft’s own field engineers on-site quite often.
If I had to describe Microsoft management tools for Active Directory, that word would be… bare
Edited 2017-09-17 08:40 UTC
It’s troubleshooting the Microsoft Way (TM) when it doesn’t work that I hate. Not many things more annoying than seeing something fail with an obscure error code that’s not even documented in Microsoft’s own reference material. That an PowerShell being the most overly verbose interactive CLI I’ve ever dealt with, and that includes OpenVMS and Juniper SRX. Recently things have gotten even more frustrating as Microsoft attempts a half-assed move of their admin tools to the Server Manager (a bloated modern-UI mess), which has made server management kind of like managing a Windows 10 desktop: an inconsistent half-assed jumble with conflicting documentation and uninformative diagnostic messages. I actually liked the Microsoft admin tools the way they were even though they were somewhat limited, as compared to what the situation is now. And, with this new project, they propose to change to something completely different yet again, not that a web-based system wouldn’t be an improvement at this point.
Depends on the size of your organization. If it is huge and a lot of servers (thousands), you usually do it via command line.
If it is a smaller organization, you can do both command line and GUI. The GUI can speed up simpler operations if the GUI supports them, so this is a very welcome addition, especially if you can manage the rest of the servers from one of your lesser used domain controllers.
Why would you ever do that?.. That’s horrible practice. Usually, you would have a dedicated admin server with terminal services role and licenses for many concurrent admins, plus all the needed administration tools installed on it.
Domain controllers, like all the other servers, need to be left alone to do their role. If you’re using some server for admin work that is not dedicated for admin work, you’re doing it wrong.
Yeah, additional licenses just to admin the damn thing…
Precisely. Unless, of course, you’re working in a small and el. cheapo company where such a cost cannot be justified. But then in that case you’re probably also using pirated licenses of Windows Server, too…
Rokas,
Sure, if you have significant load. But not all enterprises warrant dedicated servers for each function. It increases operational and licensing costs for not much benefit. This was the case at one of the places I worked at with about 20 desktop computers.
Sure if you have load issues, then dividing the high usage processes makes sense, but otherwise I’d recommend just keeping it simple
I haven’t done windows admin in a long time, my clients on the linux side tend to have one large VPS running several daemons (DNS, SMTP, HTTP, SSH, etc) rather than several smaller VPSs, which at their scales would incur higher costs and overhead than running everything on one instance.
Nope. Role segregation is not just about load distribution. It’s mostly about security, interoperability issues and ease of upgrades. You see, when you have only one role on the server, it’s much, much, MUCH easier to reboot it, upgrade it, do maintenance on it than on the server where there are dozens of very different critical services running, each of which might have it’s own needs/requirements… When you do maintenance on such a monolithic server, you’re basically taking down entire infra and there’s much higher risk that one or another role/service will fail after maintenance.
Also, if any single service/role gets compromised on such a monolithic server, you are totally screwed, since it means complete takeover of all your infra.
Edited 2017-09-15 08:09 UTC
Rokas,
Yes, there’s a valid point, this is the reason why it’s useful to run daemons under user isolation so that compromising one doesn’t compromise others. Unfortunately though even if services are logically & physically separated, it doesn’t necessarily mean we’ve stopped privilege escalation. For example, compromised websites often lead to compromised databases regardless of whether they’re running on a different server. Many of the ways to mitigate the risks apply equally to daemons running locally and remotely.
Small companies don’t often have the resources to hire specialized team, so for a lone overworked IT worker, it can be both easier and faster to restore a single server than to try and investigate exploits across many servers. Ultimately, I’m not necessarily disagreeing with you, but I am asking you to consider the small business perspective you may not have as much experience with.
I am talking OS patching. And I think both Windows and Linux still need a reboot after installing most OS/Kernel level patches.
Also, maintenance can include more activities than just updating… Even if you’re not expecting any downtime for a given maintenance activity, you must consider that possibility and act accordingly…
About the rest, yes, I agree. Many things are different in small companies with very small IT budgets.
Rokas,
I find this to be one of the biggest challenges with small companies. They want everything running smoothly 24/7 on a shoestring budget, alas those are often mutually exclusive, but you do the best you can, haha.
Most admins don’t properly segregate. Even if you have single roles running on different servers, just one getting compromised can still lead to a takeover of your infrastructure.
There is no real “it” tool. You use what makes sense within the context of the problem / task at hand.
Some things are enormously quicker via command line (SQL Server installs), others via GUI (following an SSL signing chain).
You can remotely manage Windows servers now via a GUI as long as there’s an MMC snap-in, but that (unless I’m mistaken) isn’t available on Linux… so a web-based IDE would be quite useful.
Well… I manage IT infrastructure since many years and this could be very interesting.
MS has since a long time group policies which is a really good way to spread rules and configs on a large number of servers.
MS also has different versions of Windows which allow to strongly reduce the surface of potential attack and at the same time reduces the maintenance complexity of systems. For example Windows Core, Hyper-V or Nano.
The big problem on those GUI-less versions of Windows was that it was always complex to manage individual settings and configurations not covered by GPOs. Server manager, to some point, allowed to do it but for the rest you had to rely on PowerShell.
You can do everything now with PowerShell (even more than what is possible through GUI) but let’s be fair. Even if I love PowerShell, sometimes it can be a pain for some tasks that are lightning fast through a GUI.
In this aspect Honolulu could really bring something.
One thing is sure, I’ll install this stuff in my Lab as soon as it’s available in preview and if it works well, it could make the management of my Hyper-V farms much much easier :-).
I’m really looking forward to it.
Given that PowerShell actually works on server. Which is not always the case. Also, every new version of PowerShell makes changes to the syntax for no other reason than to “change something” and break your habits (and scripts) in the process.
A lot of it depends upon the number of servers in the environment and the familiarity of the staff with various tools. I tend to go to the cli for a lot of items, especially with the ease that PowerShell brings to management, but sometimes there are things that are just plain easier to get done with a GUI. Which would be just about anything involving SharePoint, as I’m convinced that the PowerShell cmdlets were designed for programmers rather than for administrators. If you compare it to Exchange or Lync/Skype management it is a completely different style.
But there are definitely some admins and engineers I work with who would rather lose an arm than lose their GUI. Which fortunately means they give a wide berth to the Linux servers I stand up.
this looks like a clone of fedora’s cockpit, which basically does exactly the same things.
Microsoft has also been investing heavily in microservices and Nano builds of Windows Server with the new release. Now you can even run linux containers directly from Windows.
It’s usefull as well to have a local browser based management tool for your private repositories.
Problem is that they’re a bit late to the party. World has moved along for some time now. Not sure how long this catch up game will last for Microsoft.
Edited 2017-09-15 07:52 UTC
Has a suspiciously similar look like http://cockpit-project.org/ .
Edited 2017-09-15 08:15 UTC
Linux admins react:
2 claps, a cough and a grin
A very small baby step has been taken…
I did not get your comment. What was the point again?
He’s being sour. There’s a fix..
cat “Linux admins react:\n\n2 claps, a cough and a grin\n\nA very small baby step has been taken…” > /dev/null