Category: Microsoft Office SharePoint 2007

Workflow History deleted after 60 days

Got an e-mail from a customer who was trying to look for workflow histories for some of their older documents. As they, and apparently lots of other people have discovered, there is a SharePoint timer job that deletes workflow histories after 60 days in order to keep things tidy.

More specifically, the job deletes the link between the item that triggered the workflow and the workflow history. The workflow’s history is preserved in a hidden list named, appropriately enough, “Workflow History.”

For more information, and instructions on how to use this list to get the information you want, see this blog.

http://www.fusecollaboration.com/Blog/archive/2011/10/10/recovering-workflow-history-after-60-days.aspx

I did discover one thing that the blog doesn’t mention: if you’ve customized your workflow to report history to a different history list, you’ll have to use that list instead (for example, if you decided to name your new workflow “My Workflow” you’ll find the history for that workflow under “My Workflow History.”

SharePoint 2010, SharePoint v3 [2007] sites and “Email a Link”

If you’ve imported a site to SharePoint 2010 from SharePoint 2007 and have not “upgraded” it yet to the new Ribbonized v4 interface, you may notice that when you click on the drop down menu for an item in a document library the “Send to > E-mail a Link” option does not work – clicking on it does nothing.

The fix for this problem is simple, provided that you have SharePoint Designer.  Open the site in the application, then open the page’s default.master page.  Within the code view, add the following tag:

<SharePoint:SPPageManager runat="server"/>
That's it.

Resolving “The start address cannot be crawled” issues in MOSS Shared Services

We’ve been getting SharePoint Services Search warning 2436 in our event logs.

The start address cannot be crawled.

Context: Application ‘Search index file on the search server’, Catalog ‘Search’

Details:
The object was not found. (0x80041201)

For more information, see Help and Support Center at http://go.microsoft.com/fwlink/events.asp.

It’s more of an annoyance than anything as searches are working fine.

The top Google search results suggest a registry edit involving loopback checking. That didn’t work. Nor did another search that suggested changing content access accounts. What did work – and makes sense – is this post on a Microsoft forum:

http://www.microsoft.com/communities/newsgroups/en-us/default.aspx?dg=microsoft.public.sharepoint.setup_and_administration&tid=83b7ce07-e248-4ed3-8be6-5ba9089e0055&cat=en_US_36D27378-C1C7-DC25-5AE5-1A1D5FBC9671&lang=en&cr=US&sloc=en-us&m=1&p=1&mid=fac055df-c177-42f2-9347-87f45f5b5f72

Basically, what is happening is that the Shared Services Administration site is being hosted on a URL with no default page. The indexer is thus getting a 404 error and assuming that the URL is invalid. The fix is easy enough; simply create a new site collection at the root of the Shared Services Administration site and the warning will go away.

Security issues with SharePoint (Part 1)

I am currently in the process of building new MOSS and WSS servers.  Upon completion of the configuration wizard, I got the following error when I logged on to Central administration:

Examining the Event Viewer yields the following error (warning to be exact):

Event code: 3005
Event message: An unhandled exception has occurred.
Event time: 6/24/2009 1:15:01 PM
Event time (UTC): 6/24/2009 5:15:01 PM
Event ID: c940ce1192b3433e93e9eed22da82c15
Event sequence: 1
Event occurrence: 1
Event detail code: 0

Application information:
Application domain: /LM/W3SVC/1576543627/Root-47-128903373014688345
Trust level:
Application Virtual Path: /
Application Path: C:\Inetpub\wwwroot\wss\VirtualDirectories\80\
Machine name: xxx

Process information:
Process ID: 4016
Process name: w3wp.exe
Account name: [account]

Exception information:
Exception type: HttpException
Exception message: The current identity ([account]) does not have write access to ‘c:\WINDOWS\Microsoft.NET\Framework\v2.0.50727\Temporary ASP.NET Files’.

Request information:
Request URL: [removed]
Request path: /_vti_bin/sitedata.asmx
User host address: [removed]
User:
Is authenticated: False
Authentication Type:
Thread account name: [account]

Thread information:
Thread ID: 8
Thread account name: [account]
Is impersonating: False
Stack trace:    at System.Web.HttpRuntime.SetUpCodegenDirectory(CompilationSection compilationSection)
at System.Web.HttpRuntime.HostingInit(HostingEnvironmentFlags hostingFlags)

As you can figure from the message, the error is occurring because ASP .NET can’t access its temporary files folder via the service account being used.

The twist here is that you don’t grant the privileges through Windows Explorer security (I suppose you could, but I haven’t tried).  Instead, you do it through the command prompt.  Switch to the .NET directory (usually C:\WINDOWS\Microsoft.NET\Framework\v2.0.50727) and type the following:

aspnet_regiis.exe -ga “[account]”

The .NET framework will grant the appropriate permissions to [account].  You may need to restart IIS afterwards and apply the permissions to any other service accounts SharePoint is using, but afterwards, you should be able access your site.

No search results when Database Status is offline

IMO, one of the dumbest (or most poorly worded, anyway) settings one can find in SharePoint is the “Database status” option on the “Manage Content Database Settings” Central Administration page.  This setting gives you two options: marking a database as “Ready” or “Offline.”

Given the wording, you might think that setting a database to “Offline” would take it, well, offline – preventing the database and its contents from being accessed, at least temporarily.

Except, not quite.  Take a look at the description of the setting on the left (emphasis mine):

Specify database connection settings for this content database. Use the Database status options to control whether or not new sites can be created in the database. When the database status is set to Ready, the database is available for hosting new sites. When the database status is set to Offline, no new sites can be created.

Setting the database to “Offline” doesn’t actually “Offline” the database, it only prevents new site collections from being added to it!  Existing site collections can continue to add, modify, or delete data from the database!  You cannot take the database offline in this manner, which makes the nomenclature being used hella confusing for anyone new to SharePoint.

Still, the setting is useful if you want to force a new site collection to be stored in a certain database: just set every database but the one you want the site collection to be stored in to “Offline” and the new database will be put in the correct location.  This was what I did recently to my SharePoint installation: one of our databases was growing to be too big, so I forced new site collections into a new database (yes, I know SharePoint is supposed to balance site collections and databases, but it’s not the best method either).

Then I started having issues with search.  In particular, sites stored in the “Offline” database started returning no results.  Sites in the new database had no problems.  It wasn’t until I thought to change the first database back to “Ready” that I got results again.  So, at least from what I’ve seen, it appears that the “Offline” setting works for some parts of SharePoint but not others.  Like I said, dumb.

Has this happened to anyone else or is it just me?

Problems with Explorer View on Windows Server 2003

This was a fun one – just as I thought I’d found the right solution I’d hit another roadblock. In the end, it wasn’t too bad, only a day’s worth of cursing.

I was trying to write a batch file (remember those?) on a Windows 2003 system that would get and put data from a SharePoint library by accessing the library as if it were an ordinary file share, i.e. \\sharepointserver\sharepointsite\library. The only problem was that the batch file didn’t seem to be able to access the library: a “net use” command would return a “The network name cannot be found” error. Trying to access the path in Windows Explorer didn’t work either: “Windows cannot find ‘\\server\path’. Check the spelling and try again, or try searching for the item by clicking the Start button and then clicking Search.” The only way I could access the library was if I went to the library itself and chose the Explorer View option. This would bring up an IE window with the address “http://server/site/library.” Unfortunately web addresses don’t really work too well when you’re dealing with batch files.
Considering that I eventually found myself working on the SharePoint server itself I figured it wasn’t a network issue. I knew the path was valid; it worked perfectly well on my own workstation (Windows XP). And I knew the “net use” command worked, because I’d done it before on another system (Windows Server 2008).

So the common factor seemed to be the operating system: Windows XP and 2008 would work, but Windows 2003 would not, because they saw the library as an actual web address and not a file share. A Google search led me to a blog post suggesting that a patch for Web Folders would do the trick. It didn’t, but it did have a link to a Microsoft whitepaper that would turn out to be very useful: Understanding and Troubleshooting the SharePoint Explorer View. A through (my first read through led me down another wrong path) read of this document led me to the solution.

As it turns out, there are two ways to access SharePoint libraries in Explorer: WebDAV and FPRPC. WebDAV is a newer protocol that allows the library to be treated as if it were a simple file share; FPRPC is an older one that treats them as web addresses with content that you can manipulate. WebDAV requires the Web Client service to be running. By default, it isn’t running on Windows Server 2003. So the reason I wasn’t able to get it to work was because Windows was unable to use WebDAV (since WebClient wasn’t running) to access the library and defaulting to FPRPC.

To enable the Web Client, you need to go into Services and change the “Startup type” for WebClient to “Automatic.” Viola, right?

Not just yet. Yes, you’ll now be able to get to the library via Windows Explorer, but you’ll also be prompted for a password. Unacceptable, since you can’t really enter passwords automatically in batch files (well, you can, but why would you want to?)
And that brings us to the other problem. As it turns out, “basic authentication” in Windows Server 2003 SP1 is turned off by default. It’s a good thing really, you don’t really want your passwords being sent out in clear text. Unfortunately SharePoint requires basic authentication to get Explorer view working fully, so you will have to add a DWORD key named “UseBasicAuth” with a value of 1 to “HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\WebClient\Parameters” in the Registry. Full instructions can be found here. You will need to reboot your system in order for this change to go into effect; I wasn’t able to get it to work simply by restarting the WebClient.

When the reboot finishes, you’ll be able to view your SharePoint library in Explorer via a network share path and mount it using “net use.” Now all that’s left is brushing up on those DOS skills of yours. You do remember DOS, don’t you?

Indexing select Office 2007 (Visio/OneNote) and Zip files with MOSS

I was asked the other day why Visio documents weren’t being indexed properly (you couldn’t search inside documents for certain terms).

As it turns out, a default installation of MOSS doesn’t include iFilters for Microsoft Visio. Nor do they have them for OneNote or Zip files. Go figure, OneNote and Visio are Microsoft products.

In December, Microsoft released the Microsoft Filter Pack, which contains the relevant filters. Once you install the filters on your index server (it’s a simple installation), you will need to do some registry edits and restart the search service. Complete instructions can be found here.

NOTE: I’ve been told that SP1 already includes a OneNote filter by default, so if you’re running that you may not need to do this.

Moving to Windows Server 2008?

Microsoft’s SharePoint Products and Technologies Team Blog has a post regarding installing SharePoint (both the Services and MOSS applications) here:

http://blogs.msdn.com/sharepoint/archive/2008/01/16/windows-server-2008-and-sharepoint-resources.aspx

You’ll need WSS/MOSS SP1 to use SharePoint on Windows Server 2008. They’re still working on an installation package that includes everything you need for MOSS. So if you’re not in a hurry to get everything working, it might be beneficial to wait a little bit.

Opening Office files on SharePoint sites crashes Internet Explorer

First post!

One of the most common problems (it’s come through my inbox several times and you’ll see plenty of results if you Google for it) with SharePoint Services 3.0 and Office 2007 SharePoint sites is that opening an Office file crashes Internet Explorer, like so:

Internet Explorer crashing

Closing the “we’re sorry” dialog gives you another error message:
Office IE error message

This problem occurs when you have two versions of Microsoft Office installed on your computer. Here, for example, we use Microsoft Office 2003 for our standard Office applications, but many people use SharePoint Designer 2007 to customize their SharePoint sites. The issue is that the two versions of Office have a conflicting DLL, owssupp.dll. When you repair or update Office 2003, this DLL is overwritten with the older version, causing IE to attempt to do something it can’t with the older DLL and crash.

The official solution would be to download the hotfix from Microsoft. The link to download the hotfix, as well as the official description of the problem, can be found here:
http://support.microsoft.com/kb/938888
If, for some reason, you don’t want to install the hotfix, here are some alternative solutions:

  • Stop using Internet Explorer and use Firefox or Opera instead. As an added benefit, you’ll get features you might not find in IE.
  • On the other end of the spectrum, upgrade to Microsoft Office 2007 and make the bean counters at Microsoft happy. From what I hear, that ribbon feature is pretty nifty!
  • “Repair” your Office 2007 installation (Control Panel > Add/Remove Programs > Microsoft Office [Office Application] 2007 > Change > Repair). Note that you’ll probably have to do this everytime you update Office 2003, so you’re probably better off installing the hotfix.