How the Restart-Netadapter command fixed an inaccessible Windows Cluster

Introduction.

Recently a Windows Server OS upgrade of a two node cluster caused some head scratching issues.  This cluster consisted of two physical servers, each with ILO connectivity.  The cluster had on it several Hyper-V virtual servers - thus this upgrade was indeed a high impact change.  Working on physical servers remotely does require a steady hand.  Obviously with a VM server we can revert back to a snapshot quickly if something goes wrong - provided you have remembered to take a snapshot beforehand.

I did upgrade one node to Server 2022 and it appeared to go well.  But things started falling apart when upgrading the second node.

Why did the Cluster Collapse?

I had moved all the Hyper-V machines onto the upgraded server, in readiness for upgrading the now Hyper-V VM empty Windows Server.  The upgrade was from 2016 to 2022.  The upgrade of the second Windows 2016 server to Server 2022 went well and it was believed all was stable and OK.  But all was not well.  The problem was that the first server to be upgraded was now no longer accessible.  It could not be pinged nor could you RDP onto it.  

In addition the cluster was unmanageable using the Failover Cluster Manager tool.  An error message indicated one of the nodes was not contactable.

So what had happened?  

Thankfully I was able to access the offending server using the ILO portal and was able to sign into Windows using a local administrator account.  I performed an iponfig command and realized that it now had an APIPA address.

An APIPA address is a self-assigned IPv4 address in the range 169.254.0.1 to 169.254.255.254 with a subnet mask of 255.255.0.0, used when a device cannot obtain an address from a DHCP server.

This was most unusual because the NIC was configured with a static address and not a DHCP address.  

I cannot be sure how this did occur.  Nevertheless I was able to duplicate the issue in my lab by shutting the cluster node down.  I then assigned its IP address to another network device.  I then powered on the node - this replicated this issue using DAD (Duplicate Address Detection).

The Repair

I could not just restart the server node because it had live Hyper-V machines on it.  And I could not risk right clicking on the server's production nick and disabling it - as I was not sure I would not lose connectivity altogether, and not be able to enable it again.  So I tried the Restart-NetAdapter PowerShell command.  In my lab the command was:

restart-netadapter -name "Ethernet"

Initially this command failed because I had not started the cmd console with admin permissions.  When I did start with admin rights, the command executed successfully and my node now had its proper IP Address.

This then allowed me to connect to the cluster using the Failover Cluster Manager Tool.

Conclusion

We know how procedures should work - but oftentimes they do not work as expected.  In live environments and under strict change control timeframes it is important to keep cool.  Examine the logs, protect whatever connectivity you do have and resolve the issue - try not to panic.  I hope you have enjoyed reading about my cluster upgrade issues - and I wish your own troubleshooting endeavors as much success.

Join the HP ThinPro device to Active Directory

Introduction 

Indeed it has been some time since my last post, and now that I have a little reprieve from my busy work schedule - I thought why not write an article about my favorite subject: the great ThinPro linux based thin client device from HP. In this article I demonstrate how to join your device to a Microsoft Active Directory domain.

Joining the device to Active Directory

You will have to switch your ThinPro device into admin mode.  You can then open the Control Panel by clicking on the bottom left hand Start icon and selecting Control Panel. Click on the Manageability option.

The Active Directory blade is at the top of the list.  Enter in the Domain Name and select the Join the thin client to domain option.  If desired you can expand Advanced options and specify an OU to join - in this case I chose to leave this blank.

Click on Apply.  An information splash appears advising of a system reboot requirement.

Click on OK.  You are prompted to enter in your domain join credentials.

Click on OK.  The domain join process begins.

After about 30 seconds you are presented with a message and a requirement to reboot.

Click on OK to reboot the device.

You can now go into Active Directory Users and Computers and verify that your ThinPro device is now a member of your Active Directory.  In this case the ThinPro has been added to the Computers OU.

The Login experience for an AD joined ThinPro Device.

Now that the ThinPro device is a member of your domain, it does not just load straight into the desktop.  You are now required to enter in your AD credentials at startup.

Conclusion

The ThinPro device is a very secure solution.  Using the AD join feature will add an extra layer of security to your user's experience.  In addition, support staff will now be able to switch the device into Admin mode using an Active Directory administrator account and password, thus a single root administrator password does not need to be disseminated to multiple administrators.  I hope you have enjoyed this little post, and I wish you the same success in joining your ThinPro device to your Active Directory Domain.