.Net Framework 3.5 SP1 and SharePoint Search/InfoPath/Etc.

Recently, I installed .NET framework 3.5 SP1 onto my production SharePoint WFE after thoroughly testing a new AJAX based field control I had developed.  In my staging and development environments, I encountered no issues with the framework itself, however, once I installed on production, a couple issues arose:

• Administrator approved InfoPath forms with custom code were causing errors (no indication of what the error was)
• Search Service was failing to crawl content with the error "Access Denied."

After some Googling, I came across a MS KB article , and an MSDN blog both referring to a security feature in IIS 6 called "loopback check."  This feature was added (also present in IIS 5.1) to prevent reflection attacks on the server.  Please see the blog entry by jiruss for more information on this feature.

Of the two workarounds listed, either disabling the loopback check, or modifying the host names specified in the registry, I believe modifying the host names to be the best solution.  I agree with jiruss in that completely disabling the loopback check increases the attack surface area of your system, and should be avoided.

The actual modifications I made were to add the URL/host headers/AAM mappings for my various sites (main portal and mysites were the only two that did not use the machine name in AAM) to a newly created "Multi-String Value" registry key called BackConnectionHostNames (each entry on a separate line) at the registry path:

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Lsa\MSV1_0

Hope this helps any people experiencing "Access Denied" related issues after installing .NET framework 3.5 SP1.

Enjoy!

--andrew

Customized Input Forms: The JavaScript Approach

Correction [02.13.2009]: I have recently been informed of an issue with field values not saving when they are disabled for the user. Please see my post here for updated code.

If any of you have had to customize the input forms for lists or libraries in SharePoint, you'll know that it is not easy. You can customize the form with a custom list form web part, but you better not delete the original list form web part, otherwise your list gets hosed. You can have both on the page (with the original web part hidden), but then you lose attachment support with JavaScript errors. If you create a new page without the original list form web part, then you get a nice JavaScript alert saying that the form has been customized to not allow attachments. If you used the custom list form web part, then you might find it cumbersome and tedious to make changes when new columns are added. I have tried countless recommendations for modifying the list input form, and none of them really seemed to work cleanly and effectively. Until I stumbled across the forum discussion located here on MSDN Forums.

Of all of the ideas proposed in this forum topic, I found tscheifler's usage of JavaScript quite intriguing. There were some limitations that I found when implementing their exact solution (most notably around disabling columns of type: Lookup, Date and Time, and Multiple lines of Text). Extending this, and incorporating various other bits of information lying about the web, I ended up with a solution I am quite happy with. This assumes you have an existing list with several fields you would like to hide/disable for certain user groups. We will begin by modifying the "NewForm.aspx" page, but these steps will work for any of the input forms:

