PowerShell for Windows Admins


July 24, 2011  12:13 PM

PowerShell remoting–User group meeting

Richard Siddaway Richard Siddaway Profile: Richard Siddaway

Final reminder for the user group meeting on Tuesday 26 July

Details from:

http://msmvps.com/blogs/richardsiddaway/archive/2011/07/20/july-2011-user-group-reminder.aspx

July 22, 2011  1:43 PM

Can I? Should?–copying VBscripts

Richard Siddaway Richard Siddaway Profile: Richard Siddaway

One of the major errors I see PowerShell newcomers performing is copying script structures and syntax of VBScript into PowerShell. Let me give you an example

This piece of VBScript is borrowed from the Windows 2000 scripting guide

 

strComputer = "."
Set objWMIService = GetObject("winmgmts:" _
& "{impersonationLevel=impersonate}!\\" & strComputer & "\root\cimv2")
Set colSettings = objWMIService.ExecQuery _
("SELECT * FROM Win32_OperatingSystem")
For Each objOperatingSystem in colSettings
Wscript.Echo "OS Name: " & objOperatingSystem.Name
Wscript.Echo "Version: " & objOperatingSystem.Version
Wscript.Echo "Service Pack: " & _
objOperatingSystem.ServicePackMajorVersion _
& "." & objOperatingSystem.ServicePackMinorVersion
Wscript.Echo "OS Manufacturer: " & objOperatingSystem.Manufacturer
Wscript.Echo "Windows Directory: " & _
objOperatingSystem.WindowsDirectory
Wscript.Echo "Locale: " & objOperatingSystem.Locale
Wscript.Echo "Available Physical Memory: " & _
objOperatingSystem.FreePhysicalMemory
Wscript.Echo "Total Virtual Memory: " & _
objOperatingSystem.TotalVirtualMemorySize
Wscript.Echo "Available Virtual Memory: " & _
objOperatingSystem.FreeVirtualMemory
Wscript.Echo "OS Name: " & objOperatingSystem.SizeStoredInPagingFiles
Next

It uses the Win32_OperatingSystem class to display information about the computers OS. As you can see the bulk of the script is concerned with formatting. Note the error in the script regarding OS Name

 

What often happens is that this will be translated directly, line by line, into PowerShell – which gives us something like this

$strComputer = "."            
            
$colSettings = Get-WmiObject -Query "SELECT * FROM Win32_OperatingSystem" -ComputerName $strComputer            
foreach ($objOperatingSystem in $colSettings){            
 Write-Host "OS Name: "  $objOperatingSystem.Name            
 Write-Host "Version: "  $objOperatingSystem.Version            
 Write-Host "Service Pack: "  $objOperatingSystem.ServicePackMajorVersion "." $objOperatingSystem.ServicePackMinorVersion            
 Write-Host "OS Manufacturer: "  $objOperatingSystem.Manufacturer            
 Write-Host "Windows Directory: "  $objOperatingSystem.WindowsDirectory            
 Write-Host "Locale: "  $objOperatingSystem.Locale            
 Write-Host "Available Physical Memory: "  $objOperatingSystem.FreePhysicalMemory            
 Write-Host "Total Virtual Memory: "  $objOperatingSystem.TotalVirtualMemorySize            
 Write-Host "Available Virtual Memory: " $objOperatingSystem.FreeVirtualMemory            
}

This is less code but still seems like a lot of work

 

lets put it into PowerShell as if we had written it from scratch

$strComputer = "."            
            
Get-WmiObject -Class Win32_OperatingSystem -ComputerName $strComputer |            
select Name, Version, ServicePackMajorVersion, ServicePackMinorVersion,            
Manufacturer, WindowsDirectory, Locale, FreePhysicalMemory,             
TotalVirtualMemorySize, FreeVirtualMemory

 

Now that is much easier. Quicker to code and easier to understand.

 

By all means use VBscripts as references for using WMI classes (I do) but re-write into PowerShell its much, much easier.

