Search Configuration

In order for your SharePoint site to be searchable, you must first create and configure a Search Service application. To do so, follow these steps:

1. Open Central Administration, and click on the Manage Service Applications link, under Application Management:
   
   
2. Click on the New icon in the ribbon (under the Create section), and select Search Service Application:
   
3. The following dialog will appear, with entry fields to enter information needed to create the new Search Service Application. Enter a Service Application Name, and select ‘None’ under FAST Service Application. For the Search Service Account, you can create a managed account to associate with the Search Service Application (I kept the default Network Service account selection, for simplicity).
   
4. You will then need to create a new application pool for the Search Admin Web Service. You can select an existing application pool by selecting one from the dropdown list, under the Use existing application pool selection. To create a new application pool, select the Create new application pool selection, and enter an appropriate name for your application pool. For the application pool security account, you can use a predefined account (I used the default Network Service account), or you can create a new managed account if you wish to have greater control over the service account.
   
5. You will also need to create an application pool for the Search Query and Site Settings Web Service. You can select an existing application pool by selecting one from the dropdown list, under the Use existing application pool selection. To create a new application pool, select the Create new application pool selection, and enter an appropriate name for your application pool. For the application pool security account, you can use a predefined account (I used the default Network Service account), or you can create a new managed account if you wish to have greater control over the service account. Press the OK button when you are ready to create the new search service application.
   
6. A dialog will appear when the system has successfully created the new search service application. Press OK to close this dialog.
7. Returning to Central Administration, you should now see two (2) new service applications.
   
8. The next step is to verify that the user(s) you selected as service accounts have the proper permissions for Search. Scroll down the list of service applications to find the User Profile Service Application and click on the whitespace next to it (so the ribbon changes). Click on the Administrators button in the ribbon, under the Operations section.
   
9. A dialog will appear, with a listing of all the administrator accounts. Find the account(s) you specified for the service accounts (when configuring the search service application), and verify that the Retrieve People Data for Search Crawler checkbox is checked. In this example, the NT AUTHORITY\NETWORK SERVICE account was used as the service accounts, so that is the only account I need to verify. Press OK when you are finished.
   
10. The next step is to verify that the service account(s) you selected as service accounts have read access to your SharePoint site. Go back to Central Administration, and under Application Management, click the Manage Web Applications link.
    
11. Click on whitespace next to the SharePoint – 80 web application and select the User Policy button in the ribbon (under the Policy section).
    
12. A dialog will appear. Verify your service account(s) have Full Read permissions. In this example, the NT AUTHORITY\NETWORK SERVICE account was used as the service accounts, so that is the only account I need to verify. Press OK when finished.
    

Crawling Configuration

Now that the service application is properly configured, the next step is to setup the search crawl, so content is included when a user performs a search.

1. Open Central Administration and click your search service application (under Application Management à Manage Service Applications).
   
2. You are now taken to the main area where you can specify all the configuration information for search in SharePoint 2010, including content sources, search crawls, search scopes, and crawl rules.
   
3. In order to setup a search crawl for a SharePoint site, click on the Content Sources link, under the Crawling section (on the left hand side of the page). This page will display the content sources for the search (Local SharePoint Sites is created by default). Right mouse click on Local SharePoint Sites to display the context menu, and select Edit.
   
4. The Edit Content Source page is displayed, and this is where you configure the content source. You are able to specify what URLs the content source will look through when crawling (under the Start Addresses section). You can also setup a crawl schedule for the content source, specify priority for the content source, as well as kick off a full crawl when you press the OK button.
   

Search Scopes

Search scopes define specific areas that users can search in, when performing searches from SharePoint. This gives you the flexibility to limit search results to specific content areas in your SharePoint environment.
Here are the following steps to configure a search scope. I am using a scope called Data Forms as an example, so you can repeat these steps for whatever search scope you wish to configure.

1. Create a content source that corresponds to the search scope you are configuring.
   
