Thecus NAS devices – when things go weird

I’ve use a few Thecus NAS devices, but most of my experience has been with the N8800Pro and the N5200XXX. Both have, at various times, given me a great deal of grief.

The first thing to note is that these devices are only doing software RAID. This is a pain, because of the performance implications. This is also a boon, because of the recovery options it gives you. Either way, it’s good to know before you buy.

The second thing to note is that a power failure can, on occasion, cause disks in the array to be incorrectly flagged as failed. If you are very unlucky, this may cause your array to not only become degraded, but also just to fail to mount. If you can pull the disks out and identify them, you can force the disk improperly flagged to be marked clean and remount your array. Slot the disks back in to the Thecus (you labelled them, right?) and everything should start normally.

The third thing to note (and the inspiration for writing this post) is that sometimes, when you change the network configuration, the Thecus will start to lie to you. It will claim that it is restarting, but isn’t. Or that it is shutting down, but isn’t. Or that it is changing the network configuration, but, you guessed it, IT ISN’T. Pings are maintained the whole way through these procedures, as is access to the admin web interface.

This is bollocks.

The only way I’ve found to get around this rubbish cleanly is to install the HiSSH module from Thecus. When you have downloaded and installed, make sure you activate it. Use Putty to connect to the IP of the Thecus, and use the username ‘root’ and your usual admin password. The just use the bash command ‘reboot’ and you’re away.

If you own a Thecus NAS and it’s compatible with that module, download, install and activate it now. If things seem screwy, you’ll have another hammer to bash away at the problem with.


Getting KMS hosting working on Server 2012 Core

I had occasion to set up a Windows Server Datacentre 2012 Core VM recently, as a domain controller, FSMO role holder, and DNS server.

Since the network didn’t have a KMS host in use (but did have KMS keys) I thought I’d set it up as one.

Installing the key and activating the host is a cinch. From an administrative command prompt:

slmgr -ipk <key>
 slmgr -ato

But to get other clients to connect to this host, there are a few hoops to jump through.

First, you need to set a firewall exemption for the KMS traffic. From the same command prompt:

netsh advfirewall firewall set rule group="Key Management Service" new enable=yes

You’ll also need the DNS entry for the KMS service. This should be created automatically by your first KMS host, but if it isn’t there are a few permissions you’ll need to set. I followed the broad instructions here to allow for adding another KMS host in the future. In my situation, however, the KMS entry was automatically created.

It’s also worth noting that if you have multiple DNS servers (you do, don’t you?) then you’ll want to wait for, or force, replication of this record between those servers to avoid red herring chases of spurious DNS errors.

Your last obstacle should then be actually getting enough clients to try to authenticate that your KMS host can activate them. If you have a bunch of servers, this is easy again. Five servers should tip you over to activation, or you can settle for 25 workstation clients.

If you need the KMS client keys, everything from 2012 R2/8.1 on down is here:

Server 2012 VM Replication with Workgroup hosts

Replication between two 2012 Hyper-V hosts that aren’t members of a domain is a little more complicated than the domain-joined route. Between two resources, you should be able to get this set up with a minimum of fuss, however.

An excellent, step by step guide:

The only shortcoming here is that if you plan to do this replication as a kind of internal-only disaster recovery option, buying SSL certificates might not be worth it (although the certs you would need are pretty cheap). This is particularly true if you’re just testing and don’t want to spend money on certificates you’ll be throwing away.

Implementing self-signed certs is pretty easy as well. There’s a decent, though flawed, guide from Microsoft here:

The flaws are a couple of typos, and a registry key not included that your environment may require. Check the comments for the extra information you’ll need.

Note that you need the makecert.exe tool from the Windows SDK. If you don’t have this (or Visual Studio) it’s a quick and easy install.

I came across one infuriating gotcha, in that I ran the makecert.exe tool from a PowerShell window, and on the longer commands received errors about too many parameters. Hunting around for solutions led me up the garden path chasing improperly coded dashes. The solution is much easier: run this from an elevated command prompt, not from PowerShell. Worked for me straight up.

Creating DHCP reservations in Windows Server

I wrote earlier about exporting DHCP reservations in Windows Server using netsh. Have a look at that post and follow the instructions to get the reservations from a full DHCP scope dump.

Having exported our DHCP reservations, we’ll now look at how to get netsh to help us recreate them in another scope, or on another server.

Assumptions: we dumped our scope ( from a server PHOENIX1 on the domain, and we want to recreate those reservations in a scope ( on a server PHOENIX2 on the domain bookgrub.local. We’ll be leaving the last two IP address fields the same, so will be becoming

To begin, we’ll need to open the text file that has our reservations and examine the contents. Helpfully, our netsh dump has outputted the full command syntax we’ll need to reimport the reservations. Here’s a sample line showing a reservation for a Sharp MX-450 photocopier, netbios name SharpMX450, able to be given both DHCP and BOOTP reservations:

Dhcp Server \\ Scope Add reservedip 001122aabbcc "SharpMX450" "Sharp MX-450 Photocopier" "BOTH"

With just a couple of quick steps followed, we’ll have all the reservations in our new scope in no time.

Tidying up

Our find command has dropped a couple of extraneous lines at the top of the text file, so delete them.

Search and destroy replace

  1. Replace phoenix1 with phoenix2
  2. Replace with bookgrub.local
  3. Replace 192.168 with 10.10

That’s it for this example. Obviously, YMMV in practice. Your worst likely case, though, is probably only going to need to be manually changing reserved IPs in addition to the steps we’ve taken here. In most cases, you’ll want to retain the description and name of your reservations.


Save the file (in a different name if you want) and copy it across to your destination DHCP server. Open an administrative command prompt and CD into the directory you saved the file in (ours is called reservations.txt). Then run the command:

type reservations.txt | netsh

All being well, you just recreated all your DHCP reservations, with new IPs in a new scope on a new server in a new domain in maybe just a couple of minutes. Give yourself a pat on the back (mentally, so you don’t look stranger than usual) and move on with the next job.

Exporting DHCP reservations in Windows Server

Easily the most horrible thing about documenting, migrating, or recreating DHCP scopes in Windows are the DHCP reservations.

I create reservations for anything that is getting a static IP, along with the usual suspects like network printers, APs, and so forth. So on any decent size, flat network this can be a lot of work if you have to recreate or document it manually. This is particularly true when you inherit a network and haven’t been able to document as you go.

I’ll deal with using this data in a later post, but the commands below will give you a list of existing reservations to reference or document.

To start, it’s best if you know the scope (dotted quad) and DHCP server name or IP. Examples below will assume the DHCP server is PHOENIX1, and our scope is All these commands need to be run from an administrative command prompt, and it’s easiest on the DHCP server itself. We’ll save all outputs to txt files in the C:\Temp directory.

If you only care about IP and MAC, use:

netsh dhcp server \\phoenix1 scope show reservedip > C:\Temp\showReservedIP.txt

To get a dump of your entire DHCP scope:

netsh dhcp server \\phoenix1 dump > C:\Temp\scopeDump.txt

Then you can filter that for just the reservations, this time getting most of the useful information including source server, scope, ip, MAC, reservation name and reservation description:

find “reservedip” C:\Temp\scopeDump.txt > C:\Temp\reservations.txt

You can do this in one line, using a pipe.

netsh dhcp server \\phoenix1 dump | find "reservedip" > C:\Temp\reservations.txt