502 usually results from an intermediate gateway/proxy unable to understand server’s response.

If however, you don't expect a gateway or proxy to sit between your client and server, this error may result from a misconfigured proxy settings on your client box.

To view, proxy settings, run the following on your client box:

    netsh winhttp show proxy

The problem should go away once you reset your client side proxy configuraiton

   netsh winhttp reset proxy

Operational channel is enabled by default. Analytic needs to be enabled

This will be the first in a series of posts about out-of-band management.  First, "out-of-band" basically means outside of the Operating System.  Specifically, a client is managing hardware irrespective of what OS is installed or if an OS is even installed/running.  This is possible because the hardware (typically called a Baseboard Management Controller (BMC)) implements some management protocol and in this case, we're using WS-Management. 

The scripts I have here are tested against Intel's vPro only because that happens to be what is in my office.  The same scripts (in theory) should work against any vendor implementation of WS-Management as long as the appropriate CIM Profiles are available.  I'll leave discussion about CIM Profiles for another post.  If you want to use these scripts, I assume the hardware you want to manage is already provisioned for remote management.  Also, to successfully execute these scripts, you need to enable unsigned script execution in Powershell, allow unencrypted traffic, and trust the management endpoint in the WinRM client configuration (you should only do these things in a test environment).

For this first entry, we'll focus on one aspect of the CIM Power State Management Profile specifically on changing the power state.  BMCs are typically low power devices that enable management of the main system.  They are capable of running just on standby power.  Some share the NIC with the main system, so you could have a computer system turned off (on standby) and plugged into the network and be able to remotely turn it back on.   

The first step is to get the current power state.  Here's the first of two Powershell scripts and I'll explain any interesting parts of it.

Param ([parameter(Mandatory=$true,Position=0)][string] $connectionUrl = "http://wsman-intelpc:16992/wsman",     [System.Management.Automation.PSCredential] $credential,     [string] $authentication = "Digest")

Since we are remoting to the hardware, we need some information.  First is the connectionUrl, this includes the transport (http or https), the computer address, the port, and the rest of the URL.  In this case, I've hardcoded the URL to the machine in my office and using the standard vPro port and URL.  Next, we need credentials as well as the authentication method.

$assocPowerMgmtSvc = Get-WSManInstance -ConnectionURI $connectionUrl -Authentication $authentication `         -Credential $credential -Enumerate -ResourceURI cimv2/CIM_AssociatedPowerManagementService             if ($assocPowerMgmtSvc -eq $null)     {         "The remote endpoint does not support the Power State Management Profile"         exit     }

If you follow the Use Cases defined in the CIM Power State Management Profile spec, you would first see if the management endpoint supports this particular profile by going to the Interop namespace and looking for the corresponding instance of CIM_RegisteredProfile.  Then find the associated CIM_AssociatedPowerManagementService instance and then validate its capabilities, and finally perform the management operation.  We'll shortcut some of this by attempting to get the CIM_AssociatedPowerManagementService directly.  If it exists, we'll try to read the current power state, if not, well then it's obviously not supported.

$powerStates = "Unknown", "Unknown", "On", "Sleep-Light", "Sleep-Deep",         "Power Cycle (Off-Soft)", "Off-Hard", "Hibernate (Off-Soft)", "Off-Soft",         "Power cycle (Off-Hard)", "Master Bus Reset", "Diagnostic Interrupt (NMI)",         "Off-Soft Graceful", "Off-Hard Graceful", "Master Bus Reset Graceful",         "Power Cycle off-Soft Graceful", "Power Cycle Off-Hard Graceful"         $assocPowerMgmtSvc.PowerState + ":" + $powerStates[$assocPowerMgmtSvc.PowerState]

The CIM class will just return an integer value (for localization reasons), so we'll hardcode the English values here so that we know a value of 2 means On and 8 means Off.  Pretty simple so far.  Changing the power state is a bit more complicated which we cover next and is in a seperate script.

$remoteParams = @{ConnectionURI=$connectionUrl;Authentication=$authentication;Credential=$credential}

I'm skipping defining the Powershell script parameters which are similar to Get with the addition of a PowerState parameter. Unlike reading the current state, setting it requires multiple network calls, so we'll store the commonly used paramters in a variable.

$powerprofile = Get-WSManInstance @remoteParams -Enumerate -ResourceURI `         cimv2/CIM_RegisteredProfile?__cimnamespace=interop |         Where-Object { $_.RegisteredName -eq "Power State Management" }         if ($powerprofile -eq $null)     {         "The remote endpoint does not support the Power State Management Profile"         exit     }