This isn’t a contradiction of my previous post as I advocated leaving legacy VBScript alone until you needed to  modify it


July 20, 2011  3:09 PM

Can I? Should I?–examples–legacy scripts

Richard Siddaway Richard Siddaway Profile: Richard Siddaway

In this post http://msmvps.com/blogs/richardsiddaway/archive/2011/07/17/can-i-should-i.aspx I stated that PowerShell isn’t necessarily the right answer to every problem.

I was left a comment asking if I could expand.  I’ll do that over a series of short posts as I think of examples.

One of the first that comes to mind is legacy scripts.

VBScript never really caught on as a mainstream administration tool. There were a number of reasons for this:

  • non interactive
  • harder to use and debug
  • less information
  • less flexible
  • admins addicted to the GUI
  • less pressure on people i.e. more admins

However, a number of organisations created a significant number of scripts and performed some very clever stuff.

Now, the question for those organisations is this -

“PowerShell has appeared. Do I convert all those scripts, that work really well to PowerShell?”

 

My answer would be no!  Learn PowerShell first . Get really proficient. Develop new stuff in PowerShell and migrate the legacy scripts when they need an over haul (or you get some free timeSurprised smile) that way you get the best of both worlds and run the smallest risk when you come to migrate the legacy scripts.


July 20, 2011  2:49 PM

July 2011–User Group reminder

Richard Siddaway Richard Siddaway Profile: Richard Siddaway

Next Tuesday – 26 July there will be a UK user group session looking at PowerShell remoting:

  • cmdlets with remoting capabilities
  • .NET remoting capabilities
  • Invoke-Command
  • PowerShell sessions
  • WinRm and WSMan cmdlets

Details on joining the live meeting session:


When: Tuesday, Jul 26, 2011 7:30 PM (BST)


Where:

*~*~*~*~*~*~*~*~*~*

A look at PowerShell Remoting using individual commands, Invoke-Command and PowerShell sessions. How to configure remoting and get the best out of it

Notes


Richard Siddaway has invited you to attend an online meeting using Live Meeting.
Join the meeting.
Audio Information
Computer Audio
To use computer audio, you need speakers and microphone, or a headset.
First Time Users:
To save time before the meeting, check your system to make sure it is ready to use Microsoft Office Live Meeting.
Troubleshooting
Unable to join the meeting? Follow these steps:

  1. Copy this address and paste it into your web browser:
    https://www.livemeeting.com/cc/usergroups/join
  2. Copy and paste the required information:
    Meeting ID: C7JCCP
    Entry Code: fKg^5N’,D
    Location: https://www.livemeeting.com/cc/usergroups

If you still cannot enter the meeting, contact support

Notice
Microsoft Office Live Meeting can be used to record meetings. By participating in this meeting, you agree that your communications may be monitored or recorded at any time during the meeting.


July 18, 2011  12:36 PM

Joining objects

Richard Siddaway Richard Siddaway Profile: Richard Siddaway

PowerShell doesn’t have the equivalent of an SQL Union statement that lets you join objects together. What you can do is use New-Object to create the joined output.

As an example that recently came up on a forum

$outputs = @()            
Get-WmiObject -Class Win32_NetworkAdapterConfiguration -Filter "IPenabled=$true" |            
foreach {            
 $nic = Get-WmiObject -Class Win32_NetworkAdapter -Filter "DeviceId='$($_.Index)'"            
            
 $output= New-Object -TypeName PSObject -Property @{            
  NICCardName = $nic.NetConnectionId            
  DHCPEnabled = $($_.DHCPEnabled)            
  IPAddress = $($_.IPAddress)            
  SubnetMask = $($_.IPSubnet)            
  Gateway = $($_.DefaultIPGateway)            
  DHCPServer = $($_.DHCPServer)            
  DNSDomain =  $($_.DNSDomain)            
  DNSDomainSuffixSearchOrder = $($_.DNSDomainSuffixSearchOrder)            
  DNSServerSearchOrder = $($_.DNSServerSearchOrder)            
 }             
$outputs += $output            
}            
$outputs

