SharePoint Tip of the Month - Closing, Deleting, and Restoring a Web Part

Closing, Deleting and Restoring Web Parts
This month’s SharePoint tip will show users how to manage SharePoint web parts on their site by closing, deleting or restoring them. Below you will find out the difference between these three actions and when it is appropriate to use them.

Closing a Web Part:

When a user temporarily wants to remove a web part from their site, they can simply close them. A web part can be closed by clicking the x button in the top right corner. This will remove the web part from the page; however, it will not delete it. The web part is still loaded on the page, just merely not displayed. This feature comes in handy when and if the user chooses to use the web part again.

Deleting a Web Part:

Should the user want to permanently remove the web part from the site to free up the resources allocated, they will need to delete it. There are two options to do so. First, here are the steps to delete a single web part displayed on the page:

1. Site Actions -> Edit Page
2. Click the edit button on the web part of choice
3. Choose Delete -> OK

If the user would like to delete multiple web parts at once, or delete a web part that has already been closed, they can do so from the Web Part Maintenance Page by following the steps below:

1. From the main Team Site page, add “?contents=1” to end of the URL string in the address bar window (ex. http://YourSite/Default.aspx?contents=1).
2. From this page, users can select the check boxes for web parts they wish to delete. Notice, the right hand column specifies whether the web part is currently open or closed.
3. Choose Delete -> OK

Restoring a Web Part:

Finally, if the user would like to reopen a web part that has been closed, but not deleted, they will need to restore the web part. This can be done by following these simple steps:

1. Site Actions -> Edit Page
2. Click Add a Web Part
3. Click Advanced Web Part Gallery and Options
4. Click Closed Web Parts
5. Drag closed web part onto page
   

Workflow "Error" System Account An error has occurred after workflow completed MOSS 2007

Problem: If you have a "built in" or custom approval workflow setup for your document library. The workflow runs correctly, however when sometimes you look at the workflow status, you may receive an error after the task has been approved and completed such as, Event Type: Error User ID: System Account Description: An error has occurred in [name of workflow].

Resolution: When you define your workflow, there is a section "Post-completion Workflow Activities", where you can check "Update the approval status (use this workflow to control content approval)". If you check this option, and you do NOT have content approval enabled on the library level, you get the system account error message. If you do not check it, everything works fine.

Reason for occurrences: The account listed in the "User ID" column does not have permission to "something" that is being requested in the workflow code. Workflow usually running as the "system account" within SharePoint and should have access to all the objects within SharePoint. However, the system account may not have access to some resources that are outside of SharePoint and needed by the workflow code. Accessing outside resources is usually done via the .NET worker process account (e.g. NETWORK SERVICE).

Increasing the maximum size of list templates

Saving a list as a template is an easy way of transferring data from one place to another in SharePoint. By default, however, the maximum size of list templates in WSS 3.0 and MOSS 2007 is 10MB.

If you try to save the list as a template that is larger than this you will get the following error:

The list is too large to save as a template. The size of a template cannot exceed 10485760 bytes.

To increase the maximum size, simply run the following stsadm command (from the C:\Program Files\Common Files\Microsoft Shared\web server extensions\12\BIN directory) replacing the propertyvalue to the new maximum size (in bytes):

stsadm -o setproperty -propertyname max-template-document-size -propertyvalue 50000000

Points to note:

1.The propertyvalue parameter is in bytes, so the example above will increase the maximum size to approx 50MB.

2.There is a hard limit of 500MB so the value must be less than 524288000 or you will get an error when saving the list as a template.

3.The above increases the maximum size of both site and list templates.

Office 2003 and SharePoint 2007 - Comparision

This is always recomanded that if you are going to use SharePoint 2007 you really should use Office 2007 with it. In this post I will try to describe differences between various versions so you can know what to expect on your implementation.
Every project is different, and you will encounter numerous combinations of Microsoft software installed. Some large corporations we work with, are still using Office 2000 and Office XP. The majority of enterprise accounts are still using Office 2003 on Windows XP. (I cannot find any hard figures on this though).

Scenario 1
Client platform: Office 2007
Server Platform: SharePoint Portal Server 2003
You might have a customer that moved to Office 2007 but who is still using SharePoint 2003. There might be a number of reasons for this. Your customer probably has a very customized SharePoint 2003 and have decided not to upgrade it because it the solution work fine.

Feature Office 2007 with SharePoint Portal Server 2003
Saving documents to SharePoint sites Yes
Editing documents stored to a SharePoint site No (Edition only works for the Office 2003 formats.
You cannot save a DOCX back to SharePoint 2003)
Check-out/in, version history Yes
Updating properties Yes(it works but not as elegant as on SharePoint 2007)

Scenario 2
In most cases you will run into this scenario. Your customer decided to implement SharePoint 2007, but they will still be using Office 2003. Here are differences between Office 2003 and Office 2007 when working with data from SharePoint sites.

Application / Feature Office 2003 Office 2007
Saving and editing Office 2003 files from SharePoint sites Yes Yes

Saving and editing Office 2007 files from SharePoint sites Yes Yes Check-out/in, version history Yes Yes
Start a workflow No Yes

Source: http://www.sharepointblogs.com/usecases/default.aspx

The instruction at "0x30cb0bad" referenced memory at "0x00000000".

Hi Guys, Today I have faced a new error message with the user. when he tries to upload or edit something in "content editor webpart" in his SharePoint. IE got freeze and he has to terminate the session. Though this was not a SharePoint issue but still i finds it to be somewhat important to discuss.

To resolve this issue, use the following methods in the order in whichthey are presented.

Method 1: Clear cached data in Internet Explorer 7.

To determine whether a performance issue or an error message is causedby corruption in the Temporary Internet Files or in other cachedinformation that is used by Internet Explorer 7, you must clear cacheddata. To do this, follow these steps:
1) Open Internet Explorer 7.
2) Click Tools, and then click Delete Browsing History.
3) In Delete Browsing History, click Delete All.
4) Click to select the 'Also delete files and settings stored byadd-ons' check box, and then click OK.

