A recent comment to one of my posts was also a question. Interestingly I had a colleague at work ask me almost the same question the other day. Clearly there’s a gap in the market, ripe for a blog post 🙂 .
This is something you will kick you self about because it’s obvious really once you know how.
How can I enumerate all the objects in a container?
The question was how can I enumerate all the objects in a container. The answer is don’t tell the commandlet what you are looking for. OK that’s obvious isn’t it? Well it is, if you step back and look at why you’re not getting the child objects returned.
If I use Get-QADObject <DN of an OU or Container> then I’m going to get just that OU or container object returned. The object will have a property ParentContainer and another ParentContainerDN but you won’t find any property or method that will list the child objects, if any exist.
So how do I list all the child objects? Use the searchRoot switch.
Don’t give the commandlet an absolute object reference use the searchRoot switch instead and specify the top level container.
Remember your interviewing skills…. don’t ask closed questions or you’ll get yes or no back as an answer which won’t always be useful.
use the command line switches to filter the result set
-type to filter the types of object returned
-searchScope to list oneLevel ( just objects in the immediate container) or subTree ( all child objects – this is the same as Dir /s )
In the case of an ARS scheduled task it looks like the scheduledTask and scheduledTasksContainer are both the same object type, thanks Dell.
Use Get-Member to list properties of the returned objects.
If you come across this then use Get-Member to see if there are other properties that might help to filter the results. The classname and a WHERE clause will solve that for ARS scheduled tasks and containers.
Actually I take back that last comment about the task and the container being the same type. I used .getType() and this returned what looked like the same object type, and ARSDirectoryObject but actually when I used Get-Member I could see the type was listed as edsScheduledTasksContainer and edsScheduledTask and I checked, you can use these as a values for the type switch and it works fine.
I said it was obvious didn’t I?