I was working in my Hyper-V lab this morning trying to PXE boot a client VM into a ConfigMgr Task Sequence but somehow things had just stopped working, overnight. SMSPXE.log was showing me this;
[TSMESSAGING] AsyncCallback(): WINHTTP_CALLBACK_STATUS_SECURE_FAILURE Encountered [TSMESSAGING] : WINHTTP_CALLBACK_STATUS_FLAG_CERT_REV_FAILED is set sending with winhttp failed; 80072f8f Failed to get information for MP: https://CON-CM1.contoso.local. 80072f8f. PXE::DB_InitializeTransport failed; 0x80004005 Unspecified error (Error: 80004005; Source: Windows)
My MPControl.log had also, within minutes, gone from this (working);
>>> Selected Certificate [Thumbprint 37d4c9502df29c6780a456597b5088d569ceca6b] issued to 'CON-CM1.contoso.local' for HTTPS Client Authentication Call to HttpSendRequestSync succeeded for port 443 with status code 200, text: OK
to this (broken);
>>> Selected Certificate [Thumbprint 37d4c9502df29c6780a456597b5088d569ceca6b] issued to 'CON-CM1.contoso.local' for HTTPS Client Authentication Call to HttpSendRequestSync failed for port 443 with status code 403, text: Forbidden
So what happened here?
First things, I wanted to isolate if this was a problem with the Management Point component or the PKI setup – so I simply set the Management Point role to run as HTTP only. Within minutes I was seeing a working management point in the MPControl.log – so it was certificate related.
I looked on my Windows Server 2008 R2 Certificate Authority and there were no certificate revocations. Maybe the client certificate is a bit screwed up I thought – so I deleted the Client Authentication Certificate from the Personal Store on the Management Point and tried to request a new one from the CA but received a failure that the Certificate Revocation Server was unavailable. Weird. A quick visit back to the CA and I stopped and restarted the CA service and tried the request again from the MP and it went through fine.
I changed the Management Point back to HTTPS and again within a few minutes I was seeing a working Management Point again in the MPControl.log.
Just goes to show that it isn’t always (actually, it isn’t USUALLY) Configuration Manager that is to blame when things aren’t working correctly.