Window 11 24H2 / Can't Join Domain

It is clear that version 24H2 has a serious problem with certain network/domain combinations.

In our case, a Windows Server 2016 Domain server, a Single Label domain, which works without problems with versions 23H2 of W11 and W10.

We have tried all the recommendations found:

• Activate the key AllowSingleLabelDnsDomain in the registry
• Disable IP6
• Manually configure the DNS
• use the .local suffix of our domain

The only solution that worked for us, but partially, was to activate the Credential Guard by editing the Windows registry In the path HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Lsa including the key "LsaCfgFlags" with value 1 or 2 (to use or not the UEFI lock, 1 uses it, 2 does not...)

This option already allows logging in with the domain user, but all connections to shared resources or logon scripts or access to shared directories of sysvol or netlogon are lost, so our users do not have full functionality when connecting to our network.

The only thing that works is going back to version 23H2 from the Windows Update options, as long as it hasn't been more than 10 days since the PC was updated.

To prevent this DISASTER VERSION of Windows 11 from being installed, we have created a script with registry modifications to block the version to 23H2

In the path: HKLM:\SOFTWARE\Policies\Microsoft\Windows\WindowsUpdate

Create the keys:

• "TargetReleaseversion" type DWORD32, with value: 1
• "TargetReleaseversionInfo" type STRING, with value: 23H2

Currently we cannot get the 23H2 ISO since Microsoft only offers 24H2 to the public, but if you are a Microsoft Insider, you can get the 23H2 ISO by downloading the iso: Windows 11 Insider Preview (Beta Channel) - Build 22621

I'm afraid we have to wait for Microsoft to create a new build that fixes all these problems. In the meantime, formatting, reinstalling or returning to Windows 10 are the options we will have to use.

We are having the same issue, and the work-around we've been using is just doing an offline domain join using the djoin command.

same story here with same results.

Are we even sure this problem lands at Microsoft? till now no relpy from moderator, technician or something.

just silence...

I had the same problem with a "mydom." without tld .lan, .local .

The problem was present both on 23H2 and 24H2

Here is the fix I found and solved the problem :

On each DC :

KEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Netlogon\Parameters\AllowSingleLabelDnsDomain  (dword 1)

On computer :

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\DnsCache\Parameters\UpdateTopLevelDomainZones (dword 1)

Restart computer and join on "mydomain." (do not forget the "." to validate tld )

Hi Everyone,

I encountered the same issue, specifically with my 24H2 OSD deployment. Every time I deployed 23H2, the OS installation and domain join were successful. However, with 24H2, I ran into problems. Upon checking the NetSetup.log, I noticed that the Setup Config Manager step took 20 minutes, during which the following errors occurred:

- NetpModifyComputerObjectInDs: Account exists and re-use is blocked by policy. Error: 0xaac

- NetpProvisionComputerAccount: LDAP creation failed: 0xaac

As a result, the client could not join the domain.

I found an Article indicating that if the OS was patched with the August 13, 2024 update, even 23H2 would fail due to NetJoinLegacyAccountReuse.

The issue arises if:

• The user attempting the operation is the creator of the existing account.
• The computer was created by a member of domain administrators.
• The owner of the computer account being reused is part of the "Domain controller: Allow computer account re-use during domain join" Group Policy setting.

This setting requires the installation of Windows updates released on or after March 14, 2023, on all member computers and domain controllers.

**Solution:**

Configure the new allow list policy using Group Policy on a domain controller and remove any legacy client-side workarounds. Follow these steps:

1. Install the September 12, 2023, or later updates on all member computers and domain controllers.
2. In a new or existing group policy that applies to all domain controllers, configure the settings as follows:
   • Navigate to Computer Configuration\Policies\Windows Settings\Security Settings\Local Policies\Security Options
   • Double-click Domain controller: Allow computer account re-use during domain join
   • Select Define this policy setting and ``
   • Use the object picker to add users or groups of trusted computer account creators and owners to the Allow permission (preferably using groups for permissions). Do not add the user account performing the domain join.

**Warning:**

Limit membership to the policy to trusted users and service accounts. Do not add authenticated users, everyone, or other large groups. Instead, add specific trusted users and service accounts to groups, then add those groups to the policy.

3. Wait for the Group Policy refresh interval or run gpupdate /force on all domain controllers.
4. Verify that the HKLM\System\CCS\Control\SAM – "ComputerAccountReuseAllowList" registry key is populated with the desired SDDL. Do not manually edit the registry.
5. Attempt to join a computer with the September 12, 2023, or later updates installed. Ensure one of the accounts listed in the policy owns the computer account. If the domain join fails, check the c:\windows\debug\netsetup.log.

If additional workarounds are needed, review computer account provisioning workflows and understand if changes are required. Here are some options:

• Perform the join operation using the same account that created the computer account in the target domain.
• If the existing account is stale (unused), delete it before attempting to join the domain again.
• Rename the computer and join using a different account that doesn’t already exist.
• If the existing account is owned by a trusted security principal and an administrator wants to reuse the account, follow the guidance in the Take Action section to install the September 2023 or later Windows updates and configure an allow list.

**I have opened a case with Microsoft and have received confirmation that the above is a solution to this problem**.