2. When you create the new content source, make sure you add the subsite location (or folder) in the Start Addresses that correspond to the area you want the search scope to crawl content for. Also select Custom – specify page depth and server hops options under Crawl Settings, with an unlimited page depth, so the crawler crawls all content under the start address you specify. Depending on how your content is structured, you may find it more appropriate to select one of the other crawl settings options. Press OK when finished.
   
3. You need to create a crawl rule to include the address that corresponds to your search scope, so the crawler knows to include the content. Click on Manage Crawl Rule, under the Crawling section (on the left hand side links) to navigate to the page to create crawl rules.
   
4. Click on New Crawl Rule, and enter the appropriate URL in the Path entry area. Select Include all items in this path, under the Crawl Configuration area. Selecting Exclude all items in this path will exclude the content in this rule. The three checkboxes are not necessary, unless you have specific data that has special crawling considerations. Press OK when finished.
   
5. The next step is to create the actual search scope. Click on the Scopes link under Queries and Results section (in the left hand links area). This will display a page that lists all the search scopes in the system.
   
6. Clicking on New Scope will display a page that allows you to create a new search scope. Give the new search scope a title. You can leave the Target Results Page selection to the default results page (unless you have a custom search results page created). Click OK when finished.
   
7. You now need to add a couple of rules to the search scope, so right mouse click the newly-created search scope, and select Edit Properties and Rules.
   
8. The Scope Properties and Rules page will display. This screen allows you to create rules that determine what content is included or excluded for this search scope.
   
9. Click on New Rule to create another new rule for this search scope. For our rule, we are including all the content from the appropriate URL that corresponds to the subsite for the search scope. Select Web Address from the Scope Rule Type section, and select the Folder option from the Web Address section, and enter the appropriate URL. Under the Behavior section, select the Include option. Press OK when finished.
   
10. As a last step, make sure you run full crawls on the entire site. This should update the crawled content, and you should be able to perform searches in your SharePoint environment.

Powershell commands to sharepoint 2010

Powershell Commands

MOSS - stsadm commands
SP2010- powershell scripts

stsadm –o addsolution –filename “D:\Deploy\MySharePointSolution.wsp“

We used the following command to deploy the solution once installed to a specific web
application:

stsadm –o deploysolution –name MySharePointSolution.wsp –url http://myspwebappp –
allowgacdeployment –immediate

If we would upgrade an existing solution, we would use the following:

stsadm –o upgradesolution –name MySharePointSolution.wsp –
filename “D:\Deploy\MySharePointSolution.wsp” -immediate

And finally, we used the following commands to retract and delete a specific solution from the
web application:

stsadm –o retractsolution –name MySharePointSolution.wsp –url http://myspwebapp –immediate
stsadm –o deletesolution –name MySharePointSolution.wsp

Now, let us see how we could do above operations with PowerShell. For this, we use the
following PowerShell commands:

Add-SPSolution “D:\Deploy\MySharePointSolution.wsp“
Install-SPSolution –Identity MySharePointSolution.wsp –WebApplication http://myspwebapp –
GACDeployment

If you would like to add the solution as sandboxed, you would use the Install-SPUserSolution
command instead. To upgrade a solution, we specify which solution is to be updated and with
which new solution file:

Update-SPSolution –Identity MySharePointSolution.wsp –LiteralPath “D:\Deploy\MySharePointSolution.wsp” –GacDeployment

To retract and remove a solution, we use the following commands:

Uninstall-SPSolution –Identity MySharePointSolution.wsp –WebApplication http://
myspwebapp
Remove-SPSolution–Identity MySharePointSolution.wsp

Working with features

Similarly, commands exist for working with features. The stsadm equivalents:

stsadm –o activatefeature –name MyFeatureName –url http://myspwebapp
stsadm –o deactivatefeature –name MyFeatureName –url http://myspwebapp

Needless to say, there are easy equivalents in PowerShell:

