Monthly Archive

Categories

Monthly Archives: March 2016

IIS information

In my recent post about getting server information from a IIS web server I said I post about getting similar information from later machines.

 

You still have the root\MirosoftIISv2 namespace available if you install the IIS 6.0 tools but one question to keep in mind – how long will they continue to be available?

 

Your alternative is the root\webadministration names space. You can use the Site class to get the relevant information

 

$serverdata = @()
Get-CimInstance -Namespace root\webadministration -ClassName Site -ComputerName $env:COMPUTERNAME |
foreach {

$serverdata += New-Object -TypeName PSObject -Property @{
Port = [string]::Join(',', ($_.Bindings | select -ExpandProperty BindingInformation))
SiteName = $_.Name
SiteId = $_.id
PSComputerName = $_.PSComputerName
Status = Invoke-CimMethod -InputObject $_ -MethodName GetState | select -ExpandProperty ReturnValue
}

}
$serverdata

 

Remember that COM objects are inert so you can’t call the method directly on the object. otherwise the info is about the same

European PowerShell Conference 2016–few places left

There are still a few places left at the European PowerShell conference next month - http://www.psconf.eu/

 

There’s a terrific line up of speakers and I really recommend you get there if you can

IIS 6.0 server information

A question of the forum asked about getting data from IIS 6.0 servers

 

One of the ways to access this data is to use CIM (WMI). IIS 6.0 has the root\MicrosoftIIsV2  namespace. Later versions of Windows server also have a root\webadministration namespace which is preferred.

 

The original question asked about IIS 6.0 – I’ll show the same functionality using the later namespace in the next post

 

This based on the original code in the question and isn’t necessarily how I would do it from scratch

$file = Get-Content "C:\Temp\PowerShellScripts\IISQuery\servers.txt"
$OutputDir = "C:\Temp\PowerShellScripts\IISQuery\Output"
$OutputFile = Join-Path $OutputDir "IIStest.csv"
$serverdata = @()

foreach ($computername in $file)
{
$IISWebServer = Get-WmiObject -Namespace root\MicrosoftIIsV2 -Class IISWEbServer -ComputerName $computername -Authentication 6
foreach ($webserver in $IISWebServer) {

$IISWebServerSet = Get-WmiObject -Namespace root\MicrosoftIISv2 -Class IISWebServerSetting -ComputerName $computername -Filter "Name='$($webserver.Name)'"  -Authentication 6

$serverdata += New-Object -TypeName PSObject -Property @{
PScomputername = $IISWebServerSet.PScomputername
ServerComment = $IISWebServerSet.ServerComment
SiteStatus = $webserver.ServerState
Bindings = [string]::join(';',($IISWebServerSet.ServerBindings | select -expand hostname))
Port = [string]::join(';',($IISWebServerSet.ServerBindings | select -expand Port))
SiteName = $IISWebServerSet.Name
}

} ## end of foreach ($webserver in $IISWebServer)

}  ## end of foreach ($computername in $file)
$serverdata | Export-Csv -Path $OutputFile –NoTypeInformation

 

Start by defining input and output files and an empty array

 

Loop through the servers and get the IISWebserver class instance. You’ll get one object per web site. Loop through the sites and get the IISWebServerSetting class for that site (using –Filter).

 

Create and output object and add to the array

Export the array to a csv file

 

There are a few improvements that could be made to this to make it more efficient that I’ll cover in a later post

Breaking CIM sessions

A CIM session is analogous to a PowerShell remoting session but for CIM based cmdlets – the CIM cmdlets themselves and any CDXML based cmdlets e.g. the networking cmdlets

By default a CIM session uses WSMAN as its transport protocol – the same as remoting. You do have the choice to create a CIM session using DCOM for transport (same as the WMI cmdlets use)

I’ve always maintained that DCOM based sessions could be broken if the remote machine was re-started. This was based on the testing I did when writing PowerShell and WMI.

Some recent information cast doubt on that assertion though.  I’ve digging into CIM sessions recently and have what I think is a definitive statement on DCOM based CIM sessions.

If you create a DCOM based CIM session to a machine running PowerShell 2.0 from a machine running PowerShell 3.0 (or PowerShell 4.0 – I haven’t tested recently but remember doing this when writing the CIM section of PowerShell in Depth) access the remote machine and then restart and attempt to use the session – it will break like this:

$dopt = New-CimSessionOption -Protocol Dcom
$dcs = New-CimSession -ComputerName W8R2STD01 -SessionOption $dopt
Get-CimInstance -ClassName Win32_OperatingSystem -CimSession $dcs

SystemDirectory   Organization     BuildNumber      RegisteredUser   SerialNumber     Version          PSComputerName
---------------   ------------     -----------      --------------   ------------     -------          --------------
C:\Windows\sys...                  7601             Windows User     00477-179-000... 6.1.7601         W8R2STD01

Restart-Computer -ComputerName W8R2STD01
Get-CimInstance -ClassName Win32_OperatingSystem -CimSession $dcs
Get-CimInstance : Access is denied.
At line:1 char:1
+ Get-CimInstance -ClassName Win32_OperatingSystem -CimSession $dcs
+ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
    + CategoryInfo          : PermissionDenied: (root\cimv2:Win32_OperatingSystem:String) [Get-CimInstance], CimExcept
   ion
    + FullyQualifiedErrorId : HRESULT 0x80070005,Microsoft.Management.Infrastructure.CimCmdlets.GetCimInstanceCommand
    + PSComputerName        : W8R2STD01

