The server has returned the following error invalid enumeration context

I ran into a situation similar to the scenario below; although, I caught the problem during testing and not the production implementation. I was faced with a decision to rework my code, or understand the error so I could address it effectively. In this article
I will elaborate on what I found to be the cause of this error, and what situation brings it about. I will then show you what to do about it without having to revert to older methodologies to handle your task.

Scenario

If you have been working in an Active Directory environment for any length of time, there is a good possibility that you have run into a situation where you needed to run some process against all, or at least a large portion, of your Users or Computers.
Managing each account individually is very time consuming and inefficient, so you turn to the almighty PowerShell to automate this process. You start by using Get-ADUser or Get-ADComputer to retrieve the Objects you want from AD, then you use the powerful
Pipeline of PowerShell to send those AD Objects to another cmdlet to do the additional work you need. You may even take the results of the secondary cmdlet and use the pipeline to send them to tertiary, and quaternary cmdlets. The pipeline makes this all very
easy. You’ve tested your process on a few objects and are ready to process against your entire domain. Your change control is approved, you are in the driver’s seat, and you hit the enter button. This wonderful process takes off; it’s pure magic. Flying along,
PowerShell is processing each object and doing exactly what it was designed to do, but you have thousands of objects so this is going to take a while. Your part has been done, you created the process and kicked it off. PowerShell is doing its part, running
your creation. Might as well go to the kitchen and warm up some leftover pizza and grab a nice cold Dr Pepper. You glance over at your laptop on your way to the La-Z-Boy and see that everything is running smoothly, so you flip on an old rerun of Gilligan’s
Island. You watch as they put together some crazy contraption, which in the end utterly fails. If only they had you and PowerShell, they would be home sipping their own Dr Peppers by the end of the show. You glance back over at your laptop and the unthinkable
has occurred. In your PowerShell console where your process should be running, you see this:

get-aduser : The server has returned the following error: invalid enumeration context.

At line:1 char:1