Enable-SPFeature –Identity MyFeatureNameOrGuid –url http://myspwebapp
Disable-SPFeature –Identity MyFeatureNameOrGuid –url http://myspwebapp

Interview Questions in SharePoint InfoPath

>What is an InfoPath?InfoPath is an XML based electronic forms development product.

What are the benefits of InfoPath 2007?
Prior to the introduction of Office 2007, the InfoPath client application, like other Office products, had to be installed on every user’s computer.

In order to develop and use a form:

1.The form had to be designed using InfoPath.
2.The resulting form template should be hosted in a network file share, or installed in individual user machines, or uploaded into a form library in SharePoint, from where users could fill the forms.
3.Filling up forms required InfoPath to be installed on the client machine.
4.Developing a connected InfoPath was complicated for end users.
5.Developers didn’t have an integrated development platform.
6.The product didn’t integrate with other Office products such as Word and Excel.
Benefits of Office 2007
This introduced a new server-side runtime to host InfoPath forms known as InfoPath Form Services. The new capabilities include:

1.Ability to convert Word and Excel documents into InfoPath form templates.
2.With the help of InfoPath form services, a InfoPath form can be browser enabled.
3.The new InfoPath forms can be embedded in Outlook.
4.The form can be built once and rendered in different modes and devices, .i.e., Design Once.
5.Introduction of the document information panel. I.e., an InfoPath form that is hosted inside Word 2007 or PowerPoint 2007 can be used to edit document properties.
6.Introduction of logic inspector. The components which provide visual view of all the rules embedded in the form.
7.The new InfoPath forms can be published to content types.
8.Introduction of template parts, i.e., reusable code sections.
9.Introduction of an integrated development environment inside Visual Studio 2005 using Visual Studio Tools for Office.
10.The information right management can be used to protect sensitive data in the form.

>What is the structure of an InfoPath form template?
The InfoPath form template (.xsn file) is actually a CAB file [can also be considered a zip file] containing the different component files of which InfoPath is built. Following are some of the important files contained inside that CAB file:

1..xsf
2..xsl
3..xsd
4..dll
5..htm and other resource files.

>What is a .xsf file? Or what is the Form Definition file [XSF file]? Or what is a manifest.xsf file?
It’s a manifest file that provides the basic definition of other form files. This file contains XML code that describes all aspects of a form. The .xsf file is automatically created by InfoPath when a new form template is created and saved in Design mode. As form designers and developers change the form template or add new features to it, InfoPath updates the .xsf file to reflect those changes.

Note: The .xsf file can also be modified directly by using any text or XML editor, such as Microsoft Notepad. However, care should be taken when making modifications to the .xsf file: if an invalid entry is made, the form that the file is associated with may be left in an unusable state. However, some customizations can be made to the .xsf file that cannot be generated in Design mode.

The .xsf file is the core file of an InfoPath form because it contains information about the form as a whole. Some of the data it contains includes processing metadata, user interface customizations, schema definitions, views, business logic declarations, event handlers, and deployment information.

The following are some of the items that the .xsf file contains:

