SharePoint Services

The application-specific permission settings do not grant Local Activation permission for the COM Server application with CLSID - MOSS / SharePoint 2007 Server Issues Revisited

Michael J. Hamilton, Sr. — Tue, 19 Dec 2006 11:47:00 GMT

You may see this error - more than once - when working with your Microsoft Office SharePoint Server (MOSS) 2007 deployment. This animal / error generally shows itself after you have applied an upgrade to an existing deployment. For example, when upgrading from B2 MOSS to B2TR MOSS - or when applying a special service pack from MSFT - you may begin to see a lot of these errors pop up in the SYSTEM event log.

The error CLSID is followed by a class ID for the DCOM+ application that the service account trying to activate that application - does NOT have permission to activate.

For example, let's say I installed MOSS on a server, and used the account mossService as the service account (a least privileged, user account you created to run the MOSS service(s))., when I get this error, I could very well see an error like the following:

The application-specific permission settings do not grant Local Activation permission for the COM Server application with CLSID

{61738644-F196-11D0-9953-00C04FD919C1}

to the user <serverName>\mossService SID (S-1-5-21-<serviceSID>). This security permission can be modified using the Component Services administrative tool.

Copy the GUID following the CLSID above, and Start-->Run-->regedit

With the registry editor open, ensure that your cursor is on the computer at the beginning of the tree (make sure you are not in the middle of some previous edit session in the registry editor).

Edit-->Find and paste in the GUID. It'll stop at the application entry - and you will want to note the application name on the right side pane. In this example, it was the IIS WAMREG admin service that popped up.

Now, open Component Services (typically, from the server - Start-->Administrative Tools-->Component Services), expand Component Services, Computers, My Computer, DCOM Config. Scroll down and find the application (IIS WAMREG in this case). Right-Click-->Properties and select the Security tab. You'll have some options here - the first block Launch and Activation Permissions - ensure that the Customize radio button is selected, and click Edit. Now, add your service account - giving it launch and activate - and in some requirements - remote launch / activate permission.

Restart IIS and continue on.

NOTE: This is not applicable to MOSS setups only - and hopefully this will help someone else that sees these annoying DCOM errors in their SYSTEM event log.

Regards...

A failure was encountered while launching the process serving application pool 'SharePoint Central Administration v3'. The application pool has been disabled. - SharePoint Server 2007 Setup

Michael J. Hamilton, Sr. — Tue, 19 Dec 2006 11:24:00 GMT

Just an FYI...

As you forge ahead into the world of MOSS and deploying / configuring MOSS sites with actual service accounts - you may very well run into this error. The PRIMARY cause of this error has to do with the service account. When you created the service account, you set a password for it. Did you document that with your client? If you did not, it is very possible that someone in IT at the client site will change it to something THEY know and want to manage. Alas, all things SharePoint begin to fail - at least for those application pools that were using the service account.

NOTE: Service account - a least privileged user account you created to run the MOSS Central Admin and varying AppPools.

HTH's...

WSS (Windows SharePoint Services), Session State, Trust Level and beyond...

Michael J. Hamilton, Sr. — Thu, 02 Mar 2006 22:54:00 GMT

I have a Windows 2003 Server notebook I use for development. I have a dozen or so IIS 6 sites, and recently decided to place WSS on here for use with BizTalk Server 2006.

Alas, the woes of WSS and hostile take-overs!!!

I installed WSS on the Default Web Site, added all of my exclude paths in WSS for the sites I needed to continue hosting/developing, and ran into the infamous “Trust” and “Session State” issues. In summary I made the following modifications to resolve these 2 issues:

</httpHandlers>

Notice I added the <clear/> and my own PageHandlerFactory, commenting out the SharePoint path.

Next I removed the comments on the name=”Session” handler a little lower in the file.

Finally, I changed the <trust level= from the WSS setting to “Full” Please see the following...

Best Practice? No, absolutely not. But this is a development notebook and I get the full benefits of WSS and can still do all of my other ASP.Net 1.1 and 2.0 development unhindered now.

Hopefully this will help some others out there...

