vBulletin statistics
July 2010 - Posts - Windows Server 2008 (R2) blog by Kurt Roggen [BE]

July 2010 - Posts

PowerShell 2.0 brings some great new management functionality such as:

  • Remoting: lets you run commands on one or more remote computers from a single computer that is running Windows PowerShell. PowerShell remoting allows for multiple ways of connecting, including interactive (1:1), fan-out (1:many) and fan-in (many:1 by using the IIS hosting model).
  • New cmdlets: over 100 built-in cmdlets, enabling you to do computer-related tasks, event log and performance counter management task.

PowerShell version 2.0 is bundled into the Windows Management Framework.

The Windows Management Framework makes some updated management functionality of Windows 7 and Windows Server 2008 R2 available to be installed on Windows XP, Windows Server 2003, Windows Vista, and Windows Server 2008.

Windows Management Framework contains 3 components:

  • Windows Remote Management (WinRM) 2.0
  • Windows PowerShell 2.0
  • Background Intelligent Transfer Service (BITS) 4.0.

Using WSUS (part of Windows Server 2008 R2 as a server role), you can import the PowerShell 2.0 package and approve it for installation on your Windows Server 2008, Windows Server 2003, Windows Vista and Windows XP machines.

image
Import updates directly into WSUS

image
Add selected updates to download basket

Once the updates are imported into the WSUS infrastructure, you can approve the update on the required computer groups containing your targeted machines.

image 
Approve the imported updates

NOTE: Be aware that the Windows Management Framework is about 30-35 MB in size.  If bandwidth is an issue or if you are dealing with a serious amount of clients, you may want to throttle the bandwidth used by the Background Intelligent Transfer Service (BITS) which is used as transport mechanism by the Windows Update engine.

More about that another time…

Related reading:

To be able to troubleshoot the Windows Deployment Services, it is crucial to first understand the overall WDS architecture, since you can activate logging at most levels in the architecture.  We did that in previous post.

The second step, is drilling down into these components and their logging/debugging facilities.

Looking at WDS Configuration

To get a quick overview of your current WDS configuration, type the following command:

C:\> wdsutil /get-server /show:config

For more information, read my previous blog post.

 

Looking at WDS Eventlogs

If the multicast transmission still start automatically too soon, I suggest enabling logging for WDS Events:

1. Open Server Manager
2. Select Diagnostics -> Event Viewer -> Applications and Services Logs
3. Navigate to Microsoft\Deployment-Services-Diagnostics
4. Right-click the Admin log and choose Enable log
5. Right-click the Operational log and choose Enable log

Reproduce the issue and check the event logs.

image_thumb2

 

Looking at WDS Logging

  • WDS Server-side - %windir%\Tracing\wdsserver.log – Set REG_DWORD EnableFileTracing = 1
  • WDS Mgmt - %windir%\Tracing\wdsmgmt.log
  • WDS MMC snapin - %windir%\Tracing\wdsmmc.log
  • Client-side - X:\Windows\Panther, $Windows.~BT\Sources\Panther, %systemdrive%\Windows\Panther

image_thumb3

 

Related reading:

The other day, I got asked about WDS (Windows Deployment Services) troubleshooting…
To be able to troubleshoot the Windows Deployment Services, it is crucial to first understand the overall WDS architecture, since you can activate logging at most levels in the architecture.

Understanding the WDS Architecture

image

WDS Server Service
The WDSServer service is the main server-side service for Windows Deployment Services. It provides basic service functions such as memory management, thread pooling, and network interface binding in an effort to support its hosted subcomponents, known as providers. The providers provide the true functionality associated with WDSServer. There are five providers included with the default (Deployment Server) installation:

  • PXE provider
  • PXE server
  • Image server
  • Multicast server
  • TFTP server

WDS PXE Server
The Pre-Boot Execution Environment (PXE) server is used by Windows Deployment Services to provide network boot programs to client computers. PXE technology is a standard created by Intel that establishes a common and consistent set of pre-boot services within the boot firmware. The end goal is to enable a client to perform a network boot and receive a network boot program (NBP) from a network boot server.

WDS PXE Provider
The Pre-Boot Execution Environment (PXE) provider for Windows Deployment Services provides client boot services over the network. It registers itself with the WDSServer service (the main server-side service of the Windows Deployment Services solution) and requests a remote procedure call (RPC) endpoint.

PXE technology is a standard created by Intel that establishes a common and consistent set of pre-boot services within the boot firmware. The end goal is to enable a client to perform a network boot and receive a network boot program (NBP) from a network boot server.

WDS Image Server
The Windows Deployment Services image server stores and maintains the installation and boot images. The image server is the module used by the Windows Deployment Services client when it is communicating with the server. The server registers a remote procedure call (RPC) endpoint for communication between the client and the server.

