[Carbon] Re: carbon info
- From: "Bill Johnston" <bj@xxxxxxx>
- To: "'Aaron Jensen'" <aaron@xxxxxxxxxxxxxxxxxx>
- Date: Wed, 5 Nov 2014 08:14:44 -0800
Thanks Aaron. This is valuable information on the version number. I can just
grab the first 8 bits if needed or I’ll play around with your update
get-programinstallinfo. I’m trying to figure out how to get this working on
remote computers. We have over 700 servers and 50K desktops so putting the
module on all of these systems would be impossible with our current set up.
I’ll keep you informed on progress.
-Bill
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.
Other related posts:
