Tag Archives: SharePoint

Add New Item link not displaying on List View Web Part Added to Page

Symptom: A List View Web Part does not show the +New Item link although the Toolbar Type has been changed to a type other than No Toolbar.

Cause:  Unknown. User reports the displayed view was edited using the Edit Current View option rather than starting from a Named View in the list.

Workaround:  Create a Named View, delete the existing list view web part, and re-add the list view web part. Change the Current View option to use the Named View.

  1. From the List, create a view with the required fields, sorted and filtered as you wish it to appear in the List View Web Part.
  2. Name and Save the view. Ensure that the New Item link is visible.
  3. Delete the existing List View web part from the Page.
  4. Re-add the List view web part to the Page.
Advertisements

SharePoint Designer Workflow Intermittently Fails to Update an Item in Another List

SharePoint Designer Workflow Intermittently Fails to Update an Item in Another List

Symptom: Workflows periodically fail with the following error message in the Workflow History Log:

The workflow could not update the item, possibly because one or more columns for the item require a different type of information

Possible Data Causes

The data used in the update is invalid, such as putting text in a number field or not providing a value for a required field.

The data used in the update does not provide a unique value in a field that requires unique values.

The data string used in the update is too long, such as putting a string that is more than 255 characters in a field with a data type of “single line of text”

Workaround: Compare the data type and validation rules between the two lists to find the mismatch. You might also add one or more Log to History steps to capture the value of certain fields prior to the Update step. Correct the validation rules in the list from which the data is being transferred to match the validation rules in the list receiving the update.

Possible Permissions Cause

The workflow initiator does not have the level of permissions required to perform the list update. In this case, you may see that some initiators always have their workflows complete, while other initiators always have their workflows fail.

Workaround: In a 2010 Workflow, use an impersonation step to have the update complete using the permissions of the workflow author. In a 2013 Workflow, use an App Step to allow the update to be performed with App level permissions, which allows read and write access to all items on the site.

Possible Performance Cause

On updates that require complex data manipulation or lookups, or updates that require a secondary workflow to complete before the next step in the current workflow, the workflow may error out if the dependent actions have not yet completed when the workflow attempts the Update action. This may also be a problem with high numbers of simultaneous workflow initiations or in environments with known bandwidth issues.

Workaround: Add a step to pause for X number of seconds to allow the dependent actions to complete before attempting the Update step.


People Picker in SharePoint 2010 Throws “Unexpected Error” on Some Client Machines

Symptoms: Some users report that attempting to use the People Picker in a SharePoint List Item results in an “Unexpected Error” message.  The affected users have either recently upgraded to IE9 or have new client hardware. Other users are able to use the People Picker without error.

Cause: Security settings in IE9 prevent the tool from fetching the required user information.

Solution: The SharePoint site should be added to a trusted or intranet zone in the browser settings, as described in this post on avoiding multiple authentication prompts in SharePoint.   


SharePoint “Open with Explorer” Button Intermittently Disabled

Symptoms: Users find that in some instances of Internet Explorer, they are able to use the “Open with Explorer” button on the SharePoint List or Library tab.  In other instances, the button is disabled. Closing and reopening the library sometimes corrects the problem.

Open

Cause: The “Open with Explorer” button is not available in the 64-bit version of IE. When the problem is intermittent, it usually means that the client has both 64-bit and 32-bit versions of IE available on the same machine, perhaps with the shortcut to one on the task bar and a shortcut to the other on the start menu or desktop. The button availability changes based on which shortcut the user chooses.

Solution: Delete any shortcuts to the 64-bit version of IE. Replace them with shortcuts to the 32-bit version of IE.  Note that with system generated shortcuts, the 64 bit version will be titled, “Internet Explorer (64-bit). If needed, search for “Internet Explorer” from the start menu to find both versions in the search results, right click the result which does not say “(64-bit)”, and choose “Pin to task bar” or “Pin to Start Menu”.


Document Library Prompts to Save PDF Although Web Application Set to Permissive

Problem: Users are prompted to save the file when clicking a PDF document link in SharePoint, and no option is given to open the file without saving. This behavior may not be universal, and may affect only a single or a few document libraries, while the remaining libraries open the document as expected.

Cause: By default, SharePoint 2010’s handling of documents in the browser is set to “Strict,” a setting which, with some file type exceptions, will not allow documents to be opened directly in the browser. Most users notice this when attempting to open files of type PDF. While this setting is set in Central Administration* at the web application level, and making a change there should affect the BrowserFileHandling property of all libraries within the web app, in some cases a library may “lose” this setting and may retain a different property setting than the rest of the libraries within the web app.  Most cases mention some type of customization of the library (adding a content type, creating the library from a template, etc.) as the action initiating the setting change.

