Go to “Software\Microsoft\Windows\CurrentVersion\App Paths\InfoPath.exe” in your registry (if infopath.exe does not exist create it), there you will see a “Path” value if you do not then create a new string value with the the name “Path” and in the “Value Data” portion add the path to the infopath exe folder, for example, “C:\Program Files (x86)\Microsoft Office\Office12\

Also in the ‘Default’ string add the path with the actual filename ie. “C:\Program Files (x86)\Microsoft Office\Office12\infopath.exe”

Now close K2 designer & reopen, you will now be able to edit Infopath forms from within K2

Step 1:Add the Contact Selector control to InfoPath – this only has to be done once within InfoPath, then it will be available for future forms.
1. From the Controls task pane, click on “Add or Remove Custom Controls…” then click Add.
2. Select “ActiveX Control” then click Next.
3. Locate “Contact Selector” in the list, select it, then click Next.
4. Ensure “Don’t install a .cab file” is selected, click Next.
5. Set the Binding Property to “Value”, click Next.
6. In the drop-down menu for field or group type, select “Field or Group (any data type)” then click Finish.
7. Click Close, click OK.

Step 2: Add a data connection – this must be done for each new form created.
There is some preliminary work here, first you have to create an XML file and save it. Open notepad and paste: <Context siteUrl="http://<your site url>“/>. Save the file as Context.xml. This same file can be used each time you create a new data connection of this type.

1. In InfoPath click Tools>Data Connections, then click the Add button.
2. Select “Create a ne connection to:” and “Receive data”, click Next.
3. Select “XML Document” and click Next.
4. Browse to the Context.xml file you created in notepad, click Next.
5. “Include the data as a resource file in the form template or template part” should be selected, click Next.
6. Leave the connection named “Context” and automatically retrieve the data when the form is opened, click Finish.

Step 3: Add the control to the form.
1. Drag and drop the control to the desired location on the form.
2. Go to the Data Source task panel.
3. Modify the data source so that the group that is created by the new control is exactly like the data source pictured. The “Person” group is a repeating group, the field names are case sensitive and must be exactly as shown below.

The control on the form that can be used to lookup users in Active Directory. Which is pretty nice if the DisplayName and Account ID are all the information that is needed. Here’s how to get more:

Step 4: Add your rules.

1. While in the Data Source task pane, create a field in the main data source (but not in your Contact Selector group) and name it something meaningful. I use HiddenAccountName to keep it distinct from the field in the Contact Selector group.
2. Click the drop-down menu on your data field in the data source, click “Properties”, then click the function button to set the default data.
3. Click “Insert Field or Group…”
4. Select the AccountId field from your contact selector group, then click OK on each window until the Field or Group Properties is showing(2 times).

5. Click the Rules and Merge tab, click Add.
6. Don’t set any conditions, this rule always applies, click Add Action.
7. Select “Set a field’s value” from the drop down.
8. Click the data source button next to the “Field” field.
9. Select the data source you wish to use for the lookup in the drop-down menu. *Be sure you don’t re-use the connection for the current user data if you have one in this form.
10. Expand the query fields and sub-groups, then select “Account Name”, click OK.

11. Click the function button next to the “Value” field, then click Insert Field or Group.
12. Select the current field you created in step 1 above, click OK until all windows are closed (3 times).
13. In the data source pane, use the drop-down menu to select the data source that you will use to look up another user’s profile information.
14. Expand the query fields and all sub groups until the field AccountName is visible. Click the drop-down menu on the AccountName field, then click properties.
15. Click on the Rules and Merge tab, then click Add.
16. Do not set any conditions, this rule will always apply. Click Add Action.
17. Select “Query using a data connection” from the drop-down menu.
18. Select the data connection you wish to use for the lookup from the drop-down menu (it should be the same as the data source listed in the task pane), then click OK.
19. Click Add Action.
20. Select “Set a field’s value” from the drop-down.
21. Click on the data source button next to the “Field” field.
22. Ensure you change the data source to “Main” and select the field you wish to auto-populate, then click OK.
23. Select the function button next to the “Value” field, then click Insert Field or Group.
24. Expand the data fields group and all sub-groups, select “Value”, click Filter Data, then click Add.
25. Where the “Value” field is defaulted, click the drop-down and select “Select a field or group…”
26. Select the “Name” field under “Property Values”, click OK.
27. In the third field, click the drop-down and select “Type Text”.
28. Type the property from the user profile that you wish to enter in the field, then click OK until you are back to the “Rule” window (5 times).