A progress bar is displayed to indicate that the browsing history isbeing cleared. After this process is complete, test Internet Explorer toverify that it works correctly. If issues still occur, try Method 2.
Method 2: Reset security settings for Internet Explorer 7If you configure security settings to be too restrictive, you mayprevent Internet Explorer 7 from displaying certain web sites. Todetermine whether an issue is caused by overly restrictive securitysettings, revert to default security settings. To do this, follow thesesteps:

1) Open Internet Explorer 7.
2) Click Tools, and then click Internet Options.
3) Click the Security tab.
4) Click Reset all zones to default level, and then click OK.

After you do this, test Internet Explorer to verify that it workscorrectly. If issues still occur, try Method 3.

[If this method does not resolve the issue, you can restore InternetExplorer 7 to its previous security level.]

Note - Overly restrictive settings in third-party software (particularlythird-party security software, such as antivirus, antispyware orfirewall applications) may also prevent Internet Explorer 7 fromdisplaying certain web sites. Review your settings in third-party software.

Method 3: Run Internet Explorer 7 in "No Add-Ons" mode.

Third-party add-ons for Internet Explorer, such as ActiveX controls andbrowser toolbars, are used by some web sites to provide an enhancedbrowsing experience. An error may occur if an add-on is damaged or if anadd-on conflicts with Internet Explorer 7. To determine whether theerror is caused by an add-on, run Internet Explorer 7 in "No Add-Ons"mode. To do this, follow these steps:

For Windows XP:
Start > All Programs > Accessories > System Tools > Internet Explorer(No Add-ons)
For Windows Vista:1) Click Start, and then type Internet Explorer in the Start Search box.2) Click Internet Explorer (No Add-Ons). Internet Explorer 7 openswithout add-ons, toolbars, or plug-ins.3) Test Internet Explorer to verify that it works correctly.

If issues still occur, try Method 4.

If no issues occur, the problem is caused by one of the add-ons thattypically load together with Internet Explorer 7. In this case, use one of the following options:

Option 1: Reset Internet Explorer 7

Reset Internet Explorer 7 to its default configuration. This step willalso disable any add-ons, plug-ins, or toolbars that are installed.Although this solution is quick, it also means that, if you want to useany of those add-ons in the future, they must be reinstalled. To resetInternet Explorer 7 settings, use Method 4.

Option 2: Use the Manage Add-ons tool to determine which add-on iscausing the issueUse the Manage Add-ons tool in Internet Explorer 7 to individuallydisable each add-on to determine which add-on is causing errors. To dothis, follow these steps:

1) Open Internet Explorer 7.

2) Click Tools, point to Manage Add-ons, and then click Enable orDisable Add-ons.

3) In the Show box, select Add-ons that have been used by InternetExplorer to display all add-ons that are installed on the computer.

4) For each item in this list, select the add-on, and then click Disableunder Settings.

5) When you have disabled all the items in this list, click OK.

6) Exit and then restart Internet Explorer 7.

7) If issues do not occur, repeat steps 1 through 3.

8) Click Enable for a single add-on.

9) Repeat steps 6 through 8 until you determine which add-on causeserrors to occur.