Here I show what it looks like to see if the managed node supports the Power State Management Profile.  One thing you'll notice is that I use Powershell to perform filtering on the client.  Intel vPro supports the WS-Management Selector filter, however, it only filters against Key properties and the RegisteredName property of CIM_RegisteredProfile is not a key.  To be completely proper, we are supposed to check the Capabilties to see if it supports the RequestPowerStateChange method, however, it's just easier to call it to determine whether it will work.

$comp = Get-WSManInstance @remoteParams -Enumerate -ResourceURI cimv2/CIM_ComputerSystem |         Where-Object { $_.Dedicated -ne 14 }     $ManagedSystemName = $comp.Name

Now that we know that this machine supports it, we need to find the right CIM_ComputerSystem that we want to turn on or off.  In the case of the BMC, you'll actually get two instances of CIM_ComputerSystem where one represents the BMC itself and the other the managed system.  CIM_ComputerSystem has a Dedicated property we can filter agains to determine which is which.  A value of 14 means the Management System, so we just look for the other one.  Since this isn't a key property, we perform the filtering on the client using Powershell.  We store the name of the managed system for later use.

$managedSystemEPR = Get-WSManInstance @remoteParams -Enumerate -ResourceURI cimv2/CIM_ComputerSystem `         -Dialect Selector -Filter "Name='$managedSystemName'" -ReturnType EPR

The CIM method we'll actually be using later to change the power state requires an EPR (EndPoint Reference) which is the path to an instance.  The WS-Management GET operation doesn't support returning a EPR (rather than the object itself), so we'll use a little trick here (otherwise we'd have to construct the XML ourselves).  Basically, I perform an enumeration, but using the Selector filter, I can just get the single instance I care about and have the EPR returned.

$powerMgmtSvcs = @(Get-WSManInstance @remoteParams -Enumerate -ResourceURI cimv2/* -Dialect Association `       -Filter "{Object=CIM_ComputerSystem?Name=$ManagedSystemName;ResultClassName=CIM_PowerManagementService}")

Next, we need to get the CIM_PowerManagementService that is associated with the instance of CIM_ComputerSystem we want to change the power state since the method belongs to this class.  We do this using the Association filter dialect providing the CIM_ComputerSystem instance resource URI and specifying the ResultClassName we want.

