Determining the Site Template used on a SharePoint site

I just recently responded to a post in one the MSDN SharePoint forums where a user was asking how he could determine what templates where being used by his sites. I didn't really feel like having him look at the database, so I wrote a simple application page that exposes the WebTemplate and WebTemplateID properties of the SPWeb object. Here is what the code looks like:

<%@ Assembly Name="Microsoft.SharePoint, Version=12.0.0.0, Culture=neutral, PublicKeyToken=71e9bce111e9429c"%><%@ Page Language="C#" MasterPageFile="~/_layouts/application.master" Inherits="Microsoft.SharePoint.WebControls.LayoutsPageBase" %><%@ Import Namespace="Microsoft.SharePoint" %>

<%@ Assembly Name="Microsoft.SharePoint, Version=12.0.0.0, Culture=neutral, PublicKeyToken=71e9bce111e9429c"%> <%@ Page Language="C#" MasterPageFile="~/_layouts/application.master" Inherits="Microsoft.SharePoint.WebControls.LayoutsPageBase" %> <%@ Import Namespace="Microsoft.SharePoint" %>
<script runat="server"> protected override void OnLoad(EventArgs e){ SPSecurity.RunWithElevatedPrivileges(delegate() { SPWeb thisWeb = this.Web;
lblWebTempalte.Text = thisWeb.WebTemplate; lblWebTemplateID.Text = thisWeb.WebTemplateId.ToString(); }); } </script> <asp:Content ID="Main" runat="server" contentplaceholderid="PlaceHolderMain" > <p> Web Template: <asp:Label ID="lblWebTempalte" runat="server" /> </p> Web Template ID: <asp:Label ID="lblWebTemplateID" runat="server" /> </asp:Content>
<asp:Content ID="PageTitle" runat="server" contentplaceholderid="PlaceHolderPageTitle" > Site Template Information </asp:Content>
<asp:Content ID="PageTitleInTitleArea" runat="server" contentplaceholderid="PlaceHolderPageTitleInTitleArea" > Site Template Information </asp:Content>

Save the page to your layouts folder (usually c:\program files\common files\microsoft shared\web server extensions\12\template\layouts\). Once the page has been saved, you can access it from any of your SharePoint sites via http://yoursharepointsiteaddress/_layouts/pagename.aspx

Source : http://blog.rafelo.com/

Crawling SharePoint sites using the SPS3 protocol handler

When you setup your content sources in a Microsoft Office SharePoint Server (MOSS 2007), you have a few options to choose from: SharePoint Sites, Web Sites, File Shares, Exchange Public Folders and Business Data. When you use the SharePoint Sites option, you're instructing the indexer to crawl a WSS web front end and you will use sps3:// as the prefix for your start address. This tells the crawler to use a SharePoint-specific protocol handler to enumerate the content and then grab the actual items from the SharePoint server.

A common question here is whether this uses some sort of RPC call into the SharePoint Web Front End (WFE) server. The answer is "no". People asking the question are usually trying to configure the firewalls between a indexer and a MOSS WFE and need to know what TCP/IP ports they need to open. You should be fine with just HTTP (or HTTPS, if your portal requires that). The SPS3 protocol handler uses a web services call (using HTTP/SOAP) to enumerate the content and then uses regular HTTP GET requests to get to the actual items. Crawling using the SPS3 protocol handler requires no RPC calls or direct database access to the target farm. That's the main reason why this type of crawling is supported over WAN links and has a good tolerance to latency.
If you want to confirm this, configure two separate MOSS farms and have one crawl the other:
Configure a new content source using Central Administration, Shared Services, Search Settings, Content Sources, Add Content Source.

Specify SharePoint sites as the type and use SPS3://servername as the start address
Start a full crawl
If you have any network monitoring hardware or software, you will notice that one the first things the crawler will do is use the "Portal Crawl" web service at http://servername/_vti_bin/spscrawl.asmx. The methods in this web service are EnumerateBucket, EnumerateFolder, GetBucket, GetItem and GetSite. It is interesting to see how both "Enumerate" methods will basically return just an "ID" and a "LastModified" datetime, hinting at how SharePoint can do incremental content crawls via this protocol handler... If you just point your browser to that URL yourself, you can find the additional information about the web service, including sample SOAP calls and the WSDL (as you get with any .NET web service). At this point, I could not find much detail on this web service beyond the actual class definition for Microsoft.Office.Server.Search.Internal.Protocols.SPSCrawl.
Here a few pointers to documention that will help you understand the big picture:

There is an overview of this way content sources and protocol handlers work at http://technet2.microsoft.com/Office/en-us/library/f32cb02e-e396-46c5-a65a-e1b045152b6b1033.mspx

You can find some more detailed information and a nice diagram on what a protocol handler does at http://msdn2.microsoft.com/en-us/library/ms974315.aspx

There is also the description of the web services call used at http://msdn2.microsoft.com/en-us/library/ms583576.aspx

Source : http://blogs.technet.com/

Open and use a Web Part Maintenance Page

If you encounter problems with a Web Part or Web Part connection on your Web Part Page, you can use the Web Part Maintenance Page to help isolate and fix your problem. You must have the appropriate Web Part, Web Part Page, or Web Part zone permission to use the Web Part Maintenance Page.

Tip: If you are not sure which Web Part or Web Part connection is causing a problem on your Web Part Page, it is a good idea to work in a step-by-step fashion by closing one Web Part at a time and then browsing through the Web Part Page (click Go Back to My Web Part Page) to see if that fixes the problem. After you identify the problem Web Part, you can consider resetting or deleting it.

