Search results for 'app:weblogs' matching tags 'WMI' and 'desktop management'

Use PowerShell to Find Detailed Windows Profile Information

Anonymous — Mon, 04 Mar 2013 06:00:00 GMT

Summary: Microsoft Scripting Guy, Ed Wilson, talks about using Windows PowerShell to find detailed Windows profile information.

Hey, Scripting Guy! I am in a bind. I need to find out who is using what profile on a desktop computer. I also need to find out when the profile was last used. This is because many of the computers in our lab have rather small hard disk drives, and these drives are nearly filled up with user profiles. After I know who has been using a profile and when it was last used, I can decide if I want to remove the profile.

—KG

Hello KG,

Microsoft Scripting Guy, Ed Wilson, is here. It is a new week for the Hey, Scripting Guy! Blog. It is also a new month. This means that this Thursday, March 7, 2013 we will have our Charlotte Windows PowerShell User Group meeting at the Microsoft office. If you are in the area, check it out. You will need to register first so we know how much food to purchase. It is always a lot of fun, and we will be playing a mini Scripting Game.

KG, your request is a reasonable one. To find user profile information, I use WMI.

Finding user profile information

To find user profile information, I use the Win32_UserProfile WMI class. To query the Win32_UserProfile WMI class, I can use the Get-WmiObject cmdlet. This technique is shown here (gwmi is an alias for Get-WmiObject).

gwmi win32_userprofile

The command and its associated output are shown here.

There is a lot of information that I am not interested in examining. In fact, what I really need is LastUseTime, LocalPath, and SID. The revised query is shown here.

gwmi win32_userprofile | select lastusetime, localpath, sid

The revised command and its output are shown here.

But I need something a bit easier to read. Also, I am not interested in profiles that are not used. In Windows PowerShell 3.0, the Get-CimInstance cmdlet translates the time. This brings me a step closer to what I need. Here is the command.

get-ciminstance win32_userprofile | ? lastusetime | select lastusetime, localpath, sid

The command and its output are shown here.

Translating SID to a user

Groovy. Now I need to translate the SID to a readable user account, and I am home free. There are several ways to translate a SID to a user account. One way to do this is to use the Win32_UserAccount WMI class. It is easy to do—and hey, I am already messing around with WMI.

So how does it work? Well, the Win32_UserAccount WMI class has a SID property in addition to a Name property. But I like to use Caption because it has both the domain and the name in it. So I filter on the SID, and boom it works. Here are a couple of examples:

