When you get an access denied after you enable the publishing infrastructure feature on a WSS site, follow the steps in this post. Worked like a charm for me!

Joris Poelmans has a great list of tools to use with SharePoint 2007 (WSS and MOSS). Check it out here.

We have a setup with a MOSS 2007 server (web front-end) and a separate SQL Server 2005 SP2. The MOSS server also runs SQL Server Reporting Services and is configured for integrated mode. Integrated mode allows a report designer to publish reports (rdl files) to a document library. Users can then just click on the report in the document library to view the report. Nice idea but there are quite some issues with this setup.

When we setup this environment with Kerberos from client --> MOSS --> SQL Servr 2005 it all works fine. But we do not want Kerberos from the client to the MOSS server, we want basic authentication over SSL. Switching to basic authentication is easy enough: just go to Central Administration and from the authentication providers link you can change the authentication settings. MOSS will then configure the IIS web site appropriately. The user can then logon to MOSS using basic authentication and you can verify that in the event viewer of the MOSS server. Just look for a logon event in the security log for the user where the logon process is ADVAPI.

After switching to basic authentication, the MOSS sites work just fine. But when we click on a report we get an error: "An unexpected error occurred while connecting to the report server. Verify that the report server is available and configured for SharePoint integrated mode".

To explain the error we have to delve a bit deeper in how the integration works by going over the complete request:

1. User connects to MOSS using basic authentication. In our lab environment the URL is http://sp.newtech.local.
2. A connection is made from the MOSS server (not the client) to http://sp.newtech.local/_vti_bin/ReportServer/ReportService2006.asmx using the user's credentials. This is the Report Server proxy endpoint as discussed in this article.
3. A connection is made to the actual RS endpoint as configured with the Reporting Services configuration utility. In our case the endpoint sits in the Default Web Site (separate from sp.newtech.local).

When we switch to basic authentication, it goes wrong at step 2 with a 401 Unauthorized. Of course, the switch to basic authentication also makes http://sp.newtech.local/_vti_bin/ReportServer use basic authentication and that is probably not supported (wild guess because I can't find documentation about it). The solution to this problem is to configure the _vti_bin/ReportServer virtual directory with Integrated Authentication. That is a bit annoying especially when you add front-end web servers later because the SharePoint Timer service won't configure this setting automatically.

UPDATE: this fix will not work for other sites below the root. In our lab, if we have reports at http://sp.newtech.local/sites/othersite/reports then the proxy web service is at http://sp.newtech.local/sites/othersite/_vti_bin/reportserver and that URL will use basic authentication as configured in Central Administration. Because that URL is not even visible in IIS Manager, I cannot switch it to Integrated Authentication. I have not yet found a solution to this problem.

Anyway, the reports now work over basic authentication. When reports need to make connections to other servers with Kerberos, make sure you configure Kerberos appropriately with SPNs and delegation settings. Also see this article.

Time to configure SSL. I won't go in the details about how to do that. Suffice it to say that we used an online certificate authority and configured a certificate on our IIS web site for https://sp.newtech.local. Of course, you need to configure SharePoint's alternate access mappings or you won't get anywhere but I guess you know that already. If you don't, check this. Make sure that the certificate is trusted by the system or step 2 will go wrong again with a failure to validate the certificate!

Now for the piece that is not working (grin). If you configure the SSL URL for a zone other than Default, viewing a report with the SSL URL will not work. It appears that Reporting Services in integrated mode only supports requests if they belong to the Default zone. So we needed to configure the URL https://sp.newtech.local for the default zone and make sure that our users only go to our site using that URL. Fair enough, no big deal there.

That should fix it right? WRONG. When you access the reports from the correct URL (default zone), the following error pops up: "The item '<report URL>' cannot be found. (rsItemNotFound)". For that one, we have not found a fix yet. I will keep you posted if we do. And if you have any ideas, let us know.