WDS Multicast Server
The multicast server deploys an image to a large number of client computers concurrently without overburdening the network. When you create a multicast transmission for an image, the data is sent over the network only once, which can drastically reduce the network bandwidth that is used.

WDS Multicast Content Provider
The multicast server uses a content provider to transmit the data from the server to the client. The Windows Deployment Services content provider can transfer any file over a multicast transmission. This content provider connects the multicast transmission or namespace to the data that has been requested by clients.

WDS TFTP Server
You use the Windows Deployment Services Trivial File Transfer Protocol (TFTP) server to download the files that are needed to do a network boot using the Pre-Boot Execution Environment (PXE). PXE technology is a standard created by Intel that establishes a common and consistent set of pre-boot services within the boot firmware. The end goal is to enable a client to do a network boot and receive a network boot program (NBP) from a network boot server.

The TFTP server downloads boot files such as Pxeboot.com, Wdsnbp.com, Bootmgr.exe, and Default.bcd, as well as the boot image that contains Windows Preinstallation Environment (Windows PE).


Related reading:

MVP

I’m proud to announce and pleased to see that Microsoft has recognized all my contributions made in the past, by awarding me with the MVP title in Management Infrastructurefor the 3rd year in a row.

In the end, nothing really changes… I will keep doing what I have been doing so far: sharing knowledge and information. 

Hope you enjoy it, too!!
Kurt

I've been using PowerShell for a while now but it still hasn't replaced the command prompt for me yet, even though it is extremely powerful!!  I have been using the Command Prompt From Here a lot to make it easier to open up a command prompt at a specific folder location from the Explorer.  So now I added some settings to the registry that will do the same but with PowerShell instead.

image

Here is the registry file for making the entry in Explorer:

Windows Registry Editor Version 5.00

[HKEY_CLASSES_ROOT\Directory\shell\PowerShell]
@="Open PowerShell window here"

[HKEY_CLASSES_ROOT\Directory\shell\PowerShell\Command]
@="\"C:\\Windows\\System32\\WindowsPowerShell\\v1.0\\powershell.exe\" -NoExit -Command [Environment]::CurrentDirectory=(Set-Location -LiteralPath:'%L' -PassThru).ProviderPath\""

Related reading:

When doing a P2V (Physical To Virtual) by moving a workload from the physical world into the virtual world, you actually don’t want those specific IHV’s network, storage and other drivers/services starting up at next boot time, because it will cause a long delay to fail all these drivers/services.  They no longer make sense in your virtual environment, where synthetic or legacy drivers take over…

There are tools out there, that assist you in removing these drivers and services (once you are on the other side) such as the HP Proliant Support Pack Cleaner tool.

But know that when doing a P2V with SCVMM, there is this undocumented manifest (BlockList.xml) that disables Services and/or Drivers during the P2V process.

On the SCVMM server, in the following location C:\Program Files\Microsoft System Center Virtual Machine Manager 2008 R2\VMMData, you can find BlockList.xml.
In this file, you can list all services and drivers to disable in a virtual machine during the P2V process.
The syntax of this file is simple and uses the short name for services and drivers.

However editing this file is not supported by Microsoft…

<?xml version="1.0" encoding="utf-8" ?>
<BlockList> 
   <!-- services to disable –>
   <Service>
      <Name> </Name>
   </Service>
   <!-- drivers to disable –>
   <Driver>
      <Name> </Name>
   </Driver> 
   <!-- programs to disable –>
   <Program>
      <Name> </Name>
   </Program>
</BlockList>

When dealing with HP hardware, you may want to exclude following drivers, services and programs:

For use with HP hardware/software

Driver(s) Service(s) Program(s)
CpqArray
CpqArry2
CpqAsm2
CpqCiDrv
CpqCISSE
HpCISSs2
CpqCISSM
CpqTeamMP
SysMgmt
q57w2k
N1000
CpqNicMgmt
CpqRcmc
CpqVCagent
CqMgHost
CqMgServ
CqMgStor
CpqWebMgmt
SysDown
SysMgmtHP
CPQTeam


For use with Dell hardware/software

Still in progress


For use with IBM hardware/software

Still in progress

As you seen I’m still in the process of completing the lists for both Dell and IBM hardware, so fee free to sent me your feedback on drivers and services to disable.

Anyhow, it would definitely avoid messing around with the CLI using sc.exe

sc [\\server] query type= driver
sc [\\server] query type= service

sc [\\server] config start= disabled

 

Related reading:

To get a quick overview of your current WDS configuration, use the WDS CLI and type the following command:

C:\> wdsutil /get-server /show:config [/server:yourRemoteServer]