Get the NetworkAdapterConfigurations where they are IPenabled. Then for each get the associated adapter.

Create a new object and add the properties.  Add the object to the array of results.

At the end output the array.

I would not use the array and just output the object and allow the pipeline to take care of any other processing


July 17, 2011  4:17 AM

Can I? Should I?

Richard Siddaway Richard Siddaway Profile: Richard Siddaway

The question “Can I do X with PowerShell?” comes up very frequently.

PowerShell provides access to a huge range of functionality:

  • .NET
  • COM
  • WMI
  • Microsoft and third party products

Usually the answer is “Yes, you can”

BUT

What doesn’t seem to be considered so often is the question “Should I do X with PowerShell?”

If you don’t have alternatives then by all means try it but if there are better ways to accomplish the task then consider them.

If all you have is PowerShell everything looks like a script


July 15, 2011  6:47 AM

Printer Security settings

Richard Siddaway Richard Siddaway Profile: Richard Siddaway

I was recently asked about getting the security settings for printers.

$pace = DATA {            
ConvertFrom-StringData -StringData @'
983052 = ManagePrinters
983088 = ManageDocuments
131080 = Print 
524288 = TakeOwnership
131072 = ReadPermissions
262144 = ChangePermissions 
'@            
}             
$flags = @(983052,983088, 131080, 524288, 131072, 262144)            
            
            
function get-printersecurity {            
 [CmdletBinding()]            
 param (            
  [string]$computer="."            
 )            
             
 Get-WmiObject -Class Win32_Printer -ComputerName $computer |            
 foreach {            
  "`nPrinter: $($_.DeviceId)"            
  $query = "ASSOCIATORS OF {Win32_Printer.DeviceID='$($_.DeviceID)'} WHERE ResultClass=Win32_Share"            
  Get-WmiObject -ComputerName $computer -Query $query |             
  foreach {            
    ""            
    "Share: $($_.Name)"            
                
    $query2 = "ASSOCIATORS OF {Win32_Share.Name='$($_.Name)'} WHERE ResultClass=Win32_LogicalShareSecuritySetting"            
    $sec = Get-WmiObject -ComputerName $computer -Query $query2            
    $sd = $sec.GetSecurityDescriptor()            
    $sd.Descriptor.DACL | foreach {            
      ""             
      "$($_.Trustee.Domain)  $($_.Trustee.Name)"            
                  
      foreach ($flag in $flags){            
        if ($_.AccessMask -band $flag){            
          $pace["$($flag)"]            
        }            
      }            
    }            
  }            
 }            
}

 

Create a hash table lookup and an array of flags

The function then gets all the printers on a system, links through to any shares and then gets the security descriptor of the share. The DACL on the security descriptor is iterated over to generate a list of users and their permissions


July 13, 2011  5:01 AM

European PowerShell Deep Dive

Richard Siddaway Richard Siddaway Profile: Richard Siddaway

In April there was a Powershell Deep Dive at The Experts conference. It went
so well that the event is to be repeated at the European version of The Experts
Conference – October 17-18

Available details are limited but start here

http://blogs.msdn.com/b/powershell/archive/2011/07/12/powershell-deep-dive-the-experts-conference-europe-2011.aspx


July 13, 2011  2:55 AM

Windows SysInternals Administrators Reference

Richard Siddaway Richard Siddaway Profile: Richard Siddaway

Windows SysInternals Administrators Reference

Title: Windows SysInternals Administrators Reference

Publisher: Microsoft Press

ISBN: 978-0-7356-5672-7

The SysInternals tool set – http://technet.microsoft.com/en-us/sysinternals/default.aspx
 – should be one of a Windows administrator’s