The CIM session will usually become usable again after a period of time.

If you repeat the experiment using WSMAN or DCOM sessions to machines running PowerShell 3.0 or above the command to use the session is effectively paused until the session is responsive – this can take a little time

A machine running PowerShell 5.0 RTM can create a CIM session to PowerShell 2.0 (DCOM)  or later (DCOM or WSMAN) and the command is effectively paused until the remote machine is up.

The only time I can see the need to use a DCOM based CIM session is to access a PowerShell 2.0 machine – under any other circumstances I’d recommend using the default WSMAN based sessions.

Bottom line is that DCOM based sessions can be broken under specific circumstances that hopefully with time will disappear. 

LocalAccounts module

I’m running Windows 10 and I’m on the fast ring for new Windows 10 builds. Sometimes that’s a good thing and other times its not.

 

I decided to update help and after the update got a message: Failed to update Help for the module(s) 'Microsoft.PowerShell.LocalAccounts'

That was a new one to me

 

I looked at the release notes - https://github.com/PowerShell/PowerShell-Docs/tree/master/undefined 

 

What a dogs breakfast!

I understand why ‘open sourcing’ the release notes but using git hub for release notes is a truly awful experience

 

Any way I couldn’t find anything about a LocalAccounts module

 

I need to do some investigation but current the module is at version 1.0.0.0 and contains these cmdlets

Add-LocalGroupMember
Disable-LocalUser
Enable-LocalUser
Get-LocalGroup
Get-LocalGroupMember
Get-LocalUser
New-LocalGroup
New-LocalUser
Remove-LocalGroup
Remove-LocalGroupMember
Remove-LocalUser
Rename-LocalGroup
Rename-LocalUser
Set-LocalGroup
Set-LocalUser

Module Name change NetworkSwitch to NetworkSwitchManager

Just been caught out by a module name change in WMF 5.0

The NetworkSwitch module has been renamed to NetworkSwitchManager.  Still has the same functionality

Disable-NetworkSwitchEthernetPort       
Disable-NetworkSwitchFeature            
Disable-NetworkSwitchVlan               
Enable-NetworkSwitchEthernetPort        
Enable-NetworkSwitchFeature             
Enable-NetworkSwitchVlan                
Get-NetworkSwitchEthernetPort           
Get-NetworkSwitchFeature                
Get-NetworkSwitchGlobalData             
Get-NetworkSwitchVlan                   
New-NetworkSwitchVlan                   
Remove-NetworkSwitchEthernetPortIPAddress
Remove-NetworkSwitchVlan                
Restore-NetworkSwitchConfiguration      
Save-NetworkSwitchConfiguration         
Set-NetworkSwitchEthernetPortIPAddress  
Set-NetworkSwitchPortMode               
Set-NetworkSwitchPortProperty           
Set-NetworkSwitchVlanProperty

One of these days I should read the realease notes Smile

PowerShell Community in action

In response to this post - ttps://richardspowershellblog.wordpress.com/2016/02/29/csv-file-with-in-headers/

 

Japp Brasser wrote a function to automate header name replacements. You can find the function at https://github.com/jaapbrasser/UtilityScripts/blob/master/Import-CsvFixHeader.ps1

 

Enjoy

Network adapter Index

A few years ago I wrote a post about setting the IP metric on a connection - https://richardspowershellblog.wordpress.com/2012/01/01/changing-ip-connection-metric/

 

I was recently asked if the Index’s associated with network adapters were consistent acros machines. The answer – unfortunately- is no they’re not as a rule.

 

I used the function from the original post

function Test-IPmetric {
    Get-WmiObject -Class Win32_NetworkAdapter -Filter "AdapterType = 'Ethernet 802.3'" |
    foreach {
        Get-WmiObject -Class Win32_NetworkAdapterConfiguration -Filter “Index=$($_.DeviceId)” |
        Select-Object Description, Index, IPEnabled, IPConnectionMetric
    }
}

to view the index

 

The Index property from Win32_NetworkAdapaterConfiguration is identical to the DeviceId from the Win32_NetworkAdapater class for a given network adapter.

 

if you try the function on a number of machines you’ll see that Index numbers assigned by Windows aren’t consistent.  My test VMs (Hyper-V) all seem to have the same index numbers assigned but I always create my VMs and add network adapters in the same way.

 

I wouldn’t rely on a particular index being assigned to a given network adapter – always pull the data and test

Really?

Been testing things for my container talk at the Summit and opened Internet Explorer on my Server 2012 R2 machine to be greeted by

 

“Microsoft recommends upgrading to Windows 10”

 

Forget Server 2016 guys all you need is Windows 10  Smile

PowerShell package management on PowerShell 3 and 4

PowerShell 5.0 introduced PackageManagement (Oneget) – for managing software installation packages and PowerShellGet for managing PowerShell modules.

 

Those features are now available on PowerShell 3 and 4

https://blogs.msdn.microsoft.com/powershell/2016/03/08/package-management-preview-march-2016-for-powershell-4-3-is-now-available/