Invoke-WSManAction @remoteParams -ResourceUri cimv2/CIM_PowerManagementService -SelectorSet `         @{Name=$powerMgmtSvcs[0].Name;CreationClassName=$powerMgmtSvcs[0].CreationClassName} `         -Action RequestPowerStateChange -ValueSet `         @{PowerState=$powerState;ManagedElement=$($managedSystemEPR.InnerXml)}

Finally, we are ready to call the RequestPowerStateChange method.  We need to provide the path to the specific instance of CIM_PowerManagementService and I'm using the SelectorSet parameter to do this.  The method parameters is the new PowerState and ManagedElement is the instance of CIM_ComputerSystem we want to power on/off.

I'll have more scripts and scenarios in the future.  Note that I'll be on leave during April, so my next post will be either the end of this month or in May.

Steve Lee
Senior Test Manager
Standards Based Management

As you may know, WinRM and WMI are implementations of public standards -- WMI is our implementation of CIM, and WinRM is our implementation of the WS-Management protocol.  These are both published by the Distributed Management Task Force (DMTF), a consortium of 160 companies and organizations that develops and promotes standards for systems management.  You can read more about them at http://www.dmtf.org/about.

The world of standards development can b a strange and confusing one.  If you want to learn more about the DMTF, what they produce, and how they're organized, there's a great tutorial hosted by WBEM Solutions that explains it clearly: http://www.wbemsolutions.com/tutorials/DMTF.

Enjoy!

Nathan Burkhart

Program Manager  |  WS-Management

A common request that I get from customers is that they would like to use PowerShell to configure the BITS Upload Server extension on IIS. In the past, automating upload server configuration required the use of the Windows Scripting Host and the BITS ADSI extension (see http://msdn.microsoft.com/en-us/library/aa362825(v=VS.85).aspx ). It is also possible to do this using PowerShell and the same BITS ADSI extension.

First, let’s begin by installing the BITS Upload Server extension for IIS. We will need to import the Server Manager cmdlets and use the Add-WindowsFeature cmdlet to do this.

In order to enable or disable BITS uploads using the BITS ADSI extension; we will need to run PowerShell using Single-Threaded Apartment (STA).

Let’s start configuring a website to allow BITS uploads. To do this, we will need an ADSI object that represents the website’s configuration settings. In the following example, we get the configuration for an IIS directory called “Uploads” under the “Default Web Site”.

To enable BITS uploads on this directory; we can call the EnableBitsUploads method. (Note: The local path associated with this directory must allow write access to the built-in “IUSR” user. Otherwise, any BITS uploads to this directory will result in an access denied error.)

We call the RefreshCache method to synchronize the ADSI object with the latest configuration settings. We can then get a list of the configurable properties for this directory. The properties that affect the BITS upload server configuration are highlighted below. You can find out more about them at http://msdn.microsoft.com/en-us/library/aa362818(v=VS.85).aspx .

The current BITSMaximumUploadSize value is 18446744073709551615, which indicates that the default upload size limit is being used (on IIS 7.0 the default upload size limit is 30 million bytes). We can set this limit to a different value. After updating the value, we call the CommitChanges method so that the new configuration takes effect.

Finally, if we need to disable BITS uploads to the directory, we can call the DisableBitsUploads method.

Hope this helps!

Alex Ng

SDET – Windows Manageability

I found a blog which has a few helpful VBScripts to perform some common tasks.

http://blogs.msdn.com/alejacma/archive/tags/WMI/default.aspx

Hope this helps.

Aditya Patwardhan [MSFT]

This blog entry describes the reasons behind getting "Access Denied" on certain commands run on remote PS runspaces and ways to work around them. The category of commands include ones that authenticate to other services, try to access network resources and others that depend on the "impersonation" level of the security token.

The commands would otherwise work when run on locally.

A brief context of why this problem occurs : Powershell uses WSMan (or WinRM) to communicate to a remote endpoint. The default authentication that WinRM supoprts (Kerberos or Negotiate) ends up generating a "network" token on the server side that does not have authentication privileges. Powershell remote runspace and all associated commands run in the context of the "network" token.

 To support these scenarios, WinRM has added the support for CredSSP in version 2.0. CredSSP authentication results in server side token that is capable of doing authentication. Refer http://msdn.microsoft.com/en-us/library/ee309365(VS.85).aspx for more details

Here is an article that shows how to use Powershell to easily configure WSMan Limits.

http://blogs.msdn.com/powershell/archive/2010/05/03/configuring-wsman-limits.aspx

Hope this helps.

Aditya Patwardhan [MSFT]  

System Center Configuration Manager (SCCM) leverages BITS and BranchCache to download patches from a local distribution point and conserve WAN usage. Check out this blog post that provides an overview of how SCCM leverages this feature and how to enable it.

http://blogs.msdn.com/b/steverac/archive/2010/02/06/configuring-sccm-and-branch-cache.aspx

Alex Ng

SDET – Windows Manageability

Today, we released Windows PowerShell 2.0 and WinRM 2.0 for pre-Windows 7 operating systems on Windows Update. This non-security, optional update is designed for Windows Server 2008 SP2, Windows Vista SP2, Windows Server 2003 SP2, and Windows XP SP3.  Now it's even easier to install these great management tools!

Check out this post at the PowerShell blog for more details.

Enjoy!

Nathan Burkhart

Program Manager  |  WS-Management

Here's an oldie but a goodie. Heath Stewart provides example scripts on how to enable and disable ETW logging for the BITS service.

See http://blogs.msdn.com/b/heaths/archive/2008/07/07/bits-logging.aspx

First, let me apologize for the lack of posts to this blog.  Out original team goal was to have a new post every month, but holidays/vacations/work got in the way.  I’ll try to restart this rhythm.  For this first post of the New Year, I’m going to cover a more technical topic.

Most Windows administrators should already be aware that Powershell is the preferred ITPro scripting and command-line experience.  Many products from Microsoft and also third-parties expose their management interface as Powershell cmdlets.  Since Powershell is currently only available on Windows, how can you manage Windows from a non-Windows box?

Although Powershell remoting is built on top of WS-Management, it’s really a protocol within a protocol and trying to interop with PSRP (Powershell Remoting Protocol) directly would essentially require replicating Powershell on the client.  The alternative is to make use of a lesser known remote command-line tool called WinRS.  WinRS is a simple utility allows remote cmd.exe and is also built on top of WS-Management.  The difference is that WinRS reuses Create and Delete from WS-Transfer and introduces a few new custom SOAP web-methods.  For this blog post, I’ll be focusing on the WinRS “protocol” and won’t be discussing WS-Transfer, SOAP, nor HTTP in detail.  The complete details of the WinRS WS-Management Protocol extensions is documented here: http://msdn.microsoft.com/en-us/library/cc251526(v=PROT.10).aspx

WinRS has a relatively simple protocol, the workflow is:

1. WS-Transfer Create to create a shell, an EPR (End-Point Reference) to the created Shell is returned which is used for the next set of operations
2. Invoke the Command custom SOAP action to start a new command
3. Invoke the Receive custom SOAP action to receive output from the command (there is a corresponding Send for sending input, but it’s not needed for this scenario)
4. repeat step 3 until CommandState is Done
5. WS-Transfer Delete on the shell EPR

Let’s go through each step in a bit more detail.

For the WS-Transfer Create SOAP message, the body should contain the streams you want to send and receive.  The resource URI should be:  http://schemas.microsoft.com/wbem/wsman/1/windows/shell/cmd.  We are essentially creating a cmd.exe shell which we use to run powershell.exe.

If the request was successful, you’ll receive a standard WS-Transfer Create SOAP response which contains the newly created Shell EPR which resembles:

This EPR should be cached for all subsequent operations.  The first custom SOAP action Command uses the Action uri: http://schemas.microsoft.com/wbem/wsman/1/windows/shell/Command.  WinRS supports two console modes: interactive and batch.  For an interactive session, WinRS will wait for input (even if the command completes) until the client indicates there is no more.  For a batch session, WinRS will expect input to be sent only during the lifetime of the running command.  For this scenario, it is important to specify the WS-Management option WINRS_CONSOLEMODE_STDIN with a value of true which means to use batch mode.  The command-line is split into separate Command and Arguments.  The SOAP fragment would look like:

If this request was successful, the response will contain a CommandId element in the body that should be cached and used for subsequent operations for receiving the output.  Although the protocol was defined to allow one shell to host multiple commands, WinRS is limited to a single command per shell.  An example body of this response would resemble:

Once the Command response is received, the command is running on the server.  WinRS will block output (and therefore the command) once the maximum envelope size is reached.  The custom SOAP action Receive uses the action uri: .  Since the resulting output may exceed a single SOAP envelope, the client needs to specify an incrementing SequenceId in case any packets were lost. WinRS will only cache the last sent packet.  The request should contain the streams you want to read from and the CommandId associated to the stream in the body:

The response will contain the text output of the streams base64 encoded (to keep the SOAP xml well-formed and valid).  The client should check the state of the command to know whether to continue to invoke Receive for more output. 

Once the CommandState is “Done”, there is no more output and WS-Transfer Delete should be called on the shell EPR.  This will clean-up any resources being used on the server. 

The example code shows how to invoke a Powershell cmdlet.  It does not make use of any WinRM api’s, but instead creates the necessary SOAP messages from templates and uses System.Net.HttpWebRequest to send it over the wire.  To enable using the sample code in Windows, you’ll need to enable Basic authentication in the WinRM service config (which only works for local acocunts), you can run this Powershell command as admin: Set-Item WSMan:\localhost\Service\Auth\Basic $true.  You will need to deploy a server cert to use HTTPS or for testing purposes, set the WinRM service config to allow unencrypted HTTP.  Here's an example command line to use with the sample code:

WinRSPsh http://server:5985/wsman user password "get-service"

If you want the output in a application consumable form, you can convert to XML (.Net serialization):

WinRSPsh http://server:5985/wsman user password "(get-service ^| convertto-xml).OuterXml"

Note that in the above example, you have to escape the pipe so that cmd.exe doesn't try to interpret it.

Background Intelligent Transfer Service (BITS) has introduced a more granular control over the BITS bandwidth usage for background jobs, with a new set of group policies. Bandwidth limits can now be applied to the three BITS job priorities individually, hence providing a way of allocating more bandwidth to higher priority jobs.

A concept of time based schedules is presented, splitting the day into two schedules, namely, “Working Schedule” and “Non-Working Schedule”. These two schedules are complement of each other. Another schedule called the “Maintenance Schedule” is also supported. The bandwidth limits defined during Maintenance Schedule pre-empt Working and Non-Working schedule bandwidth limits. Within each time based schedule, bandwidth limits can individually assigned per job priority.

Highlights:

·         Priority based bandwidth control allows higher priority jobs to use more bandwidth, but still imposing a limit on it.

·         Time based schedules allow jobs to automatically switch their bandwidth usage when schedule changes, say from Working Schedule to Non-Working Schedule.

·         Bandwidth limits can be ignored for jobs, if the source and destination are on the same subnet, using a setting in the group policy.

·         Bandwidth limits can be set in kbps, mbps and unlimited units, per job priority level.

·         Schedules are defined as a continuous time slot; say Monday – Friday – 8 am to 5 pm.

These group policies are available under:

Local Computer Policy -> Administrative Templates -> Network -> Background Intelligent Transfer Service

Setting a bandwidth policy on Work Schedule:                                      

Setting a bandwidth policy on Maintenance schedule:

Hope this helps!

Aditya Patwardhan [MSFT]

Copying blog post from PowerShell blog

Windows Management Framework 3.0 CTP1 makes some updated management functionality available to be installed on Windows 7 SP1 & Windows Server 2008 R2 SP1. Windows Management Framework 3.0 contains Windows PowerShell 3.0, WMI & WinRM.

Windows PowerShell 3.0     
Some of the new features in Windows PowerShell 3.0 include:

• Workflows
  Workflows that run long-running activities (in sequence or in parallel) to perform complex, larger management tasks, such as multi-machine application provisioning. Using the Windows Workflow Foundation at the command line, Windows PowerShell workflows are repeatable, parallelizable, interruptible, and recoverable.
• Robust Sessions
  Robust sessions that automatically recover from network failures and interruptions and allow you to disconnect from the session, shut down the computer, and reconnect from a different computer without interrupting the task.
• Scheduled Jobs       
  Scheduled jobs that run regularly or in response to an event.
• Delegated Administration
  Commands that can be executed with a delegated set of credentials so users with limited permissions can run critical jobs
• Simplified Language Syntax       
  Simplified language syntax that make commands and scripts look a lot less like code and a lot more like natural language.
• Cmdlet Discovery
  Improved cmdlet discovery and automatic module loading that make it easier to find and run any of the cmdlets installed on your computer.
• Show-Command
  Show-Command, a cmdlet and ISE Add-On that helps users find the right cmdlet, view its parameters in a dialog box, and run it.

WMI
WMI in Windows Management Framework 3.0 CTP1 introduces:

• A new provider development model
  This new model brings down the cost of provider development and removes the dependency on COM.
• A new MI Client API to perform standard CIM operations.
  The API can be used to interact with any standard WsMan + CIMOM implementation, allowing management applications on Windows to manage non-Windows computers.
• The ability to write Windows PowerShell cmdlets in native code
  The new WMI Provider APIs supports an extended Windows PowerShell semantics API allowing you to provide rich Windows PowerShell semantics. e.g., Verbose, Error, Warning, WhatIf, Confirm, Progress      

WinRM     
With Windows Management Framework 3.0 CTP1:

• Connections are more robust
  Session disconnect and reconnect, with or without client session reconstruction, allows long-running tasks to continue even when the session in which they were started is closed and the client computer is shut down. This feature also allows administrators to reconnect from different computers to check the status of remote running tasks and get results.
• Connections are more resilient
  In Windows PowerShell 3.0 CTP1, connections can survive short-term network failures; the client-server connection is not severed at the first sign of trouble. If network problems persist, the client is safely disconnected and can reconnect by using the Connect-PSSession or Receive-PSSession cmdlets.

Windows PowerShell Web Service     
Windows PowerShell Web Service enables an administrator to expose a set of PowerShell cmdlets as a RESTful web endpoint accessible via the Open Data Protocol (OData). This provides remote access to invoke cmdlets from both Windows and non-Windows clients.

Prerequisites

Windows Management Framework 3.0 CTP1 can be installed on the following supported operating systems:

• Windows 7 with Service Pack 1
• Windows Server 2008 R2 with Service Pack 1

Windows PowerShell 3.0 requires version 4.0 of the common language runtime (CLR). CLR 4.0 is includes with the Microsoft .NET Framework version 4.0.

To install WMF 3.0 CTP1:

1. Download and extract the correct package for your architecture from the Microsoft Download Center
   1. For 64-bit systems, download WMF3-CTP1-x64.cab
   2. For 32-bit systems, download WMF3-CTP1-x86.cab
2. Extract the contents of the downloaded CAB file by typing: expand <<package name>> -F:* <<destination you want for extracted files>>
3. Close all Windows PowerShell 2.0 windows.
4. Run the WINDOWS6.1-KB2506143 MSU.

NOTES:

• You do not have to uninstall or remove any programs before installing the WMF 3.0 CTP1.
• This package requires Service Pack 1 (SP1) for Windows 7. If you receive a “This update does not apply” message when trying to install, verify that SP1 is installed.

To uninstall the WMF 3.0 CTP1:

Locate and uninstall the following installed Windows Update: KB2506143

Additional Information:

This software is a pre-release version. Features and behavior are likely to change before the final release.

This preview release is designed to enable the community to experience and review the preliminary designs and direction of key features Windows PowerShell 3.0 and to solicit feedback before features are finalized.

Travis Jones  
Windows PowerShell PM   
Microsoft Corporation

<Copied from http://blogs.msdn.com/b/powershell/archive/2011/12/02/windows-management-framework-3-0-community-technology-preview-ctp-2-available-for-download.aspx>

I’m pleased to announce that the Community Technology Preview #2 (CTP2) is available for download.

Windows Management Framework 3.0 CTP2 makes some updated management functionality available to be installed on Windows 7 SP1 & Windows Server 2008 R2 SP1. Windows Management Framework 3.0 contains Windows PowerShell 3.0, WMI & WinRM.

IMPORTANT: If you have WMF3.0 CTP1 installed, you must uninstall it before installing CTP2.

Overview of changes since WMF 3.0 CTP1
1. Customer Reported Bug Fixes
Many customer reported bugs have been fixed since the WMF 3.0 CTP1. The release notes contains a list of bug titles, but please check Connect for full details.

2. Single Command Pane in Windows PowerShell ISE
The Command and Output panes in Windows PowerShell ISE have been combined into a single Command pane that looks and behaves like the Windows PowerShell console.

3. Updatable Help
The WMF 3.0 CTP1 release notes described a new Updatable Help system in Windows PowerShell 3.0 and included a copy of the help content. The Updatable Help system is now active on the Internet. To download and update help files, type: Update-Help.

4. Windows PowerShell Workflows
A number of enhancements have been made in the scripting experience for Windows PowerShell Workflows, including new keywords: Parallel, Sequence & Inlinescript. A document describing these changes will be published to the download page shortly.

5. Remote Get-Module
The Get-Module cmdlet now supports implicit remoting. You can now use the new PSSession and CIMSession parameters of the Get-Module cmdlet to get the modules in any remote session or CIM session. A number of other module enhancements are listed in the release notes.

Feedback & Bugs
We welcome any feedback or bug submissions to the Windows PowerShell Connect site: http://connect.microsoft.com/PowerShell

Additional Information:
This software is a pre-release version. Features and behavior are likely to change before the final release.

This preview release is designed to enable the community to experience and review the preliminary designs and direction of key features Windows PowerShell 3.0 and to solicit feedback before features are finalized.

For an interesting post describing what to expect with a CTP, read this very old post from Jeffrey

Travis Jones [MSFT]
Program Manager – Windows PowerShell
Microsoft Corporation

Beta release of Windows Server “8" is now available for download..<drum beats and celebrations>

We are excited as WMI , WinRM and SMIS are at the heart of management capabilities highlighted by Bill Laing in his blog. We provide the 'Management Infrastructure' for Hyper-V, Storage, Networking and many other Windows components.. and WinRM is the transport for all remote automation in PowerShell.

Stay tuned for more exciting stuff on this blog and Windows Server Blog from server leadership team.

We look forward to recieve feedback from you on the investments we have done in Windows 8 and backward compatibility of existing features in WMI and WinRM.

Thanks

Team 'Standards Based Management'

IPMI (Intelligent Platform Management Interface) is a specification defined by Intel and adopted by a number of companies for standardizing hardware management, particularly in server systems.  IPMI supports both in-band (from the operating system) and out-of-band (from the network direct to hardware) management.  The protocol IPMI uses for out-of-band management is not based on WS-Management and not the focus of this blog post.

Available since Windows 2003 R2, Microsoft has developed a generic IPMI Driver and IPMI Provider in Windows to enable management of BMCs (Base board Management Controller) that implement IPMI.  The IPMI Driver (IPMIdrv.sys) is essentially a light-weight “pass-through” driver which takes IPMI requests and returns IPMI responses.  The IPMI Provider (IPMIprv.dll) takes the heavy load of converting between IPMI and CIM.

The IPMI Provider only exposes a subset of the capabilities exposed by IPMI.  However, because of the IPMI Driver “pass-through” design, you can take advantage of this and send custom IPMI requests.  You can even do this remotely over WS-Management (via the OS) and that’s what I’ll talk about today.

Even though the IPMI Driver runs in the kernel, it exposes a User Mode (meaning Applications can call it) interface as a WMI class (Microsoft_IPMI) in the Root/WMI namespace.  It implements a dynamic method (meaning you execute the method against the instance) called RequestResponse() that we’ll use to send IPMI commands.  You will need to be in the administrators group to be able to call this method successfully.

I’ve published a PowerShell module (written in PowerShell script) on TechNet that can be used as a sample.  One of the main helper functions is this:

function Invoke-IPMIRequestResponse {
    [CmdletBinding(DefaultParametersetName="CimSession")]
    Param (
        [Parameter(ParameterSetName="CimSession",Position=0)]
        [Microsoft.Management.Infrastructure.CimSession] $CimSession,
        [byte]$Command,
        [byte]$LUN = $DefaultLUN,
        [byte[]]$RequestData,
        [byte]$ResponderAddress = $BMCResponderAddress)

    Process {
        $ErrorActionPreference = "SilentlyContinue"

        if ($CimSession -eq $null) {
            $CimSession = New-CimSession
        }

        $ipmi = Get-CimInstance -Namespace root/wmi -CimSession $CimSession Microsoft_IPMI
        $ErrorActionPreference = "Stop"

        if ($null -eq $ipmi) {
            Write-Error "Microsoft IPMI Driver not running on specified system"
        }

        $arguments = @{Command=$Command;LUN=$LUN;NetworkFunction= `
	$(Get-NetFn $command);RequestData=$RequestData;RequestDataSize= `
	[uint32]$RequestData.Length;ResponderAddress=$ResponderAddress}

        $out = Invoke-CimMethod -InputObject $ipmi -CimSession $CimSession RequestResponse -Arguments $arguments
        if ($out.CompletionCode -ne 0) {
             Write-Error ("IPMI Command failed (0x{0:x}): {1}" -f $out.CompletionCode, `
             (Convert-CompletionCodeToText $out.CompletionCode)) 

        }
        $out.ResponseData
    }
} 

