Thursday, October 30, 2008

InfoPath Forms Services best practices

This comes from:

Updated: 2006-12-01

We recommend that you follow these best practices when managing your InfoPath Forms Services environment.

Document limit of 2,000 in Windows SharePoint Services document libraries

If a form template will be filled out and submitted more than 2,000 times in total, you should either write code in the form template to submit to a database by using a Web service, or create a custom submit function that places forms into multiple libraries. This is due to a limitation in the capacity of Windows SharePoint Services 3.0 document libraries, which may experience performance degradation if more than 2,000 documents exist in the library.

If you think a form template may be submitted more than 2,000 times, it is easier to begin by programming the form to use an alternative submit method than to correct this issue once it becomes a problem, particularly if the form template is available to a publicly accessible Web site.

Use Form View when configuring session state for InfoPath Forms Services

You can configure InfoPath Forms Services to use the Session State Service (the default option) or Form View to control how user sessions are managed. When you configure InfoPath Forms Services to use the Session State Service, all browser sessions are maintained on the SQL Server database corresponding with the Shared Services Provider (SSP) associated with the Web application on which the form template is hosted. This scenario uses little network bandwidth, but has a cumulative performance impact on the computer running SQL Server. When you are using Form View, sessions are maintained on the client browser, and all session data is included in each postback to the server, up to 40 kilobytes of session data. This uses more bandwidth than using session state, but does not affect the computer running SQL Server. Once session data reaches 40 KB in size, the session automatically transitions to session-state management.

We recommend the use of Form View in environments that have smaller groups of users, because it reduces the impact on SQL Server. If your InfoPath Forms Services deployment will have many users, particularly if session data is below 40 KB for many high-usage form templates, session state is likely a better choice. If Form View is used, the bandwidth used by browser sessions of 40 KB or fewer can be monitored if there is a concern that network performance might be adversely affected.

Running SQL Server on a front-end Web server is not recommended

If you run SQL Server on an Office SharePoint Server front-end Web server (for example, in a single-server evaluation deployment), the ASP.NET cache will release system memory at a lower threshold than SQL Server, which could result in InfoPath Forms Services memory starvation.

ASP.NET employs a strategy of targeting maximum Internet Information Services (IIS) memory use of the lesser of either 800 megabytes or 60% of available physical RAM. These settings are configurable in IIS manager. ASP.NET also monitors physical RAM use, not just for the w3wp.exe process, but for the entire system. When 80% of the physical memory on the server is committed, ASP.NET begins periodically dropping the oldest and lowest priority 5% of the cache. When 85% of physical memory is committed, ASP.NET drops 50% of the cache periodically. At 90% or more, ASP.NET aggressively trims the cache and sets a low limit on the maximum number of entries, which remains in effect until ASP.NET reassesses memory pressure on the server and raises the threshold.

The memory usage threshold for SQL Server is higher by default than the ASP.NET cache. In this scenario, SQL Server never releases memory, because the ASP.NET cache will already have released memory before the SQL Server threshold is reached. This situation can lead to a condition in which the throughput of InfoPath Forms Services is reduced with a subsequent impact on performance.