After you have used this process to determine which add-on is causingerrors, you can disable that add-on. Or, you can uninstall the softwarethat installs the add-on. You should contact the software vendor thatprovided the add-on for additional troubleshooting and support.

Method 4: Reset Internet Explorer 7 settings

To determine whether a performance issue or an error message is causedby configuration settings, reset Internet Explorer 7 to its defaultconfiguration. This was its state when Windows Vista was originallyinstalled. To do this, follow these steps:

1) Open Internet Explorer 7.

2) Click Tools, and then click Internet Options.

3) Click the Advanced tab.

4) Under Reset Internet Explorer Settings, click Reset.

Issues with Internet Explorer 7 can also caused by the presence ofviruses or other malicious software, collectively known as malware.Since malware can be very hard to detect you want to thoroughly scanyour system for malicious software with /several/ of the better onlinescanners (Kaspersky, Eset, Trend Micro, Panda, Sophos, Symantec etc.)and, if necessary, submit a HiJack This log to one of the expert websites that analyze these logs.

Deploy administrator-approved form templates (Office SharePoint Server)

In this article:
Deploying administrator-approved form templates
Upgrading administrator-approved form templates
Quiescing administrator-approved form templates

InfoPath Forms Services provides functionality that enables both Office administrators and users to deploy browser-compatible form templates. InfoPath form templates (XSN files) created in the design mode of the InfoPath program can be published as browser-enabled form templates that can be opened and edited in a Web browser from servers running InfoPath Forms Services. This enables you to expose full-featured forms to users who do not have the InfoPath program, such as customers and partners.
Form templates that contain business logic (such as a compiled, managed code DLL), require full domain trust, or use a data connection that is managed by an administrator must be deployed by an administrator. Because of the potential for security, performance, and manageability issues, it is important that these form templates are thoroughly reviewed by an administrator prior to deployment. You can manage these form templates on the Manage Form Templates page on the Central Administration site.
Deploying administrator-approved form templates
To deploy an administrator-approved form template, you must complete three actions after the form template has been designed: verify, upload, and activate . These steps can either be performed through the command-line interface or through the Central Administration site. You can upload a form template by using the Publishing Wizard in the InfoPath program, using the command line on a server running InfoPath Forms Services in the farm to which the form template will be deployed, or by using the Central Administration interface. As the farm administrator, you typically receive from the form designer a form template that is already prepared for deployment.
Deploying administrator-approved form templates using the command line
You can deploy form templates and perform many other InfoPath Forms Services administrative tasks from the command line using the stsadm.exe tool. This can be useful if you want to write a script to automate repetitive administrative tasks. This tool is located on Office SharePoint Server 2007 servers in the C:\Program Files\Common Files\Microsoft Shared\Web server extensions\12\BIN directory, and operations using the tool can be run from any server in a farm. You must be authenticated to the server as a farm administrator to use this tool.
Note:
Form template verification is an optional step in the deployment process that checks that the form template is acceptable to be uploaded to the server. This step should be performed by the administrator, either through the command-line interface or the Central Administration site, prior to deployment to verify that a solution is valid. If you do not verify the form template manually, then it will be automatically verified during the upload process. Manual verification returns both messages and errors, while automatic verification only returns errors.
Note:
Command-line verification must be performed on a server in the farm where the form template will be deployed.
To verify and upload a form template using the command line

1. Click Start, and then select Run.
2. Type cmd, and then click OK.
3. On the command line, type cd ":\Program Files\Common Files\Microsoft Shared\web server extensions\12\BIN" (include the quotation marks).
4. On the command line, type stsadm –o verifyformtemplate –filename .
5. Read the errors and messages to verify that this form template can be uploaded.
6. To upload the verified form template, type stsadm –o uploadformtemplate –filename .

Although the form template is uploaded, it is not yet available to users. It must be activated by the administrator of the site collection to which the form template will be activated. This can also be performed by a farm administrator who also has administration privileges to the site collection. For more information about activating form templates, see "Activating administrator-approved form templates" on this page.

Deploying administrator-approved form templates using the Central Administration site
You can deploy form templates from the Central Administration site. You must be a farm administrator to access this site.

Note:
Form template verification is an optional step in the deployment process that checks that the form template is acceptable to be uploaded to the server. This step should be performed by the administrator, either through the command-line interface or the Central Administration site, prior to deployment to verify that a solution is valid. If you do not verify the form template manually, then it will be automatically verified during the upload process. Manual verification will return both messages and errors, while automatic verification will only return errors, if any.

To verify and upload or upgrade a form template using the Central Administration site