•A unique identifier for the form
•Global metadata information about the form, including deployment and publishing information
•The XML schema definitions for the XML document that the form produces
•Definition of views and their associated user interface components (menus, toolbars, and buttons)
•Definition of editing actions that are made available using user interface components, and how their availability will be determined contextually
•Workflow and routing information
•Event handlers, data validation, and business logic that is associated with individual XML nodes of the form’s underlying XML document, or with the XML document itself
•Event handlers associated with the form as a whole
•Packaging information about all of the files contained within the form template
The .xsf file is based on the xsf namespace. Its root element is the xDocumentClass element.

 
<?xml version=”1.0″ encoding=”UTF-8″?>
<!–
This file is automatically created and modified by Microsoft Office InfoPath.
Changes made to the file outside of InfoPath might be lost if the form template
is modified in InfoPath.
–>
<xsf:xDocumentClass trustSetting=”automatic” solutionFormatVersion=”2.0.0.0″ 
   dataFormSolution=”yes” solutionVersion=”1.0.0.6″ productVersion=”12.0.0″
   publishUrl=”" 
   name=”urn:schemas-microsoft-com:office:infopath:Unpacked:-dataFormSolution”
   xmlns:xsf=”http://schemas.microsoft.com/office/infopath/2003/solutionDefinition“ 
       xmlns:xsf2=”http://schemas.microsoft.com/office/
                   infopath/2006/solutionDefinition/extensions” 
       xmlns:msxsl=”urn:schemas-microsoft-com:xslt” 
       xmlns:xd=”http://schemas.microsoft.com/office/infopath/2003“ 
       xmlns:xsi=”http://www.w3.org/2001/XMLSchema-instance“ 
       xmlns:xdUtil=”http://schemas.microsoft.com/office/infopath/2003/xslt/Util“ 
       xmlns:xdXDocument=”http://schemas.microsoft.com/office/infopath/2003/xslt/xDocument“ 
       xmlns:xdMath=”http://schemas.microsoft.com/office/infopath/2003/xslt/Math“ 
       xmlns:xdDate=”http://schemas.microsoft.com/office/infopath/2003/xslt/Date“ 
       xmlns:xdExtension= xmlns:xdEnvironment= 
          “http://schemas.microsoft.com/office/infopath/2006/xslt/environment“ 
       xmlns:xdUser=”http://schemas.microsoft.com/office/infopath/2006/xslt/User“ 
       xmlns:q=”http://schemas.microsoft.com/office/infopath/2003/ado/queryFields“ 
       xmlns:d=”http://schemas.microsoft.com/office/infopath/2003/ado/dataFields“ 
       xmlns:dfs=”http://schemas.microsoft.com/office/infopath/2003/dataFormSolution“ 
       xmlns:my=”http://schemas.microsoft.com/office/infopath/2003/myXSD/2007-03-19T15:02:59“ 
       xmlns:xdado=”http://schemas.microsoft.com/office/infopath/2003/adomapping“>
  <xsf:package>
    <xsf:files>
      <xsf:file name=”schema.xsd”>
        <xsf:fileProperties>
          <xsf:property name=”editability” 
             type=”string” value=”none”></xsf:property>
          <xsf:property name=”namespace” type=”string” 
             value=”http://schemas.microsoft.com/office/infopath/
                    2003/dataFormSolution”></xsf:property>
          <xsf:property name=”rootElement” type=”string” 
                value=”myFields”></xsf:property>
          <xsf:property name=”useOnDemandAlgorithm” 
             type=”string” value=”yes”></xsf:property>
        </xsf:fileProperties>
      </xsf:file>
      <xsf:file name=”schema1.xsd”>
        <xsf:fileProperties>
          <xsf:property name=”namespace” type=”string” 
             value=”http://schemas.microsoft.com/office/infopath/2003/ado/dataFields“>
          </xsf:property>
          <xsf:property name=”editability” type=”string” 
                  value=”none”></xsf:property>
        </xsf:fileProperties>
      </xsf:file>
      <xsf:file name=”schema2.xsd”>
        <xsf:fileProperties>
          <xsf:property name=”namespace” type=”string” 
             value=”http://schemas.microsoft.com/office/infopath/2003/ado/queryFields“>
          </xsf:property>
          <xsf:property name=”editability” type=”string” 
             value=”none”></xsf:property>
        </xsf:fileProperties>
      </xsf:file>
      <xsf:file name=”template.xml”></xsf:file>
      <xsf:file name=”sampledata.xml”>
        <xsf:fileProperties>
          <xsf:property name=”fileType” type=”string” 
                      value=”sampleData”></xsf:property>
        </xsf:fileProperties>
      </xsf:file>
      <xsf:file name=”view1.xsl”>
        <xsf:fileProperties>
          <xsf:property name=”lang” type=”string” value=”1033″></xsf:property>
          <xsf:property name=”queryView” type=”string” value=”yes”></xsf:property>
          <xsf:property name=”componentId” type=”string” value=”12″></xsf:property>
          <xsf:property name=”xmlToEditName” type=”string” value=”12″></xsf:property>
          <xsf:property name=”mode” type=”string” value=”1″></xsf:property>
        </xsf:fileProperties>
      </xsf:file>
    </xsf:files>
  </xsf:package>
  <xsf:importParameters enabled=”yes”></xsf:importParameters>
  <xsf:extensions>
    <xsf:extension name=”SolutionDefinitionExtensions”>
      <xsf2:solutionDefinition runtimeCompatibility=”client server” 
                   allowClientOnlyCode=”no”>
        <xsf2:offline openIfQueryFails=”yes” cacheQueries=”yes”></xsf2:offline>
        <xsf2:server isPreSubmitPostBackEnabled=”no” isMobileEnabled=”no” 
                   formLocale=”en-US”></xsf2:server>
      </xsf2:solutionDefinition>
    </xsf:extension>
  </xsf:extensions>
  <xsf:views default=”View 1″>
    <xsf:view name=”View 1″ caption=”View 1″>
      <xsf:mainpane transform=”view1.xsl”></xsf:mainpane>
      <xsf:editing>
        <xsf:xmlToEdit name=”DimCustomer_7″ 
              item=”/dfs:myFields/dfs:dataFields/d:DimCustomer” 
              container=”/dfs:myFields”>
          <xsf:editWith caption=”DimCustomer” 
                  xd:autogeneration=”template” component=”xCollection”>
            <xsf:fragmentToInsert>
              <xsf:chooseFragment parent=”dfs:dataFields” innerFragment=”d:DimCustomer”>
                <d:DimCustomer CustomerKey=”" Title=”" 
                     FirstName=”" MiddleName=”" LastName=”" 
                     BirthDate=”" MaritalStatus=”" 
                     Suffix=”" Gender=”" EmailAddress=”" 
                     AddressLine1=”" AddressLine2=”"></d:DimCustomer>
              </xsf:chooseFragment>
            </xsf:fragmentToInsert>
          </xsf:editWith>
        </xsf:xmlToEdit>
      </xsf:editing>
      <xsf:menuArea name=”msoInsertMenu”>
        <xsf:menu caption=”&amp;Section”>
          <xsf:button action=”xCollection::insert” 
             xmlToEdit=”DimCustomer_7″ caption=”DimCustomer”></xsf:button>
        </xsf:menu>
      </xsf:menuArea>
      <xsf:menuArea name=”msoStructuralEditingContextMenu”>
        <xsf:button action=”xCollection::insertBefore” xmlToEdit=”DimCustomer_7″ 
              caption=”Insert DimCustomer before” showIf=”immediate”></xsf:button>
        <xsf:button action=”xCollection::insertAfter” xmlToEdit=”DimCustomer_7″ 
              caption=”Insert DimCustomer after” showIf=”immediate”></xsf:button>
        <xsf:button action=”xCollection::remove” xmlToEdit=”DimCustomer_7″ 
              caption=”Remove DimCustomer” showIf=”immediate”></xsf:button>
        <xsf:button action=”xCollection::insert” xmlToEdit=”DimCustomer_7″ 
              caption=”Insert DimCustomer” showIf=”immediate”></xsf:button>
      </xsf:menuArea>
    </xsf:view>
  </xsf:views>
  <xsf:applicationParameters application=”InfoPath Design Mode”>
    <xsf:solutionProperties 
      fullyEditableNamespace=”http://schemas.microsoft.com/office/
                              infopath/2003/myXSD/2007-03-19T15:02:59″ 
      lastOpenView=”view1.xsl” 
      lastVersionNeedingTransform=”1.0.0.3″></xsf:solutionProperties>
  </xsf:applicationParameters>
  <xsf:documentSchemas>
    <xsf:documentSchema rootSchema=”yes” 
       location=”http://schemas.microsoft.com/office/infopath/2003/
                 dataFormSolution schema.xsd”></xsf:documentSchema>
    <xsf:documentSchema 
       location=”http://schemas.microsoft.com/office/infopath/2003/ado/
                 dataFields schema1.xsd”></xsf:documentSchema>
    <xsf:documentSchema 
       location=”http://schemas.microsoft.com/office/infopath/2003/ado/
                 queryFields schema2.xsd”></xsf:documentSchema>
  </xsf:documentSchemas>
  <xsf:fileNew>
    <xsf:initialXmlDocument caption=”Unpacked” 
       href=”template.xml”></xsf:initialXmlDocument>
  </xsf:fileNew>
  <xsf:query>
    <xsf:adoAdapter connectionString=”Provider=SQLOLEDB.1;Integrated Security=SSPI;
                           Persist Security Info=True;Initial Catalog=AdventureWorksDW;
                           Data Source=[Source];Use Procedure for Prepare=1;
                           Auto Translate=True;Packet Size=4096;Workstation ID=[ID];
                           Use Encryption for Data=False;
                           Tag with column collation when possible=False” 
           commandText=”select &quot;CustomerKey&quot;,&quot;Title&quot;, 
                        &quot;FirstName&quot;,&quot;MiddleName&quot;,
                        &quot;LastName&quot;,&quot;BirthDate&quot;,
                        &quot;MaritalStatus&quot;,&quot;Suffix&quot;,
                        &quot;Gender&quot;,&quot;EmailAddress&quot;,
                        &quot;AddressLine1&quot;,&quot;AddressLine2&quot; 
                        from &quot;dbo&quot;.&quot;DimCustomer&quot; 
                        as &quot;DimCustomer&quot;” 
           queryAllowed=”yes” name=”Main connection” 
           submitAllowed=”no”></xsf:adoAdapter>
  </xsf:query>
