But its a dhcp server, network admins would be expected to touch config files, and the interface for a DHCP server really can't be much worse than the GUI version that microsoft supplies!
but digressions, to say "this is why I won't use a linux desktop" in response to a server-specific use-case, is at best antagonistic!
Seriously, I understand where you're coming from, but you're blathering needlessly about an issue that is a) not really a contentious one, and b) completely irrelevant to the discussion.
Conversely, most group policies I have ever needed were pointed out, including where to find them, after one web search, and their use is extensively documented in the config editor.
> were pointed out, including where to find them, after one web search,
Well, if you are doing that one web search, it doesn't matter whether the named key is for gui or text config. Except for that localization issue, if you find English string, it won't help you with localized one.
Then there is the issue of the GP items themselves: many times you don't know whether to choose enable or disable, because double negatives FTW.
There are still some configuration items that have to be set in the registry or through Powershell (wmi and so on). The registry is much worse than editing files in /etc/ because you can't back it up, revision control it, or put comments in.
Random googling reveals people having surprisingly similar problems with the Windows DHCP server: https://community.spiceworks.com/topic/332253-cannot-backup-...
As for GNU/Linux, I know it since Slackware 2.0.
Leaving aside the fact that the variation among Windows versions is quite small versus the GNU/Linux distribution fragmentation.
Making it authoritative is then to just press a button in that dialog.
Yes. You have to know that you have to open the GUI for DHCP server configuration in order to configure the DHCP server, but that's really all you need to know to prevent the issue described here.
isc-dhcpd that's often used under linux doesn't even warn to syslog when it's not authoritative. All indication for doing so is given in the sample config file using
# network, the authoritative directive should be uncommented.
#authoritative;
It doesn't however explain to you why you should or shouldn't do that and, again, it starts up just fine without this uncommented.Case in point: Back when I was learning about all of this my Windows-based DHCP servers were all authoritative, whereas none of my Linux or FreeBSD based DHCP servers were.
# If this DHCP server is the official DHCP server for the local
# network, the authoritative directive should be uncommented.
From that, it’s a little more clear that you should be uncommenting that option.Though for the opening to the current discussion that is a moot point - this is not relevant to either OS on the desktop.