To mitigate this issue, you should configure SQL Server memory limits manually when SQL Server is installed on the same computer as Office SharePoint Server. For more information on adjusting SQL Server memory settings, see the article Server Memory Options ( on the Microsoft Web site.

Best practices for anonymously accessible forms

When you deploy a form to a location where it is exposed to anonymous users, such as a public SharePoint document library or an embedded form in a Web page on the Internet, ensure the integrity of your form. There are several additional steps you should take to mitigate the risk of improper form usage, Denial of Service (DoS) exploits, and potential performance issues.

  • Ensure that form templates cannot be accessed by scripts or other automated processes. One way to achieve this is to force users who are submitting a form template to enter an identification code such as a short alphanumeric string displayed in an image, which cannot be "read" by a script or automated process.

  • Form templates that contain sensitive information such as authentication information, server or database names, or proprietary code should never be exposed to anonymous users.

  • Form templates that contain an e-mail submit data connection should not be deployed to servers that are anonymously accessible, as e-mail messages generated when the form is submitted will show "sent by anonymous user" in the Subject line.

  • Form templates that contain code or functionality that can invoke processes on a server should be carefully evaluated and tested to ensure that security cannot be compromised by making the form template accessible to anonymous users.

  • In order to prevent users from submitting multiple copies of a form, you might consider including code that tracks the IP address of each user who submits a form and prevents duplicate submissions from the same IP address.

  • Protect the integrity of form templates by enabling protection to prevent the form template from being changed.

Thursday, October 23, 2008

MOSS Page Setting Error - Value does not fall within the expected range

Thanks to these guys for the solution

I found an error when trying to change the Page Settings of a default.aspx in one of my sites today.

I wanted to update the page layout template in use but on selecting Page Settings from either the Page drop down in edit mode or from the Site Content & Structure page i received the follwoing error:

Value does not fall within the expected range
  1. Open the site in SharePoint Designer
  2. Select File / Export and choose the page you are trying to update
  3. Open the page locally using Notepad
  4. Search the source for “mso:PublishingPageLayout"
  5. Look at the path :

    http://mossdev/_catalogs/masterpage/customLayout.aspx, Custom Reports Layout

  6. The string points to my old development environment http://mossdev
  7. Update the path to the live environment eg: http://mosslive
  8. Save the file
  9. In SharePoint Designer select File / Import and choose the modified file
  10. Check the files back in and approve them.
Problem solved - i can now update the page settings with no error.

Thursday, October 09, 2008

SSP Stuck on Unprovisioning

I tried to delete a test SSP the other day via Central Administration. Having selected the options to also delete associated content databases and web applications i hit ok and left it to run. The SSP status changed to 'Unprovisioning' and an hour later was still stuck.

I then followed this example in the hope the SSP would delete.

    1. Tried: stsadm -o deletessp "TestSSP" –force, but this did not work
    2. Login to SQL server.
    3. Open SQL Management Studio and expend Databases.
    4. Expand Configuration Database & Tables.
    5. Opened table for dbo.object.
    6. Executed following query in query analyzer: SELECT * FROM [MOSS_CFG_CA_01].[dbo].[Objects]where name like ‘Name of the Shared Services’.
    7. Copy the ID of object referenced in objects table of configuration database.
    8. Open command prompt and changed directory to C:\Program Files\Common Files\Microsoft Shared\web server extensions\12\BIN> and executed following command to delete the Shared Services using the ID which was copied: Stsadm -o deleteconfigurationobject -id “id retrieved from object table”
  • To clean up we decide to delete the DBs via SQL Management Studio and delete the web applications via Central Administration.
A week later I discovered that one of our servers had rebooted itself with the following log (don't yet know if this is related):

System Failure: Stop error
Reason Code: 0x805000f
Bug ID:
Bugcheck String: 0x000000c5 (0x00000004, 0xd0000002, 0x00000001, 0x8089bce3)
Comment: 0x000000c5 (0x00000004, 0xd0000002, 0x00000001, 0x8089bce3)

I then discovered that the search was no longer working. Submiting a query returned the following error:

Cannot connect to the search service

The status of the test SSP i had tried to delete was still stuck on 'Unprovisioning'. Also the other SSPs 'Edit Properties' pages in Central Administration were no longer available and returned the following error:

An unhandled exception occurred in the user interface.Exception Information: Cannot open database "xxx" requested by the login. The login failed. Login failed for user 'xxx'.

In the event log on the server I found multiple instances of the following error:

Application Server Administration job failed for service instance Microsoft.Office.Server.Search.Administration.SearchServiceInstance (e6a1ecb4-3aa8-45cd-a179-d7e053aa927a).

Reason: Cannot open database "xxx" requested by the login. The login failed.
Login failed for user 'xxx'.

  1. Restart the Office SharePoint Server Search service in via the Computer Management console - Search still not working.
  2. I retried the STSADM CMD
    stsadm -o deletessp "TestSSP" –force
Operation was successful this time and the SSP has now gone. The event log is now clear of all errors and the unavailable pages in Central Administration are now available again.