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.

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.


SharePoint Saturdays: Hosting Ideas

SharePoint Saturday events provide free technical training, create networking opportunities, and allow vendors to introduce and demonstrate their products to a defined audience. After attending my first SPS in Tulsa, it’s been my privledge to speak at several great events, including SPS Ozarks, Kansas City, New Orleans, and Houston, and I’m looking forward to one whale of an SPS (over 1000 attendees registered!) in Washington DC.

Working for an agency tasked with providing training events for large numbers of people, I’ve witnessed the tremendous amount of work required in the planning and coordination of these types of events. There are venue, food, scheduling, transportation, speaker, sponsor, and registration tasks to be wrangled. Kudos to the organizers of the SPSs I’ve attended—they made all of this look seamless and effortless, all while still performing their full-time jobs.

Local user groups are usually the primary organizers of an SPS. Tulsa and Oklahoma City groups are discussing hosting one together, as the two major cities are only a 90-minute drive apart.

If your user group is considering hosting a SharePoint Saturday event, be sure to reach out to founder Michael Lotter and some of the Chairs of past events at SharePointSaturday.org. They can provide invaluable advice on every aspect of the event coordination.

Here are some ideas your group might consider:

Provide a PowerPoint template. A standard template can lend a cohesive feel to the presentations. It also allows all the speakers to deliver consistent info on housekeeping items, such as the procedure for session evaluations and the prizes available to be won. Some presentations may not lend themselves well to a template, however, so flexibility is urged. You can always provide a template, but make its use optional.

Separate evaluations from the papers used to draw for prizes. This allows for anonymous feedback, which may be more honest regarding areas that need improvement. You can accomplish this by using two forms or by designing the bottom part of the evaluation forms as detachable (either perforated or with provided scissors) and create two boxes…one of the evals and one for the drawing. An optional section can be included on the evaluation where attendees can provide their contact information if they wish to the speaker to have it.

Make sure the social aspects of the event, such as SharePint, are well advertised in advance. Networking at these events is almost as valuable as attending the sessions.  #YAHBN

Use EventBrite or similar online registration service. This will give you attendee information to create mailing lists and name tags. You can optionally add questions to be answered, such as type of attendee (newbie or advance, dev or IT Pro) and whether contact info may be shared with vendors, speakers, and/or user groups.  

Create computer-generated name tags for speakers and pre-registered attendees. Sticky name tags will work for walk-ins, if printing on site is not an option. Tip: Print the FIRST NAME in a large font size so that it is legible from several feet away. This is particularly helpful to speakers answering questions in large groups and for networking folks who may need several reminders before they commit a new name to memory.

Get ladies’ sizes on shirts for female speakers. I’ve heard the comment often enough: “Wow, there are a lot of women at SharePoint events [as compared to other tech confs]!” and it’s true. Houston managed this, and my SPS Houston shirt has been worn to work. The rest are patiently hanging in the closet, waiting for the day I sprout chest hair or polo mini-dresses come into style. Encourage your vendors to carry a variety of sizes and styles in their give-away shirts as well.

Require attendees to visit sponsor booths. Sometimes folks are a little nervous to approach vendors if they don’t know the product, they are not the decision maker/purse-string holder for their company, or they are just new to SharePoint. Kansas City tried requiring vendor attendees get their drawing entry stamped by a certain number of vendors. This provided increased interaction for both the vendors and the attendees, because it added a social aspect to the process. The SPS vendors I’ve met weren’t “booth babes” (although they are adorable!).  They’re tech people who actually know the product they are representing, so they’re worth visiting.

Ask the speakers to provide their slide decks to be posted online after the event. Presentations can be saved in PDF format so they are read-only. Also consider asking for copies of any handouts and a write-up of Questions and Answers brought up in the session, both those with answers and those requiring research and follow-up. Event volunteers or fellow speakers can provide note-taking for these questions during the sessions.


Display Site Owners on Each SharePoint Site

Update 8/28/12: It looks like SharePoint Diva Laura Rogers has worked out how to do this. Check out her excellent How To article.

An interesting problem arose in a SharePoint governance planning committee today.

Scenario: Client governance plan assigns several responsibilities to site owners, through whom many lower-level user requests for changes are to be handled. To help these casual users determine which people are site owners for a given site, the client wants to display the site owners for each site in a uniform manner. Of course, this needs to be dynamic, preferably with either

      A: the phone and email of the site owner displayed with the name or  

      B: the list generated so that the site owner’s name is a link to that person’s My Site.

Additional specs in the “this would rock but we could probably live without it” category:

1. Would like this Site Owner list or a link to it displayed in standard area, such as within Quick Launch or Above Top Nav near the My Site link.

2. Would like this Site Owner list available on views of lists and libraries within a site, so if a user follows a link in an email to a view of a doc library, the site owner information would be readily available without having to backwards navigate to the site housing the list or library.

The SharePoint 2007 Site Users web part shows members, and you can filter that to members of a particular group, such as “Accounting Owners”; however, if permission to this SharePoint group is granted through membership in an Active Directory Group, only the group name, not the individuals within that group, are displayed.

The DB gal in me knows this info is stored in the database; therefore, this is possible…at least at the web part level, perhaps through a Data View Web Part. Accommodating the extra requests seems doable as well, but a stretch. Anyone done something similar that might give a starting point on this problem?


Moving Email-Enabled SharePoint Calendar

Devin Walker has an excellent blog post on a strictly browser-based method of moving SharePoint lists from one site to another using the List Template method. I used the instructions with success on one of our calendars.

I was concerned about the effect the move might have on events emailed to the calendar and on its display in Outlook as another user’s Calendar. These problems were resolved by giving the new calendar the same email address as the old calendar. However, making this email assignment required a direct edit in Active Directory, because attempting to assign the old address to the new calendar resulted in an error that the email address was already in use. Disabling email in the old calendar did not remove the Contact entry  in AD; neither did deleting the old calendar from the site. After removing the Contact from AD directly, I was able to assign the email address to the new calendar.

Testing showed the new calendar accepting emailed calendar items, and the new calendar displayed in Outlook correctly without having to delete and re-add the new calendar as another User’s Calendar.