Repeat steps 19 through 28 for all fields that you wish to have auto-populate with the other user’s data. It is important that “Query using a data connection” remain the first action. If it is not the first action, highlight that action and move it up until it is the first.

29. Click OK on all windows until you are back to your form.

Now you have a contact selector that allows a user to look up another user in AD and have their profile properties auto-populate fields on the form.

Source: http://www.pointgowin.com

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.

You want to a user file in your InfoPath form to auto populate with the current user who is logged on, follow these steps:

1) Create a new form by Designing a New Form Template

2)Choose blank form

3) Add a text box to the form (Field1)

4) Go to Tools | Form Options

5) Go to the Open Behavior section and click on Rules

6) Add Action to Set a Field’s Value

7) Choose the field you added above as the field to populate

8 ) For the value, click on the Fx button and choose Insert Function

9) View All in the Categories drop down

10) At the bottom you’ll see userName, pick it

11) The formula that gets dropped in is userName()

12) Preview the form, you’ll see your UserName in field1

Upgrade to IE7 on the desktop. There are performance benefits to moving up to IE7. In some cases the difference is 5x to 10x.

Make sure the IE cache is big enough so our necessary 250K of content and scripts needed for the browser to render Forms Services forms – doesn’t get pushed out the cache after an initial download. Customers with extraordinarily low thresholds (like ~1MB) will have issues. Disk is cheap, increase that value to something reasonable like 10% of disk.

A good perf trick is to populate dropdowns via an XML file (especially if they are somewhat static) that is made a part of the form XSN. We can cache that on the server and get good load performance optimization. You can always republish the solution when the data changes.

If you have to download data via a data connection for a dropdown list or calculation, try to dynamically build a filtered query (via code) so that you are as efficient as possible with what you are retrieving.

Try to minimize On_Load activities like queries unless absolutely necessary.

Conditional visibility logic has some known performance problems. A hotfix is available http://support.microsoft.com/kb/937206, which is manifested in a modifed 250K initial download when accessing Forms Services the first time. The performance issue is related to the IE Script Engine and occurs at the browser level, not server-side.

Instead of using conditional visibility logic, try implementing multiple views on a form. Splitting complex views into more than 1 view provides noticeable performance improvements.

Rich Text controls are noticeably slower in IE vs. Firefox, because Rich Text editing in Forms Services is an IE-only feature. Limiting the number of Rich Text controls shown in the same view can really help form performance.

Try to prevent unnecessary roundtripping between the form browser and the server. There are several round trip switches available on controls. See the Browser Forms Tab on a given control to expose finer-grained options over the behavior. Note what the warning messages you receive say about the form’s potential round trip behavior when admin deploying the form. It will tell you when multiple server roundtrips will be likely to occur when using your form.

If you have to do roundtrips to the server, try to have them triggered by buttons, so that the users know they initiated the wait themselves. This UI trick can tend to reduce user dissatisfaction with the form performance.

Try not to treat an InfoPath form as a full, rich VB application. It’s not designed to be performant in that use case.
The more declarative logic (heavy use of rules, etc.) and managed code you have in the form, the slower it will be. Try and follow the KISS method if at all possible (Keep it Simple, Stupid).

Consider breaking out the server role of Forms Services to another machine on the MOSS farm. Services such as indexing and query serving, or high file I/O operations can really impact the ability of Forms Services to get a time slice and perform properly.