</xsf:xDocumentClass>

The xsf:extensions element is used to bind the form to other platforms, like SharePoint.

>What are the Form View files in InfoPath? Or XSL files?
The .xsl file is the form view file that provide a way to represent different information, depending upon the runtime environment and other factors, including the security profile of end users. They are based on XML stylesheets that can be formatted depending upon the condition. [Conditional formatting is itself an inbuilt property of XSL.]

>What is an .XSD file in InfoPath?
It is the form schema file of InfoPath. It determines the format of data that InfoPath recognizes.

>Where does data get stored in an InfoPath form?
Data is stored in XML files.

>Explain in brief the architecture of InfoPath forms?
An InfoPath form template is actually a CAB File containing different component files.

Below is a list of files which forms part of an InfoPath template.

•.xsf file: A manifest file that describes the basic definition of other form files.
•.xsl file: Defines the transformation for data into different views.
•.xsd file: Defines the data source schema.
•.dll file: Carries the custom logic built into .NET or COM.
•.htm and other resource files: Custom HTML resource files and other resources for the form.
When a form template is uploaded using Administrative deployment, the template is stored in the content database of the site. Office Forms Services provide a server-runtime environment for InfoPath Forms Services. While running on the browser, all rules, validations, and calculations are executed in the browser using client-side script.

