Sep 7, 2009 at 8:19 PM

Regarding the choice of returning a single object or all of the objects of that type I can see scenarios when I would want both options.

My preference is for the default behaviour to return all. This is the default behaviour on the core PowerShell cmdlets and for a number of other implementations. For the times I want a single object I can identify that object explicitly. I know the AD, and IIS as well I think, PowerShell implementations return single objects.  I find this awkward as it seems contrary to the base PowerShell. I wonder if the AD team took the decision to return a single object because of the potentail number of objects that could be returned?

There are cmdlets that return a single object eg the SDM group policy cmdlets that take * as a parameter to return all objects.  This is a bit clunky to my mind but is workable.

Another option would be to make the default setable through a global parameter.  Doable but messier.

Sep 8, 2009 at 12:16 PM

For the sake of consistency I am willing to give in on the return values but I would like to you to honestly think about what is actually more intuitive (setting aside your current knowlege.)

I think this current process of returning all was a mistake on the Powershell PG (although I know why) side and even more so on Quest. If you think about it.... when would you ever want to return 1000 random objects? It would make more sense for it to either prompt for more info or just return a single object (to view what the object may look like.)

I will say that if we decide to stick with the return all mindset we will need to have format files.

Sep 8, 2009 at 4:42 PM

My novice experience leads me to the single object return as my preference.

Sep 8, 2009 at 10:02 PM

I had an experience recently where I was mixing Quest and Exchange cmdlets.  I was expressing all my OUs in the form "network.local/production/users" which Quest supports.  The Exchange cmdlets however want the DN of the OU.  Rather than stopping when it hit the OU in a form it didn't understand, the Exchange cmdlet went and hid all mailboxes from the GAL.  BAD!

So my first desire is that we don't return or do anything if we could be doing harm.

Now about the behaviour of the Quest cmdlets.  I like it.  For the simple reason it is more intuitive to tune down a query than tune it up.  If you know the total size of the set, then it's easier to work with subsets.


Sep 8, 2009 at 10:10 PM

Any of our set/new cmdlets will support -whatif and -confirm