none
Intermittent not enough space errors when doing LDAP queries against 2019 domain controller

    Question

  • Hi All,

    We have deployed some new 2019 domain controllers are are having issues where LDAP queries are coming back with:

    00000008: SysErr: DSID-0205199E, problem 12 (Not enough space), data 0

    Turning on diagnostic NTDS logging the domain controller logs (Event ID: 1535):

    Internal event: Active Directory Domain Services has encountered the following exception and associated parameters. 

    Exception:
    e0010003 
    Parameter:


    Additional Data 
    Error value:

    Internal ID:
    205199e

    Internal event: The LDAP server returned an error. 
     
    Additional Data 
    Error value:
    00000008: SysErr: DSID-0205199E, problem 12 (Not enough space), data 0

    The domain controller has plenty of space 80Gb. The issue seems to occur when LDAP clients use the filter syntax: memberOf:1.2.840.113556.1.4.1941:

    Has anyone seen this error before?.  Dcdiag and repladmin are clean.

    Friday, December 14, 2018 3:53 AM

All replies

  • It occurs both on Full GUI and server core.
    Friday, December 14, 2018 4:49 AM
  • We are having the similar issues when firing 'memberOf:1.2.840.113556.1.4.1941:' though the error does not seem to occur when the resulting search >~1000 or so. 

    As you we have recently deployed new 2019 domain controllers.


    Wednesday, December 19, 2018 8:21 AM
  • We are having exactly the same issue (with jenkins for example (sometimes the login works, sometimes it does not)).

    We also deployed Windows Server 2019 domain controllers recently.

    Have you found a solution/workaround?

    Thursday, January 3, 2019 7:59 AM
  • We rolled back to 2016 domain controllers. Clearly some bugs have appeared due to the memory changes they made in 2019 for Active Directory.
    Monday, January 7, 2019 6:30 AM
  • We have the same descriptive behavior in our environment.

    At any time the LDAP login fails, I can found a "not enough space" message at the same time in the directory log... :\

    I've created a MS Support case...

    Tuesday, January 8, 2019 10:02 AM
  • Please let others also know on what conclusion you became with the support.
    Tuesday, January 15, 2019 1:59 PM
  • Bad news...

    MS has closed the ticket as "won't fix" because I can't deliver a proper repro as case target.

    So: we rolled back to 2016 domain controllers too.

    Hopefully more users will report this behavior in future.

    Wednesday, January 16, 2019 3:36 PM
  • I just installed the new Jan update: https://support.microsoft.com/en-us/help/4476976/windows-10-update-kb4476976 and I can no longer reproduce this problem. 

    Are others able to confirm after installing this update.

    Thursday, January 24, 2019 10:14 PM
  • kb4476976 Didn't solve the problems for us unfortunately.
    Thursday, January 31, 2019 9:08 AM
  • still the same. Windows 2019 Server AD is unusable for us
    Friday, February 1, 2019 9:24 AM
  • This blog post describes the only known change in how AD handles memory, and seems relevant for this issue:

    https://blogs.technet.microsoft.com/askds/2018/10/02/deep-dive-active-directory-ese-version-store-changes-in-server-2019/

    In the comments, Daniel Appleby asked if this updated algorithm for the ESE version store caused the LDAP out of space problem. The blog author replied that he believes it does not. Still, to me this sounds like the cause, although admittedly after only a quick glance at the post.

    I would suggest anyone with Windows Server 2019 work through the troubleshooting section of the blog post, and perhaps make the registry changes mentioned, to see if it helps.


    Richard Mueller - MVP Enterprise Mobility (Identity and Access)

    Friday, February 1, 2019 2:58 PM
  • In an environment of a customer we can reproduce the issue with the following PowerShell commando:

    Get-ADUSer -Server W2019DC -LDAPFilter "(&(objectClass=user)(objectCategory=person)(sAMAccountName=user)(!(userAccountControl:1.2.840.113556.1.4.803:=2))(memberof:1.2.840.113556.1.4.1941:=CN=group name,OU=Groups,DC=company,DC=domain))"

    Result:
    Get-ADUSer : Server returned out of memory error

    When using OID: 1.2.840.113556.1.4.1941 for nested group extraction by AD the error occurs, without it doesn't. The eventviewer reports: SysErr: DSID-0205199E, problem 12 (Not enough space), data 0

    The error occurs most of the time, but once in a while it works. On Windows 2019 servers with more memory the command is working without problems more often than on servers with a lower amount of memory. The command process without problems on older OS versions.

    • Edited by Roy- Monday, February 4, 2019 12:04 PM
    Monday, February 4, 2019 12:03 PM
  • We are on KB4487044 it is still the same.
    Thursday, February 14, 2019 11:44 AM
  • I have been monitoring our bucket use with the perfmonitor and had a look at the event log, all seems clean.
    Thursday, February 14, 2019 12:33 PM
  • This is still occurring for us. Even after installing the update. My test had an  (&(cn=username)(memberOf:1.2.840.113556.1.4.1941=DN)) but just doing (memberOf:1.2.840.113556.1.4.1941=DN) returns the same error.
    Thursday, March 21, 2019 3:19 AM
  • Microsoft told me the root cause for this issue is found. A private hotfix will become available in 2/3 weeks.

    Tuesday, April 2, 2019 5:42 PM
  • Hi Roy, Could I ask you to notify, when you got a fix?
    Thursday, April 18, 2019 7:34 AM
  • Roy, 

    We are having similar issues using the memberOf:1.2.840.113556.1.4.1941  filter . 

    Would you be able to post here once you receive the hotfix and get it running? 

    Thanks... 

    Wednesday, April 24, 2019 2:03 AM
  • We have the same problem.
    Wednesday, April 24, 2019 1:21 PM
  • KB4495667 may have fixed this. Still testing - but looks promising so far.
    Monday, May 6, 2019 8:43 AM
  • No, worked only a few minutes after the reboot of the DCs.
    Monday, May 6, 2019 3:26 PM
  • Same issue on this end, reproducible in PowerShell.  I'm not seeing any events in the Directory Services log.

    EDIT: Also, the server itself has plenty of memory, and for the "version buckets allocated" limit (detailed in the Deep Dive article previously linked in this thread out of the 12,000 limit we have ... 2.

    • Edited by TMitera Thursday, May 9, 2019 6:15 PM
    Thursday, May 9, 2019 6:03 PM
  • For the purposes of anyone else either lurking on this thread currently, or for future posterity, I am working with Microsoft support on a support request of my own.  Current information is that the support rep believes that "[the issue] might be a known issue [and] will confirm it with [their] Product Team."  As I continue to get updated information I will similarly update this thread.
    Wednesday, May 15, 2019 5:56 PM