All business logic is executed on the server. So when a browser requests business logic execution, a postback is executed using low cost XMLHTTP. FormsServer.aspx is an Infopath Forms Services page that accesses the form’s data from the content database and renders it to the client.

>What are the main components of InfoPath Form Services that are responsible for rendering the .xsn file on browsers?
The InfoPath Form Services consists of four components that are responsible for rendering the .xsn file on browsers:

1.ASP.NET modules: Return HTML to the browser.
2.Infopath Form Services HTTPHandlers: Forward requests from IIS to the page generator.
3.Converter: Responsible for converting the .xsn file into .aspx pages.
4.Page generator: Communicates with internal data sources, and is responsible for processing postback data from the browser and maintaining session states.

>What are the steps to create a Template Part?
In the Design a Form dialog box, you can choose to design a template part instead of a form template. If you do this, InfoPath features that aren’t supported in template parts are either hidden or disabled so that you aren’t tempted to use them in your template part.

1.On the File menu, click Design a Form Template.
2.In the Design a Form Template dialog box, click Template Part.
3.In the Based on gallery, do one of the following:
?To define the data source (Data source: the collection of fields and groups that define and store the data for an InfoPath form. Controls in the form are bound to the fields and groups in the data source.), as you design the template part, click Blank.
?To use an XML document (.xml) file or an XML schema (XML schema: A formal specification, written in XML, that defines the structure of an XML document, including element names and rich data types, which elements can appear in combination, and which attributes are available for each element.) (.xsd) file as the data source for the template part, click XML or Schema.
Note: If you base your template part on an XML document or XML schema, InfoPath populates the Data Source task pane with fields (field: an element or attribute in the data source that can contain data; if the field is an element, it can contain attribute fields; fields store data that is entered into controls) and groups (group: an element in the data source that can contain fields and other groups; controls that contain other controls, such as repeating tables and sections, are bound to groups) that map to XML elements (XML element: an XML structure that consists of a start tag, an end tag, and the information between the tags; elements can have attributes and can contain other elements) in the document or schema. The data source is locked. Depending on the document or schema, you might not be able to add new fields or groups to part or all of the data source, or to change certain aspects of existing fields and groups.