PS C:\> (gwmi win32_useraccount -Filter "sid = 'S-1-5-21-1457956834-3844189528-354135

0385-1613'").name

Tim O'Brian

PS C:\> (gwmi win32_useraccount -Filter "sid = 'S-1-5-21-1457956834-3844189528-354135

0385-1613'").Caption

IAMMRED\Tim O'Brian

PS C:\>

Sweet, so now all I need to do is to create a custom property on my custom object, and I am good to go.

Create custom object with required info

I need to create a custom object with the LastUseTime property, the LocalPath, and the user name. To do this, I use the Select-Object cmdlet. I choose the LastUseTime property and the LocalPath property. I then use a hash table to resolve the SID to a user account name. Here is the hash table I use:

@{LABEL='user';EXPRESSION={(gwmi win32_useraccount -filter "SID = '$($_.sid)'").caption}}

Now, what I am doing in the expression is using WMI to query the Win32_UserAccount WMI class. I specify the filter as Sid = ‘$($_.sid)’. I need the subexpression here to keep the WMI SID property from unraveling. Because the query returns a user account object, and I only want the caption, I group the expression and select only the Caption property. The entire command is shown here (it is a single line command):

get-ciminstance win32_userprofile |

? lastusetime |

select lastusetime, localpath,

@{LABEL='user';EXPRESSION={(gwmi win32_useraccount -filter "SID = '$($_.sid)'").caption}}

The complete command and the output from the command are shown in the image that follows.

KG, that is all there is to using Windows PowerShell and WMI to return user profile stuff. Join me tomorrow when I will talk about more cool Windows PowerShell stuff.

I invite you to follow me on Twitter and Facebook. If you have any questions, send email to me at scripter@microsoft.com, or post your questions on the Official Scripting Guys Forum. See you tomorrow. Until then, peace.

Ed Wilson, Microsoft Scripting Guy

Use PowerShell to Detect Power State and to Set Power Plan

Anonymous — Wed, 28 Nov 2012 06:00:00 GMT

Summary: Microsoft Scripting Guy, Ed Wilson, talks about using Windows PowerShell to detect the power state on his laptop and to set the appropriate power plan.

Microsoft Scripting Guy, Ed Wilson, is here. This evening in Oslo, Norway, the Scripting Wife and I are attending the Microsoft Technology User Group meeting. The meeting runs from 18:00 until 20:00 (CET). Interestingly enough, the lows in Oslo and in Charlotte, North Carolina, are about the same. The big difference is the 30-degree temperature between high and low in Charlotte. Oh well, and the other big difference is a bit of snow! WOO HOO!!!

Detect power state by using PowerShell

To detect whether or not my laptop is running on battery, I can query the Win32_Battery WMI class. This WMI class is in the Root\CimV2 WMI namespace and has been around since forever. There is nothing special about this class. The only thing is to ensure that my laptop actually populates information in the class—and that the information is reliable.

In the past, I have had laptops in which the Win32_Battery WMI class did not populate at all when the laptop was plugged into electricity; it only became available when the laptop ran on battery. There is another WMI class—Win32_Portablebattery. This WMI class also derives from Cim_Battery, but it provides a bit more information than Win32_Battery. On the other hand, Win32_Battery provides information about recharge status. The differences are shown here.

PS C:\> $b = Get-CimClass win32_battery

PS C:\> $p = Get-CimClass win32_portablebattery

PS C:\> Compare-Object $b.CimClassProperties.name $p.CimClassProperties.name

InputObject SideIndicator

----------- -------------

CapacityMultiplier =>

Location =>

ManufactureDate =>

Manufacturer =>

MaxBatteryError =>

BatteryRechargeTime <=

ExpectedBatteryLife <=

The battery is discharging

If the laptop runs on the battery, the BatteryStatus reports 1, which means that “The battery is discharging.” The other conditions are a bit more complicated. The following chart details the meaning of the status of the battery.

Value	Meaning
1	The battery is discharging.
2	The system has access to AC so no battery is being discharged. However, the battery is not necessarily charging.
3	Fully Charged
4	Low
5	Critical
6	Charging
7	Charging and High
8	Charging and Low
9	Charging and Critical
10	Undefined
11	Partially Charged

For my purpose, I use the value like a Boolean—1 means ”on battery,” everything else means “plugged in” (at least for my script). Here is how I obtain the battery status.

(Get-CimInstance win32_battery).batterystatus

Set the appropriate power plan

To set the power plan on my laptop, I use the Win32_PowerPlan WMI class (see yesterday’s article) and I call the Activate method. All I really need to do is to add a bit of logic, then retrieve the appropriate power plan, and activate it. I decided, right now, that I will use Power Saver if the battery is discharging (1), High Performance if the battery is fully charged (3) and Balanced, if the battery is any other status. The script is a simple If / ElseIF / Else type of construction. Here is the code.

SetPowerSaverPlan.ps1

If ((Get-CimInstance win32_battery).batterystatus -eq 1)

{

$p = Get-CimInstance -Name root\cimv2\power -Class win32_PowerPlan `

-Filter "ElementName = 'Power Saver'"

Invoke-CimMethod -InputObject $p -MethodName Activate }

Elseif ((Get-CimInstance win32_battery).batterystatus -eq 3)

{

$p = Get-CimInstance -Name root\cimv2\power -Class win32_PowerPlan `

-Filter "ElementName = 'High performance'"

Invoke-CimMethod -InputObject $p -MethodName Activate }

Else

{

$p = Get-CimInstance -Name root\cimv2\power -Class win32_PowerPlan `

-Filter "ElementName = 'Balanced'"

Invoke-CimMethod -InputObject $p -MethodName Activate }

What I do not know, yet, is how often the script will select High Performance. This is because, with the Windows Battery Conditioning technology, the battery does not always fully charge. At times, for example, on my laptop, the battery stops charging at 98 percent or so—and I do not know if THAT condition reports as fully charged (3). Therefore, after a bit of testing, I may eliminate the ElseIf condition, and do a simple If / Else and use the Else condition to set the full power plan.

If I want to check to see what power plan gets applied as a result of the above script, I can do a simple query to check for the active power plan, as shown here.

Get-CimInstance -Name root\cimv2\power -Class win32_PowerPlan -Filter "isactive = true" |

Select-Object elementname

Well, that is about it for now. We have a lot of stuff to do and to see here in Oslo before the user group meeting this evening.

Join me tomorrow when I will talk about changing the power plan on servers running Windows Server 2008 R2 and Windows Server 2012.

Ed Wilson, Microsoft Scripting Guy

PowerShell Community and the Windows System Administration Tool

Anonymous — Fri, 06 Jan 2012 06:00:00 GMT

Summary: See how guest blogger, Rich Prescott, leveraged the Windows PowerShell community as he built his popular ArPosh Client System Administration tool.

Microsoft Scripting Guy, Ed Wilson, is here. We are really starting the new year off correctly. We have another very strong guest blogger today. Rich Prescott, is currently working as an infrastructure architect and Windows engineer at a large media company, with his main areas of focus on automation and Active Directory. The automation responsibilities allow him to work with a wide-range of technologies including virtualization, storage, and monitoring. He started learning Windows PowerShell in 2009 while he was working as a desktop engineer, and he is the lead scripting guy for his organization. He is also a moderator on the Official Scripting Guys Forum, and was recently rewarded as a Microsoft Community Contributor.

Blog: Engineering Efficiency: Scripts, Tools, and Software New in the IT World
Twitter: @Rich_Prescott

Take it away Rich…

When I first joined the IT world, I was working at the Help desk for a large company. Being new to IT and troubleshooting, I always wondered why there was no single tool for troubleshooting remote computers. I would receive a call about a computer being slow, and I would have to go through four tools to try to diagnose the issue. I began searching for an easy solution, and that is when a coworker introduced me to Windows PowerShell. After reading blog posts from Hey, Scripting Guy! and the Scripting Wife, I was writing basic scripts to gather the information that I needed for troubleshooting. This is an example of a basic script I wrote back then.

$PC = “PC01”
Get-WmiObject Win32_OperatingSystem –ComputerName $PC
Get-WmiObject Win32_StartupCommand –ComputerName $PC
Get-WmiObject Win32_Process –ComputerName $PC

After the underlying issue was targeted, I needed a way to remediate the issue, such as removing a hung process. This was possible remotely by querying the Win32_Process class on a remote computer, filtering for the process that was causing an issue, and invoking the Terminate method. Here is an example of using the Terminate method to stop a process on a remote computer.

(Get-WmiObject Win32_Process –ComputerName $PC |
Where-Object {$_.Name –eq “HungProcessName”}).Terminate()

At last, I was able to efficiently troubleshoot issues remotely and even resolve some of them without ever having to leave my desk. As I became more familiar with Windows PowerShell, I thought, “Wouldn’t it be cool if I could share the efficacy of Windows PowerShell with others, even if they don’t know any scripting?” After a few months of researching, scripting, and testing GUI creation with Windows PowerShell, the Arposh Client System Administration tool (ACSA) was released.

As with any technology that you learn rapidly, when you look back on what you were doing a year ago, you think to yourself, “What was I thinking when I wrote that? I could write that in half the code and make it twice as fast.” So I set out to find resources to help me rebuild the script from scratch, and I used this opportunity to remove some of the prerequisites, make it compatible with servers, and improve the overall user experience.

PowerShellGroup - #PowerShell chat room

One of the advantages of using Internet Relay Chat (IRC) is that there are chat rooms for almost any topic you can think of and when you are learning a new technology, having a live discussion can be really helpful. While revamping the ACSA tool, one of the user-experience features that I wanted to add was to give the user the ability to decide which feature sets to use through a configuration file.

I joined the #PowerShell chat room on PowerShellGroup.org, and I asked about an easy way to give users configuration options. Jaykul, a Windows PowerShell MVP, responded with a way to read settings from an XML file. By using the following XML code and three lines of Windows PowerShell, a user is able to set a default domain to connect to when using the GUI. To have the GUI use the current domain of the logged on user, simply update the Enabled option of the default domain to “False” in the XML configuration file.

<?xml version="1.0" standalone="no"?>
<Domain Default="LDAP://DC=RU,DC=lab" Enabled="True"/>

In the first line of code, we use Get-Content on the XML configuration file and specify that it is XML code by using [XML]. We then check to see if the default domain option is enabled, and if so, we set the Domain variable to what is specified in the XML. If the option is disabled, the GUI sets the Domain variable to the currently logged on domain.

[XML]$XML = Get-Content “AWSA.Options.xml”
if($XML.Domain.Enabled –eq $True){$Domain = $XML.Domain.Default}
else{$Domain = ([DirectoryServices.ActiveDirectory.Domain]::GetCurrentDomain()).Name}

TechNet Wiki

My next task was to make the GUI easy to use, and this meant removing any unnecessary pre-requisites included in the original release. My first stop was the TechNet Wiki to find a way to query Active Directory for computers without the need to import a Windows PowerShell module that was not freely available on all systems. After a quick search, I landed on a wiki contribution from Richard Mueller, another MVP, for ADSI searches, which showed me the syntax necessary to build my custom function.

function Get-RPADComputer{
if($ComputerName -match "."){$ComputerName = $ComputerName.Split('.')[0]}
$searcher=[adsisearcher]"(&(objectClass=computer)(name=$ComputerName*))"
$Properties = $XML.Options.Search.Property
$searcher.PropertiesToLoad.AddRange($Properties)
$searcher.FindAll()
}

This function checks the $ComputerName parameter that is specified in the textbox of the GUI, and if a fully qualified domain name (FQDN) is specified, it translates it to a short name. It then creates a query that will search for any computers that match the new $ComputerName variable. The third line reads a list of properties that the user specifies in the XML settings file and adds them to the list of properties to load. The final line of the function executes the query and returns the results.

TechNet forums

After adding in the ability to set a default domain when launching the GUI, the user needed a way to change domains without having to edit the XML file and relaunch the script. I was not familiar enough with the ADSI scripting techniques that I found on the TechNet Wiki, and I decided to head over to the Official Scripting Guys Forum on the TechNet Forums and ask for some assistance.

I posted my question with some examples of the input and output that I wanted, and within four hours, I received multiple responses from the community. And what do you know—Richard Mueller again came to the rescue with a way to prompt for a domain and then convert the response into the LDAP path for that domain. By slightly tweaking his code, I was able to add the ability to search alternate domains to my custom Active Directory computer search function.

TechNet ScriptCenter

There are many new features in this update of the GUI, but I want to highlight one that many administrators will find very useful and sigh at the mention of: local administrator rights. Every system administrator has received a request along the lines of, “I need to install XYZ software right now!” or “I am using VPN from home, and I need to add a local printer.” One way to get around this (not always the best way) is to grant the user temporary local administrator rights. To find out how to do this the Windows PowerShell way, I headed over to the TechNet ScriptCenter Repository to search for some examples.

Using the Categories listing in the left pane, I drilled down into Local Account Management, and I immediately saw what I was looking for: Local User Management Module. I clicked through to the details page and looked through the included functions. I was in luck! By using ADSI code in the Set-LocalGroup function, I morphed it into my own function as shown here.

Function Add-LocalAdmin {
  [System.Reflection.Assembly]::LoadWithPartialName('Microsoft.VisualBasic') | Out-Null
  $Input = [Microsoft.VisualBasic.Interaction]::InputBox("Enter a username to add (Domain\Username)", "Add Local Admin", "")
  $Group = [ADSI]("WinNT://" + $ComputerName + "/Administrators, group")
  $Group.Add("WinNT://" +$Input.Replace(‘\’,’/’)
}

The first line of the function loads the Visual Basic assembly; this allows me to create a custom input box, which prompts the user for the username to add to the local administrators group and then stores it in the $Input variable. The function then binds to the Administrators group on the remote computer using ADSI. Now we call the Add method of ADSI to add the desired user account to the administrators group. But there is a snag, the username is specified as Domain\Username, whereas ADSI requires a forward slash. To get around this, we use the Replace method to turn the back slash into a forward slash.

Arposh Windows System Administration tool

Whether you are new to Windows PowerShell and only need a simple script to get you going or you are a Windows PowerShell guru and need a nudge in the right direction, there are numerous resources for everyone. Thanks to all of these resources, I was able to take a simple GUI that I created for myself to make tasks easier and improve it enough to where the Windows PowerShell community would also find it useful. Without further ado, here is the Arposh Windows System Administration tool.

~Rich

Ed Wilson, Microsoft Scripting Guy

Use PowerShell to Find and Uninstall Software

Anonymous — Wed, 14 Dec 2011 06:00:00 GMT

Summary: Learn how to use Windows PowerShell to get software installation locations, and to uninstall software from remote computers.

Hey, Scripting Guy! We have a dumb application that we have to use at work. The company has released a new version of this application, and I am trying to write a Windows PowerShell script to uninstall the old application—the problem is that I need to find the application first. I tried looking in the registry, but the install key is empty…figures. Like I said, this is a really dumb application. I read the guest blog written by Marc Carter about problems using the Win32_Product WMI class, but it looks like I am going to be stuck using this anyway. The problem is that it is really slow. Is there any way to speed this thing up? I have to query over a thousand computers, and in our testing, this query takes nearly five minutes to complete—that would be three and a half days for only one query.

—BT

Hello BT,

Microsoft Scripting Guy, Ed Wilson, is here. The Scripting Wife and I were in Texas for the Corpus Christi Windows PowerShell User Group meeting when Marc Carter told me about the problem with the MSI installer reconfiguring applications when the Win32_Product WMI class is queried. I immediately encouraged him to write a guest blog about this issue.

BT, there is a way to use the Win32_Product WMI class in a more efficient manner. It relies on using the [WMI] type accelerator, instead of doing a generic WMI query. The problem is that the [WMI] type accelerator returns a specific instance of a WMI class. To connect to a specific instance, I must use the Key property of a WMI class.

I can use the Get-WMIKey function from my HSGWMImoduleV6 module. In the following code, I first import my HSGWMImoduleV6 module, and then I use the Get-WMIKey function to return the key to the Win32_Product WMI class. The commands and the output from the commands are shown here.

PS C:\> Import-Module hsg*6

PS C:\> Get-WmiKey win32_product

IdentifyingNumber

Name

Version

The Key property for Win32_Product is a composite key comprised of IdentifyingNumber, Name, and Version. The easy way to get this information is to use the Get-WmiObject cmdlet to query for the information. I only need to do this once, and I will have the three pieces of information. A table is a nice way to display the information. In the code shown here, I use the Get-WmiObject cmdlet (gwmi is an alias) to return product information, and then I pipe the management objects to the Format-Table (ft is an alias) cmdlet for display.

gwmi win32_product | ft name, version, ident*

In the image that follows, I import the HSGWMIModuleV6 module, use the Get-WMIKey function to retrieve the Key property of the Win32_Product WMI class. I then use the Get-WmiObject cmdlet (gwmi is an alias) to query the Win32_Product WMI class, and I output the management objects to a table via the Format-Table (ft is alias) cmdlet. The following image displays the commands and the output from the commands.

BT, you may ask, “What about Marc Carter’s warning about using the Win32_Product WMI class? “ Well as seen in the results from querying the event log, it is a concern. Shortly after querying the Win32_Product WMI class, I used the Get-EventLog cmdlet to query the application log for MSIInstaller events. The following image shows massive product reconfiguring going on.

The query to return the three parts of the composite key only needs to run once; the values do not change. It is also possible to use the Get-WmiObject cmdlet and a filter to improve the performance of the command a little bit. The nice thing about this command is that it returns the information that is required by the [WMI] type accelerator. The command and associated output are shown here.

PS C:\> gwmi win32_product -filter "Name LIKE '%Silverlight%'"

IdentifyingNumber : {89F4137D-6C26-4A84-BDB8-2E5A4BB71E00}

Name : Microsoft Silverlight

Vendor : Microsoft Corporation

Version : 4.0.60831.0

Caption : Microsoft Silverlight

When I have the three pieces of information (the IdentifyingNumber, the Name, and the Version), it is time to create the key. This is where quite a bit of experimentation could be required. I have to use the back tick (grave) character to escape inside quotation marks. I have to escape the quotation mark and the opening curly bracket for the IdentifyingNumber property. I also have to escape the closing curly bracket and the closing quotation mark. I then have to escape the quotation marks that surround Microsoft Silverlight, in addition to the quotation marks for the Version property. There are also two quotation marks at the end of the ClassKey.

Here is the key I derived for Microsoft Silverlight on my computer. (This is a single line command. A space between Microsoft and Silverlight exists, but other than that, there are no spaces).

$classKey="IdentifyingNumber=`"`{89F4137D-6C26-4A84-BDB8-2E5A4BB71E00`}`",Name=`"Microsoft Silverlight`",version=`"4.0.60831.0`""

The reason for all the escaping in the ClassKey, is that WMI expects the quotation marks and the curly brackets in the key itself. To see what WMI expects to receive via the command, I use the Windows Management Instrumentation Tester (WbemTest) command, and I view the instances of the class. The following image illustrates the instances of Win32_Product on my computer.

When I have the ClassKey, I can use the [WMI] type accelerator to connect to the specific software package (Microsoft Silverlight in this example). In fact, using the [WMI] type accelerator is very easy. Here is the command. (The command is [WMI], the class name, and the key).

[wmi]"Win32_Product.$classkey"

I can also include the WMI namespace (really important if the class resides in a namespace other than the default root\cimv2). In the command that follows, notice that there is a backslash that precedes the word root. One other thing to notice is that a colon separates the WMI namespace and the WMI class name.

[wmi]"\root\cimv2:Win32_Product.$classkey"

If I need to connect to a WMI class on a remote computer, I use a double backslash and the name of the computer, then the WMI namespace, the WMI class, and the WMI ClassKey. The command that follows illustrates this.

[wmi]\\remotehost\root\cimv2:Win32_Product.$classkey

In the image that follows, I illustrate the different ways of querying WMI for Microsoft Silverlight software. I then compare the speed of using the Get-WmiObject cmdlet against the speed of using the [WMI] type accelerator. As shown in the following image, the Get-WmiObject cmdlet, using the filter to find Microsoft Silverlight, takes over five seconds on my laptop. Using the [WMI] type accelerator takes less than one-half of a second. This is more than 10 times faster.

By the way, there was not much difference between using the filter to look for Microsoft Silverlight or using the Where-Object. In the following output, I use the Measure-Object cmdlet to determine the performance of using the Where-Object (the ? is an alias for Where-Object).

PS C:\> measure-command {gwmi win32_product | ? {$_.name -match 'silverlight'}}

Days : 0

Hours : 0

Minutes : 0

Seconds : 5

Milliseconds : 311

Ticks : 53112518

TotalDays : 6.14728217592593E-05

TotalHours : 0.00147534772222222

TotalMinutes : 0.0885208633333333

TotalSeconds : 5.3112518

TotalMilliseconds : 5311.2518

If you suspect that the problem with the filter is that I used the like operator as opposed to the equality operator, that is not the case. Here are the results from using the equality operator.

PS C:\> measure-command {gwmi win32_product | ? {$_.name -match 'silverlight'}}

Days : 0

Hours : 0

Minutes : 0

Seconds : 5

Milliseconds : 311

Ticks : 53112518

TotalDays : 6.14728217592593E-05

TotalHours : 0.00147534772222222

TotalMinutes : 0.0885208633333333

TotalSeconds : 5.3112518

TotalMilliseconds : 5311.2518

When using the [WMI] type accelerator, a complete instance of the WMI class instance returns. The properties and their associated values are shown in the following image. Notice two properties: the __Path (that is, double underscore Path) property is the key to the WMI class instance. The InstallLocation property points to the location where the software installs.

BT, you did not ask, but there is an Uninstall method available from the Win32_Product WMI class. It appears only on instances of the class. Therefore, it is possible to uninstall software by using the command that is shown here. (If I want to uninstall from a large collection of servers, I use the foreach statement ($servers is an array of server names).

foreach($server in $servers)

{ ([wmi]"\\$server\root\cimv2:Win32_Product.$classKey").uninstall() }

BT, that is all there is to using the Win32_Product WMI class to detect or to uninstall software. Join me tomorrow when I will have a guest blog written by Raymond Mitchel as he talks about Windows PowerShell and SharePoint.

Ed Wilson, Microsoft Scripting Guy

Create a Custom Object from WMI by Using PowerShell

Anonymous — Tue, 27 Sep 2011 05:00:00 GMT

Summary: Create a custom object from WMI to display processor and operating system information using Windows PowerShell.

Hey, Scripting Guy! Your script yesterday was pretty cool. However, in addition to obtaining information about the processor, I also need to know operating system is 32-bit or 64-bit, the version of Windows that is installed, and the service pack that is installed. I hate to be picky, but this is the information I need in order to plan for our upgrade project.

—BB

Hello BB,

Microsoft Scripting Guy Ed Wilson here. First, I need to apologize to the Scripting Wife. Yesterday was her birthday, and I did not mention it in the Hey, Scripting Guy! Blog. Sorry!

Beyond the disappointed Scripting Wife, BB, I am glad you enjoyed yesterday’s article. It is one of those things that sort of gets out of control. I begin working on a script and keep adding to it. So I will simply continue adding to it for today.

First, make sure you have the script from yesterday’s Hey Scripting Guy! Article. The script, as it stood at the end of yesterday, is shown here:

Import-Module ActiveDirectory

$pingConfig = @{

"count" = 1

"bufferSize" = 15

"delay" = 1

"EA" = 0 }

$computer = $cn = $null

$cred = Get-Credential

Get-ADComputer -filter * -Credential $cred |

ForEach-Object {

if(Test-Connection -ComputerName $_.dnshostname @pingconfig)

{ $computer += $_.dnshostname + "`r`n"} }

$computer = $computer -split "`r`n"

$property = "systemname","maxclockspeed","addressWidth",

"numberOfCores", "NumberOfLogicalProcessors"

foreach($cn in $computer)

{

if($cn -match $env:COMPUTERNAME)

{

Get-WmiObject -class win32_processor -Property $property |

Select-Object -Property $property }

elseif($cn.Length -gt 0)

{

Get-WmiObject -class win32_processor -Property $property -cn $cn -cred $cred |

Select-Object -Property $property } }

Now, let’s see if I can find the additional information you need for your upgrade project. Actually, it is pretty simple because everything you need is in the Win32_OperatingSystem WMI class. The Win32_OperatingSystem WMI class is documented on MSDN, but the properties needed for today’s script are rather straightforward and do not need extensive documentation. A quick check of the Win32_Operatingsystem WMI class reveals everything I need. The command I use to perform this check is shown here (gwmi is an alias for Get-WmiObject and fl is alias for Format-List):

gwmi win32_operatingsystem | fl *

The command and associated output are shown in the following figure.

The revised script is named GetADComputersAndWMiProcessorAndOSInfo.ps1.

GetADComputersAndWMiProcessorAndOSInfo

Import-Module ActiveDirectory

$pingConfig = @{

"count" = 1

"bufferSize" = 15

"delay" = 1

"EA" = 0 }

$computer = $cn = $null

$cred = Get-Credential

Get-ADComputer -filter * -Credential $cred |

ForEach-Object {

if(Test-Connection -ComputerName $_.dnshostname @pingconfig)

{ $computer += $_.dnshostname + "`r`n"} }

$computer = $computer -split "`r`n"

$property = "systemname","maxclockspeed","addressWidth",

"numberOfCores", "NumberOfLogicalProcessors"

$osProperty = "Caption", "OSArchitecture","ServicePackMajorVersion"

foreach($cn in $computer)

{

if($cn -match $env:COMPUTERNAME)

{

$obj = Get-WmiObject -class win32_processor -Property $property |

Select-Object -Property $property

$os = Get-WmiObject -class win32_OperatingSystem -Property $osproperty |

Select-Object -Property $osproperty

} #end if

elseif($cn.Length -gt 0)

{

$obj = Get-WmiObject -class win32_processor -Property $property -cn $cn -cred $cred |

Select-Object -Property $property

$os = Get-WmiObject -class win32_OperatingSystem -Property $osproperty -cn $cn -cred $cred |

Select-Object -Property $osproperty

} #end elseif

New-Object psobject -Property @{

"name" = $obj.systemname

"speed" = $obj.maxclockspeed

"addressWidth" = $obj.addressWidth

"numberCores" = $obj.numberOfCores

"numberLogicalProcessors" = $obj.NumberOfLogicalProcessors

"OSname" = $os.Caption

"OSArchitecture" = $os.OSArchitecture

"ServicePack" = $os.ServicePackMajorVersion

}

#$os

} #END FOREACH

When the script runs, the first thing that happens is a credential dialog box displays. This is because I request credentials for connection to remote systems. The credentials are not used to connect to the local computer. The credential dialog box is shown in the following figure.

I added an array of properties to store the operating system information:

$osProperty = "Caption", "OSArchitecture","ServicePackMajorVersion"

This change is shown in the following figure.

In addition, I changed the portion of the script inside the Foreach loop so that I am storing the Processor object instead of directly emitting. I also added a WMI query to retrieve the operating system information. The revised section is shown here:

foreach($cn in $computer)

{

if($cn -match $env:COMPUTERNAME)

{

$obj = Get-WmiObject -class win32_processor -Property $property |

Select-Object -Property $property

$os = Get-WmiObject -class win32_OperatingSystem -Property $osproperty |

Select-Object -Property $osproperty

} #end if

elseif($cn.Length -gt 0)

{

$obj = Get-WmiObject -class win32_processor -Property $property -cn $cn -cred $cred |

Select-Object -Property $property

$os = Get-WmiObject -class win32_OperatingSystem -Property $osproperty -cn $cn -cred $cred |

Select-Object -Property $osproperty

} #end elseif

This portion of the revised code is shown in the following figure.

To make it easier to work with the output, I decided to return a custom object. This object contains information from both WMI classes. In addition, I changed some of the column headings to make it easier to read. This section of the script that creates the new object is shown here:

New-Object psobject -Property @{

"name" = $obj.systemname

"speed" = $obj.maxclockspeed

"addressWidth" = $obj.addressWidth

"numberCores" = $obj.numberOfCores

"numberLogicalProcessors" = $obj.NumberOfLogicalProcessors

"OSname" = $os.Caption

"OSArchitecture" = $os.OSArchitecture

"ServicePack" = $os.ServicePackMajorVersion

} #end new object

This portion of the new code is shown in the following figure.

When the script runs, the following output is displayed.

BB, that is all there is to using Windows PowerShell to query for both processor and operating system information.

Ed Wilson, Microsoft Scripting Guy