This function takes a CimSession which is a new type we introduced in the Windows Management Framework 3.0 that makes it easy to manage remote management operations as well as using the new CIM cmdlets.  If a CimSession is not provided, this function works against the local machine. 

An IPMI request (as defined in the IPMI specification) is essentially split into: Command, LUN, RequestData, and ResponderAddress.  For the most part, LUN (Logical Unit Number) is usually 0 and ResponderAddress is usually 32 (meaning the BMC itself responds).  Command is the operation (for example, Get LAN Configuration) and RequestData is a byte-array specific to that Command.  Additional required data such as NetworkFunction (basically the Command category) is computed automatically.  I’m not going to go into details about IPMI itself, but people familiar with IPMI should be able to easily see how to make use of this function.  Here is an example of using the PowerShell module:

So what would you do with this?  On server systems, the BMC is typically on a different NIC than the host system, so the BMC would have a different network identity than the host system.  Given two IP Addresses and even two MAC Addresses, you would not be able to correlate that this BMC manages this particular host.  Using IPMI (and this PowerShell module), you can query the IP address of the BMC from the OS and thus be able to correlate the two together.  It’s also possible to store information from the OS into the BMC.  The example above, I made use of the IPMI Set System Info Parameter Command to store the OS name into the BMC.  This means that management software that talks to the BMC remotely would be able to determine what OS is installed and/or running on that system.

