Camper

export site fatal error a0e5a010-1329-49d4-9e09-f280cdbed37d for list template 10102 not installed

mdcamp00 — Wed, 01 Jul 2009 05:10:00 +0000

I was running into an issue when trying to run the stsadm export command on a site I wanted to move. The error I was getting was "FatalError: Feature 'a0e5a010-1329-49d4-9e09-f280cdbed37d' for list template '10102' is not installed in this farm. 10102 refers to the "List of user browser-enabled form templates on this site collection." The operation could not be completed." Some people get this because they don't have the InfoPath services feature installed. My issue was that we migrated our SharePoint site from a farm with enterprise services turned on to a farm without enterprise services, hence no feature. So, I couldn't activate the feature. I looked at the export log, and the error occurred right after the list "Converted Forms" but I couldn't find it in the site directory. I pulled up SharePoint Manager and browsed to my Site collection. In it I found the following:

What I was then able to do was grab the URL from the DefaultViewUrl and execute the stsadm command forcedeletelist.

If you have the same scenario you can just run: stsadm -o forcedeletelist -url http://%SITE_COLLECTION_URL%/IWConvertedForms to delete this list. You should be able to export your site afterwards.

Publishing Page – List does not exist error message

mdcamp00 — Tue, 28 Aug 2007 03:06:00 +0000

I ran into an issue today where users could not access as SharePoint 2007 Publishing Site Page. The error message was:List does not exist.

The page you selected contains a list that does not exist. It may have been deleted by another user. Troubleshoot issues with Windows SharePoint Services. I had no problem viewing my site and couldn't figure out what was wrong. I then looked at the URL for the page which was:
http://[sharepoint-site-URL]/_layouts/AccessDenied.aspx?Source=[SharePoint-site-URL]&Type=list&name=%7B2007BFAB%2D9CC4%2D41DA%2D8ED0%2D7E4C5BDAE90C%7D

The key here was the AccessDenied pages and the name query string value:
7B2007BFAB%2D9CC4%2D41DA%2D8ED0%2D7E4C5BDAE90C%7D

After decoding the html encoded characters out I got a GUID of:
{2007BFAB-9CC4-41DA-8ED0-7E4C5BDAE90C}If you look at the name, it is actually the id of `list item' that the user has been denied access from viewing. I then went to central administration to get the name of the content database of the site I was working on, and then went to SQL Server Management Studio and expanded my content database to dbo.AllLists.I ran a query against my content database for the list that users have been denied access to.select * from dbo.alllists
where tp_id='{2007BFAB-9CC4-41DA-8ED0-7E4C5BDAE90C}' I received one result with a tp_Title of `Master Page Gallery' That was all I needed. I then went to my page and looked at the template it was using. It was using a custom page layout I created. I proceeded to look at my Master Page Gallery and saw that the page layout it was using was never checked in and was in a `pending' status.

Not the best error message, but the lesson here is that users cannot access pages using page layouts that have never been checked it. Makes sense, but a more meaninful error message would have been nice. I've learned my lesson

Customizing People Search Core Results Display

mdcamp00 — Sat, 18 Aug 2007 01:06:00 +0000

Problems Denying Server Admins access to WSS 2.0 sites

mdcamp00 — Thu, 16 Aug 2007 11:16:00 +0000

