>

Event ID 10016, DistributedCOM: The application-specific permission settings do not grant Local Activation permission for the COM Server application (2)

I have posted about this issue before, this was about this CLSID {61738644-F196-11D0-9953-00C04FD919C1}, click here to read.

Beside that error, probably after a recent update I have seen this similar error:

The machine-default permission settings do not grant Local Activation permission for the COM Server application with CLSID
{000C101C-0000-0000-C000-000000000046}
and APPID
{000C101C-0000-0000-C000-000000000046}
to the user domain\spfarm SID (S-1-5-21-1813126608-4190571182-3204100927-3160) from address LocalHost (Using LRPC). This security permission can be modified using the Component Services administrative tool.

The big difference with the other error is when you go to the Dcom config, security the option are all greyed out. So you need to do some additional steps:

Open registry editor (run regedit.exe), browse to Hkey_classes_root\AppID\{000C101C-0000-0000-C000-000000000046} right click and choose permissions.

Choose Advanced

Go to the Owner tab, select the Administrators (Domain\Administrators) group under Change owner to and select the replace owner on subcontainers and objects. Choose OK to close the window. You will return to the permissions window.

Select Administrators (Domain\Administrators) and set Allow Full Control permissions.

After you have done the above settings you go to Administrative Tools – Component Services. Expand Component Services, Computers, My Computer, DCOM Config. Scroll way down till you find the {000C101C-0000-0000-C000-000000000046} icon, right click and choose properties.

Go to the security tab, select customize at Launch and Activation Permissions and choose Edit…

Select the SharePoint Farm Account and set the Local Activation right.

Posted in Blog, SBS 2011 at July 25th, 2011. 21 Comments.

SharePoint Services 3 Search event errors and update problems

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

Posted in Blog, SBS 2008 at December 15th, 2010. 1 Comment.

SharePoint Services 3 Search event errors after applying certificate on a SBS2008 server

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

Posted in Blog, SBS 2008 at October 26th, 2010. 2 Comments.

Errors trying to move Windows SharePoint Services Data on SBS 2008

When you try to move Windows SharePoint Services Data via the Windows Small Business Server (SBS) 2008 server console, Backup and Server Storage on the tab Server Storage. You get this error: “An error occurred while attempting to move the Windows SharePoint Services data.” The remote server returned an error: (401) Unauthorized.

SharePoint Services Data move error

Solution: This error can occure after installing Microsoft Knowledge Base update kb957097. Read the article or this kb926642 carefully there are some methods to change a registry key witch give a solution. After changing the registry you have to restart your SBS 2008 server before the change take effect.

After restarting the server again tried to move Windows SharePoint Services Data the following error occurred: “An error occurred while attempting to move the Windows SharePoint Services data.” The remote name could not be resolved: ‘companyweb’

SharePoint Services data move error

Solution: In DNS Manager create a cname record “companyweb” in your Forward Lookup Zone Domain.local and point this to servername.domain.local. (don’t forget the . dot at the end)

Posted in Blog, SBS 2008 at July 21st, 2010. 3 Comments.

Sharing Buttons by Linksku