July 9 2010

SCCM clients not installing in native mode

I had set my SCCM 2007 R2 environment (using native mode) up for automatic client push but noticed that none of my clients have the SCCM agent installed after a few days. The log contained at c:windowsccmsetupccmsetup.log on the client showed that the installation was failing and the error messages included:

WINHTTP_CALLBACK_STATUS_FLAG_CERT_CN_INVALID is set
Failed to send HTTP request. (Error at WinHttpSendRequest: 12175)

This indicates that the computer name that the client is using to contact the management point doesn’t match the FQDN in the Web Server certificate Subject, which is installed on the server and configured in IIS.

The solution was to request (from the enterprise certificate authority) and assign a new certificate in IIS. Using IIS 7.5, open the IIS manager console, click on the server name, double-click Server Certificates and then Create Domain Certificate. Fill in the details and select your enterprise EA server. It is important here to use the FQDN of the server in the Common Name section. Once complete, head to the Default Web Site, edit Bindings and click on edit for https, then select your newly issued certificate. You don’t need to restart IIS. Initiate a new client install – it should be successful this time.

November 4 2009

Office Communicator error – Cannot synchronize address book

We’d rolled out Office Communicator 2007 R2 across the environment, however a handful of machines were getting the ‘Cannot synchronize address book’ error and when expanded the entire error message was ‘Cannot synchronize with the corporate address book. This may be because the proxy server setting in your web browser does not allow access to the address book.’

So after doing some extensive Googling, I did some troubleshooting and found that the situtation was:

– There was no issue with the proxy server. I could manually enter the name of one of the address book files (eg https://ocs.domain.com/Abs/Ext/F-0918.lsabs) and download it manually through the browser.

– There is no GalContacts.db file in the ‘C:Documents and Settings%UserName%Local SettingsApplication DataMicrosoftCommunicator’ folder meaning that there was no locally cached copy of the address book.

– In the registry under ‘HKCUSOFTWAREMICROSOFTWINDOWSCURRENTVERSIONINTERNET SETTINGS’ if I set the CertificateRevocation DWORD and to 0, I can successfully sign in and retrieve the address book (below)

Registry setting
Registry setting

This pointed to an issue with the certificate we were using and specifically the Certificate Revocation List (CRL). From here we need to check the certificate we were using for OCS, look at the details tab and check the CRL Distribution Point (shown below)

Check Certificate
Check Certificate

I then checked this distribution point (a HTTP location in our case) and found out that it was invalid. Right, so next it was off to reconfigure our internal Certificate Authority server with the correct CRL locations.

On the Certificate Authority, we open up the MMC snap-in, right click the server name and select properties. On the extension tab, select ‘CRL Distibution Point’. You then want to configure some valid location underneath here and tick the box to ensure these are being included in the issued certificates. For example in my case, I ensured that there were 3 additional entries (not including the C:Windows one):

LDAP:///CN=<CATruncatedName><CRLNameSuffix>,CN=<ServerShortName>,CN=CDP,CN=Public Key Services,CN=Services,<ConfigurationContainer><CDPObjectClass>
[TICK] Publish CRLs to this location
[UNTICK] Include in all CRLs…….Active Directory…..
[UNTICK] Include in CRLs….Delta CRL Locations…..
[TICK] Include in the CDP extension of issued certificates
[TICK] Publish Delta CRLs to this location

file://\<ServerDNSName>/CertEnroll/<CaName><CRLNameSuffix><DeltaCRLAllowed>.crl
[TICK] Publish CRLs to this location
[GREYED OUT] Include in all CRLs…….Active Directory…..
[UNTICK] Include in CRLs….Delta CRL Locations…..
[TICK] Include in the CDP extension of issued certificates
[UNTICK] Publish Delta CRLs to this location

http://<ServerDNSName>/CertEnroll/<CAName><CRLNameSuffix><DeltaCRLAllowed>.crl
[GREYED OUT] Publish CRLs to this location
[GREYED OUT] Include in all CRLs…….Active Directory…..
[UNTICK] Include in CRLs….Delta CRL Locations…..
[TICK] Include in the CDP extension of issued certificates
[GREYED OUT] Publish Delta CRLs to this location

Selecting OK will then restart the Certificate Services service. Then you need to recreate your OCS certificates via the OCS MMC certificate wizard. Once these have been applied to the OCS server (OCS services do NOT need to be restarted), you clients just need to sign out and back in and all of your address book issues are fixed!

If you look at your new certificate, the newly added CRL Distribution Points should be listed. You can also use the ‘Certutil.exe –v –verify –urlfetch c:exported_certificate.cer’ with above certificate and check that CRL locations can be reached successfully. The ‘pkiview.msc’ tools from the Windows 2003 Resource Kit was also very useful in checking that the CRL locations could be reached.