While getting disk size from a remote computer would seem basic easy thing, I am trying to walk you about the limitation of doing this the old way. Get disk size the smart way using PowerShell is a modern firewall friendly way to bring you disk information, like disk size. In case of an error, you will get a pretty good error handling information to consume and act upon.
Get disk size the old way
You can find many scripts out there to help you get WMI data, especially disk space stuff. I was searching online for a PowerShell function to get disk space information, and there are two interesting things (not problems for sure), but things that I didn’t like, and I will share with you what I think.
First, most scripts out there, will deal with errors and timeouts in different ways. Most of the time, they will either throw exception, write something in the screen or in a verbose stream, or in best case scenarios, they will write the name of that computer in an error log file.
The second interesting thing is that most of those scripts online will throw disk info objects on the pipeline, with a computername property for you to distinguish. So you will receive an object for each disk (not computer). Something like the below figure.
Get disk size the smart way using PowerShell
The below figure shows my own point of view of how I think the first point should be handled. If I requested WMI Disk information about a computer, I expect an object back representing information about this computer.
- I do not care if the computer is reachable or if there is problem querying wmi data.
- I do not want to see or handle exceptions.
- I do not want to look at log files.
- JUST GIVE ME AN OBJECT BACK.
So suppose you want to connect to 12 computers, and get disk information. You would usually loop through each computer, and try to get wmi data, and handle exceptions with some logic.
What would be better, is that you throw a wrapper function, that will go and hit those 12 computers, and will return you 12 objects in return. Inside each object, there is a property that you can check, and it will tell you if there was an error getting data. So, an object should be returned silently. If the remote computer is not reachable, then I will still get an object with “n/a” for the disk information property.
It is the calling function job then to receive that object and investigate the fields. This level of abstraction allows the calling function to deal with all results coming back from the WMI function in the same way. The calling function should always receive an object silently.
Now, back to the second point. We have 12 computers, we want to receive 12 objects in return. I do not want object per disk. So, the wrapper function should return for me an object per computer that contains the following information:
- ComputerName
- Child Object : containing disk information
Script breakdown
Taking into consideration the above points, the script will return an object per computer. The object fields are:
- ComputerName
- Child object called (Disks) with the following properties:
- Drive
- VolumeName
- Size in GB
- Free space in GB
- Free space percentage
As you can see from the below figure, we will get one object back, containing child object for the disks.
Same thing when we query two computers, we will get two object back .In case of error when doing the WMI query, the child object called (disks) will be replaced by the string “n/a”
Extend the script
You can download this wrapper function from TechNet Gallery.
The script is using (Get-WmiObject) to get disk info. You can look at a more modern and firewall friendly way to get WMI data, by using PowerShell CIM.