Dot Net Haven and SharePoint Portal and Beyond...

Michael J. Hamilton, Sr. — Sat, 25 Feb 2006 07:25:00 GMT

A few months ago a few of us had an idea - what would be the ideal hosting and support site for .Net Developers? Dot Net Haven? Perhaps.

www.dotnethaven.net is currently active and growing quickly.

Initial features are hosting plans, FAQ's with the responses that only premier blogs like this one provide; a Help Desk Ticket system that provides some limited support for users.

Finally? If you are an authorized MSDN Licensee and get clearance, you have access to the SharePoint Portal sandbox that we're using as a learning and training ground. Here we provide extensive access to 2 different servers that provide extensive development opportunities for developers. Coming soon? BTS 06, Host Integration Server, and many more. Again however, you have to be an authorized and cleared MSDN subscriber.

But hey, check it out. You never know.

Local paths or mapped drives are not allowed in a farm, UNC notation is required

Michael J. Hamilton, Sr. — Fri, 09 Dec 2005 18:37:00 GMT

Local paths or mapped drives are not allowed in a farm, UNC notation is required

If you are trying to restore a SharePoint Portal backup and you see this error - and you, like me (big smile) - are new to SPS - then this will drive you nuts!!!

SharePoint does not backup/restore to / from physical drives / paths. You have to setup a share on the server and backup to and restore from a share.

For example, if I have a backup.xml manifest in the C:\SPSBackup folder, and I attempt to restore from this physical path, I receive the error above.

To resolve this, simply share that path on the server (or conversely, create a similar share on the portal you are trying to restore to), and then browse that share. (i.e. \\servername\SPSBackup\backup.xml) and that should resolve this problem for you.

The version in the manifest file does not correspond with the current version of SharePoint Portal Server

Michael J. Hamilton, Sr. — Fri, 09 Dec 2005 18:19:00 GMT

The version in the manifest file does not correspond with the current version of SharePoint Portal Server

If you are trying to restore a complete portal backup from one setup to another, you may receive this error. So, what version of SharePoint are you running? Regular SPS 03 deployment, or SP1 or 2 applied?

1. On the server, go to 'Add or Remove Programs'

2. For SPS and/or WSS, click 'Click Here for Support Information'. Note the version numbers below:

Standard Installation:

Windows SharePoint Service: 11.0.5608.0

SharePoint Portal Server: 11.0.5704.0

With Service Pack 1:

Windows SharePoint Service: 11.0.6361.0

SharePoint Portal Server: 11.0.6715.0

Ensure that the server you are restoring to is the same as the one you backed up. This is also covered in detail in the Microsoft Windows SharePoint Services from MS Press, by Jim Buyens - pp. 442-443.

Hopefully someone will find this helpful before struggling for hours to resolve it the hard way :)

"#50070: Unable to connect to the database STS_Config

Michael J. Hamilton, Sr. — Tue, 29 Nov 2005 15:57:00 GMT

"#50070: Unable to connect to the database STS_Config

This is similar to the message I received when bringing up 2 VPC's (Virtual PC's) - one is the AD/DC (Active Directory / Domain Controller) with SharePoint Portal Server 2003 on it, and the other is my SQL 2K server - a member server of this domain.

I had completed these server configurations on these VPC's, and did so with the network IP property settings setup to pull their IP addresses from our corporate LAN.

Now, I'm in a different location, pulling a different set of IP's - and voila! - my DNS Server is not quite sync'd.

If you research this problem online you find more references to the WMSDE database not being updated, or being corrupt, or basically references to your database configuration not being what it should be. Well, that's not far from the problem - or is it?

In my case I found 2 indicators that helped me resove the problem.

On the domain controller, and SPS server, the Application Event Log revealed a hoard of events that had this error - basically conveying that it could not connect to the database server.

On the member server and SQL Server at that, the System Event Log revealed something more subtle - a login was attempting to gain access to SQL Server, and the login could not be validated with any valid login server. MMMmmm This was interesting. For example, I'd see

