chandler's blog - MOSS SharePoint 2007, Office 2007, Windows Server 2003 RSS 2.0
 Monday, 09 February 2009


In some cases the deployment of InfoPath forms has to be done through the central administration of the SharePoint 2007 as administrator approved form. For example if you are using custom C# or VB code this procedure is necessary. But are there other ways of deploying the forms to SharePoint server 2007, despite the way using the Publishing wizard of the InfoPath client?


Yes, there are many ways of getting the form templates into the SharePoint server 2007. Depending on your requirements different ways could be appropriate for you. Here I’d like to summarize the differences between administrator-approved Form Server Templates and the simple usage of site content types.

Source code in InfoPath forms requires the form to be fully trusty and therefore you have to upload it through the central administration. This is also leading the SharePoint Server to recycle the application pool of the SharePoint Portal web application. Something that is not very welcome in production environments, because the server is not serving requests for several seconds, up to a minute depending on the hardware and the workload.

Also it is difficult, when the designer of the form does not have administrator privileges on the form server. Such environments require steady contact between designer and administrator to publish, upload and approve the form templates.

So, we’ve not talked about the disadvantages of administrator-approved Form Server Templates, but what about site content types? Probably the site content types requires also a lot of work for the designer, but administrator privileges are only required on the site where the content type is created. But the greatest advantage of using site content types is that the application pool is not recycled and the server is not interrupted.

The procedure is as follows: On the “Modify all site settings” page go to “Site content types”. Click on create and give the content type a name (I suggest you do not use blanks here, you can change it later anyway) and a description. As parent content type please select “Document Content Types” and “Form”. Finally a group has to be set for the content type. A good starting point is the existing group “Microsoft Office InfoPath”.

If you created your content type add site columns from existing site columns or create new ones to be used in your form libraries and finally go to advanced settings and upload your InfoPath form template. The forms will be stored under \\servername\_cts\CONTENT*TYPE*NAME\Template*Name.xsn, but they will work like the administrator-approved Form Server Templates without any restrictions regarding the use of source code. The only real difference is the storage of the files that differs from the \\servername\FormServerTemplates\Template*Name.xsn folder when using the FormServerTemplates method. Probably this could help you a lot and if you experience disadvantages of the site content type method let me know. I didn’t either experience any by now…

Thanks to maikl for this great entry!

Monday, 09 February 2009 11:52:11 (W. Europe Standard Time, UTC+01:00)  #    -
Infopath | SharePoint
 Sunday, 01 February 2009


Quite often you run into situations, where you have InfoPath forms in several variations. For example a form with red colored design for critical issues, a yellow one for normal issues, and a green one for absolutely not critical issues. Each of these content types has different fields, but all of them share the same fundamental columns.

To use multiple lists should not be considered to be the correct solution, it would be better to use a single form library and group by content types. Here comes the big drawback: using the same fundamental columns is not easy when using the publishing feature of InfoPath and you probably will run into issues like values of published columns not appearing or multiple columns are created for each content type.


A good start is to create the xml data structure of the forms first, before designing the forms. This helps you to find out about the shared columns. This is important, because you have to know the shared columns before you publish them the first time to the form library.

After developing the xml schemas for the forms and finding out about the shared columns, let’s move to the SharePoint Server 2007 to create what we need. A blank form library is a good starting point. There are several options; here I will describe the one that is in my opinion the cleanest and most appropriate way of doing it.

Create site columns on the site that contains your new form library. I have experienced, that using new groups for the site columns that are named accordingly to your project is a big DO, while using blanks in the names of the site columns is a absolute DON’T. This is because when you are writing XSLT queries or if you are programming C# or VB code for your InfoPath forms and query the lists fields, the blanks will be converted to “%5Fx0020%5F” resulting for example in the field name “This%5Fx0020%5Fis%5Fx0020%5Fa%5Fx0020%5FTest” so not a very desirable name for a variable.

If you finished this first step you are almost done. Just select the site columns in the publishing wizard of InfoPath and all of your forms will publish their data to the same columns, no additional ones will be created and the values will appear correctly when the forms are submitted to the list. At the end, just group the form library entries view by content type or create views that filter by content type to enhance the user experience. It’s really that easy…

Thanks to maikl for this great entry!

Sunday, 01 February 2009 11:45:57 (W. Europe Standard Time, UTC+01:00)  #    -
Infopath | SharePoint
 Saturday, 22 November 2008


Save the workflow.  In Tag Properties of your Form Action Button, change the value property to “Sign Up”.  Go to your “onClick” event.  It should read something like this:

javascript: {ddwrt:GenFireServerEvent('__workflowStart={{7696F6EA-2079-4A53-A97B-CE61D99A02AB},New,{66402E3B-C94E-4E6F-9936-10E596CC5795},}')}

Modify it and add the following (see changes bold):

javascript: {ddwrt:GenFireServerEvent(concat('__workflowStart={{7696F6EA-2079-4A53-A97B-CE61D99A02AB},New,{66402E3B-C94E-4E6F-9936-10E596CC5795},ClassID=’,@ID,’}__redirect={MyClasses.aspx}'))}