1. On the taskbar, click Start, point to Administrative Tools, and then click SharePoint 3.0 Central Administration.
2. In the top navigation bar, click the Application Management tab.
3. On the Application Management page, under InfoPath Forms Services, click Upload form template.
4. On the Upload Form Template page, in the Deploy Form Template section, click Browse.
5. In the Choose File window, select the template you want to verify, and then click Open.
6. Click Verify to check the form template for problems. If there are problems with the form template, then they will be displayed in the Report Details section of the Form Verification Report.

In the event that the verification process returns errors, have the form designer correct the errors and messages and then provide you with an updated form template. Then you can repeat the above steps. If there were no errors and no unacceptable messages, you may continue with the upload or upgrade.

Note:
If the system warns you that the template already exists, click Application Management, click Manage Forms Services form templates, point to the form template, click the arrow that appears, and then click Remove Form. On the Remove Form Template page, click Remove. You may then repeat this procedure to upload the form.

1. Click OK to return to the Upload Form Template page. When you return to the Upload Form Template page after verifying a form template, you will have to browse for the template again.
2. On the Upload Form Template page, in the Deploy Form Template section, click Browse.
3. In the Choose File window, select the template you want to upload, and then click Open.
4. In the Upgrade section, choose how you want InfoPath Forms Services to behave if another version of the form template already exists on the server.

• If a previous version of the form template does not exist on the server, or if you do not want to upgrade the existing version of the form template to the new version automatically, clear the Upgrade the form template if it already exists check box. This box is checked by default.
• After you upgrade the form template, new sessions will start using the upgraded version of the form template. Forms already open will continue to use the current version of the form template. If you want existing browser-based form-filling sessions to continue using the previous version of the form template, leave the Allow existing browser-based form filling sessions to complete using the current version of the form template button selected. Otherwise, select the Terminate existing browser-based form filling sessions button. Note that selecting this choice causes any data in existing sessions to be lost.
• If you wish to wait until all sessions of the form template have been completed before upgrading, navigate to Manage Form Templates, select the form template, and choose Quiesce settings. For more information on quiescing form templates, see "Quiescing Administrator-approved form templates" on this page.

1. Click Upload. The upload process may take a few minutes to finish, particularly in a farm with multiple Web front-end (WFE) servers. You can check the status of the upload on the Manage Form Templates page.

Although the form template has been uploaded to the central Forms Library, it is not yet available to users. It must be activated by the administrator of the site collection to which the form template will be activated. This can also be performed by a farm administrator who also has administration privileges to the site collection. For more information about activating form templates, see "Activating administrator-approved form templates" on this page.

Activating administrator-approved form templates

To make an administrator-approved form template available to users, the form must be activated to a site collection. Form templates may be activated to a site collection from the Site collection features page by a site collection administrator. A form template can also be activated to a site collection from the Central Administration site by a farm administrator who has administrator privileges to that site collection. A form template can be activated to more than one site collection; repeat the activation process for each site collection to which you want to activate the form.

Note:
Before activating a form template that uses data connections, ensure that the data connections are configured appropriately. For more information about data connections, see Introduction to data connections.
Note:
InfoPath Forms Services is not supported for site collections based on some site collection templates, such as the Basic Meeting Workspace template. If you activate a form template to a site collection that does not support InfoPath Forms Services through the Central Administration site, the activation will appear to succeed, but the form template will not be accessible from the site collection. Form templates that are available for activation by site collection administrators will appear in the site collection features list. However, if you attempt to activate a form template to the site collection or to activate the Office SharePoint Server Enterprise feature, which enables InfoPath Forms Services, you will see an error message that reads Required Feature: One or more features must be turned on before this feature can be activated.

To activate a form template to a site collection from the Central Administration site

1. On the taskbar, click Start, point to Administrative Tools, and then click SharePoint 3.0 Central Administration.
2. In the top navigation bar, click the Application Management tab.
3. On the Application Management page, under InfoPath Forms Services, click Manage form templates.
4. On the Manage Form Templates page, point to the form template that you want to activate, click the arrow that appears, and then click Activate to a Site Collection.
5. To activate the form template to the current site collection, click the Activate button. The form template is now available to users.

• To choose a different site collection, in the Activation Location section, click the site collection box, and then click Change Site Collection. The Select Site Collection Web page dialog box appears.
• Click the URL of the site collection to which you want to activate the form template, and then click OK. If the site collection you want is on a different Web application, click the Web Application box, click Change Web Application, and click the name of the Web application.
• Then click the appropriate site collection and click OK.

The form template is now available for users to access.

To verify that the form template is available

1. In Internet Explorer, browse to the URL of the site collection to which you have activated the form template.
2. Click All Content.
3. On the All Content page, in the Document Libraries section, click the Form Templates document library. The template you made available should appear in the Form Templates list.