I made a goof and just thought I would share it. I was FINALLY able to upgrade an older server with WSS 2.0 SP 2 in order to improve the security of WSS 2.0 sites and prevent server admins from being able to access all SharePoint sites using the denymachineadminaccess fix (http://support.microsoft.com/kb/892295).Unfortunately, as a server admin I was still able to access several sites that I shouldn't have had access to. I made sure that I was NOT a member of the “SharePoint administrative group account” configured through central admin, but I couldn't figure out why I still had access. I then went to central admin and clicked on the WSS link. I clicked on Manage Site Collection Owners and entered the URL for the site I shouldn't have had access to. Lo and behold I was a site owner for the site. So, I learned something new, or just something I forget. The lesson: Site owners have complete administrative access over an ENTIRE site collection, regardless of their permissions, or lack thereof.

So, even if you have installed WSS 2.0 SP2, and enabled denymachineadminaccess, if YOU are a site owner for a site, you will still have administrative privelages for the entire site collection.

MOSS 2007 Image Library AdRotator

mdcamp00 — Thu, 16 Aug 2007 11:15:00 +0000

MOSS 2007 People Search Issues

mdcamp00 — Fri, 13 Jul 2007 20:02:00 +0000

Issue:

Unable to search for People within MOSS 2007. Specifically, the People Scope within your SSP Search Settings shows 0 people after successfully importing User Profiles from your LDAP service. I finally resolved the people search issue I have encountered since I first installed SharePoint, so I have decided to document it for someone else that might have the same issue. The main issue was that I could not search for people from SharePoint sites, however, there were no issues in importing User Profiles as indicated by over 3000 user profiles in the User Profiles of my shared service. When I went into the Search Settings, and viewed the Scopes of my SSP, I realized that I had 0 People included in my People Scope. I found several posts where people deleted and recreated the People scope, but that didn't work for me. So, in an over simplification of what is going on, I tried to think about what SharePoint is doing:

Importing User Profiles into user profile database
Indexing the User Profiles to make them searchable

Okay, so it's not an issue with the import, so SharePoint isn't indexing the content properly; why?

Did I have a domain account that didn't have the correct permissions to the database where the user profiles were imported? (Big Disclaimer: My friend Milan Gross recommended looking at permissions as a likely culprit, and while I don't believe this was ultimately my issue, I would like to say that I have been diligent in following the SharePoint Administrator's Companion)
Did I configure something incorrectly?
Did SharePoint configure something incorrectly?
Is SharePoint broken?

The clue I found that pointed me in the right direction was in the crawl logs for the Local Office SharePoint Server sites under search settings. I found the following error message: sps3://servername:port#
Error in PortalCrawl Web Service A similar message was also in the windows application event log. This led me to a few posts online including this one by Sheetal Jain:http://office12.blogspot.com/2007/05/people-search-and-my-site-ssp.html While the post itself didn't solve me problem, it pointed me in the right direction, in that it mentioned the need to create a dummy site collection at the mysite root. As Sheetal put it, not having a site collection at the my site web application root caused a “stomach ache for SharePoint Indexer.” As a lessons learned, here are a few things I tried to modify based on different threads I found; none of which worked. After I made each setting change I re-imported all profiles, and performed a full crawl on Local Office SharePoint Server sites.

Modified “sps3://servername:port#/” in Shared Services Administration: Shared Services > Search Settings > Content Sources > Edit Content Source of Local Office SharePoint Server Sites to “sps3://servername:port#/mysite”.
Create Site Collection on the MySite web application root “/” managed path as a MySite Host under the Enterprise Tab of the Site Collecction Templates.

This seems to be what Sheetal was referring to, but I seemed to have an issue with it in that I got a permission error when creating a site collection on the root of the web application. After the error I could not repeat the step of creating a My Site Host site collection on the root. I even went to delete the site collection on the root, but it wasn't in the site collection list to delete, and the only kind of site collection SharePoint would let me create now was a site collection under the sites or personal managed paths. Oy!

Delete the MySite “mysite” managed path. This did nothing, as expected, but was a last resort.
Undid step 1.
Changed MySite Personal Site Services provider location in SSP. a. I changed it from http://servername:port#/mysite/ to http://servername:port#/, as “mysite” is the Relative URL I entered when I created the SSP.

After none of these steps worked I started creating new Shared Service Providers, just to see what would happen. I haven't played with SharePoint 2007 Administration too much and I was still a little reluctant to create a bunch of SSPs. DON'T BE! It is super easy to create them change web site associations, and delete them. It was almost fun . When creating my first alternate SSP I left everything as the default setting, imported the user profiles, crawled the Local sites, and poof, User Profiles were indexed. I figured there was probably a permissions issue when I initially configured SharePoint, so I deleted the MySite under the new SSP and moved all the web applications from the old SSP to the new SSP, and poof, my indexed profiles were gone! Hm. What is happening? Several more SSPs later I narrowed it down to one setting, that appears to be throwing something off on SSP creation, which is the relative URL for the My Sites. Every time I created a SSP with a relative URL for the MySite web application the Indexer was not able to index the User Profiles. I was then unable to figure out what settings needed to be changed to get it to start working again.

So, it appears that ultimately I had the same problem as Sheetal where the SharePoint indexer is not able to index the imported User Profiles because it is not able to access sps3://servername:port#, however, I resolved it is very different.

Resolution:

1. I created a Brand new SSP

2. As always, I created a separate Web Application for the SSP Web Application and the My Site Location.

3. I left the Relative URL BLANK!

4. I made the new SSP the default SSP.

5. I moved all my existing Web Applications to the new SSP EXCEPT the old SSP Administration site host and the old MySite web application, as I could not resolve the issues with the old MySite web application.

This worked well for me because I was still testing a SharePoint installation and there were only two personal sites created; mine and one other user's. This is probably not the best solution for someone that has already implemented SharePoint across an enterprise.

If anyone else knows of a better or simpler solution, I would love to know about it!

As this is my first MOSS 2007 Blog post, I can't wait to look back on it a year from now and laugh at my MOSS naivety.