Monthly Archives: November 2012

This is more of a reminder to myself…

A user wanted to change the number of items showing up in the Announcement List web part on their home page.  They’re using the built-in Summary View, which doesn’t show up in the list of views for the Announcement List.  So here’s how you do it…

• Site Actions > Edit Page
• Announcement Web Part – Edit Web Part
• In the Announcement List View properties, click the Edit The Current View link under the <Current View> selection.
• Scroll down to the Item Limit section, expand it, and enter the number of items to display.
• Click OK.
• Save/Check-in the page, and publish it if that’s necessary.

You now have more or less items showing than you did before.

I had a report today of someone who couldn’t open a Word document that was part of their Agenda list in a Meeting Workspace area.  They would click the clink and the document would open in the browser with Office Web Apps, but then it would fail when trying to open in Word.  The error message was as follows:

Microsoft Word Web App
To open this document, your computer must be running a version of Microsoft Word and a browser that supports opening files directly from the Office Web Apps.

Some research turned up this KB entry from Microsoft:

The Office Web App cannot open an Office document in Office 2010 if multiple versions of Office are installed.

In this case, Office 2007 had been uninstalled, but Visio 2007 was still floating around.  They uninstalled Visio 2007 and Office 2010 to make sure everything was cleaned out, and then reinstalled Office 2010.  Once that was done, everything opened perfectly.

Hopefully this will help someone else…

I’ve run into issues where I get help desk cases saying that a document is locked in SharePoint and the user can’t get into it.  Of course, my first thought is that someone has it checked out.  But when I go out to see who has it, the answer is… no one.

The real issue ends up being an internal document lock in the file itself.  Microsoft covers that in this KB:

You receive a “<FileName> is locked for editing by ‘another user'” message when you try to modify a document in Windows SharePoint Services even though you are the user who previously opened the document

This normally happens when the person’s computer crashed or locked up during a previous edit session with the document, and the file wasn’t closed properly.

When a document is opened by a client program, Windows SharePoint Services puts a write lock on the document on the server. The write lock times out after 10 minutes. Users cannot modify the document during the time when the document is locked.

In a scenario where the program that opens the document unexpectedly quits or crashes and you try to open the document again before the write lock times out, the message that you receive says that the document is locked by another user. This behavior occurs even though you are user who previously opened the document.

The solution is to wait 10 minutes and try it again. 🙂

Sometimes ignoring problems *do* make them go away…

This situation bit me the other day when I was trying to figure out why someone couldn’t open a document in a library that they apparently had permissions to view.  I did some research and found that there was a slight (but significant) difference between Read permissions and “View Only” permissions.

Reza Alirezaei summarized it well in his blog post titled Interesting Difference Between “View Only” and “Read” Permissions Levels:

• If a user has “Read” permission level to a document, they can always find the document using search or browser and open it in the browser or their Office client app.
• If a user has “View”Only” permission level to a document, they can only find and open the document in the browser. In that case, Search doesn’t show the document!

Check out his entry for further details.  Thanks for sharing that, Reza… maybe I’ll remember I jotted this down next time I run into the problem. 🙂