Share iT…

I have written before here about this and mentioned to change the search account, but as now known this will create problems installing updates like SharePoint 3 Service Pack 2.

So changing the accounts is no solution because it creates new problems. Additional information about this problem is found here.

Browsing above problem I found another possible sollution for solving the Event ID:
2436 Windows SharePoint Services 3 Search

The start address cannot be crawled.
Context: Application ‘Search inde file on the search server’, Catalog ‘Search’
Details:
Access is denied. Verify that either the Default Content Access Account has access to this repository, or add a crawl rule to crawl this repository. If the repository being crawled is a SharePoint repository, verify that the account you are using has “Full Read” permissions on the SharePoint Web Application being crawled. (0×80041205)

1. Click Start, click Run, type regedit, and then click OK.
2. In Registry Editor, locate and then click the following registry key:
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Lsa\MSV1_0
3. Right-click MSV1_0, point to New, and then click Multi-String Value.
4. Type BackConnectionHostNames, and then press ENTER.
5. Right-click BackConnectionHostNames, and then click Modify.
6. In the Value data box, type the URL mentioned in the above warning event, and then click OK. (With URL is meant only the remote.domain.com part.)
7. Quit Registry Editor, and then restart the IIS service.

Source: the Official SBS Blog

Update:
It seems that changing the search accounts, creates a problem with installing SharePoint updates like SP2. So before changing the search accounts read this article!

After installing a ssl certificate on a SBS 2008 server you get 2 different SharePoint Services 3 Search event errors.

Event ID: 2424
The update cannot be started because the content sources cannot be accessed. Fix the errors and try the update again

Event ID: 2436
The start address cannot be crawled.
Context: Application ‘Search inde file on the search server’, Catalog ‘Search’
Details:
Access is denied. Verify that either the Default Content Access Account has access to this repository, or add a crawl rule to crawl this repository. If the repository being crawled is a SharePoint repository, verify that the account you are using has “Full Read” permissions on the SharePoint Web Application being crawled. (0x80041205)

Solution: Got this solution from my brother, thanx for that:

First we have to create 2 service accounts: SPSearch and SPContent

1. On your SBS, open Active Directory Users & Computers (Start –> Administrative Tools –> Active Directory Users & Computers.
2. Within ADU&C, navigate to the Organizational Unit where you want to create the new user accounts.
3. Right-click on the OU and select New –> User
4. On the first page of the new user window, enter the following info:
   o First Name: SPSearch
   o Last Name:
   o Username: spsearch
5. Click Next.
6. Enter a strong password for the new account.
7. Uncheck the option “User must change password at next login”
8. Check the option “User cannot change password”
9. Check the option “Password never expires”
10. Click Next
11. Click Finish.
12. Repeat steps 3-11, using “SPContent” instead of “SPSearch” in step 4

We do not have to worry about granting any access or permissions to the two new accounts we created.
After the accounts have been created, close Active Directory Users & Computers, then open SharePoint Central Administration (Start –> Administrative Tools –> SharePoint 3.0 Central Administration).

1. When SharePoint 3.0 Central Administration opens, go to the Operations tab.
2. Click on the “Services on Server” link
3. In the Action column, click the link to Stop the “Windows SharePoint Services Search” service.
   o You will receive a warning that stopping the search service will remove existing indices. Click OK to acknowledge the warning.
4. When you return to the SharePoint Central Administration Operations tab, the Windows SharePoint Search Service will show as stopped. Click the link to Start the Windows SharePoint Services Search service. This will open the Search service configuration page.
5. In the Service Account section, select the “Configurable” option
   o. For a username, enter \SPSearch (where is your AD domain).
   o. For a password, enter the strong password you assigned to the SPSearch account.

1. In the Content Access Account section, select the “Configurable” option
   o. For a username, enter \SPContent (where is your AD domain)
   o. For a password, enter the strong password you assigned to the SPContent account.
2. In the Search Database section, change the database name by appending and underscore 1 (“_1”) to the database name.
   o By default, the database name should be WSS_Search_[SERVERNAME], so we’re changing it to WSS_Search_[SERVERNAME]_1.
   o Changing the name is necessary because the default database name already exists with search data. If we attempted to use the default database name, SharePoint would throw an error that the database contains user-defined schema and cannot be used. By changing the search database name on this configuration page, SharePoint Central Administration will create a new database using this name and configure search to use this new database. Since the new database is empty, we won’t encounter any errors.

1. Accept the remaining defaults and click the OK button.

After clicking OK, the settings should be applied and you should return to the “Services on Server” page in SharePoint Central Administration, and the Windows SharePoint Services Search” service should be listed as started.

Close SharePoint Central Administration and open the Services MMC (Start –> Administrative Tools –> Services). Restart the Windows SharePoint Services Search service. Verify that the Windows SharePoint Services Search service is configured to login with the SPSearch account you created.

And as last we have to create the following registry key:
[HKLM\System\CurrentControlSet\Control\Lsa] “DisableLoopbackCheck”=dword:00000001

On the Exchange 2010 with the Hub Transport role installed you get several EventID 12014 errors on the MSExchangeTransport source.
“Microsoft Exchange could not find a certificate that contains the domain name mail.domain.com in the personal store on the local computer. Therefore, it is unable to support the STARTTLS SMTP verb for the connector “your send or receive Connector” with a FQDN parameter of mail.domain.com. If the connector’s FQDN is not specified, the computer’s FQDN is used. Verify the connector configuration and the installed certificates to make sure that there is a certificate with a domain name for that FQDN. If this certificate exists, run Enable-ExchangeCertificate -Services SMTP to make sure that the Microsoft Exchange Transport service has access to the certificate key.”

Solution: This error will occur when the FQDN you have entered in the send or receive connector doesn’t match with the FQDN names used at your exchange certificates.

You can change the FQDN at the connector to a name available on you certificate or install a new certificate with the right FQDN name.
It can also be that the SMTP service is not bind to the right certificate, in this case you can bind the SMTP service to the certificate using this FQDN.