Windows Server 2025 is now generally available. It delivers security advancements and new hybrid cloud capabilities in a high performing, AI-capable platform. Windows Server 2025 is Microsoft’s latest Long-Term Servicing Channel (LTSC) release for Windows Server. To download a free 180-day evaluation, visit the Microsoft Evaluation Center.
To learn more about Windows Server’s Lifecycle Policy, see the Windows Server 2025 lifecycle article.
One aspect that hasn’t been discussed yet is the release of ARM64 support. While there were some ARM64 releases during the testing phase in the insiders group, there’s no official word on the GA versions yet. Additionally, here are the minimum requirements for CPUs. (From NeoWin).
The GodBoxV3, equipped with its first-generation Xeon SP processor, requires an upgrade to transition to Server 2025. Hmmm….
With the whole Work From Home thing probably becoming more and more normal in the years to come (I can count on 2 hands how many times I have physically been in my main office in the last 7 months) there are a couple of certainties in that people will come up against. One is passwords expiring and needing to be changed, one is password resets being required and finally laptops or desktops needing to be domain joined or connected to the domain before they can be fully provisioned. As the (currently only) IT guy in our office, I have had to deal with these first hand, and decide to write this post, helping both my fellow employees, and possibly other IT Admins stuck in this challenge.
So, as the IT person, there are a couple of assumptions:
You have on premises AD
You have Azure AD (P1 and above seems to be required if users are mixed AD and on prem. Free allows just Cloud users).
Azure AD Sync installed and enabled
If all above are set, you will need to follow the steps to Enable Azure Active Directory Self Service Password Reset. I have enabled this on our domain. Next, you need to get your users to setup their secondary authentication for backup. All our users have a 2FA requirement, so most of them had that already. New users need to go though those setups. Finally, if a user needs to change or reset their password, they can do so though https://aka.ms/sspr. If all is done well, that reduces the amount of support calls I (and you) get.
Now, the next task: domain joining over VPN. This is a bit more “fun” to play with.
First, you need a VPN connection. We use Meraki gear using Active Directory for RADIUS auth. I wont go into too much details on setting that part up, but the script we use to build the VPN connections for users is below. This will probably be different for different VPNs, but this is our starting point.
Lines you need to change are at 8, 9, 10 and 47. Line 39 can also be modified to change from Split Tunneling (only sending traffic to internal subnets) or full Tunneling (all traffic over VPN). If you have multiple internal subnets, Line 49 can be copied with more.
The most important part we need though is line 34. The -AllUserConnection allows the connection to be available to all users on the machine, but also on the start screen. This is important.
So, with all that in place, you will need to connect to the VPN
you should now be able to join the domain as if you where on your local network.
reboot your machine as usual and when it boots, you should see a new option on the login screen
Click this icon and if you only have one VPN connection the screen below will show up. If you have more than one, you will be given a list of options to use.
Enter your domain credentials. Since our AD and VPN use the same credentials, it will automatically log you in aswell.
So, there you have it. How to domain join a machine outside the network. Now, in reality, Azure Active Directory and Intune would probably be the better option, but that’s future work…