+ get-aduser -Filter {msExchRecipientTypeDetails -eq «2147483648» -AND -NOT(UserAc .

+ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

+ CategoryInfo : NotSpecified: (:) [Get-ADUser], ADException

+ FullyQualifiedErrorId : The server has returned the following error: invalid enumeration context.,Microsoft.ActiveDirectory.Management.Commands.GetADUser

What happened? A quick web search of «The server has returned the following error: invalid enumeration context.» returns lots of content on the topic with two prevailing recommendations.

1. One of the attributes being queried is not indexed in AD. You can resolve this by modifying the Attribute in the AD Schema enabling the index flag.
2. Ditch get-aduser and get-adcomputer and use ADSI DirectorySearcher instead.

IE:

https://social.technet.microsoft.com/Forums/scriptcenter/en-US/e3ae9c0d-4eed-4703-b120-14727e797df9/invalid-enumeration-context-using-powershell-script-to-check-computer-accounts?forum=ITCG

You don’t really want to manually modify your Active Directory schema, but this process is important so you give it a shot. Looking at all of the attributes you are pulling you notice that they are all already indexed, or you enable indexing but the problem
persists. You really like using native PowerShell functionality and you don’t really want to rework your code to use ADSI DirectorySearcher, but you really have no other options right? Wrong!

Digging for the Roots

The error message gives clear indication that the cmdlet which threw the error was Get-ADUser. Since our process is using Get-ADUser to send objects down the pipeline to other cmdlets, we run the Get-ADUser cmdlet by itself to see if we can get any new info.
Surprisingly the Get-ADUser command completes with no errors, and fairly quickly; however, every time we run the cmdlet and pass objects to other cmdlets through the pipeline, we generate the error. That is interesting because Get-ADUser is supposed to just
get the full results and hand them down the pipeline as soon as they come in right? Well, let’s see.

What can we find out about how Get-ADUser works? If we look at the help of Get-ADUser, we see two parameters that are of interest.

So based on these parameters, we know that by default, Get-ADUser will return all matched objects from Active Directory, but it will do it in pages consisting of 256 objects per page.

Side Note: What exactly is paging? Simply put, it’s breaking a large query result down into smaller more manageable pieces. By default, if a Query results in 1000 objects, rather than sending all 1000 object back to the client, the server will send 256
object at a time (in separate pages) until all objects are sent. 1000 objects would result in 4 pages. It is up to the client to tell the server when it is ready for the next page of results.

(Paging Search Results: https://msdn.microsoft.com/en-us/library/aa367011(v=vs.85).aspx)

Now let’s look at Get-ADUser in action.

Using the sysinternals tool, TCPView.exe, we monitor the TCP communication of our Get-ADUser cmdlet while using Measure-Command to capture our runtime.

From the results we see that it took us 28.9 seconds to get 14.79 MBytes (15,504,491 Rcvd Bytes) of returned data from our query. We also see that we are connecting to TCP port 9389 on our domain controller. A quick web search on this TCP port reveals that
this is the port used by Active Directory Web Services (http://www.t1shopper.com/tools/port-number/9389/).

In order to see how many return objects we are dealing with, we run the command again, piping the results into Measure-Object

The first thing we notice is that our process does not error out this time, even though we are using the pipeline. So maybe the problem relates to how long it takes to process our other pipeline commands. Since Measure-Object takes very little time to process,
it does not result in the error being generated. In order to test this theory we will use start-sleep to inject some processing time down the pipeline.

After a while of running, we once again get our «The server has returned the following error: invalid enumeration context.» error, but why? The code runs fine without the pipeline, and it runs fine with the pipeline as long as the subsequent cmdlets complete
quickly. We know that the Get-ADUser cmdlet completes in about 30 seconds without the pipeline. Is it the same when we have slower processing further down the pipe?

Let’s do two things to see what is going on. We will use TCPView and Measure-Command, as we did before, to see what is going on from a network perspective and how long our code is running before generating the error.

After 5 minutes of running, we see that we have only received 2.15 Mbytes of data.

After 10 minutes of running, we are only sitting at 4.09 Mbytes of data.

Our slow data rate return continues until we finally error out after 30 minutes, and we also see that we did not receive our expected full data size of around 14.79 Mbytes.

So our data is returning a lot slower, and we are erring out before receiving our full dataset. This is indicative of a timeout. Since we know that we are connecting to Active Directory Web Services, a quick web search for «Active Directory Web Services
Timeout 30 minutes» gets us here: https://technet.microsoft.com/en-us/library/dd391908(v=ws.10).aspx

Excerpt from above site:

Ok, lets put together what we’ve learned.

1. Get-ADUser uses paging (256 object per page by default)
2. It is up to the client to request new Pages
3. When piping out AD Objects, the longer the code down the pipeline takes to process, the slower we retrieve data from Active Directory Web Services
4. If that slower processing causes the retrieval time to run over 30 minutes, then the Enumeration Context Expires

Now lets fill in the blanks for the full, end to end process.

1. Get-ADUser executes sending the query to Active Directory Web Services
2. Active Directory Web Service receives the query, creates an enumeration context for the results, and returns the first page of results containing 256 objects
3. Get-ADUser receives those results and sends them down the pipeline, but does not query Active Directory Web Services for the next page until the pipeline has finished processing all 256 objects already received.
4. The pipeline processes each object placed in it one at a time down the entire pipeline. So all pipeline processes are completed on the first object before the second object begins it journey down the pipeline. (For 256 objects with 200 millisecond pipeline
   processing per item, that’s 51.2 seconds per page. With 14163 object, we are looking at 55.32 pages and 47.21 minutes.)
5. Once all 256 objects have been processed for the current page, Get-ADUser requests the next page of results from Active Directory Web Services.
6. Active Directory Web Services returns the next 256 objects.
7. Steps 3 — 6 repeat until all objects are retrieve or the processing time goes longer than 30 minutes. After 30 minutes, Active Directory Web Services expires the enumeration context it created in step 2. Once expired, Active Directory Web Services returns
   the error, «invalid enumeration context», when Get-ADUser request the next page because the enumeration context has expired and is no longer valid.

So mystery solved.

Solutions

There are two possible solutions to this issue, the first of which I would not recommend.

1. Increase the «MaxEnumContextExpiration» value for Active Directory Web Service. There are many reasons not to take this approach.
   1. First and foremost, Microsoft recommends again this. «Changing the default value of this parameter is strongly discouraged. Most of the search results are returned within 30 minutes.»
   2. This change would have to be made on all Domain Controllers that the script would possibly hit.
   3. The target value to increase to would be a moving target depending on number of objects returned and length of time required to process all pipeline code.
   4. Increasing this value increases the potential impact of long running processes on your Domain Controllers.
   5. If you choose this method, it can be done by modifying the «Microsoft.ActiveDirectory.WebServices.exe.config» file in the ADWS directory. By default: «C:WindowsADWS».
2. Retrieve your Active Directory objects to a variable first, then send it down the pipeline using the variable. This method is easy to implement in your code without lots of configuration changes in your Active Directory environment. It works because writing
   the objects to a variable is very fast so your Get-ADUser and Get-ADComputer cmdlets can quickly write all object to the variable and request the next page until all object are received.

It’s this simple:

Instead of doing this:

Do this:

Or if you wanna keep it on a single commandline for the PowerShell console, just separate it with a semicolon:

My hope is that you will find this useful. Please feel free to leave a comment and let me know how it has helped. Thanks for reading!

The server has returned the following error invalid enumeration context

This forum is closed. Thank you for your contributions.

Answered by:

Question

I’m running a powershell command to add the email (AD mail) attribute to users in a specific OU. It seems to work then will bomb out with the error in the title.

I’m using a «scripting guy» command that I’ve altered with my specfic OU/domain information however, I’m pasting in the more «generic» version :: Get-ADUser -LDAPFilter «(!(mail=.name*))» -resultSetSize $null -searchbase «ou=test,dc=nwtraders,dc=com»| %

I work for a school district and this command is being used to add the mail attribute to the student’s accounts. I think about 2/3 of the students are completed but the script/command bombs and I’m not sure where or why. I’ve resubmitted the command several times but I’m not sure whether it’s starting from where it bombed or if it’s starting again at the beginning and essentially re-doing the ones already completed.

Can someone point me in the direction of a work around or a resolution to the Get-ADUser error?

Источник

Get-ADUser: The server has returned the following error: invalid enumeration context

I am trying to get all of the contractors and employee from our AD with enabled true for filter. AD itself is very huge and lots of data that may cause timeout limits when running powershell script. I am getting this error when I put it into variable and if I do a straight export, I am getting timeout limit.

Is there any way to gather all of the contractor and employee data with enabled employees with big AD without having this issue? I am getting a output but not sure if the output is realiable since I am getting error.

2 Answers 2

This TechNet article gives us a hint on why does this error can occur, basically:

1. Get-ADUser uses paging (256 object per page by default)
2. It is up to the client to request new Pages
3. When piping out AD Objects, the longer the code down the pipeline takes to process, the slower we retrieve data from Active Directory Web Services
4. If that slower processing causes the retrieval time to run over 30 minutes, then the Enumeration Context Expires

Most likely, your query has been running for 30 minutes which lead to this exception. Solution to this is to make a more efficient query so it completes before this time or, not recommended by MS:

Increase the «MaxEnumContextExpiration» value for Active Directory Web Service. There are many reasons not to take this approach.

You can leverage LDAPFilter to increase the performance of your query, using Where-Object is not needed in this case:

To translate the LDAP Filter into something readable:

• & — Logical AND Operator
• | — Logical OR Operator
• (!userAccountControl:1.2.840.113556.1.4.803:=2) — Enabled User Object
• (|(employeeType=CONTRACTOR)(employeeType=EMPLOYEE)) — employeeType is «Contractor» OR «Employee»
• (&(. )(|(. )(. ))) — All clauses must be met. We can read it as:
  ( User is Enabled )AND( User’s employeeType is «Contractor» OR «Employee» )

Источник

Error with Get-ADUser: Invalid enumeration context

I posted this question the other day Extract e-mail from grouped objects

The code works on one domain it works fine, testing it against a small set of users in a OU.

When testing on the domain I want to test against, which has a lot of users in it this code fails. The OU has email address in it which are not of an e-mail format. It points towards Get-ADUser for the error.

I am lost to why I am getting this error on one domain but not another.

2 Answers 2

The biggest issue you have here is you are asking a lot from Get-ADUser . Based on your comment you are pulling in over 900,000 accounts. On top of that you are pulling all properties of those users. There is a touch of insanity there.

While I am not perfectly clear what your error means I do know that everyone that gets it is returning a lot of users which you clearly are. The first step to mitigate this is to use -ResultPageSize of Get-ADUser . Your mileage may vary but you need to experiment with number of records to return. 500-1000 is usually a good start.

I would never use -Properties * unless I was pulling for one user and wanted to see everything. I strongly doubt you are using all those properties in your function. Limit yourself to what you need for efficiency’s sake. You would obviously need to specify Mail .

Since you are processing based on the mail property another thing would be to limit your results to those which only have a populated mail property. Couple of things you could do filters e.g ««, «. «(from comments by Vesper) or «@» based on your comment of

There are some email field with 123 and . in them, so I will have to use length -gt 3 or something to skip them.

Not sure about this and I don’t have the sample data to test the theory but using the pipeline should also help things along instead of saving the results just to use them in the pipe anyway.

Источник

get-adcomputer error: «Invalid Enumeration Context» when running powershell script

We’re switching to WDS for deployment, so I’m writing a powershell script that will ping a computer and if it responds, get its MAC address and set the netbootGUID field in Active directory. It runs and works. for a while and then returns:

Get-ADComputer : The server has returned the following error: invalid enumeration context. At PathToScriptssetNetbootGUIDremoteComputers.ps1:3 char:15

4 Answers 4

NB: I’m not a PS guru

My google fu turned up the following link.

In short, I think it has something to do with your -ResultSetSize $null portion of the script. In the link, the OP used -notlike «*» instead of the -eq «$Null»

Maybe play with that portion of the script and see what happens.

I like the get-adcomputer and quest-active directory commands for cases where i need a lot of information on a server, but otherwise stick with the active-directory commands dsquery and dsget , because I find the get-adcomputer and especially the quest commands unnecessarily slow, though something may be requiring you not to use these ds commands. If you do have access to these commands, this might be worth a shot, even if it just gives you a different error message, as it by-passes the use of get-adcomputer and existing method of determining ping-ability ( kind of Mickey-Mouse, but sometimes this way provides additional information ) —

Been out of work for past couple months, and have no access to a Windows machine, so the code is off the top of my head, but I hope it works for you. Seems right.

I hope you solved the problem, but if not, I hope this can help in some way.

Источник

The server has returned the following error invalid enumeration context

This forum is closed. Thank you for your contributions.

Answered by:

Question

I am using a powershell script downloaded from technet gallery (http://gallery.technet.microsoft.com/PowerShell-Organize-d37c2a29#content) to automatically move the computers to OUs based on IP subnets in active directory. But after a while the script is failing with an error ‘Invalid Enumeration Context’ on the line

I tried to fix the error by including diffrent Page Size values 10, 1 and 0 as shown below but thats only helped to run the script a little longer before failing with the same error. I also incrased the MaxPageSize value to 10000 in ladp policies using ntdsutil in active directory but had no effect.

Get — ADComputer — Filter < OperatingSystem — like «Windows 7*» -or OperatingSystem -like «Windows XP*» >— Properties PasswordLastSet -ResultPageSize 1 | ForEach — Object <

Can you please help me with this issue?

Thanks veru much in advance!

Answers

The blog post Bill linked suggests the problem is worsened if you query based on an attribute that is not indexed. The operatingSystem (and also the operatingSystemVersion) attribute is not indexed. Assuming you have a large number of computer objects in your domain, and you frequently query based on OS, it perhaps makes sense to make operatingSystem indexed. This is controlled by the searchFlags attribute of the attribute (of the attribute object in the cn=Schema container). This is a flag attribute, similar to userAccountControl, where each bit of the integer corresponds to a different setting. In this case, the bit mask for IS_INDEXED is 1. In my domain, the searchFlags attribute of the operatingSystem attribute has no value. If this is also true in your domain, you could simply assign the value 1 to make operatingSystem indexed.

In ADSI Edit, navigate to the container cn=Schema,cn=Configuration,dc=MyDomain,dc=com, find the attribute with name «Operating-System» (the Common Name is «Operating-System», but the LDAPDisplayName is «operatingSystem»), right click and select «Properties», find the searchFlags attribute, click «Edit» and enter the value 1. Then save. I assume it takes awhile for the attribute to be indexed.

My guess is that the Get-ADComputer cmdlet is prone to this problem because it retrieves a default set of properties, whether you need them or not. Some of these properties require code to convert into friendly formats, like objectGUID and SID. You only add one additional property, but it also requires code to convert into a friendly format. This makes the recordset larger than necessary, and requires more work on the DC. So, another workaround might be to use DirectorySearcher instead of Get-ADComputer. If this approach is of interest, I have a PowerShell V1 script linked on this page:

which documents the datetime the password was last changed for all users in the domain. This could be modified for all computers with the specified OS’s by replacing the LDAP syntax filter with this:

$Searcher .Filter = «(&(objectcategory=computer)(|(operatingSystem=Windows 7*)(operatingSystem=Windows XP*)))»

You would add your code to compare pwdLastSet to your critical values and move the appropriate objects. Come to think of it, I also have a PowerShell V1 script that moves old computers (based on pwdLastSet) linked on this page:

In this case the filter includes a clause to only consider enabled computer accounts (testing the flag attribute userAccountControl). You can add the clauses for operatingSystem (use the OR operator «|» to filter on either W7 orXP), and you can remove the clause with userAccountControl if you also want to consider disabled accounts.

In my experience, these PowerShell V1 scripts are faster than ones using Get-ADComputer in PowerShell V2. This may not be true in PowerShell V3, which supposedly has greatly improved the efficiency of the AD cmdlets. In fact, another workaround for you might be PowerShell V3.

Источник

Troubleshooting AD Powershell queries: server has returned the following error – invalid enumeration context

By Andrei Ungureanu — Last updated: Saturday, October 22, 2016 — Save & Share — Leave a Comment

I’ve seen a lot on the web about the error in the title (server has returned the following error – invalid enumeration context) and the reason I am writing about this is because there is a lot of confusion about this.

You might see this error when you try to query AD from powershell (get-aduser, get-adcomputer, etc) and the query is taking a long time to finish.

+ FullyQualifiedErrorId : The server has returned the following error: invalid enumeration context.,Microsoft.ActiveDirectory.Management.Commands.GetADUser

But if you pay attention you’ll notice the error comes up exactly after 30 minutes of script execution.

Why’s that? Simple, because somewhere there’s a timeout in Active Directory Web Services.

If you’ll go and read the documentation for AD WS you’ll notice a parameter named MaxEnumContextExpiration which is set by default to 30 minutes.

From the documentation:

In ADWS, there are a number of configuration parameters that determine how ADWS in Windows Server 2008 R2 handles the traffic that administrators generate. Administrators can manage AD DS domains, AD LDS instances, and Active Directory Database Mounting Tool instances by using applications such as the Active Directory module or Active Directory Administrative Center. These configuration parameters are stored in the Microsoft.ActiveDirectory.WebServices.exe.config file, under %WINDIR%ADWS directory.

You can adjust these configuration parameters by editing the Microsoft.ActiveDirectory.WebServices.exe.config file to accommodate traffic that is directed at the ADWS service in their Active Directory environments. Any changes that you make to the ADWS configuration parameters on a given domain controller affect only the ADWS service that is running on this particular domain controller. In other words, changes that you make to the Microsoft.ActiveDirectory.WebServices.exe.config file on a domain controller in a given domain or forest do not replicate to other domain controllers in this domain or forest.

MaxEnumContextExpiration parameter description: Specifies the maximum allowed time period during which the ADWS service processes and retrieves the results of a query request from a client computer.

I’ve seen several recommendations to change –ResultPageSize & –ResultSetSize in order to fix this error. Although by changing those might improve the performance a little bit, if the query still takes more than 30 minutes, you’ll get the same error. Those two are still important. Why? Because you’ll need to optimize your query and make it faster.

So here’s your options:

1. Try with –ResultPageSize & –ResultSetSize and see if you can make it faster.

2. Go and change Microsoft.ActiveDirectory.WebServices.exe.config and increase MaxEnumContextExpiration

3. Improve your query so it will return fewer objects so it can take less than 30 minutes. (Example: return only active objects)

4. Sometimes there’s a lot of processing time spent on the client side. Think about all the pipelines in your one liner command. Change your code to retrieve everything in a local variable in memory if possible and then query that locally.

5. Use something else than AD Powershell Cmdlets. Maybe the Quest ones or directly from .Net. And remember there’s always VBScript.