1. Open the document library that contains the Web Part Page.
2. Point to the name of the Web Part Page, click the arrow that appears, and then click Edit Properties.
3. Click Open Web Part Page in maintenance view to display the Web Part Maintenance Page.
4. Verify that you are in the view that you want, either a personal view or shared view. If you need to switch views, do one of the following:

• If you are in a personal view and you want to switch to a shared view, click Switch to shared view.
• If you are in a shared view and you want to switch to a personal view

5. Select one or more Web Parts, and then do one of the following:

• To move a Web Part to the Web Part Page gallery, click Close.
• To remove personal property values and revert to the shared property values of the Web Part, click Reset. You are prompted for confirmation before resetting a Web Part.
• To permanently delete a Web Part from the Web Part Page, click Delete. You are prompted for confirmation before deleting a Web Part.

It is possible to have permission to delete a Web Part in a shared view but not in a personal view.

6. When you finish, click Go Back to Web Part Page.

Tip: To access the Web Part Maintenance Page for a Web Part Page that is not stored in a document library, such as the site home page, append ?content=1 to the end of the URL for the page.

Note: You cannot use the Web Part Maintenance Page to close, reset, or delete a static Web Part (that is, a Web Part outside a Web Part zone). To maintain a static Web Part, you must use a Web design program that is compatible with Microsoft Windows SharePoint Services, such as Microsoft Office SharePoint Designer 2007.

How to change user accounts that run MOSS Services & App Pools

As part of implementing some improvements to a client's MOSS Enterprise site that I'd recently recommended they undertake, I had to change the accounts that were being used in their environments to ones that were independent from each environment. I've been caught too many times by a developer doing some development who manages to miss-key the AD User's password into a config file / registry key. The app being developed is then fired up and promptly locks the account out. At the same time, another unrelated system in another part of the building stops working. Why? Because the same AD Account was used in critical aspects of both systems.

Never Ever Use The Same Accounts to Run Your Development And Production Environments!!!

Anyway, they got me back to make this change because it can be tricky. Sure enough, it was. The biggest challenge when making wholesale changes to the service / app pool accounts is that if the farm account update fails to work properly, you then struggle to perform the rest of the changes because the security decryption keys MOSS uses to keep a track of passwords is corrupted. Oh man!
So I fired off the first change and waited... and waited... the WWW Publishing service failed to shut down properly, so after 20 minutes I figured I'd reboot the server and try it again (looking back, I may have saved some time by using pskill to terminate the process instead of rebooting, but it would have resulted in the same issue). Then in the event log, I started to see a proliferation of these error messages - "Error during encryption or decryption. System error code 997" and "An unhandled exception occurred in the user interface.Exception Information: Unable to connect to the remote server"
Once in this precarious position, Microsoft's recommended solution - for the closest example of something that comes close to the error message - is to rebuild the config database (http://support.microsoft.com/kb/927156) - but it's not much help onsite at a client's place... luckily there are some alternatives. Once the Farm account is half-changed, you cannot successfully change the rest of the accounts through the UI... but stsadm is the answer. Joel has the information on this page - http://blogs.msdn.com/joelo/archive/2006/08/22/712945.aspx
Just like using a sledgehammer to swat a fly, stsadm is not encumbered by a user interface or any of those nice-to-have things - it seems to be built around the premise "If it doesn't work, force it. If it breaks, it needed reinstalling anyway!" :)

So with stsadm, I went through the following steps:

First, to fix the central admin account's decryption key used to drive the app pools, complete the following on the server running the Admin site -
From the bin directory, run

Stsadm –o updatefarmcredentials –userlogin -password

You may need to then run iisreset /noforce.
You will have to remove the "Administration Application Pool Credential Deployment" job that gets created using the timer job definitions page (otherwise it will prevent you from progressing through the next steps).
Then to update the other moss site app pools -

Stsadm –o updateaccountpassword –userlogin -password

If you happen to use the same account to drive the admin site and the web site(s) (naughty) then you will need the noadmin switch eg

Stsadm –o updateaccountpassword –userlogin -password [-noadmin]

On each other server in the farm, you will need to perform the following steps -
As each server stores an encrypted version of the admin account password, you will also need to execute the following command for the account used to run the admin app pool -

stsadm –o updatefarmcredentials –userlogin -password -local

The Web site app pools for the non-admin sites should take care of themselves, but if not then just use the "UpdateAccountPassword" feature on the server to resolve the issue.

Then you will need to fix the SSP's...
From the server running the SSP you need to run the following command for each SSP that uses credentials to operate (like ECS and FS), except for the search services (they're next) -

stsadm -o editssp -title -ssplogin -ssppassword

You then run the following commands for the search services

stsadm -o osearch -farmserviceaccount -farmservicepassword
and...
stsadm -o spsearch -farmserviceaccount -farmservicepassword

You may now need to go into the search service section of the UI and change the indexing and crawling accounts if required.
Lastly, the SSO Service has to be changed using the Services Applet in the Administration Control section of the server it runs on.
At this point, an IISReset is probably a good idea (a reboot is an even better idea) - once this is done, attempt to access each affected area of the farm and verify that they are all now functioning correctly. If you still see some issues, use the relevant part of this guide to try and reset the credential information. Eventually (after 4 attempts) I moved past the first set of steps to change the Admin site app pool account - the rest was plain sailing from there.
Source: http://sharepointblog.spaces.live.com