DirectAccess – Server Responsiveness; Server Availability Error with NLB

DirectAccess is a picky beast to get configured properly. This is mostly why I have a job. Some of the more complicated DirectAccess configurations involve NLB, especially so when Windows Server NLB is deployed instead of an external load balancer like a Kemp. Hey, Windows Server NLB, you’re great and all, and I’mma let you finish, but external load balancers are still the best thing ever.

With that out of the way, let’s say you’ve deployed DirectAccess in a single server configuration, made sure it was working correctly, then configured the topology for NLB. The Remote Access Configuration task has done its thing and configured the NLB cluster. I 100% guarantee your previously working deployment is no longer a working deployment at this point. This is partially because of the way your hypervisor handles unicast vs multicast cluster traffic. I’ll outline this and post up a link later, but let’s say that you’re a wizard and you already configured your cluster for multicast, OR performed the necessary steps to get unicast working. You might be greeted by an error stating "Critical – Server Responsiveness; Server Availability" in the DNS node for all your cluster members.

This is caused by a problem (feature?) within the Remote Access Configuration/NLB services that doesn’t re-apply the IPv6 address to the cluster after changing cluster modes. The fix is easy. Open NLB manager, and go to cluster properties:

You’ll see it only has an IPv4 address.

Add the IPv6 address as indicated by the error in the Remote Access console (it'll always end in 3333::1), let the cluster re-converge, and your Remote Access deployment will be up and at ‘em like a mosquito at a barbeque.

This article is current as of 7/25/2016, on Windows Server 2012 R2, patched to KB3156418 – May 2016 Update Rollup. Let me know in the comments if you see this behavior on a different configuration of Windows Server.

Spread the word about DirectAccess! If you're reading this article, you're a member of a very exclusive club. There are literally dozens of us!

DPM – Replicating backups for failover or DR

There are some things I wish Microsoft hyped a bit more. System Center Data Protection Manager is one of those products that typically falls off an IT admin’s radar, even when they already have System Center in place on the network in some form or another. Don’t forget, if you threw down for a System Center license, you own the whole suite! The world is your Systems Management oyster.

All aboard the hype train. Did you know that you can replicate your DPM backups? This can be a key component in your DR strategy. There are a few different ways you can configure DPM replication, but only one really matters. Essentially, DPM can be configured to back up another instance of DPM like it were any other server. Luckily for us, DPM is smart enough to realize it’s trying to protect another DPM instance and will configure itself accordingly. Let’s dive in:

Have two DPM instances configured and running. Using your secondary DPM instance, attach to the DPM agent on your primary server.

Add the primary server to your secondary DPM server’s protected items.

Note: you’ll definitely want to configure a unique protection group for your replicated DPM instances.

That’s it. No matter what, make sure you’ve protected the DPM database of your primary server, as you cannot restore protected DPM data without it. You can even pick and choose which protected items you’d like to replicate, including app-aware items like SQL or SharePoint backups!

What about failover? Using data that’s already been replicated, you can force your existing servers to utilize the secondary DPM server as their primary.

Happy DPM-ing!