Windows Server 2025 / How to Join a Windows Client to the AD Domain
Joining a Windows client to AD requires a supported edition, working internal DNS and domain connectivity, and permission to create or reuse its computer account. Point CLIENT1 at DC1, join ad.example.test, restart, and verify both the computer and user session.
Prepare discovery and join permissions
Use a Windows edition supporting AD domain join, such as the appropriate Pro or Enterprise edition. Windows Home and Microsoft Entra enrollment are different cases. DC1’s AD and DNS must work on the shared isolated network.
- Finalize CLIENT1’s name and retain a working local administrator sign-in route.
- Use DNS 172.24.50.10 and inspect actual DHCP options if applicable.
- Verify date, time, and domain communication.
- Prepare an account with the required computer-object creation or reuse rights.
Resolve-DnsName '_ldap._tcp.dc._msdcs.ad.example.test' -Type SRV -Server 172.24.50.10 nltest /dsgetdc:ad.example.test
Run these on CLIENT1. Resolve failed discovery before retrying passwords. Review domain join permissions and delegate only the needed scope.
Join through System Properties
- Run sysdm.cpl on CLIENT1 and choose Change on the Computer Name tab.
- Select Domain and enter ad.example.test.
- Supply an authorized domain identity, not CLIENT1’s local password.
- Verify the success message, save work, and restart.
- Choose Other user and sign in using AD\username or username@ad.example.test.
See the official domain join procedure. If the ordinary lab user has not yet been created, verify administration first and test that standard user later. Do not keep Domain Admins as an everyday identity.
The first domain sign-in does not automatically reuse the old local profile. A different desktop and preferences can be expected. Back up and plan any data migration rather than deleting the previous profile folder.
Use PowerShell as an alternative
Use this in elevated Windows PowerShell only if the GUI has not already joined CLIENT1. Enter credentials interactively and inspect the join result before restarting:
$joinCredential = Get-Credential Add-Computer -DomainName 'ad.example.test' -Credential $joinCredential -PassThru -Verbose Restart-Computer
A restart cannot turn a failed join into a successful one. The same preparation can join member server FS1, retaining its static .20 address and changing DNS to working domain DNS.
Check membership and the signed-in identity separately
Get-CimInstance Win32_ComputerSystem | Select-Object Name,Domain,PartOfDomain whoami $env:LOGONSERVER Test-ComputerSecureChannel -Verbose
PartOfDomain should be True and Domain should be ad.example.test. whoami identifies the current session, which can still be local on a joined computer. Test-ComputerSecureChannel here is for clients or member servers, not a substitute for domain-controller diagnostics.
In Active Directory Users and Computers on DC1, locate CLIENT1’s object. Computers is a default container, not an OU; move the object to the lab Workstations OU later for policy exercises. User and computer objects have separate locations.
Handle reuse restrictions and leaving the domain carefully
Current join protections can block reuse of an existing computer object. Inspect ownership, delegated rights, and the existing device’s status rather than disabling checks or deleting an active computer account. Review the relevant timestamp in C:\Windows\debug\NetSetup.log.
Before a departure exercise, confirm local administrator access. Change membership to a workgroup, authorize the change, and restart. Local profile data and server-side object cleanup require separate decisions. Keep CLIENT1 joined for the rest of this course, recording join, ordinary-user sign-in, DNS, and secure-channel results independently.
