When crawling your local SharePoint site you may receive the following error message:
Access is denied. Check that the Default Content Access Account has access to this content, or add a crawl rule to crawl this content. (The item was deleted because it was either not found or the crawler was denied access to it.)
This can happen even if the account has the necessary permissions to crawl the site. This error is caused by what is know as the “loopback check”. The loopback check is basically a security “feature” which won’t allow a local IIS website to be accessed using a FQDN. This prevents an attack from pretending to be local thus bypassing certain restrictions.
Unfortunately, it also prevents your crawler from accessing local sites if they are using a FQDN.
Microsoft offers two workarounds here. You can either turn off this behaviour completely (not recommended) or you can exclude your site from this check. Here is method 2 from the above link:
HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\LanmanServer\Parameters
Value name: DisableStrictNameChecking
Data type: REG_DWORD
Radix: Decimal
Value: 1
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Lsa\MSV1_0
There is so much information about Exchange 2007 and certificate errors on the internet that it is sometimes difficult to wade through it all and find exactly what you are looking for.
I’m not going to repeat all of it here but I would like to give a quick summary of what I think solves most of the issues people are having when it comes to OWA, OAB and Autodiscover certificate errors, including the error “The name of the security certificate is invalid or does not match the name of the site”. There are obviously many ways to do this. I find this the easiest and most straight forward.
Basically, when you have a single CAS server (e.g. “server1.mydomain.local”) being accessed over IIS (for EAS, OWA, OAB etc.) using more than one URL (e.g. “owa.officialdomain.com”, autodiscover.officialdomain.com) you need a certificate which contains all of your URLs (a UC cert). To create this certificate use the Exchange Management Shell:
New-Exchangecertificate -domainname owa.officialdomain.com, autodiscover.officialdomain.com, server1.mydomain.local, server1 -Friendlyname owacert -generaterequest:$true -keysize 1024 -path c:\certrequest.txt -privatekeyexportable:$true -subjectname "DC=mydomain, DC=local, CN=server1.mydomain.local”
With this request, go to your MS CA (or some online CA) and request the certificate. Then import it using the Management Shell:
Import-Exchangecertificate -path c:\certnew.cer
The management shell will then display the thumbprint, which you will need for enabling the certificate:
Enable-exchangecertificate –services IIS –thumbprint AE8863602018F46A7E72DFA7A49D3484335EF98F
You should now have your certificate working with all URLs without the invalid name errors.
Obviously, the rest of your configuration will need to be correct, i.e. you will have to your clients trust either the certificate itself or the issuing CA.
Note:
If you have pre-Vista SP1 Windows clients (e.g. XP), Outlook will not be able to connect to the Outlook Anywhere address unless it is the CN of the cert subject