image_thumb12 

To get a more detailed overview of your current WDS configuration, type the following command:

C:\> wdsutil /get-server /show:all /detailed

Here’s a quick output of such a configuration listing:

C:/> WDSUTIL /get-Server /server:SEA-WDS /show:Config

Windows Deployment Services Management Utility [Version 6.0.6001.18000]
Copyright (C) Microsoft Corporation. All rights reserved.

SETUP INFORMATION FOR SERVER BXL-WDS
[-----------------------------------------------------------------------------]

Server State:
     OS version: 6.0
     WDS operational mode: Native

Installation State:
     REMINST location: W:\Images
     REMINST share up-to-date: Yes
     Boot files installed:
         x86  - Yes
         x64  - No
         ia64 - No

[-----------------------------------------------------------------------------]

CONFIGURATION INFORMATION FOR SERVER BXL-WDS
[-----------------------------------------------------------------------------]

Server Authorization:
     Authorization state: Not Authorized

Answer Policy:
     Answer clients: Yes
     Answer only known clients: No
     Response delay: 0 seconds

Directory Services Use Policy:
     Preferred DC: 
     Preferred GC: 
     Prestage devices using MAC: No
     New machine naming policy: %61Username%#
     Domain search order: Global Catalog Only
     New machines join domain: Yes

New Machine OU:
     OU type: Server Domain
     OU: CN=Computers,DC=contoso,DC=com

DHCP Configuration:
     DHCP service status: Not Installed
     DHCP option 60 configured: <Not Applicable>

Pxe Bind Policy:
     Use DHCP ports: Yes
     Rogue detection: Disabled
     RPC port: 5040

Interface Bind Policy:
     Policy: Exclude Registered
     Registered interfaces:

Boot Program Policy:
     Allow N12 for new clients: No
     Architecture discovery: Enabled
     Reset boot program: No
     Default boot programs:
         x86  - boot\x86\pxeboot.com
         x64  - boot\x64\pxeboot.com
         ia64 - boot\ia64\bootmgfw.efi
     Default N12 boot programs:
         x86  - boot\x86\pxeboot.n12
         x64  - boot\x64\pxeboot.n12
         ia64 - boot\ia64\bootmgfw.efi

Banned GUIDs List:

Boot Image Policy:
     Default image type for x64 clients: Both
     Default boot images:
         x86  - 
         x64  - 
         ia64 -

WDS Client Policy:
     Logging policy:
         Enabled: No
         Logging level: Info

     Unattend policy:
         Enabled: No
         Command-line precedence: No
         WDS unattend files:
             x86  - 
             x64  - 
             ia64 -

OSChooser Policy:
     Menu name:

Server Auto-Refresh Policy:
     Refresh period: 900 seconds

BCD Refresh Policy:
     Enabled: No
     Refresh period: 60 minutes

Auto-Add Policy:
     Policy: Disabled
     Poll interval: 10 seconds
     Max retry count: 2160 times
     Message: 
     Retention period:
         Approved devices: 30 days
         Other devices: 1 days
     Defaults for x86:
         Referral server: 
         Boot program path: 
         WDS client unattend file path: 
         Boot image path: 
         User: Domain Admins
         Join rights: Full
         Join domain: Yes
     Defaults for x64:
         Referral server: 
         Boot program path: 
         WDS client unattend file path: 
         Boot image path: 
         User: Domain Admins
         Join rights: Full
         Join domain: Yes
     Defaults for ia64:
         Referral server: 
         Boot program path: 
         WDS client unattend file path: 
         Boot image path: 
         User: Domain Admins
         Join rights: Full
         Join domain: Yes

WDS PXE Providers:
     Name: BINLSVC
     Path: C:\Windows\system32\binlsvc.dll
     Order: 1
     Critical: Yes

WDS Transport Server Policy:
     IPv4 Source: Range
         Start IP: 239.0.0.1
         End IP: 239.0.0.254
     Start Port: 64001
     End Port: 65000
     Network Profile: 100Mbps

[-----------------------------------------------------------------------------]

The command completed successfully.

There is a little known Server Selection feature in Windows Deployment Services in Windows Server 2008 R2.
Its not documented and it's not supported by Microsoft, but it can be very useful for lab and test scenarios...

How to enable it?  Simply go to HKLM\SYSTEM\CurrentControlSet\Services\WDSServer\Providers\WDSPXE\Providers\BINLSVC and set AllowServerSelection to 1.

After restarting the Windows Deployment Service, you get the server selection option by pressing F11 and the PXE client will now discover all PXE Servers which have this registry key set and allow you to select which one you want to use.

Initial PXE Boot Screen

PXE/WDS discovery process