Get Server Up Time in a smart way (WMI)

This function will take a server name or array of server names, and return Server Up Time in form of TimeSpan data type.

Why this is different ?

What makes this script different than other scripts is two things:

– Faster : Instead of getting all WMI data from Win_OperatingSystem name space, we will only get the server up time property, so less data transfer the wire

– Returns object with two properties : ComputerName, and UpTime.

– Better error handling : Even if there is trouble getting WMI data from the remote computer, the uptime property will be replaced with “n/a” instead of throwing exception.

– Returns TimeSpan : So the UpTime property will be TimeSpan, so you can browse its properties and get uptime in days, minutes, seconds, or even more accurate information.

– Flexible Input Data: Can take input from the pipeline in form of single server or array of server names.

Download the script

You can download the script from here  Get-CorpUpTime


Get WMI data the right way – Get Disk info using WMI

You can find many scripts out there digging and getting 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 point is that 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 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 SIMPLY. Leave the technical stuff for yourself dear script and shut up.


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.

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.


Well, all what I wanted is information about two machines, so I expect two objects in return ,an object per computer, not an object per disk. Why shall I do some house cleaning on behalf of such scripts?

The answer to this issue is to return an object per computer. This object will contain two properties:

  • ComputerName
  • Child Object : containing disk information


The Script

Taking into consideration the above points, the script will get the following information:

  • 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”


Download the script

You can download the script from here : Get-CorpDisks

The script is using (Get-WmiObject) to get disk info. I recommend that you replace the Get-WmiObject  with (Get-CorpCimInfo). This way, the script will try to use Get-CimSession, then remoting then DCOM to retrieve wmi data. Have a look to my Get-CorpCimInfo script here.