This computer was not able to set up a secure session with a domain controller in domain <domainname> due to the following:

There are currently no logon servers available to service the logon request.

This may lead to authentication problems. Make sure that this computer is connected to the network. If the problem persists, please contact your domain administrator.

Reviewing the log further, I found a Kerberos error:

The kerberos subsystem encountered a PAC verification failure. This indicates that the PAC from the client <_serviceAccount> in realm <domainName> had a PAC which failed to verifiy or was modified. Contact your system administrator.

Now... We use _serviceAccounts for everything - SQL Server, SPS (SharePoint Portal Server), and so on. The root of the problem here? The DNS was cached on the domain controller. Even though I went into the DNS Server and reconfigured the Forwarding Zone, and even rebooted the DC, the DNS data was still cached - ON THE MEMBER SERVER. Ah, not so obvious.

If you build a VPC and member server VPC's, keep this in mind. It is best to hard code the network properties for TCP/IP on each server, and leave those settings. Yes, I already knew that a DNS Server is not supposed to draw an IP via DHCP - but it works, and when you're in a static development / test environment, it generally does not create a problem - like the one described here.

Hopefully another geek in need will find this useful.

You receive an "Application has generated an exception that cannot be handled" error message when you remove SharePoint Portal Server and Windows SharePoint Services from your server

Michael J. Hamilton, Sr. — Wed, 16 Nov 2005 17:19:00 GMT

You receive an "Application has generated an exception that cannot be handled" error message when you remove SharePoint Portal Server and Windows SharePoint Services from your server

November 16, 2005

During a routine setup of SPS 03 (SharePoint Portal Sever 2003) I ran into an issue that required me to uninstall the SPS instance.

During the uninstall, I received this error once, and on another occasion a different error (reported under a different posting).

This article addresses this issue from MS Support - http://support.microsoft.com/default.aspx?scid=kb;en-us;827755

However, things are not always as straight-forward as they seem.

For this issue, I did uninstall WSS first – hosing up the ability to uninstall SPS. However, the simple fix? Re-install WSS, then uninstall SPS before uninstalling WSS.

Finally, after each uninstall – restart the server in question.

NOTE: I did not have to perform the \%ProgramFile%\ file removal or Registry edits noted in the MS Support Article. The uninstall process did remove those data for me – it was failing because WSS was no longer installed.

Hope this is helpful…

The Configure Server Farm Account Settings page is not displayed, and the SharePoint Central Administration site is not configured correctly, when you run SharePoint Portal Server 2003 Setup

Michael J. Hamilton, Sr. — Wed, 16 Nov 2005 16:46:00 GMT

The Configure Server Farm Account Settings page is not displayed, and the SharePoint Central Administration site is not configured correctly, when you run SharePoint Portal Server 2003 Setup

November 16, 2005

PROBLEM

SharePoint Portal Server 2003 installs great – or does it? After a seemingly clean install, the SharePoint Central Administration page would not display.

There were no events in the System, Application, or Security Logs.

Under C:\Program Files\SharePoint Portal Server\Logs I found a SPS_xxxxx_SPSADM.LOG file with an entry that indicated that the service account ‘administrator’ would fail when it attempted to use it to start up the instance.

HISTORY

This setup was for a domain controller that was promoted, and SPS 03 would be running on this server.

The DBMS is SQL 2K w/SP3a running on a member server.

For SPS03 a service account was created; the service account was added to the DC’s Administrator’s local group, and the service account was added to SQL Server and given the roles Security Administrators and Database Creators.

RESOLUTION

During the installation, you are prompted for a user (service) account that will be used to execute SPS. During development or quick deployments to VPC’s (as was the case here) it is not uncommon to simply use the Administrator account for that server.

When the server executing SPS 03 is an AD DC (Active Directory domain controller) you MUST include the domain name (not the machine name) when providing the setup this name. For example, if I’m going to use the Administrator account, and I am running on a DC named development, then the actual entry would be development\administrator.

By entering only the admin. name, the application attempts to insert the machineName in there instead of the DC name – and the rest as they say, is history.

Hope this is helpful.