Accepted Solutions
ok, I found that already - but how do I know that it is "config.tools.toolsVersion"?
sorry for my awkwardness
Well, let's say that it sort of an... adventure.
Let's start from the VirtualMachine. We know that the tools version must be hiding in here somewhere, so we scroll down to the properties list. The second property, config, looks fairly promising, so we click on its data type, which happens to be VirtualMachineConfigInfo. If we look at its property list, toward the bottom, we see a property called tools, which is of type ToolsConfigInfo. Examining this object we finally find what we're looking for, the toolsVersion integer within the ToolsConfigInfo object.
This is how I determined the right thing to use was config.tools.toolsVersion, the name of the property I wanted in VirtualMachine was config, the name of the property in VirtualMachineConfigInfo was tools and the property I wanted was toolsVersion. Joining the names together with ., as I would if I were accessing a nested object in Java/C# or other languages causes the data I want to be returned. When I do this I arrive at the string config.tools.toolsVersion. You could think of this as a top-down approach to finding where the data you want lives in the API.
Often you don't know exactly where to look for the information you want. In this case we can adopt a bottom-up approach. What you can do in this case is use the search interface of the top-level API document. If you click on "All Types" there and type in "tools", you'll find the ToolsConfigInfo data object. Since ToolsConfigInfo is a data object, rather than a managed object, you won't be able to query for it directly. Instead you have to look for a managed object that contains this data object. At the top of a data object's API page there is a section called "Property Of", which lists the objects that contain this information. In the case of ToolsConfigInfo this is VirtualMachineConfigInfo and VirtualMachineConfigSpec. One tip to keep in mind when doing this, Info objects contain persistent information about objects whereas Spec objects are used to change the configuration of objects. In other words, we don't have to bother looking at the VirtualMachineConfigSpec object when we're trying the path to use to query the data we want. When we look at the VirtualMachineConfigInfo object we see that it, in turn, is a property of a VirtualMachine object, which is the kind of object we get back from get-vm. We still have to refer to the properties list to determine what the objects are called, but the end result is the same, config.tools.toolsVersion.
I hope that helps. We realize this is pretty tricky, which is one of the reason we're developing the PowerShell toolkit in the first place. In total a VM has over 1000 properties and finding the one you want can be a challenge, which is why we're trying to put the most valuable stuff in the objects you get back from cmdlets like get-vm.
ok, I found that already - but how do I know that it is "config.tools.toolsVersion"?
sorry for my awkwardness 
ok, I found that already - but how do I know that it is "config.tools.toolsVersion"?
sorry for my awkwardness
Well, let's say that it sort of an... adventure.
Let's start from the VirtualMachine. We know that the tools version must be hiding in here somewhere, so we scroll down to the properties list. The second property, config, looks fairly promising, so we click on its data type, which happens to be VirtualMachineConfigInfo. If we look at its property list, toward the bottom, we see a property called tools, which is of type ToolsConfigInfo. Examining this object we finally find what we're looking for, the toolsVersion integer within the ToolsConfigInfo object.
This is how I determined the right thing to use was config.tools.toolsVersion, the name of the property I wanted in VirtualMachine was config, the name of the property in VirtualMachineConfigInfo was tools and the property I wanted was toolsVersion. Joining the names together with ., as I would if I were accessing a nested object in Java/C# or other languages causes the data I want to be returned. When I do this I arrive at the string config.tools.toolsVersion. You could think of this as a top-down approach to finding where the data you want lives in the API.
Often you don't know exactly where to look for the information you want. In this case we can adopt a bottom-up approach. What you can do in this case is use the search interface of the top-level API document. If you click on "All Types" there and type in "tools", you'll find the ToolsConfigInfo data object. Since ToolsConfigInfo is a data object, rather than a managed object, you won't be able to query for it directly. Instead you have to look for a managed object that contains this data object. At the top of a data object's API page there is a section called "Property Of", which lists the objects that contain this information. In the case of ToolsConfigInfo this is VirtualMachineConfigInfo and VirtualMachineConfigSpec. One tip to keep in mind when doing this, Info objects contain persistent information about objects whereas Spec objects are used to change the configuration of objects. In other words, we don't have to bother looking at the VirtualMachineConfigSpec object when we're trying the path to use to query the data we want. When we look at the VirtualMachineConfigInfo object we see that it, in turn, is a property of a VirtualMachine object, which is the kind of object we get back from get-vm. We still have to refer to the properties list to determine what the objects are called, but the end result is the same, config.tools.toolsVersion.
I hope that helps. We realize this is pretty tricky, which is one of the reason we're developing the PowerShell toolkit in the first place. In total a VM has over 1000 properties and finding the one you want can be a challenge, which is why we're trying to put the most valuable stuff in the objects you get back from cmdlets like get-vm.
Dear Carter,
that's a pretty good explanation - I think I got it now 
Thanks for being so patient!
daniel
