Using the DisplayVersion property instead of just Version did the trick :) From: Aaron Jensen [mailto:aaron@xxxxxxxxxxxxxxxxxx] Sent: Wednesday, November 05, 2014 8:02 AM To: Bill Johnston Cc: carbon@xxxxxxxxxxxxx Subject: Re: carbon info Aaron works great so far. I have a working module to simply sys admin tasks for my team. All of my functions can remotely dig up information on servers. Do you generally just use invoke-command with these cmdlets to get info on remote servers? Generally I use Invoke-Command to run Carbon on the remote server. We keep our automation platform checked into Mercurial repositories (which includes Carbon). The platform gets packaged and deployed to each server that needs it. Then we use Invoke-Command to execute server-specific setup scripts. But all the scripts we need are already on the server. We’re slowly starting to adopt DSC, which pretty much requires your stuff to already be on the server. Generally, Carbon doesn’t have many (any?) functions that support running against a remote computer because it is focused on configuring applications running on those servers, not on managing the servers. It is a subtle difference, but you’ve run into one aspect of this: running a specific Carbon function against a X different computers. I noticed the get-programinstallinfo cmdlet doesn’t have a –computername option. Also, is the version property doesn’t appear to be correct unless this is the correct version. :) Version is a DWORD (32-bit integer) stored in the registry. After some research, it looks like the first 8 bits of that number are the major version number, the next 8 bits are the minor version, and the last 16 bits are the build number. I’ve created issue Update Get-ProgramInstallInfo to convert Version integer to a Version object <https://bitbucket.org/splatteredbits/carbon/issue/145/update-get-programinstallinfo-to-convert> to get this fixed. Until then, I would use the DisplayVersion property, since I’m pretty sure that is what the Programs and Features control panel shows.