PowerShell on Windows Embedded Standard 2009 – Part 2: Remote Device Management

PowerShell on Windows Embedded Standard 2009 – Part 2: Remote Device Management

  • Comments 2

Part one of this article focused on making PowerShell available on a Windows Embedded Standard 2009 device, whereas part two focuses on configuring a device for remote management and demonstrating some fun examples.

**Please note that information described in this article is for testing purpose only and is not officially supported by Microsoft.

Configuring a device for remote management

Although PowerShell V2 will make remote management much easier than PowerShell V1, it also requires additional features (e.g. WS-Management) to be installed on the managing host and may not be fully supported under Standard 2009 environment. We will focus on using PowerShell V1 for remote management, which can be accomplished using Windows Management Instrumentation (WMI) technology.

The remote device does not need to install PowerShell; however it needs to configure firewall exception for WMI and to enable remote launch of DCOM objects. Follow the steps below to configure.

  1. If Windows Firewall is enabled on the remote device, enable the Windows Firewall: Allow remote administration exception setting in Group Policy. Follow the steps below:
    1. Click Start, click Run, type gpedit.msc, and then click OK.
    2. Under Console Root, expand Computer Configuration, expand Administrative Templates, expand Network, expand Network Connections, expand Windows Firewall, and then click Domain Profile.
    3. Right-click Windows Firewall: Allow remote administration exception, and then click Properties.
    4. Click Enabled, and also enter the IP addresses or subnets for the managing host device (or enter ‘*’ to allow any network).
    5. Click OK.
  2. If the user who is making the remote request is not an administrator, make sure that the user has DCOM Remote Launch permissions on the remote device.
    1. Click Start, click Run, type DCOMCNFG, and then click OK.
    2. In the Component Services dialog box, expand Component Services, expand Computers, and then expand My Computer.
    3. On the toolbar, click the Configure My Computer button. The My Computer dialog box appears.
    4. In the My Computer dialog box, click the COM Security tab.
    5. Under Launch and Activate Permissions, click Edit Limits.
    6. In the Launch Permission dialog box, follow these steps if the user name or group does not appear in the Groups or user names list:
    7. a. In the Launch Permission dialog box, click Add.
    8. b. In the Select Users, Computers, or Groups dialog box, add the user name and group in the Enter the object names to select box, and then click OK.
    9. g. In the Launch Permission dialog box, select the user name and group in the Group or user names box. In the Allow column under Permissions for User, select Remote Launch, and then click OK.
  3. Reboot the device after making above changes

    Something Fun

    Once you have setup the two VPCs and configured firewall as well as DCOM service to allow remote management, you can now begin the fun part of using WMI commands and scripts to manage a remote device.

    To manually issue WMI commands, invoke the PowerShell command line console on the management host VPC. It is recommended you run PowerShell as an administrator as certain PowerShell cmdlets (e.g. set-executionpolicy) can only be issued under the administrator account.

    Issue WMI commands to get the system configuration of the remote device

    To get the system configuration of the remote device, issue the following WMI command within the PowerShell command line console.

    Get-wmiobject <wmi_obj> -credential <user> -computer <computer_name>

    Where <wmi_obj> specifies a particular WMI object (e.g. win32_bios), <user> specifies a user account in the remote device, and <computer_name> specifies the name or IP address of the remote device. For example:

    Get-wmiobject win32_bios -credential Administrator -computer WES_PS1

    After issuing the command, a dialog box will appear to prompt for the password for the user account. You must enter the correct password. If the command is executed successfully, the remote device will respond with information similar to below.

    SMBIOSBIOSVersion : 080002

    Manufacturer : American Megatrends Inc.

    Name : BIOS Date: 02/22/06 20:54:49 Ver: 08.00.02

    SerialNumber : 7104-9281-3085-7743-5902-9567-29

    Version : A M I - 2000622

    For scripting or automation purposes, the user might not be able to respond to the password prompt as part of the credential. To overcome this, the credential information can be stored in a variable first before starting a script. For example:

    $cred = get-credential Administrator

    Get-wmiobject win32_bios –credential $cred -computer WES_PS1

    With the $cred variable specified above, the user will be prompt for a password for the particular user account (i.e. Administrator). Once the credential information is stored in the variable, you can use it with other Powershell cmdlets or scripts.

    The example above is to get the BIOS information of the remote device. You can also specify other WMI object classes (e.g. win32_operatingsystem) to obtain other system or configuration information from the remote device. For a list of WMI classes, issue the cmdlet “get-wmiobject –list” in the PowerShell command line console.

    Run WMI Query language

    If you issue a command such as “Get-wmiobject win32_service”, you will get a long list of all the available services (or instances) in the machine you manage. Fortunately, Get-wmiobject cmdlet also lets you specify a WMI query (a SQL-like syntax) to filter on a specific property of the object. For example:

    Get-wmiobject –query “select * from win32_service where name=’WinRM’”

    The example above will only show the WinRM service.

    Reboot the remote device

    With WMI, you can also reboot the remote device provided you have the proper credential. Below is an example.

    $os = Get-WMIObject win32_operatingsystem -credential Administrator –computer WES_PS1

    $os.reboot()

    The above example first obtains the operating system information from the remote device using Get-WMIObject cmdlet and stores it in a WMI object, $os. Then, using the object, the reboot method is invoked and executed in the remote device.

    With PowerShell V2 CTP, rebooting a remote device becomes much easier. Only a single command is needed as follow.

    Restart-computer -credential <user> -computer <computer_name>

    As shown above, a new cmdlet (Restart-computer) is added to PowerShell V2 CTP to simplify the reboot process.

    Automation with Scripts

    Scripting is where the true power of PowerShell lies. With scripts, one can automate a series of powerful tasks including remotely managing the devices as some of the examples shown above.

    Executing scripts is disabled in PowerShell by default. To enable script execution, one needs to start PowerShell as an administrator (i.e. Right click on the application and select “Run as Administrator”). After PowerShell is started, one must set the execution policy to ‘unrestricted’ using the following command.

    Set-executionpolicy unrestricted

    The execution policy will remain unchanged once it is set even after closing PowerShell, so next time when the application is started again it is not necessary to set again.

    Additionally, a script is executed by providing its relative or full path instead of just the filename itself. If the path or filename contains a space, use quotation marks to enclose the whole path as a string.

    The following is an example script file that asks the user to enter the credential first, and then repetitively prompts the user to enter a computer name to get its BIOS information.

    $cred = get-credential Administrator

    do

    {

    $a = Read-Host "Please enter the computer name"

    if ($a -ne "")

    {$a + "`n" + "=========================="; Get-WMIObject Win32_BIOS -credential $cred -computername $a}

    }

    while ($a -ne "")

    The script is saved in a file named GetBiosInfo.ps1 under the folder C:\Windows-Powershell\Test-scripts. To execute the script in PowerShell, simply type the full or relative path name as follow.

    C:\Windows-Powershell\Test-scripts\GetBiosInfo.ps1

    Go Try It

    With the tips and tricks provided above, I strongly encourage you to go try out PowerShell with Standard 2009 devices. Then, please let the Windows Embedded Standard team know how you would use the tool and how you would like to see it make available for the Standard 2009 platform, for example, providing it as a componentized version or a macro component to install the desktop setup package.

    Summary

    PowerShell is the latest scripting tool released from Microsoft to enable users (or IT professionals) to manage computer systems and remote devices in a more simplified and powerful way. Although this tool is not currently available on Windows Embedded Standard 2009 as a componentized feature, one can easily install it on a Standard 2009 image for testing purposes by satisfying the dependencies as mentioned in this article. Once the tool is successfully installed on a management device, it becomes easy, powerful and fun to perform remote device management. Remote device management for PowerShell V1 can be accomplished via Windows Management Instrumentation (WMI); however, PowerShell V2 CTP makes this feature much simpler with the introduction of Windows Remote Management.

    - Thomas

    Technorati Tags: ,
    • To get this to work, I had to reboot the management host as well as the remote host after configuring firewall settings on the remote host. I cannot rationalize this except as some VPC/loopback adapter glitch?

      The error I was getting was "RPC Server is not available."

    • Nice post !

      But could you provide an example of how to manage the write filter on the remote device ?

      Thanks in advance.

    Page 1 of 1 (2 items)
    Leave a Comment
    • Please add 1 and 7 and type the answer here:
    • Post