Had some rather nifty issues with a DirectAccess array the other week – so I thought I would return here and blog it!
In short, everything was working fine apart from one very small part – “Manage Out” via IPHTTPS tunnel wasn’t functioning.
In short, clients were connecting the IPHTTPS tunnel before the Teredo was up. Whilst IPHTTPS is connected it will be preferred over Teredo (or 6to4) and disconnects after a random amount of time.
Clients could route traffic down here – so connecting to Intranet services was fine. Tunnel was up on both parts (Intranet/Infrastructure) and everything worked fine apart from “Manage Out”. Routes all fine, Windows Firewall (client-side) all fine.
Queue some hair tearing etc etc.
Raised a call with MS eventually – and in short its VMware causing the issue.
To quote MS (slightly edited to make sense outside of the Email trail);
We have had similar cases before where VMWare template provisioning was used for the UAG hosts, and can confirm that the problem was down to the template creating duplicate adapters that would affect tunnel bindings when configuring UAG DA. And the solution was to rebuild using standard media which completely addressed the issue.
Ouch. Oh well, rebuild we must (I’ll update once they are done!)
Had some other interesting information too regarding VMware, Unicast and DA NLB. I’ll update my original post here
Had a bit of a scary moment today – joined the Virtual Centre server to an AD so I could install backup technologies onto it.
All went fine aside from when I opened the vShpere client – all my hosts were marked as “not responding”.
Re-connected the hosts (as it can be seen above) – and the hosts popped back in and then back out again. Hmm not good!
Checked DNS, all right as far as I can see. Checked time sync, all right again.
Rather bricked myself, so off I went uninstalling the Virtual Centre server and reinstalling (using the existing DB) and voila! all is good.
In short, if you do have to join your Virtual Centre to AD, do it before you put Virtual Centre on it or reinstall afterwards!
When running a HA cluster verification you may get the following;
An error occurred while executing the test.
There was an error verifying the firewall configuration.
An item with the same key has already been added.
This is typically because the NIC GUID is duplicated between cluster nodes.
This could be because servers were deployed from an image, or cloned. Personally I had this with a VMware deployed server from a Template.
Remove and re-add a new NIC (add the new one first to be sure) and re-validate 🙂
When creating a LUN for a new MSCS, here is the methodology;
Just a quickie to remind myself of some NetApp settings 🙂
LUN Path = qtree object path (click through)
LUN Name = volume name.lun