If you are using IPMI capable hardware today (in-band or out-of-band), I would appreciate it if you let me know what scenarios are you are trying to enable or are currently exercising.  In a future post, I’ll discuss leveraging DASH and SMASH to perform operations similar to what IPMI exposes remotely, but makes use of CIM and WS-Management.

Steve Lee
Principal Test Manager
Standards Based Management Team

We are excited to introduce the investments we have made in Windows Server “8” through this excellent blog post Standards based management in Windows Server 8 by Jeffrey Snover and Wojtek Kozaczynski.

It’s a very detailed overview covering “Why Standards based management matters” and “What we have done in Windows “8” to take cloud-management to a new level”. It talks about following
investment areas providing an excellent E2E picture

-       Simplified WMI provider development using MI API.

-       Standard compliant protocol, ready for large-scale distributed management.

-       Client development using MI .NET Client API.

-       PowerShell cmdlets to manage CIM end-points (CIM Cmdlets).

-       PowerShell cmdlets written as a CIM Provider (CIM-Based Cmdlets).

-       Management OData IIS extension.

In the next few weeks, we will take you through a deep dive of each of these areas. So tighten your seat belts and get ready for take for takeoff – it is going to be an exciting journey.

-Team 'Standards Based Management'

The investments we’ve made in Windows Server 2012 (and WMF3.0) for standards based management is built around WS-Man as the remoting protocol (HTTP is the transport) and CIM as the model.  By themselves, WS-Man and CIM are useful, but may not provide a consistent experience when managing a similar class of devices or management domain.  What I mean by this is that the DMTF has provided a very rich set of schema, however, different OEMs may implement different classes, methods, or properties so although they implement the CIM Schema, a management client does not have consistency/predictability and must handle all possible situations.

