DNS/DHCP issues in modern Windows versions

Static IP addresses are a solid way to configure machines if you have few enough of them to manage them manually. But the more ability you want to have to change things on the fly, the more limiting such a configuration scheme becomes.

Unfortunately I’ve had severe problems with getting servers with DHCP leases (or even DHCP reservations) to have their names stick in DNS over time. Suddenly, after a reboot a machine would seemingly drop off the network even though it had the same IP address as earlier. Rebooting or manually re-registering its DNS record would solve the problem, but it wasn’t an acceptable solution to the underlying issue.

I found a discussion that gave a few pointers on how to get these things working in Windows, and I’ve shamelessly ripped the relevant points to present them here:

Step one: Define a user in whose context the DHCP server will run

Simply add a domain user with no special rights, and give it a properly strong password. Then open the DHCP management console, right-click the protocol you want to change (IPv4 or IPv6), and select Properties and the Advanced tab. Click Credentials and enter the relevant information for the account.

Step two: Tell DHCP to always attempt to update DNS records

In the same properties window, select the DNS tab. Ensure the following choices are ticked:

Enable DNS Dynamic Updates(…) -> Always dynamically update DNS records
Dynamically update DNS records for DHCP clients that do not request updates

Step three: Ensure DHCP server AD group membership

The DHCP server(s) should exist in the group DNSUpdateProxy. No other user or computer accounts may exist in this group.

Other tips

Make sure DHCP leases are longer than 24 hours, or bad things are likely to happen. A concrete example given is that Microsoft KMS servers have a 24 hour update cycle.

 

SMS notifications from Zabbix

To increase visibility of critical alerts, I’ve set up Zabbix to send messages to the phones of certain technicians via a GSM modem. This post documents what I had to do to get things running.

  • Zabbix server
  • MOXA ethernet-to-serial gateway
  • Siemens GSM modem

The first thing to do is to get the driver for the MOXA gateway running. The documentation is alrightish and covers some of the most used Linux distributions. Dissappointingly, after running through the checklist in the README file, the MOXA gateway will only work until after the next reboot.

The problem here, is that the init script for the MOXA driver removes and then recreates the device nodes on startup, and the scripts being called (mxmknod and mxrmnod) contain references to current dir (./) rather than their absolute path (/usr/lib/npreal2/driver). Edit those scripts, and you’ll have a working driver even after the Zabbix server reboots.

It should now be possible to test the modem by running, for example, socat - /dev/ttyr00 and entering some AT commands like in the olden days.

The next step is to install the gsm-utils package, which will create the possibility to easily send messages. Without any other options set, the gsmsendsms command expects there to be a device called /dev/mobilephone. We can create that one by making a symlink with that name to /dev/ttyr00, or we can tell the command which device to use with the -d argument.

Try sending a message: gsmsmssend -d /dev/ttyr00 <phone_number> "Hello World!"

This does not immediately solve how to send messages from Zabbix, though. Recent versions of Zabbix do have an SMS media type that can be called on, but it doesn’t seem to work when not speaking directly to one of the two modems on the compatibility list. Fortunately it’s very easy to create a new media type:

To prepare for this, create the folder /etc/zabbix/alertscripts, then modify the AlertScriptsPath definition in /etc/zabbix/zabbix-sever.conf to point at this directory, and restart the Zabbix Server service.

Now create the script /etc/zabbix/alertscripts/sendsms with the following contents:

The -c $serial argument is used to create a unique ID when serializing messages longer than 160 characters, as per the SMS standard. $1 will be populated with the contact phone number, and $2 will be populated by the actual message from Zabbix.

Finally let’s create our Media Type definition in Zabbix:

Under Administration -> Media Types -> Create Media Type define the following:

To be able to alert users, Zabbix needs to know how to contact them using this new media type:

Administration -> Users -> <username> -> Media -> Add

And finally you need to create Actions that define when to send messages via this solution, under Configuration -> Actions.

Voilà: Zabbix just got a bit noisier, in a good way.