Windows Client Running Out of Storage? Solutions to Free Up Space

Table of Contents

When attempting to join a client computer to a domain managed by a Windows Server 2003 or later domain controller, administrators may encounter an error message indicating a lack of sufficient storage to complete the operation. This message, while seemingly straightforward, often points to a specific underlying technical issue rather than a physical disk space problem on the client machine. Understanding the root cause is key to implementing the correct resolution.

Symptoms¶

The primary symptom of this issue is the failure to successfully join a Windows XP or a later version client computer to a domain. Upon attempting the domain join, the client computer displays an error message similar to the following:

The following error occurred attempting to join the domain “domain_name.com”: Not enough storage is available to complete this operation.

This error occurs specifically during the authentication phase when the client computer communicates with the domain controller. Although the error message references “storage,” it does not typically mean the client’s hard drive is full. The problem lies within system resources allocated for handling authentication data. While the article doesn’t detail specific Windows system logs for this exact scenario, related Kerberos authentication issues often log warnings or errors in the System event log, which might provide further clues about the authentication failure, potentially mentioning token-related problems.

Cause¶

This particular “Not enough storage” error during a domain join operation is commonly caused by the Kerberos token generated during the authentication process exceeding its maximum allowed size. Kerberos is the default computer authentication protocol used by Microsoft Windows operating systems. When a user or computer authenticates to a domain, the domain controller issues a Kerberos token (specifically, a Service Ticket or a Ticket Granting Ticket, depending on the context) that contains information about the security principals the user or computer belongs to.

A significant factor contributing to the size of the Kerberos token is group membership. When a user or computer is a member of various security groups within Active Directory, the Security Identifier (SID) for each of these groups is included in the user’s or computer’s access token. This access token is then encoded into the Kerberos authentication token. In complex Active Directory environments where users or computers are members of a large number of groups, especially nested groups (groups that are members of other groups), the list of SIDs can become quite extensive.

Historically, the default maximum size for a Kerberos token (MaxTokenSize) has varied across Windows versions. In the initial release of Microsoft Windows 2000, the default value for the MaxTokenSize registry entry was 8,000 bytes. With the release of Windows 2000 Service Pack 2 (SP2) and in all subsequent Windows versions, the default value was increased to 12,000 bytes to accommodate larger group memberships. However, even with the increased default size, scenarios exist where the cumulative size of all SIDs, along with other necessary information included in the token, can exceed this limit. When the Kerberos token size required for authentication exceeds the configured MaxTokenSize, the authentication attempt fails, resulting in the “Not enough storage” error message.

Essentially, the “storage” referred to in the error message is not disk storage but rather the buffer space allocated in memory for processing the authentication token.

Resolution¶

The resolution for this specific problem involves increasing the maximum allowable size for the Kerberos token on the client computer experiencing the issue. This is achieved by modifying a specific registry entry. The change should be performed on the client computer that is failing to join the domain and logging the error.

Here are the detailed steps to increase the Kerberos token size via the Windows Registry Editor:

1. Access the Registry Editor: Click the Start button, then click Run. In the Run dialog box, type regedit and press ENTER or click OK. This action opens the Registry Editor window, which allows you to view and modify system-level settings stored in the Windows Registry. Exercise caution when editing the registry, as incorrect changes can lead to system instability or failure.

2. Navigate to the Kerberos Parameters Key: In the Registry Editor, navigate through the hierarchical structure in the left pane to locate the following registry subkey:
   HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Lsa\Kerberos\Parameters

3. Create the Parameters Key (if necessary): It is possible that the Parameters key does not exist under the Kerberos key. If you cannot find the Parameters key, you will need to create it manually. To do this:

   • Locate and click the HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Lsa\Kerberos key.
   • On the Edit menu, point to New, and then click Key.
   • A new key is created. Type Parameters as the name for the new key and press ENTER to confirm.

4. Create the MaxTokenSize DWORD Value: With the Parameters key selected (or newly created and selected), you need to create a new registry value.

   • On the Edit menu, point to New.
   • Click DWORD (32-bit) Value. (Even on 64-bit Windows versions, this value is typically a DWORD).
   • A new DWORD value is created with a default name like “New Value #1”. Type MaxTokenSize as the name for this new value and press ENTER.