Management Profiles are a solution to this problem.  Management profiles as defined by the DMTF:

“A Profile, which may be specified in documents published by the DMTF or in specifications created by other organizations, defines the CIM model and associated behavior for a particular management domain (including the CIM classes, associations, indications, methods and properties). This provides a unified way of describing the management domain in CIM, which contributes to interoperability and helps with ease of use.

Each profile identifies unambiguously the classes, properties, methods and values that should be instantiated and manipulated to represent and manage a given domain.” –DMTF Management Profiles

What this means is that Profiles provide normative text on how to implement CIM Schema for a specific management domain so that the management client can expect certain behaviors predictably as long as the managed node claims conformance to a specific Profile (or set of Profiles).  It should be noted that Profiles are not required to be published/standardized by the DMTF.  OEMs are allowed to make custom extensions and expose them through OEM specific Profiles.

One of the key Profiles that make this all work is the Profile Registration Profile.  This specific Profile describes how a managed node publishes the Profiles it has implemented so that the initial discovery is a well known workflow:

1. Discover the Interop namespace

2. Find the specific CIM_RegisteredProfile you are interested in primarily by filtering against the RegisteredName (ie, Boot Control) and RegisteredVersion (ie, 1.0.0)

3. Perform a association traversal (which may cross namespaces) to the central class of that Profile (ie, CIM_ComputerSystem) via CIM_ElementConformsToProfile association class

4. Start managing based on details in the specific Management Profile

The two key benefits you get from this:

1. OEMs must implement an Interop namespace (there’s 4 possible allowed variations)

2. By using the cross-namespace association traversal, the OEM can choose whatever namespace(s) it wants to use for their implementation and the management client is oblivious to this implementation detail.

To show how this all comes together, my next blog post (I’m targeting next week) will detail a new PowerShell module I wrote (also to be published next week) that uses this workflow along with implementing use cases defined in specific Profiles exposed as higher level admin task abstraction cmdlets for out-of-band hardware management.

Steve Lee [MSFT]
Principal Test Manager
Standards Based Management