Monthly Archives: February 2011

A Configuration Manager 2007 PXE Service Point causes the Windows Deployment Services Server service to crash and hang

 

Following KB Article has been released today as a FAST PUBLISH article.

http://support.microsoft.com/default.aspx?scid=kb;EN-US;2510665

 

Symptoms

When attempting PXE boots via a System Center Configuration Manager 2007 PXE Service Point, PXE boots will initially work and succeed but then all of a sudden stop working. Examining the server where the PXE Service Point and Windows Deployment Services (WDS) are installed reveals that the Windows Deployment Services Server service has crashed and is in a hung state. Attempting to restart the Windows Deployment Services Server service on the WDS server does not resolve the issue. Restarting both the Windows Management Instrumentation and the Windows Deployment Services Server services or restarting the server may temporarily resolve the problem, but the issue will eventually reoccur and WDS will eventually crash again.

Trying to reproduce the issue by continually attempting to PXE boot PCs reveals that although the issue may happen frequently, the issue cannot be reproduced on a consistent basis and that the crashes will happen randomly.

Examining the WDS server where the ConfigMgr 2007 PXE Service Point is installed reveals the following errors in Event Viewer:

System Event Log:
<Date> <Time> Error <WDS_Server> Service Control Manager N/A N/A The Windows Deployment Services Server service terminated unexpectedly. It has done this <x> time(s). The following corrective action will be taken in 120000 milliseconds: Restart the service.

Application Event Log:
<Date> <Time> Information <WDS_Server> WDSServer WDSServer N/A Provider WdsImgSrv was shutdown successfully.
<Date> <Time> Warning <WDS_Server> WDSServer WDSServer N/A An error occurred while trying to initialize provider WdsImgSrv from C:\Windows\system32\WdsImgSrv.dll. Since this provider is not marked as critical, Windows Deployment Services server will continue. Error Information: 0xC1030136
<Date> <Time> Error <WDS_Server> WDSIMGSRV WdsImgSrv N/A An error occurred while trying to initialize the Windows Deployment Services image server. Error Information: 0xC1030136

<Date> <Time> Error <WDS_Server> Application Error {100} N/A Faulting application svchost.exe_WDSServer, version 6 <version>, time stamp <hex_time_stamp>, faulting module ntdll.dll, version <version>, time stamp <hex_time_stamp>, exception code 0xc0000374, fault offset 0x000afaf8, process id <hex_process_id>, application start time <hex_time>

The following error may also be seen:

The Windows Deployment Services (WDS) Server service terminated with service-specific error 16389 (0x4005).

 

Cause

This issue can occur in environments where there are redundant backup routers in place. If IP Helpers for PXE (DHCP relays) are placed on both the primary and backup routers, this may cause a situation where two duplicate PXE request packets are sent to WDS: The original PXE request by the primary router and a duplicate PXE request by the backup redundant router. If the timing is just right, the duplicate second PXE request may overwrite some of the information in WDS from the first original PXE request. This will cause information in WDS for the PXE request to become corrupted and will cause WDS to crash.

 

Workarounds

There are two workarounds to this issue:

  1. Disable the PXE IP Helpers in the backup redundant router so that duplicate PXE requests are not sent. For more information on PXE IP Helpers, please see the below TechNet article:
    Configuring Your Router to Forward Broadcasts
    http://technet.microsoft.com/en-us/library/cc732351(WS.10).aspx#Updating
  2. Set the ConfigMgr 2007 WDS provider to be single threaded instead of multi-threaded. This will cause only one PXE request to be processed at a time by WDS and will prevent the second duplicate PXE request from conflicting with the first original PXE request. To set the ConfigMgr 2007 WDS provider to be single threaded, create the registry key NumberOfThreads with a DWORD value of 1 in the following location:
    32bit WDS server
    HKLM\Software\Microsoft\SMS\PXE

    64bit WDS server
    HKLM\Software\Wow6432Node\Microsoft\SMS\PXE
    This normally should not have a performance impact on the server for PXE requests except in environments where there is a large amount of PXE requests being performed on a constant basis. In environments such as this, it is recommended to use the first workaround.
Advertisements

Service Manager console language

 

When changing the default incident Tier Queues (Tier1, Tier2, Tier3) to a different name trough the console in English the other language “incident tier queue list item” wont update.

The issue is that users with a Console installed on a system installed with a non-English language will show the default settings. (ex: nld: laag 1 )

So I changed my practices to delete the primary Tier 1, Tier 2, Tier 3 list items and just create new ones for the custom Tier queues the customer requires.

But if you still want to change the Tier Queues in other languages you can edit the management pack file (XML) and update the language settings in the languagepacks section of the XML File. ‘ServiceManager.IncidentManagement.Configuration.xml’

You first need to export the XML file. Then edit the XML file and then reimport the management pack XML file.


Service manager Exchange connector

 

After reading all the documentation of the exchange connector I  received the message “connector finished with error. “

After diving into the logs I found the following exchange connector Event Logs.

 

Issue 1

AutodiscoverConfiguration: <Trace Tag=”AutodiscoverConfiguration” Tid=”17″ Time=”2011-02-03 09:18:16Z”> failed: WebException (The underlying connection was closed: An unexpected error occurred on a send.) </Trace>

Solution 1

http://social.technet.microsoft.com/Forums/en-US/systemcenterservicemanager/thread/9d28361c-5a90-462a-81fa-2931d656e604/#e602946b-4f05-41f3-9347-cc7460be36d9

The solution was to make sure I could access as as the workflow user the the following url’s without a certificate error or other errors

https://<urltomailserver>/autodiscover/autodiscover.xml

https://<urltomailserver>/ews/exchange.asmx

Which in my environment redirects to

https://<urltomailserver>/ews/services.wsdl

 

Issue 2

EwsResponseHttpHeaders: <Trace Tag=”EwsResponseHttpHeaders” Tid=”18″ Time=”2011-02-02 03:02:39Z”> 401 Unauthorized
Server: Microsoft-IIS/7.5
WWW-Authenticate: Negotiate,NTLM
X-Powered-By: ASP.NET
Date: Wed, 02 Feb 2011 03:02:39 GMT
Content-Length: 0 </Trace>

A Windows Workflow Foundation workflow failed during execution.

Workflow Type: Microsoft.SystemCenter.ExchangeConnector.ProcessEmailsWorkflow Workflow Identifier: 2f93ba28-875b-b0ab-cf37-26a3d42fa633
Exception Type: Microsoft.Exchange.WebServices.Data.ServiceRequestException Exception Message: The request failed. The remote server returned an error: (401) Unauthorized.
Exception Stack: at Microsoft.SystemCenter.ExchangeConnector.ExchangeInbox.
ProcessMail() at Microsoft.SystemCenter.
ExchangeConnector.ProcessEmailsWorkflow.Execute(ActivityExecutionContext executionContext) at System.Workflow.ComponentModel.ActivityExecutor`1.Execute(T activity, ActivityExecutionContext executionContext) at System.Workflow.ComponentModel.CompositeActivityExecutor`1.
Execute(T activity, ActivityExecutionContext executionContext) at System.Workflow.ComponentModel.ActivityExecutor`1.Execute(Activity activity, ActivityExecutionContext executionContext) at  System.Workflow.ComponentModel.ActivityExecutorOperation.
Run(IWorkflowCoreRuntimeworkflowCoreRuntime) at System.Workflow.Runtime.Scheduler.Run()

 

Solution 2

On the Exchange IIS server there was an issue with  the authentication methods. 

 image

 

To fix this issue I had to disable forms authentication from the main site.

This made disappear this error messages in the service manager log.