5. Modify the MaxTokenSize Value: Now that the MaxTokenSize value exists, you need to modify its data to the recommended size.

   • Right-click the newly created MaxTokenSize value in the right pane, and then click Modify. Alternatively, select the value and on the Edit menu, click Modify.
   • The “Edit DWORD (32-bit) Value” dialog box will open. In the Base area of this dialog box, select the Decimal radio button. It is crucial to set the value using the Decimal base.
   • In the Value data box, type 65535. This is the maximum recommended value and corresponds to 65,535 bytes. Setting it to the maximum allowed value helps ensure that this specific Kerberos token size issue is resolved for even very complex group structures, up to practical limits imposed by the protocol itself.
   • Click OK to save the changes to the MaxTokenSize value.

   Note on Value Data: The default value for MaxTokenSize in Windows 2000 SP2 and later is 12,000 (decimal). Setting the value to 65535 (decimal) is the commonly recommended resolution for this specific domain join error. It’s very important to ensure you select Decimal as the base and type 65535. If you mistakenly select Hexadecimal and type 65535, you would be setting a much larger value (which translates to a decimal value of 4194303), which can potentially cause other issues with Kerberos authentication or related programs. Always double-check that you are using the Decimal base.

6. Exit Registry Editor: Once you have successfully modified the MaxTokenSize value, close the Registry Editor window.

7. Restart the Computer: For the registry changes to take effect, you must restart the client computer. A full restart is necessary for the system to load the new registry configuration into memory and apply it to the Kerberos client processes. After the restart, attempt to join the domain again.

Following these steps should resolve the “Not enough storage” error that occurs specifically due to the Kerberos token exceeding its maximum size during the domain join process.

More Information¶

The size of a user’s or computer’s Kerberos token can be influenced by several factors within an Active Directory environment. Understanding these factors can help administrators predict and mitigate potential MaxTokenSize-related issues. Key factors include:

• Direct Group Memberships: The number of groups a user or computer is directly a member of. Each direct membership adds the group’s SID to the token.
• Nested Group Memberships: The number of groups a user or computer is indirectly a member of through nested groups. Every layer and group in the nesting hierarchy contributing to the user’s effective permissions results in SIDs being added.
• Universal Groups: Membership in universal groups is always included in the Kerberos token in all domains in the forest, which can add to the token size, especially in large multi-domain forests.
• Domain Local and Global Groups: Memberships in these group types are included in the token primarily when authenticating within the domain where the group resides.
• SID History: When objects (users, groups) are migrated between domains using tools that preserve SID history, the old SIDs are added to the new object’s SID history attribute. These historical SIDs are also included in the Kerberos token, further increasing its size.
• Authentication Protocol: While this article focuses on Kerberos, the issue primarily affects Kerberos due to how it packages authentication data, including SIDs. NTLM, the older Windows authentication protocol, handles group information differently and is generally not affected by this specific token size limitation in the same way during domain join.

While increasing MaxTokenSize to 65535 bytes is a common and effective workaround for the domain join issue, administrators should be aware of potential side effects when tokens become excessively large (e.g., exceeding 48,000 bytes). Very large tokens can impact performance in applications that use Kerberos authentication, such as web servers (IIS), SharePoint, or file shares, potentially leading to slow authentication, connection failures, or errors like HTTP 400 “Bad Request” if the token exceeds HTTP request header limits. In such complex scenarios involving applications, further tuning or architectural changes (like reducing group memberships) might be necessary beyond just adjusting MaxTokenSize. However, for the specific domain join problem described, setting MaxTokenSize to 65535 is the standard and recommended first step.

Let’s summarize the default and recommended MaxTokenSize values:

Setting	Windows Version	Default Value (Decimal)	Recommended Value for Large Tokens (Decimal)
MaxTokenSize	Windows 2000 (Original Release)	8,000	65,535
MaxTokenSize	Windows 2000 SP2 and later (including XP, Server 2003, etc.)	12,000	65,535

This issue highlights the importance of careful group management practices in Active Directory. While increasing MaxTokenSize addresses the technical limitation in the authentication protocol handler, excessive group nesting or memberships can indicate potential administrative complexity or performance bottlenecks elsewhere. Administrators should periodically review their Active Directory group structure to ensure efficiency and manageability.

If you’ve encountered this error or have experience troubleshooting Kerberos token size issues, feel free to share your insights or ask questions below. Your experiences can help others facing similar challenges.