This change will allow you to pass an input parameter into a workflow and redirect your employee to MyClasses.aspx page that has attendees list view filtered by Created field equals [Me].

Saturday, 22 November 2008 12:28:29 (W. Europe Standard Time, UTC+01:00)  #    -
 Sunday, 19 October 2008
stsadm extensions

Many thanks to Gary Lapointe who developed some very useful extensions for the SharePoint command line tool stsadm.exe.


Among other cool features with this extesions you are able to:

  • copy lists and list items between sites, sitecollection... including versions and more
  • move sites, create searchscopes, and a lot of more...

SharePoint Designer - Custom Workflow Activities

The team from codeplex did a great job again. They developed some very useful custom workflow activities for the SPD.

Please find them here:

This useful activities will include:
  • grant permissions on items
  • reset list permissions inheritance
  • check user permissions/groups
  • extended email features
  • and more ...

Sunday, 19 October 2008 10:04:04 (W. Europe Standard Time, UTC+01:00)  #    -
 Sunday, 24 August 2008
When your trying to add an Active directory import to your Sharepoint SSP and get an error when retrieving the schema you have to create the following registry key on your SharePoint server:
HKEY_LOCAL_MACHINE -> System -> CurrentControlSet -> Services -> NetLogon -> Parameters -> NeutralizeNT4Emulator (New DWord)
After creating the registry key you have to set the value of it to "1".
Following this procedure you will immediately be able to retrieve the schema and finish the step for creating the AD profile import.
Sunday, 24 August 2008 11:04:15 (W. Europe Standard Time, UTC+01:00)  #    -
 Monday, 18 August 2008

Site object Guidelines for acceptable performance Notes Scope of impact when performance degrades
Site collection 50,000 per Web application

Total farm throughput degrades as the number of site collections increases.


Web site

250,000 per site collection

You can create a very large total number of Web sites by nesting the subsites. For example, 100 sites, each with 1000 subsites, is 100,000 Web sites. The maximum recommended number of sites and subsites is 125 sites with 2,000 subsites each, for a total of 250,000 sites.

Site collection


2,000 per Web site

The interface for enumerating subsites of a given Web site does not perform well as the number of subsites surpasses 2,000.

Site view


5 million per library

You can create very large document libraries by nesting folders, using standard views and site hierarchy. This value may vary depending on how documents and folders are organized, and by the type and size of documents stored.



2,000 per view

Testing indicates a reduction in performance beyond two thousand items. Using indexing on a flat folder view can improve performance.

List view

Document file size

50MB (2GB max*)

File save performance is proportional to the size of the file. The default maximum is 50 MB. This maximum is enforced by the system, but you can change it to any value up to 2 GB.

Library, file save performance


2,000 per Web site

Testing indicates a reduction in list view performance beyond two thousand entries.

List view

Field type

256 per list

This is not a hard limit, but you might experience list view performance degradation as the number of field types in a list increases.

List view


2,000 per document library

4,096 per list

This is not a hard limit, but you might experience library and list view performance degradation as the number of columns in a document library or list increases.

Library and list view

Web Part

50 per page

This figure is an estimate based on simple Web Parts. The complexity of the Web Parts dictates how many Web Parts can be used on a page before performance is affected.


Monday, 18 August 2008 10:58:14 (W. Europe Standard Time, UTC+01:00)  #    -
 Wednesday, 14 May 2008

Jetzt nur kurz Verfügbar und in limitierter Auflage!

Designer Austria T-Shirts (Österreich T-Shirts) für Fans, Sportler und allen Österreichern.

Zu finden auf der Homepage

                                                Austria T-Shirts for Men and Ladies

Wednesday, 14 May 2008 18:28:52 (W. Europe Standard Time, UTC+01:00)  #    -
 Monday, 10 March 2008
Following error appears when opening a SharePoint list within the datasheet view:
The list cannot be displayed in Datasheet view for one or more of the following reasons:
  • a datasheet component compatible with Windows SharePoint Services is not installed
  • your browser does not support ActiveX controls
  • support for ActiveX controls is disabled
1.       close your Internet Explorer
2.       open your Start menu -> Run… -> ""regedit
3.       delete the following folder in the registry
Path: HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Internet Explorer\ActiveX Compatibility
Sub-Key: {65BCBEE4-7728-41A0-97BE-14E1CAE36AAE}

4.       Start Internet Explorer again and try!
Monday, 10 March 2008 19:03:18 (W. Europe Standard Time, UTC+01:00)  #    -
SharePoint | Office
About the author
DI(FH) Handler Christian

DI(FH) Handler Christian
Graz, Austria

SharePoint Consultant &
Information Manager

© Copyright 2018
<2009 February>
Total Posts: 19
This Year: 0
This Month: 0
This Week: 0
Comments: 59

Sign In
All Content © 2018, DI(FH) Handler Christian
Graz, Austria