?To make your template part compatible with InfoPath Forms Services, select the Enable browser-compatible features only check box.
?Click OK.
A new template part opens in InfoPath.

?Design your template part.
?When you finish designing the template part, on the File menu, click Save.
How to reuse Template Parts
If you want to base the design of a new template part on an existing template part, you must open the existing template part, change its name in the Template Part Properties dialog box, and then save the new template part with another, distinguishing file name. When you change the template part name in the Template Part Properties dialog box, the template part ID is updated automatically. This ID further distinguishes one template part from another.

1.On the File menu, click Design a Form Template.
2.Under Open a form template in the Design a Form Template dialog box, click On My Computer.
3.In the Files of type list, click InfoPath Template Parts.
4.Browse to and click the template part that you want to open, and then click Open.
5.On the File menu, click Properties.
6.In the Template Part Properties dialog box, enter a new name in the Template part name box.
When you do this, the identifying text in the Template part ID box reflects the new name. The template part ID is generated automatically by InfoPath. It must be unique for each new template part that you create.

7.On the File menu, click Save As, and enter a new file name for the template part.
What is Document Information Panel?
When you create a document with Office Word 2007, Office Excel 2007, or Office PowerPoint 2007, a Document Information Panel is created for you automatically. This default Document Information Panel includes standard properties, such as Author, Title, and Subject. Alternatively, you can add custom properties by designing a Document Information Panel from scratch and then associating it with a document, or by customizing an existing Document Information Panel.

A document information panel is a form that is displayed within the client application, and which contains fields for the document metadata. Document information panels enable users to enter important metadata about a file anytime they want, without having to leave the Microsoft Office system client application.

>How many sections are there inside the InfoPath Form Services element?
There are five sections:

1.Manage Form Templates
2.Configure InfoPath Services
3.Upload form templates
4.Manage Data Connection files
5.Manage the Web Service proxy

>How is form session state maintained?
The InfoPath Form Services can maintain data in two modes:

1.SQL Server database: This approach is termed as using Session State Services.
2.ASP.NET view states stored in the client side: Termed form view.
Points to be noted: The application needs to be associated with the Shared Service Provider.

>When to use which session state mode?
Session State Service mode [SQL Server database] is recommended for low bandwidth users, as the form view states hamper the performance for low bandwidth. Whereas, Form View can be used for environments with small groups of users.

The administrator can also enter a value for the session data size allowed for Form View State. InfoPath Form Services will automatically revert to Session State Service when session data size exceeds the value associated with the form view mode.