Today I want to blog about an odd behavior you might see if you do remote administration of an Internet Information Server (IIS) from a Windows Server 2008 R2 or later OS.
Let’s say that you have a script or a tool that allows you to remotely manage IIS, and this tool is based on .NET Framework. You might notice that despite it works as expected, every time you execute it the following error is reported in your system events log:
Event ID: 10028
Task Category: None
DCOM was unable to communicate with the computer XXXXXX using any of the configured protocols; requested by PID NNNNN
In such case, you can safely ignore this event! Let see why it is logged and why you can ignore it.
The error is caused by an internal DCOM call in Microsoft.Web.Administration, a .NET DLL that is used to connect and manage an IIS instance. It is not a fatal error and does not have any impact on the functionality but unfortunately there is no way for the caller process to prevent this error entry.
For example, the following simple code works as expected but produce our DCOM 10028 error:
If you enable the auditing policy you can see that this code produces a logon failure event even though it eventually succeeds:
# A security context was deleted before the context was
# completed. This is considered a logon failure.
A debug session will show you that the error appears as soon as it calls ServerManager.OpenRemote().
The OpenRemote method needs to create the following COM object in order to be able to manage IIS:
As first attempt, it tries to create the object via CoCreateInstanceEx() specifying the RPC_C_IMP_LEVEL_DELEGATE flag, but this call can succed only if the remote computer object is trusted for delegation. The caller (Microsoft.Web.Administation library) knows that the creation with the delegation flag might fail therefore is able to catch the failure and recover! In case of failure it simply calls again CoCreateInstanceEx but without the delegation flag. This latter call eventually completes successfully.
The DCOM error you see is logged by the COM+ runtime when the first call to CoCreateInstanceEx fails.
To recap, a logon failure happens internally in Microsoft.Web.Administration, therefore any tool that uses this DLL might log the DCOM 10028 error event. The failure is expected in some scenario and is internally catched and managed. Because the tool connects successfully despite the error message, you can safely ignore this event (or you can enable “Unconstrained Kerberos delegation” for the target IIS computer object).