Controls on the InfoPath Task Edit Form Not Persisting Values

The SharePoint 2010 Visual Studio workflow uses an InfoPath form as the task edit form. On the form, values of some of the controls are persisted once the task edit form is submitted, but values of some other ones are not. For instance, input a value into a textbox then submit the task edit form, then open the task edit form again, the textbox is empty, the inputted value is gone.

It turns out that the problem is caused by the column name of the task list of the workflow. Let's say there is a textbox on the InfoPath task edit form, the textbox is bound to ClientName field and default value for ClientName field is ows_ClientName via the ItemMetadata.xml file. If the workflow task list has a column named ClientName, then the value of the textbox is not persisted. For unknown reason, the workflow engine can't process ExtendedProperties["ClientName"] correctly.

Solution: The column name of the workflow task list should not be the same name from ItemMetadata.xml file, without the ows_ prefix, if the value of the control bound to the entry in ItemMetadata.xml file needs to be persisted.

How to retrieve a reference to the SearchServiceApplicationProxy

Excerpt from this page:
http://dotnetmafia.sys-con.com/node/1498722/mobile

I think the new best practice will be to pass a reference to the SearchServiceApplicationProxy.  The trick of course is getting that reference.  First, you need to determine the name of your Search Service Application.  For a typical Enterprise Search installation it is called Search Service Application.  However, it can be called anything depending on how you configured SharePoint.  For FAST, it might be called something like FAST Content SSA.  Go to Central Administration –> Service Applications and take a look.

The proxy will usually have the same name as the Service Application, so in my case here the name of my proxy is Search Service Application.  Now we just can’t get a reference to the SearchServiceApplicationProxy directly.  We have to go through the SearchQueryAndSiteSettingsServiceProxy class first.  According to the SDK, the function of going through this service is to ensure queries are load balanced.  Here is how you get a reference to the query and settings proxy.  It also assumes this code is executing on one of the servers in the farm.

SearchQueryAndSiteSettingsServiceProxy settingsProxy = SPFarm.Local.ServiceProxies.GetValue<SearchQueryAndSiteSettingsServiceProxy>();

Now that we have a reference to the settings proxy, we can get a reference to the SearchServiceApplicationProxy with the name of the proxy that we saw above.  Change the name to match whatever yours is called.

SearchServiceApplicationProxy searchProxy = settingsProxy.ApplicationProxies.GetValue<SearchServiceApplicationProxy>("Search Service Application");

Now you can pass this proxy to the constructor of the KeywordQuery or FullTextSqlQuery.

Best Practices to Change App Pool Account for SharePoint Web Application

Basically, you should make the change via Central Admin/Security/Configure service accounts. After you make the change on that page (Credential Management), you need to do "iisreset /noforce" on all SharePoint servers.

SharePoint makes lots of changes behind the scene after you make the change on the Credential Management page. This link gives a very good rundown.

How to Auto-Populate a SharePoint 2010 Contacts list from User Profile Data

How to Auto-Populate a SharePoint 2010 Contacts list from User Profile Data from C5 Insight