To activate a form template to a site collection from the Site collection features

page

1. In a Web browser, open the site collection home page.
2. In the top navigation bar, click the Site Actions tab.
3. In the drop-down menu that appears, click Site Settings.
4. On the Site Settings page, under Site Collection Administration, click Site collection features.
5. Activate the form template to the current site collection by finding the form template in the features list and clicking the Activate button.

The form template is now available for site collection users to access.

To verify that the form template is available

1. In Internet Explorer, browse to the URL of the site collection to which you have activated the form template.
2. Click View All Site Content.
3. On the All Site Content page, in the Document Libraries section, click the Form Templates document library. The template you made available should appear in the Form Templates list.

Source : Microsoft Technet

EXACTLY where SharePoint documents are stored

Ever wonder EXACTLY where SharePoint stores documents? This isn't going to be news to developers or others that have followed SharePoint for a good while, but if you are relatively new to SharePoint it might be somewhat eye-opening.

Every time you hit "Save" on a Microsoft Office document and the path for the save is a SharePoint document library on a SharePoint site, the entire contents of the document is saved in binary format in a single image-type field in the SharePoint database. That's right, the entire document, up to 2 GB in size, is stuffed completely into a single field in the SQL Server database that SharePoint uses.

Want to know by the letter of the law that this is true? If you keep following the trail in the official documentation here is where you find it (click on the image to see it more clearly):




Here is the exact link to this page of the documentation on the Microsoft Developer Network:

http://msdn.microsoft.com/en-us/library/ms998690.aspx

(Note: the description of the Docs table on this page says that its function is to store metadata for the document. That's true, but it also stores the full contents of the document as well.)

The documentation is definitely not an exciting read, but it does tell the truth (in this case at least :) )

So, are you thinking "how can this possibly work in environments that have any kind of volume at all?". Well, as they say, that's a deep subject - especially depending on how far you want to delve down into it. In this short post, all I can say is that it indeed DOES work, if the environment is properly architected, and performs very well at incredibly high volumes.

Managing Web Parts in WSS and MOSS 2007 without using the Site Actions Menu

I keep forgetting how to do this so I'm blogging it to help me remember.

Back in the days of WSS v2 and SPS 2003, one could use some handy URL parameter passing to edit web pages and browse for or search web parts.

My three favorite parameters for WSS v2 and SPS2003 were:

To Correct or Remove Misbehaving Web Parts
http://server/default.aspx?Contents=1

To Open the Page in Web Part Design Mode
http://server/default.aspx?ToolPaneView=2

To Open the Search Web Part Zone
http://server/default.aspx?ToolPaneView=3

Now in WSS 3.0 and MOSS 2007 we have the much more practical approach of switching views. Enter the Site Actions Menu, using the menu options we can edit the page, browse to site settings, etc.. But what happens if the Site Actions menu is not visible on the page. Maybe it was missed in the look and feel or has been removed deliberately like I had to do recently for a client.
Here are my favorite parameters to date for WSS 3.0 and MOSS 2007:

To open the Design Bar - Useful for pages in the Pages Library
http://server/default.aspx?DisplayMode=Design

To turn on Web Part Zone Editing
http://server/default.aspx?ControlMode=Edit

Note: The Site Actions Menu is rights trimmed and that means not all users can see or use it. Users with limited access or read rights will not be able to make use of the URL\Query String parameters. The parameters are just an alternative to get to the editing\design controls rather then a security bypass.

'Edit Document' requires a Windows SharePoint Services-compatible application and Microsoft Internet Explorer 5.0 or greater.

Today’s helpdesk call is a problem I have been asked about several times lately. It is one of those issues that can drive a technical support pro crazy because it only effects some users, happens apparently for no reason, and sometimes fixes itself.
The problem begins when a user has an issue opening files from SharePoint. The files open, that isn’t the problem, it’s just that no matter what the user does the file opens as read only. If the user is selects a MS Word document in a SharePoint document library and select ‘Edit in Microsoft Word’ they may get an error like this:
'Edit Document' requires a Windows SharePoint Services-compatible application and Microsoft Internet Explorer 5.0 or greater.
or:
'Edit Document' requires a Windows SharePoint Services-compatible application and Microsoft Internet Explorer 6.0 or greater.