1. Open the "New Form" for the list and remove all query string variables (should end up with http://server/site/listname/NewForm.aspx)
2. Append "?ToolPaneView=2" onto the end of the url (http://server/site/listname/NewForm.aspx?ToolPaneView=2)
   
   Note: this places the page into "Add a Web Part" view
3. Add a new "Content Editor Web Part"(CEWP) to the page after the existing web part
4. Modify the source view of the CEWP to include this code:
   

   <SCRIPT LANGUAGE="JavaScript">
   <!--
   function disableChildren(currentElement)
   {
   if (currentElement)
   {
   if(currentElement.tagName == "IFRAME")
   {
   frm = window.frames[currentElement.id].document;
   disableChildren(frm.getElementsByTagName("html")[0]);
   }
   var i=0;
   var currentElementChild=currentElement.childNodes[i];
   while (currentElementChild)
   {
   disableChildren(currentElementChild);
   i++;
   currentElementChild=currentElement.childNodes[i];
   }
   if (currentElement.tagName)
   {
   currentElement.setAttribute("disabled", "true");
   currentElement.setAttribute("contentEditable",
   "false");
   currentElement.setAttribute("onclick", "");
   currentElement.removeAttribute("href");
   }
   }
   }
   
   function hideRowsAfter(currentRow)
   {
   row = currentRow.nextSibling
   while (row)
   {
   row.style.display = "none";
   row = row.nextSibling;
   }
   }
   
   function findControl(FieldName, opp)
   {
   FieldName = "FieldName=\"" + FieldName + "\"";
   //get all comments
   var arr = document.getElementsByTagName("!");
   for (var i=0;i < arr.length; i++ ) 
   {
   // now match the field name
   if (arr[i].innerHTML.indexOf(FieldName) >= 0)
   {
   switch(opp) 
   {
   case 0:  //disable all children
   disableChildren(arr[i].parentNode.parentNode);
   break;
   case 1:  //hide row
   arr[i].parentNode.parentNode.style.display="none";
   break;
   case 2:  //hide all rows after current
   hideRowsAfter(arr[i].parentNode.parentNode);
   break;
   default:
   break;
   }
   }
   }
   }
   
   function disableControls(inputArray)
   {
   for (var i=0; i < inputArray.length; i++)
   {
   findControl(inputArray[i], 0);
   }
   }
   
   function hideControls(inputArray)
   {
   for (var i=0; i < inputArray.length; i++)
   {
   findControl(inputArray[i], 1);
   }
   }
   
   function hideControlsAfter(input)
   {
   findControl(input, 2);
   }
   
   //Usage:
   // disableControls(["Field Name 1", "Field Name 2"..]);
   // hideControls(["Field Name 1", "Field Name 2"..]);
   // hideControlsAfter("Field Name");
   
   //-->
   </SCRIPT>

5. Follow the "Usage notes" to add calls to the disableControls, hideControls, or hideControlsAfter functions which will modify the fields displayed on the page
   
   Note: you can find the values to put in place of "Field Name 1" and "Field Name 2" by viewing the source view for the page and searching for: FieldName="
   The value within the double quotation marks will be what you enter inside the arrays in the hide/disable function calls.
6. In the CEWP's tool pane, add security groups or audiences which should have the fields hidden/disabled to the "Target Audience" setting
7. Save the web part properties, and click the "Exit Edit Mode" link in the upper right below "Site Actions".

Now you should see all of the fields hidden or disabled based on your security settings specified within the CEWP.

To extend this into a more reusable solution, I created a custom CEWP with this JavaScript code, exported it to a .dwp file, and then uploaded it to the Web Part gallery. Then, the only modifications needed are to add this web part to the page (under ToolPaneView=2 view), add the "usage" functions, and add the security groups to the targeted audiences.

This solution now hides/disables fields specified within the original list input form, which retains the attachment functionality, while being able to easily make modifications when new fields are added/modified based on column ordering.

However, there are some limitations to this method. None of which were show stoppers for me, since this method is very easy to undo (simply remove the CEWP from the forms). Especially in the interim until Microsoft is able to fix this little problem and offer a clean, efficient, and effective method of customizing input forms. These limitations are:

• Security groups or audiences need to be created for the group of users which should have limited access to list fields, which excludes the users with access to the restricted fields.
• You cannot make any of the hidden/disabled fields required unless you specify default values, as the fields will still remain on the page and submit data, they are just hidden to the user
• If the user employs firebug or other plugins which can alter JavaScript, they could unhide/undisable the fields you removed and then manipulate the data
• Information in these fields is still visible to users if the columns are displayed within list views, as well as Source View of the input form

Enjoy!
--andrew

Comparing InfoPath Fields - Case Insensitively

Currently have a form deployed which has 4 different views:

1. User
2. Manager
3. Process Owner
4. DBA

Each of the first three users (User, Manager, Process Owner) have an authorization field with an automatically filled in date field. Each user can only read/write for their authorization, and have read access to the authorizations below them (User cannot see anyone else's, Manager can see User's, Process Owner can see Manager's and User's, DBA can see all).

A problem arose where the Process Owner was actually the user's manager as well, but my rules for determining which view is presented to the user only showed this person the Process Owner view. I did not want to create a new view just for the case of Process Owner == Manager, so I did the following:

1. Set the Manager's authorization field to Read/Write on the Process Owner view
2. Added a conditional formatting element to the Manager's authorization field to set it to read only when the managerID field does not equal the InfoPath function "userName()"
   

This was great, except everything is case sensitive, and there is no standard "toUpper" or "toLower" functions to standardize multiple fields on one case...enter translate.

The resulting expression used in my conditional formatting is (broken onto multiple lines for ease of reading):

translate(
  substring-after(
    /my:myFields/my:grpEmployeeInformation/my:managerID,
    "\"),
  "ABCDEFGHIJKLMNOPQRSTUVWXYZ",
  "abcdefghijklmnopqrstuvwxyz") !=
translate(
  xdUser:get-UserName(),
  "ABCDEFGHIJKLMNOPQRSTUVWXYZ",
  "abcdefghijklmnopqrstuvwxyz")

Rather long and cumbersome, but you can see both the left and right hand sides of the "!=" translate all capital letters to their lower case equivalents. The substring-after() bit was just an artifact of the structure of my form, where the managerID field is in the format of "domain\username".

Note: Since this form uses the "userName()" function, it will probably require full trust.

Enjoy!
--andrew

DataView Web Parts and Page Layouts

The DataView Web Part is a nice tool to customize the way information is presented on a page. Unfortunately, this web part is not available through the browser's "Add Web Part" interface, and must be added through SharePoint Designer. The problem I ran into was that pages attached to a page layout cannot be directly modified within SharePoint Designer.

I decided to detach the page from its layout and add the DataView Web Part. Everything seemed to work, except I started to receive errors stating "This Web Part Page has been modified since you opened it." I figured this was related to detaching from the Page Layout (I may have hosed something up unknowingly). I then reattached the page to its layout and everything ended up working fine.

Therefore, if you need to add a DataView Web Part to a page attached to a layout, I suggest doing the following(all done within SharePoint Designer):

1. Detach the Page from the Page Layout
2. Go through the necessary steps to add a DataView Web Part to an existing zone on the page
3. Reattach the Page to it's Page Layout

This was fantastic since detaching/reattaching to layouts does not change any web parts or customizations made to those web parts. Also, once the DataView Web Part is on a page, you can simply modify it's display through the browser using the XSL editor.

Note: I have not attempted to reattach a page to a layout after new zones have been added and do not know exactly what will happen.

Enjoy!
--andrew

InfoPath Property Promotion Woes

Note: I experienced this issue with Administrator Approved templates only. I am unaware if this is a problem with either of the other publishing methods or if it will fix those problems.

I have been having issues lately with property promotion in InfoPath 2007 forms. When I create, publish, and deploy a form to a SharePoint site, promoted properties function correctly. If I add new structural elements and property promotion settings to a form after it has been deployed to a SharePoint site and is in use in a form library, then the new properties do not appear in SharePoint at all.

This has surfaced as a concern within my company as we have a few forms in use which require structural/property promotion changes. After several days of searching for any information on the capabilities and limitations of property promotion, I stumbled upon the following forum entry: Property Promotion - Full Trust Form - TechNet Forums.

In this forum post, there is some discussion of whether this is a bug or by design and possible resolutions.

Jasbury summed up the thread as:

The workarounds presented in this thread suggest the following:

• Rebuild the library or site


• Replace InfoPath’s “Automatically determine security level” with “Domain Security”


• Deactivate/Reactivate the InfoPath Form Template from the Site Collections

The first suggestion was not an option for my situation.
The second suggestion did not apply to me as I experienced problems with automatic, domain, and full trust permission levels.
The third option, however, was right on the mark. Once I deactivated/reactivated the template, the new properties were promoted successfully.

Thanks to bobchauvin for originally suggesting this:

I also notice when using the Publish to Sharepoint as a content type that a change to the promoted cols wont take effect until you disable and then re-enable the content type for the site collection.

With a little investigation, I discovered what was causing Jasbury's problem here:

I was able to deactivate/reactivate with some success (thanks for this work-around!!!). The missing content type columns were added. However, changes to InfoPath property promotion were not reflected...huge bummer!! That leaves me with no other options that to start over…again!

This is due to the order in which the steps were completed rather than a bug within SharePoint/InfoPath. Field values within an InfoPath form are copied into the corresponding SharePoint columns when the form is saved/submitted. If people have been filling out forms prior to fixing the missing columns in the content type, these values will not be stored anywhere. Once the content type is correct, simply open any forms and save them again for the values to be copied.

I recommend the following order for updating a form which has property promotion/structural changes:

1. Deactivate the form from all site collections it is active on


2. Upload the new version of the form


3. Reactivate the form on all necessary site collections

When you go to your SharePoint site, the content type will now reflect the correct promoted properties, and these columns will be available for use withn your form library views.

Enjoy!
--andrew

Automatic Login with Current User Name and Password....Doesn't

Recently, I had to change my network password at work. This caused a problem which I was struggling to solve: every time I attempted to access the corporate intranet (with the IE setting "Logon automatically with current username/password"), it would prompt me for my password. It worked correctly before my password change, so I figured my password was being cached somewhere.

I attempted to empty the browser cache, restart the machine, relocate the intranet URL to another security zone; all to no avail.
Just today I found a blog post by Nick Porter entitled: SharePoint prompt for password after changing network password. In his post, he states:

Cause:
What seemed to happen was it was storing the old information in the
Password list under the Manage Passwords section under "User Accounts". (Start > Settings > Control Panel > User Accounts)

His resolution was:

1. Click "Start" > "Settings" > "Control Panel"
2. Double click "User Accounts"
3. Click on the "Advanced" tab
4. In the "Passwords and .NET Passports" area click "Manage Passwords"
5. Remove everything there.

Albeit, you do not need to remove *everything* from the managed passwords if other sites are working correctly for you (and you want them to), but I removed the intranet URL, opened a new browser and navigated to the site...and it automatically logged me in!

Thanks Nick Porter.

Enjoy!
--andrew

Programmatically Inherit Master Page and CSS in MOSS 2007

So recently I have been working on two small MOSS features:

• Change the master page and stylesheet settings for a site


• Staple the first feature to all site templates, so it is activated upon site creation

I was able to create both features and deploy them with little difficulty. See the following resources for tips on solutions, features, and stapling:

• Becky Bertram - blog - Applying a SharePoint Custom Master page Globally


• Jim Yang - blog - MOSS 2007 and WSS 3.0 Master Page


• Paul Papanek Stork - blog - Feature to Install a Custom Master Page
  
  

The problem that I ran into was this little radio button:





Brief rundown of SharePoint Object Model:

• SPSite is a Site Collection


• SPWeb is a Site within a Site Collection
  
  

Within the SharePoint Object Model, there are a couple of properties of the SPWeb object which we will be using:

• [web_object].MasterUrl


• [web_object].CustomMasterUrl


• [web_object].AlternateCssUrl

These values are read/write, so you can set the values to your own strings and the values in the database will be changed accordingly.



Note: all of the following is done within the FeatureActivated function of a custom class inheriting from the SPFeatureReceiver class. Now let's dive into some code (these are all different methods I tried to no avail)

• Created some variables and hard coded the locations within the feature:
  
  string MasterUrl = "/_layouts/custom.master";

string CustomMasterUrl = "/_layouts/custom.master";

string AlternateCssUrl = "/StyleLibrary/Custom/CSS/stylesheet.css";



SPWeb web = (SPWeb)properties.Feature.Parent;

try {

  web.MasterUrl = MasterUrl;

  web.CustomMasterUrl = CustomMasterUrl;

  web.AlternateCssUrl = AlternateCssUrl;

  web.Update();

}

catch { }



• Set the values of the current site to the values from the root site:
  
  SPWeb web = (SPWeb)properties.Feature.Parent;

try {

  web.MasterUrl = web.Site.RootWeb.MasterUrl;

  web.CustomMasterUrl = web.Site.RootWeb.CustomMasterUrl;

  web.AlternateCssUrl = web.Site.RootWeb.AlternateCssUrl;

  web.Update();

}

catch { }



• Set the values of the current site to the values from it's parent site:
  
  SPWeb web = (SPWeb)properties.Feature.Parent;

try {

  web.MasterUrl = web.ParentWeb.MasterUrl;

  web.CustomMasterUrl = web.ParentWeb.CustomMasterUrl;

  web.AlternateCssUrl = web.ParentWeb.AlternateCssUrl;

  web.Update();

}

catch { }

None of these methods, upon going to the "Site Master Page Settings" page within a browser, showed the little radio button next to "Inherit site master page from parent of this site" as being checked. They did correctly set the master page and stylesheet links, but if I went to a parent site and changed the master page, the master page did not get changed on the site *unless* the "inherit" radio button was selected.



I decided to take this to the Content Database for the portal in which I was working. Looking in the dbo.Webs table, I found that if the "Inherit" radio button is selected, there are still values in the DB for AlternateCssUrl, MasterUrl, and CustomMasterUrl. Running the above code, would put the same values in these fields, but the "Inherit" radio button would not be selected. I then performed the following steps:

• Copy a row (one site) from the database to a text file


• Change each of the 3 settings (Site Master, System Master, and Alternate CSS) from "Inherit" to "Specify a ..."


• Copy the same row from the database to the second row of the text file


• Change each of the 3 settings back to "Inherit"


• Copy the same row from the database to the third row of the text file


• Change each of the 3 settings back to "Specify a ..."


• Copy the same row from the database to the fourth row of the text file

I then moved the side-scroll-bar all the way to the right (to confirm something in each lines was different) and they did not end at the same character, so I went to the beginning and compared vertically until I found different characters. There were a total of 3 instances of different characters (all 3 instances had the same characters) all within the same field, 'MetaInfo'. These values were:

• "Inherit": 547275


• "Specify a ...": 46616C73
  
  

Going back to the SharePoint Object Model, I discovered that there are two member properties to the SPWeb object which seem to correlate to site properties: Properties and AllProperties. I then tossed together a quick console app to output all Key/Value pairings for these two collections, and this is what came out:

• SPWeb.Properties (C# type SPPropertyBag)
  
  


• vti_extenderversion: 12.0.0.4518


• vti_associatevisitorgroup: 4


• vti_defaultlanguage: en-us


• vti_associategroups: 5;4;3;6;7;8;9;10;11;14;15;17;18;28


• vti_associateownergroup: 3


• vti_associatemembergroup: 5


• SPWeb.AllProperties (C# type Hashtable)
  
  


• vti_extenderversion: 12.0.0.4518


• __InheritsCustomMasterUrl: False


• vti_associatevisitorgroup: 4


• vti_categories: Business Competition Expense\ Report Goals/Objectives Ideas In\ Process Miscellaneous Planning Schedule Travel VIP Waiting


• vti_associatemembergroup: 5


• vti_defaultlanguage: en-us


• vti_associateownergroup: 3


• vti_associategroups: 5;4;3;6;7;8;9;10;11;14;15;17;18;28


• __InheritsAlternateCssUrl: False


• vti_approvallevels: Approved Rejected Pending\ Review


• __InheritsMasterUrl: False

Fancy that, there are three properties which interest me most at this point (indicated in red).



I simply set these values to "True" (note, that is a string of "True" and not a 1 or C# true), which resulted in this:



However, it did not pull the correct values to begin with. Therefore, it would appear that SharePoint uses these settings for when the parent's master pages/css are changed, and not relying on these settings for everytime the site is accessed.



All in all, here is the final code I came up with for my Feature (inside FeatureActivated function):



SPWeb web = (SPWeb)properties.Feature.Parent;

Hashtable hash = web.AllProperties;

try {

  web.MasterUrl = web.ParentWeb.MasterUrl;

  hash["__InheritsMasterUrl"] = "True";

  web.Update();

}

catch { }

try {

  web.CustomMasterUrl = web.ParentWeb.CustomMasterUrl;

  hash["__InheritsCustomMasterUrl"] = "True";

  web.Update();

}

catch { }

try {

  web.AlternateCssUrl = web.ParentWeb.AlternateCssUrl;

  hash["__InheritsAlternateCssUrl"] = "True";

  web.Update();

}

catch { }



I hope this helps you, as I know I was pulling my hair out for a long time over this.



Enjoy!

--andrew



Correction [06.11.2008]: I just realized that in my final code, I had the following line:

  web.MasterUrl = web.ParentWeb.CustomMasterUrl;

This works just fine, except I am pulling the wrong master page setting from the parent site for the current setting. This should read:

  web.MasterUrl = web.ParentWeb.MasterUrl;

I have corrected this above in the code.