Resolution: Each library has a BrowserFileHandling property. Craig Lussier (http://social.technet.microsoft.com/Forums/en-US/sharepoint2010setup/thread/95a9f8fa-3da6-4bb7-9983-2102910ff4aa ) offers the following PowerShell commands to verify and/or update the property for the given library:

  • #Get Document Library
  • $docLib = $web.lists[“Your Document Library Title”]
  • #View all properties/methods of the Document Library and you’ll see that BrowserFileHandling is a property
  • $docLib | Get-Member
  • #See the current BrowserFileHandling setting for the Document Library
  • $docLib.BrowserFileHandling
  • #If you need to change it from Strict to Permissive
  • $docLib.BrowserFileHandling = “Permissive”
  • $docLib.Update()

Another user states that this issue is reportedly fixed in the Dec 2010 Cumulative Update.

Cautions: While this script fixed the problem, researching the issue reveals the potential security risk involved with the “Permissive” setting. As an all-or-nothing setting, SharePoint will not only open PDFs in the browser, but may also open other types of files, including those that may contain malicious content. As an alternative, administrators may choose to add the PDF file type to the list of exceptions to the strict file handling setting, as described here: http://www.pdfsharepoint.com/sharepoint-2010-and-pdf-integration-series-part-1/ .

*From Central Administration, Manage Web Applications>Select the Web App>General Settings>General Settings> Browser File Handling


InfoPath Form in SharePoint 2010 Error: Root of the Certificate is Not Trusted


An InfoPath 2007 form deployed in 2010 gave repeated errors on opening, including:

“You do not have permission to access a web service.”

“The root of the certificate is not a trusted root authority.”


The InfoPath form in question was an administrator-approved form which called a SharePoint web service called GetUserProfileByName in order to pre-populate several fields with the current user’s data.  Permissions were checked and the data connection (UDCX) files were examined for errors, including incorrect URLs. The form threw no errors in SharePoint 2007.  A search for the correlation ID in the Windows Application Event logs revealed an error regarding the main wildcard SSL certificate for the site. This certificate had a valid date range and was working correctly to authenticate https traffic.


Several blogs (Share-n-dipity Eric Kraus’ SharePoint/.NET Blog ) pointed out that SharePoint 2010 has its own trusted authority store, separate from the Windows certification registry; these blogs were focused on the error when using claims authentication. This forum: InfoPath Form Errors after In-Place Upgrade from MOSS 2007 to SharePoint 2010 was more InfoPath specific. By default, only the “local” trust resides here (Central Admin>Security>Manage Trusts), but additional certificates may be added. Do not delete the “local” connection; it is used internally by SharePoint.

“I trust you, baby. I just don’t trust your friends.”


The error in the event logs meant SharePoint was complaining that the root of the authentication chain was not listed as a trusted certificate-issuing authority in the SharePoint trusts store.  In other words, SharePoint was saying, “This document looks legitimate, but are you sure the person who gave it to you was legit?” Registering the issuing authority’s certificate verifies that the authority is a trusted source. If your SSL cert includes a certificate hierarchy, all the certificates in the hierarchy must be listed in the managed trust store of SharePoint 2010.

Let’s Play “Find the Cert!”


To identify the issuing authority certificate(s) in use, find your SSL cert in the certification management console on the server on which the certificate has been installed. (Run > certmgr.msc) You may have to look under the Personal folder to find the SSL certificate (or if someone else installed the certificate, it may be under their Personal folder when logged in under their profile). In our case, the SSL cert had a 3 tier hierarchy. We noted the certificate names and exported each certificate by right clicking the certificate in the list and exporting it using the default settings to produce a .cer file. We then uploaded them to the Managed Trusts site in Central Admin, giving each a reasonable name and providing no other optional info.

One thing to note: the name displayed in the certificate hierarchy is not the name listed in the certificate list, but rather, the “friendly” version of that name. In our case, they were nothing alike, and we had a difficult time locating one of the certificates because the friendly name did not display in the regular screen display. To see the heirachical name, the user must scroll several fields to the right.

Additionally, the listing of certificates in SharePoint’s Managed Trusts center was required with this InfoPath form because the form was an administratively-deployed form containing code. InfoPath forms which do not contain code and which are published to SharePoint by users will likely not encounter this problem.



Maximum Upload Size with New or Edited Documents

A question arose in a SharePoint Governance committee on the issue of limiting file sizes in SharePoint 2007.  Central Administration* allows a web-application level Maximum Upload Size. This setting is 50MB by default.  If a user attempts to upload a document larger than the limit, the upload fails with an error message that the file is too large. The question was whether this limit would be enforced on documents created using the New option on a document library (as opposed to the Upload option), or in editing a document already housed in SharePoint, when those edits caused the document to exceed the size limit.

In other words, the committee wondered if the Maximum Upload Size would result in an overall file size limit, or if using a method other than the Upload option on a document library would allow a user to circumvent the limit. Testing by attempting to upload a large document, increasing the size of an existing document already in the library, and using the library’s New option to create a large document all resulted in the error message and a failure to save the document (or the new version of the existing document) to the library.

The Governance Committee was reassured that they need not create a separate rule regarding file size limits, as the Maximum Upload Size limit would enforce the file size limitation regardless of the method used to create or modify the document.

*Central Admin>Application Management>[In the SharePoint Web Application Management Section] Web Application General Settings. Note: Be sure you are looking at information for the correct web application, as this setting can be set separately for each web application. You can switch to a different web application by clicking the drop down arrow in the Web Application section of this screen.