The frustration begins with the fact that both IE5/6 and Microsoft Office XP or greater are already installed! You might also hear things like “It used to work! ” and “It works for other people!”. After a quick trip to Google this looks like an easy fix. Normally you will find the right Microsoft KB article in just a few seconds ( http://support.microsoft.com/kb/833714 ).
To summarize the solutions in KB833714:

First, if you don’t have Office XP or later, buy it and install it, pretty obvious.

If you already have Office XP or later make sure the feature that integrates with SharePoint is installed.

For Office XP the component “Microsoft SharePoint Support” is the one you are looking for– if it is not installed, install it.

For Office 2003 and 2007 the component is renamed “Microsoft SharePoint Services Support” but still make sure it is installed.

The KB article doesn’t mention this but you can also try uninstalling/reinstalling this component, if it is already in place.

The final method suggested by the KB article has to do with the DLL that handles SharePoint integration. If the steps above don’t solve your problem try unregistering and registering owssupp.dll.

The owssupp.dll is usually located in :
[Drive Letter]:\Program files\Microsoft Office\Office10 (for MS Office XP)
[Drive Letter]:\Program files\Microsoft Office\Office11 (for MS Office 2003)
[Drive Letter]:\Program files\Microsoft Office\Office12 (for MS Office 2007)
To unregister the DLL you go to the command line, cd to the directory that is appropriate for your version of Office and type:
regsvr32 -u owssupp.dll
To register (or re-register) the DLL you type:
regsvr32 owssupp.dll
and we get,
DllRegisterServer in owssupp.dll failed. Return code was: 0x80070716
So, Microsoft is out of ideas and our problem is still here, not good. I’ll pause for a moment while you pound your head against the wall.
Luckily I have spent a little time banging my head against the wall on this issue as well and I think I may have a few other tricks to try.
First, do you remember the different directories that Office can be installed in, depending on the version? It turns out that several people with this problem have upgraded from Office XP or 2003 to a more current version. As far as I can tell the spontaneous break seems to happen during Office updates and some MS Windows Updates. What we need to do is check to see if there are any leftover directories from previous installs of Office. In the [Drive Letter]:\Program files\Microsoft Office\ directory if you have more than one Office## (10, 11, or 12) directory find whichever one has a copy of owssupp.dll in it. Copy the owssupp.dll file into the directory that doesn’t have one. Now check to see if you can edit files from SharePoint without any trouble.

Second when you have tried all of the steps above you may be overlooking the obvious when you test the “Edit” function. Make sure you keep your eyes open for an ActiveX control warning in IE and that you allow the owssupp.dll to do its job.

The third and most hated option for dealing with this problem is the old standby, uninstall Microsoft Office, delete all of its directories, reboot, and reinstall MS Office. Don’t you hate it when that works?

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

InfoPath 2007 and InfoPath Forms Services error about user name cannot be verified

Just today an old existing SharePoint 2007 environment was re-introduced into the InfoPath development process for my current client and this morning when trying to preview a form either through InfoPath 2007 designer or InfoPath Form Services and using the InfoPath function "UserName()" the below error was given (error when viewing through InfoPath 2007).
The full error message is

InfoPathYour user name cannot be verified because the form's security settings do not permit it.Error occurred during a call to property or method 'get-UserName'.

The problem started to happen when the "Domain" textbox on the "Preview" screen and "Enter the URL of a server that is running InfoPath Forms Services and can be used to verify compatibility" textbox on the "Compatibility" screen from the "Form Options" menu was set to point to the development SharePoint server. Below are visuals of the options that I'm talking about.

The error sort of took me back at first because there weren't any problems with any of the previous forms. Since this was a new form I was thinking that there was a setting that was not correct but that wasn't the case. While troubleshooting the issue I changed the form security to "Full Trust" from "Domain" and everything was working but I knew that wasn't the solution but it got me thinking in a different direction. It got me thinking that it wasn't an InfoPath problem after all. To further that theory I changed "Preview" and "Compatibility" values to point to production and when I previewed the form everything worked with no errors. This confirmed my theory in my mind that it wasn't an InfoPath problem and I started to think what else is tied into InfoPath.

So naturally I thought it could be an IE issue because we all know that IE is an integral part of InfoPath. The first thing that I did was open each SharePoint site that I was using in IE and looked at the security zone for each site. To my surprise there was a difference between them. The production site had "Local Intranet" and the development site had "Internet". You can easily tell this by looking at the bottom right corner of the IE 7 browser. After noticing this I added the development site to the "Local Intranet" zone and then tested my InfoPath form out again and there were no errors this time.

Cheers......!

Source:www.sharepointblogs.com

Information about the characters that you cannot use in sites, folders, and files in SharePoint Portal Server 2003 or in SharePoint Server 2007

This article lists the characters that you cannot use in Microsoft Office SharePoint Portal Server 2003 site names, folder names, server names, and file names or in Microsoft Office SharePoint Server 2007 site names, folder names, server names, and file names.

Site names, subsite names, or site group names
You cannot use the following characters anywhere in a site name, in a subsite name, or in a site or Active Directory group name:
• tilde (~)
• number sign (#)
• percent (%)
• ampersand (&)
• asterisk (*)
• braces ({ })
• backslash (\)
• colon (:)
• angle brackets (< >)
• question mark (?)
• slash (/)
• plus sign (+)
• pipe ()
• quotation mark (")
• You cannot start a site name, subsite name, or a site group name with an underscore (_) character or with the period character.
• You cannot use the period character consecutively in the middle of a site name, a subsite name, or a site group name.
• You cannot use the period character at the end of a site name, a subsite name, or a site group name.

Folder names
You cannot use the following characters anywhere in a folder name or a server name:
• tilde
• number sign
• percent
• ampersand
• asterisk
• braces
• backslash
• colon
• angle brackets
• question mark
• slash
• pipe
• quotation mark
• You cannot use the period character consecutively in the middle of a folder name.
• You cannot use the period character at the end of a folder name.
• You cannot start a folder name with the period character.

File names
You cannot use the following characters anywhere in a file name:
• tilde
• number sign
• percent
• ampersand
• asterisk
• braces
• backslash
• colon
• angle brackets
• question mark
• slash
• pipe
• quotation mark
• You cannot use the period character consecutively in the middle of a file name.
• You cannot use the period character at the end of a file name.
• You cannot start a file name with the period character.

Source : support.microsoft.com

Exploring The SharePoint Content Database

There are some cases when we need to look into and read from the content databases.We will begin with some of the basic tables and a very high level diagram on some of the relationships between them.

Features
Table that holds information about all the activated features for each site collection or site.

Sites
Table that holds information about all the site collections for this content database.

Webs
Table that holds information about all the specific sites (webs) in each site collection.

UserInfo
Table that holds information about all the users for each site collection.

Groups
Table that holds information about all the SharePoint groups in each site collection.

Roles
Table that holds information about all the SharePoint roles (permission levels) for each site.

AllLists
Table that holds information about lists for each site.

GroupMembership
Table that holds information about all the SharePoint group members.

AllUserData
Table that holds information about all the list items for each list.

AllDocs
Table that holds information about all the documents (and all list items) for each document library and list.

RoleAssignment
Table that holds information about all the users or SharePoint groups that are assigned to roles.

SchedSubscriptions
Table that holds information about all the scheduled subscriptions (alerts) for each user.

ImmedSubscriptions
Table that holds information about all the immediate subscriptions (alerts) for each user.


Source : www.sharepointblogs.com

Sharepoint Backup

Types of Backup in Sharepoint V3.

As Every product or any business Disaster Recovery is very importand and in similar way, Sharepoint has some very good options for the same. Below are the methods that can be used in WSS 3.0 only or also for MOSS 2007.

1. GUI mode from Sharepoint Central Administration.

This Method is very common and most of the Administrators use this Method.

Go to Sharepoint Central Administration page -> Operations Tab -> Backup Operations.

This method will need a UNC path to store the back. It automatically creates a folder starting which will have various files in it and the most important file is the .xml file which get created, which has all the information about the backup.

The .xml file will contain data about the backup ID, The type of Backup, the Components selected during the backup.

GUI Backup is the same like the stsadm -o backup [catostrophic]. Both work the same way and the backrgound process is the same. Only difference here is the GUI interface.

By Default this backup will take the entire Sharepoint Farm backup

2. STSADM -o backup

This method is a command line backup which needs to be run from the BIN folder of Sharepoint.

This method can backup any top level sites or site collections of a Web application.

You will need to specify the URL address of the site to be backed up.By default in this method the security or permissions are also backed up.

stsadm -o backup -filename c:\back.bak -url http://siteurl/

This is the standard command. It is not necessary to give the backup file extension as .bak, it can be anything or you may not even give any extension. Using this command you can backup only 1 top site at a time within the Web Application. If you want you can create a batch file which will include the commands having different URL's and schedule te batch file to run accordingly. It also includes other parameters for which you can use

stsadm -help backup

3. STSADM -o backup [catostrophic]

This method is similar to GUI Central Adminstration backup, its only Command line interface. You will need to manually specify the parameters and components to be backed up using this command. By default if the component is not specified, Enter Farm level backup is taken. Using this command as well a UNC path is to be given, where again and .xml file will be created.

stsadm -o backup -directory \\server\backup -backupmethod full [This will take the default Farm level backup]

You can use stsadm -o backup -showtree to see the list of the items in the Farm and then use stsadm -o backup -directory \\server\backup -backupmethod full -item

4. STSADM -o export

This method will help you to take backups of subsites separately which is not possible in any of the above backups. Using this method, subsites and top level sites backup can be taken but by default User permissions are not exported, you have to manually specific to export User permissions.

stsadm -o export -filename c:\exp.back -url http://siteURL -includeusersecurity

If you do not use -includeusersecurity, User permissions will not be exported by default.

5. SQL Database backup.

This method is the usuall maintenance method from SQL Management Studio. It is recommended to have the Sharepoint Content Databases backup from SQL as well, just in case Sharepoint Backup's don't work.

Microsoft Search Server 2008

Search Server is one of the other major Enterprise servers of Microsoft which is growing Fast with Sharepoint 2007. With the new release of Search Server 2008 in March, it is expected to take Search functionality and Search Experience to the next level for Microsoft's Customer's.

There are better features than Google's Onebox Search Server Appliance, though I would say both have their own pro's and con's.

Search Server 2008
It's RTM version's are getting released in Express and Full Edition. Express Edition will be downloadable for free whereas Full version is a licensed product. There will be support provided for both these versions from Microsoft.

Express Edition's limitation is that it can be installed only on a SingleServer WSS 3.0 environment, whereas, Full Edition can be installed in a Farm WSS 3.0 enviroment.

Search Server 2008 MOSS patch is expected to be released later this year. When you install Search Server 2008, WSS 3.0 will be installed along with it, with some more cool features of Search which is not available with only WSS 3.0 Another new and cool feature of Search Server is the Federated Search which allows you to render the index of the Search engines on the internet, except for Google Search, Google blocks any search engine to crawl its content.

Search Server needs to get the results returned in XML formart to display those results in the Search query, for any Search engine that cannot return the results in XML format to Search Server, we have Federated Search custom connectors that can be created to re-format the results in XML format and store it locally. Those custom connectors is something that Shareopoint Developers will have to do. There are many 3rd party custom search connectors already available and can be used with Search Server 2008.

Google's Enterprise Search products have limitations of crawling data, depending on the product you buy, the limitations differ. In Microsoft Search Server 2008 there is no limitation to the no of files that be crawled. Also, Google's product expire in 2 years and so will their email support, they do not have any on call support. If you want to renew the support you will have to buy a new license for that to get support. (Email)

More information on the Installation and new features of Search Server 2008 will be posted soon.

Error while creating a new page in MOSS.

Getting the below error while creating a new page in Moss 2007 while using publishing or collaboration portal template.

List does not exist The page you selected contains a list that does not exist.
It may have been deleted by another user.

In ULS Logs the error listed is as below.

05/16/2008 13:13:34.51 w3wp.exe (0x1AF8) 0x148C Windows SharePoint Services General 8kh7 High List does not exist The page you selected contains a list that does not exist. It may have been deleted by another user. 05/16/2008 13:13:34.51 w3wp.exe (0x1AF8) 0x148C Windows SharePoint Services General 8nca Verbose Application error when access /_layouts/AccessDenied.aspx, Error=List does not exist The page you selected contains a list that does not exist. It may have been deleted by another user. at Microsoft.SharePoint.Library.SPRequestInternalClass.GetListsWithCallback(String bstrUrl, Guid foreignWebId, String bstrListInternalName, Int32 dwBaseType, Int32 dwBaseTypeAlt, Int32 dwServerTemplate, UInt32 dwGetListFlags, UInt32 dwListFilterFlags, Boolean bPrefetchMetaData, Boolean bSecurityTrimmed, Boolean bGetSecurityData, ISP2DSafeArrayWriter p2DWriter, Int32& plRecycleBinCount) at Microsoft.SharePoint.Library.SPRequest.GetListsWithCallback(String bstrUrl, Guid foreignWebId, String bstrListInternalName, Int32 dwBaseType, Int32 dwBaseTypeAlt, Int32 dwServerTemplate, UInt32 dwGetListFlags, UInt... 05/16/2008 13:13:34.51* w3wp.exe (0x1AF8) 0x148C Windows SharePoint Services General 8nca Verbose ...32 dwListFilterFlags, Boolean bPrefetchMetaData, Boolean bSecurityTrimmed, Boolean bGetSecurityData, ISP2DSafeArrayWriter p2DWriter, Int32& plRecycleBinCount) 05/16/2008 13:13:34.51 w3wp.exe (0x1AF8) 0x148C Windows SharePoint Services General 0 Verbose Releasing SPRequest with allocation Id {BD5F0900-38A4-40AB-BC1F-E78319A3DD70}

Resolution
=========

Go to Site Settings -> Master page Gallery -> Add Authenticated Users group and give Read Restricted Access rights.

Add the same group in Style Library and give the same permissions.