best friends. You may not need them every day but when you do they will help dig
you out of the hole. The toolset was created, and is still maintained by Mark
Russinovich. Originally, offered as an independent set of utilities it is now
owned and supplied (as a free download) by Microsoft.  

One of the difficulties, with any troubleshooting toolset,
is knowing how to get the best out of the tools, especially if you are only
using them now and again. The SysInternals tools can be downloaded as a
complete suite or the individual tools (or group of tools) can be downloaded
independently. This approach leaves the administrator possibly using, and
understanding, part of the toolset because they are used regularly but
completely ignorant of the rest of the tools.  Mark Russininovich, and his co-author Aaron
Margois, have created the Windows SysInternals Administrators Reference to address
that gap

The book is divided into three parts:

·       
Part 1 starts with the SysInternals core
concepts, including some historical background. Chapter 2 follows on with a
look at Windows Core Concepts including administrative rights, process,
threads, user and kernel mode, handles, call stacks and sessions.

·       
Part 2 is where we dive into the toolset:

o  
Process Explorer

o  
Process Monitor

o  
Autoruns

o  
PsTools

o  
Process and Diagnostics Utilities

o  
Security Utilities

o  
Active Directory Utilities

o  
Desktop Utilities

o  
Network and Communications utilities

o  
System Information utilities

o  
Miscellaneous Utilities

·       
Part 3 looks at using the tools in some real
life scenarios

o  
Error messages

o  
Hangs and sluggish performance

o  
Malware

I suspect that many readers will read parts 1 and 3 for the
very valuable information. Part 2 is more of a reference which will be dipped
into as needed. The breadth of the SysInternals toolset means that you won’t be
using all of the tools all of the time but will need the information on using
the other tools. I would strongly recommend at least skimming through the
chapters in part 2. You may well find something that will help solve an
incipient problem. They can also suggest a course of action to help investigate
potential problems.

As a very strong advocate of using PowerShell there are some
occasions where the two sets of functionality overlap. The SysInternals tools
will often take over where the PowerShell functionality finishes so tend to be
complimentary rather then competing.

This is a book to which I think every Windows
administrator/consultant needs access. I tend to carry a netbook these days
with my library of scripts and utilities plus electronic copies of the
important reference works I might need. A copy of the latest version of the
SysInternals tools plus this book is very definitely included in that content.  

Highly recommended for all Windows administrators and
consultants. Don’t leave home without it.

 


July 9, 2011  6:45 AM

Linking the network card to the Registry settings

Richard Siddaway Richard Siddaway Profile: Richard Siddaway

An interesting problem from the forum. Get the IP enabled network adapters and read the associated registry keys to get the value of the NetLuidIndex.

$HKLM = 2147483650            
$reg = [wmiclass]'\\.\root\default:StdRegprov'            
$keyroot = "SYSTEM\CurrentControlSet\Control\Class\{4D36E972-E325-11CE-BFC1-08002BE10318}"            
$value = "NetLuidIndex"            
            
Get-WmiObject -Class Win32_NetworkAdapterConfiguration -Filter "IPEnabled='$true'" |            
foreach {            
            
$data = $_.Caption -split "]"            
$suffix = $data[0].Substring(($data[0].length-4),4)            
$key = $keyroot + "\$suffix"            
            
$nli = $reg.GetDwordValue($HKLM, $key, $value)  ## REG_DWORD            
            
$nic = New-Object -TypeName PSObject -Property @{            
         Description = $_.Description            
         DeviceID = $_.Index               
         Suffix = $suffix            
         NetLuidIndex = $nli.uValue            
       }            
$nic            
} | Format-Table -AutoSize

Use the standard registry settings to read the HKLM hive and setup the WMI registry provider.

Get the network cards using a filter of IPEnabled = $true.

For each card break the caption property to get  the subkey value and add it to the key root. Do a standard DWORD read on the registry and construct an object to display the results


Forgot Password

No problem! Submit your e-mail address below. We'll send you an e-mail containing your password.

Your password has been sent to: