« Posts tagged sms

SCCM WSUS Configuration Manager Could Not Establish Trust Relationship for the SSL/TLS secure channel

May 4, 2011 / posted in Infrastructure / No Comments

I have two SCCM SUP points, one is the top and the other is downstream. The SCCM infrastructure is operating in Native Mode and all WSUS synchronizations and configurations happen over HTTPS.

The internal SUP (SKN01) is the site server and has a site system in the DMZ (DMZ01) which it uses as a SUP for external IBCM clients. I had a look at the system status a couple of days ago only to see the SMS_WSUS_CONFIGURATION_MANAGER component had gone critical with this message all over the place:

SMS_WSUS_CONFIGURATION_MANAGER Message ID: 6600

WSUS Configuration Manager failed to configure upstream server settings on WSUS Server "Internal".   
Possible cause: WSUS Server version 3.0 SP1 and above is not installed or cannot be contacted. 
Solution: Verify that the WSUS Server version 3.0 SP1 or greater is installed. Verify that the IIS ports configured in SMS are same as those configured on the WSUS IIS website.

I looked at WCM.log to see exactly which server it is failing to configure. To reproduce the error I started and stopped the SMS_WSUS_CONFIGURATION_MANAGER component using the ConfigMgr Service Manager tool.

WCM.log showed the initial connection to the primary SKN01 SUP as successful with a fairly odd .NET exception following:

System.Net.WebException: The underlying connection was closed: Could not establish trust relationship for the SSL/TLS secure channel. --->
System.Security.Authentication.AuthenticationException: The remote certificate is invalid according to the validation procedure.~~  
         at System.Net.Security.SslState.StartSendAuthResetSignal(ProtocolToken message, AsyncProtocolRequest asyncRequest, Exception exception)~~  
         at System.Net.Security.SslState.CheckCompletionBeforeNextReceive(ProtocolToken message, AsyncProtocolRequest asyncRequest)~~  
         at System.Net.Security.SslState.StartSendBlob(Byte[] incoming, Int32 count, AsyncProtocolRequest asyncRequest)~~   at
...

Basically, this meant that whatever WSUS server the primary was attempting to connect to (it wasn’t exactly specific…) was failing to negociate SSL and aborting. FYI, I used ProcMon.exe to figure out which WSUS server it was connecting to during the failure. It turns out it was DMZ01

This was odd because WSUS synchronization and configuration had worked for a while and seemingly overnight the certificate became invalid? Not likely. I checked the machine certificates and their trust chain and it all seemed in order on both servers.

I remembered that recently I was troubleshooting an issue with the Management Point and I had removed the Intranet FQDN from the site system in the DMZ (the IBCM SUP server, DMZ01).

It turns out all I had to do was enter the Intranet FQDN in the DMZ site system’s properties (DMZ01) and all was well. If you’re still experiencing issues after entering the FQDN, remove the SUP from the DMZ site and re-add it.

Who knew that removing this FQDN would cause the WSUS configuration to fail. I guess the internal SUP uses the supplied internal FQDN by the DMZ site system to validate the web server certificate supplied by WSUS.

So yeah.. make sure you configure both the Intranet and Internet FQDNs in the DMZ site system’s properties. Make sure they match the web server certificate’s SAN (Subject Alternative Name).

BUG: Task Sequence editor fails to find the MDT Toolkit package if parent group is disabled

April 19, 2011 / posted in Infrastructure, Operating System Deployment / No Comments

I’ve recently encountered an issue with an MDT integrated System Center Configuration Manager 2007 SP2 R3 installation. In a non-MDT task sequence, if you disable the parent group of the Use Toolkit Package step, the SCCM task sequence editor reports an error in locating the package:

SCCM Task Sequence MDT Package Not Found Error (BUG)

SCCM Task Sequence MDT Package Not Found Error (BUG)

You can re-select the package from your list and the (X) goes away until you click Apply or re-open the TS editor.

Workaround: If you disable the ‘Use Toolkit Package’ step itself, the package is found and there is no error reported by the editor:

SCCM Task Sequence MDT Package Not Found Error (Workaround)

SCCM Task Sequence MDT Package Not Found Error (Workaround)

This is not exactly a blocker and there is a quick and dirty workaround but may prove tedious on more complex task sequences.

I’ve experienced this issue on two separate System Center Configuration Manager 2007 SP2 R3 installations, both MDT 2010 Update1 integrated:

  • Windows Server 2008 x86
  • Windows Server 2008 R2 x64

Hope this helps…

SMS Trace64 and Trace32 for WinPE

September 10, 2010 / posted in Infrastructure, Operating System Deployment / No Comments

SMS Trace is a great tool for troubleshooting deployment issues from within WinPE, no doubt about that. It makes errors and warnings clearly visible in thousands of lines of markup logs.

Trace64 has been removed from the MDT Healthcare package, because “it is a System Center tool” and they don’t have permission to release it (See Dan’s blog).

Adding Trace32 and Trace64 to your winpe.wim is easy:

imagex /mountrw c:\winpe_x86.wim 1 c:\mount
copy /y c:\sms_trace\trace32.exe c:\mount\windows\
imagex /unmount /commit c:\mount

imagex /mountrw c:\winpe_x64.wim 1 c:\mount
copy /y c:\sms_trace\trace64.exe c:\mount\windows\
imagex /unmount /commit c:\mount

You should also create a package that copies these files to the %SystemRoot%. If your task sequence fails outside of WinPE you won’t have access to SMS Trace.

Remember to update your Distribution Points before creating the ISOs.

Download SMS Trace32 and Trace64