UPDATE: the rsItemNotFound error comes from the fact that the Report Server database is not synchronized properly. Redeploying the reports to SharePoint using the https://... URL with Visual Studio 2005 will fix the problem!

This just goes to show that SharePoint and products that integrate with SharePoint such as Reporting Services all are very promising but that they are quite complex to setup and manage. And I must say that the documentation sucks. There is enough documentation allright but not enough precise information about how things exactly work and what is supported and what not.

Just thought you should know of this:

• SharePoint 2007 Search Never Stops Crawling
• Microsoft knowledge base article

If you are looking for an easy way to implement workflows on SharePoint 2007 (WSS or MOSS), take a look at Nintex Workflow 2007 (http://www.nintex.com). To show you how easy it is to build a workflow, let me guide you through an example with an expense note approval. To make it a bit more interesting, I will use an e-mail enabled document libary. The workflow goes like this:

• The user e-mails the expense note to expenses@domain.com.
• With the appropriate e-mail routing, the e-mail is delivered to SharePoint.
• SharePoint drops the attachment in the document libary.
• A workflow is kicked off that asks for approval by the user's manager.
• When the manager approves, the user is sent an e-mail and the expense note is mailed to finance.
• When the manager declines, the user is sent an e-mail with the reason and the expense note is deleted.

By the way, users do not have rights to the document library so they cannot look at other expense notes. That is one of the benefits of using an e-mail enabled document library.

Using an e-mail enabled document library makes things a bit more complicated though because Nintex Workflow 2007 will not be able to automatically determine the user and the user's manager. But because Nintex Workflow 2007 supports things like regular expressions and LDAP queries, we can still make it work.

To build the workflow, you need to install Nintex Workflow 2007 according to the instructions. Check the Nintex website for more information. Once the product is installed, you can create and attach a workflow all without leaving your browser. The settings menu of a document library or list is extended with new items:

I created a new workflow from the Create Workflow item. The first half of the workflow looks like this (click to enlarge):

The first action in the workflow is a regular expression. As discussed above, we need information about who submitted the document. Based on the sender's e-mail address, SharePoint sets the Created By field to the user's account in the form of domain\user. I need the username without the domain for an LDAP query based on the sAMAccountName in Active Directory. With a regular expression that replaces domain\ with an empty string, the username can be put into a Nintex workflow variable. The regular expression I used is: \w*\\. Of course, you can replace \w* with the actual domain name for your environment.

After the retrieval of the username, the action set Get user's manager from AD does the following:

• Use an LDAP action to retrieve the manager field of the user object that has a sAMAccountName equal to username.
• Use another LDAP action to retrieve the manager's e-mail address so we can ask for approval.

Action sets make it easy to group multiple workflow actions and you can copy and paste them in one step. You can also save them for re-use in other workflows.

An LDAP action looks like the screenshot below (click to enlarge):

After we have the user's manager, the workflow sends an e-mail to the submitter of the expense note with a Send Notification action. The second part of the workflow can now be started (click to enlarge):

This part of the workflow is pretty straightforward. When the manager declines the expense note, the user gets an e-mail with the reason and the expense note is deleted. When the manager approves the expense note, the user gets an e-mail and the expense note is mailed to finance. The expense note is then deleted from the document library. Of course, you could keep the expense note there.

For the end-user, everything is done by e-mail. Because the e-mail confirmations are completely editable, you can make them look how you want. In this case (click to enlarge):

Conclusion

Nintex Workflow 2007 is a good solution to extend SharePoint with workflow capabilities for advanced users. You do not need developer skills to build a workflow but there are some advanced actions such as calling a web service or using SQL queries. Great stuff so definitely check it out. You can easily get a trial version from their website.

There is a new beta version of Windows Live Writer available. In addition to cosmetic changes Windows Live Writer now supports SharePoint 2007 blogs as well. You can also use Word 2007 for blogging to SharePoint but on my system Word 2007 does not accept an https address. No problem with Windows Live Writer so I am now using it as the primary tool for blogging to SharePoint.

Check it out here.