A while ago I did a talk at the Microsoft Techdays in Belgium about migrating from public folders and file servers to SharePoint. In that talk I mentioned the fact that public folders are not dead and that you can continue to use public folders if you really want to. I mentioned the guidance from a blog post at msexchangeteam.com and that guidance has now been updated. You can find the updated guidance here.

The guidance boils down to these main points:

1. Public Folders have full support for 10 years after the release of the next version of Exchange Server. That is longer than the initial reported date of 2016.
2. SharePoint is the better option for document sharing and custom applications (e.g. workflow) even if you currently use public folders for this.

For many users, the strength of public folders comes from the fact that there is full Outlook integration. It is easy to drag and drop e-mails as msg files in public folders or share things like calendars and contacts. Although some of these things can be done with Outlook 2007 and SharePoint, the features are not exactly the same. Outlook 2007 does not do two-way sync or allows you to drag and drop e-mails as msg files in document libraries. A tool such as Colligo Contributor is needed if you need those abilities. Colligo Contributor works really well and is worth having a look at.

Another strength of public folders is the built-in replication. SharePoint does not do replication but there are several 3rd party tools that can do it such as those from Infonic.

It would be great if the next version of SharePoint would include features such as replication and better Outlook integration because that would make it even easier to migrate without having to incur extra (potentially high) costs for these extra features.

If you want get some guidance for deploying Microsoft Office SharePoint Server 2007 on HP hardware, check out HP's sizer. Just go here and download the tools.

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.

Since SQL Server 2005 SP2, you can configure SQL Server Reporting Services in SharePoint Integrated mode. In this mode you can upload report files (rdl files) and shared data connection files to SharePoint document libraries and work with them from there.

To get to a report, a user just browses to a SharePoint site and selects a report from a document library.

Depending on your requirements, you can install Reporting Services on the same server as your SharePoint server or on a separate server. But if you install Reporting Services on a separate server, you will have to install SharePoint anyway because Reporting Services needs the SharePoint object model and needs to be part of the farm (see this document for more info). If you install Reporting Services on an existing SharePoint server you are deploying side-by-side and should check this document for more info.

To deploy Reporting Services on a SharePoint server side-by-side, just install Reporting Services and do not create a basic configuration. The basic configuration deploys Reporting Services in native mode. After installation, start the Reporting Services Configuration program to configure the server for integrated mode. You will also need the SQL Server Reporting Services Add-in for SharePoint Technologies. Installation is pretty straightforward and is fully explained in the documentation.

When you run a report, you frequently need to access data on a separate server. If you design a report with a datasource that queries a remote SQL Server, you will have to make sure that your credentials are passed to that server correctly. You basically have two options:

1. Connect to SharePoint using basic authentication - or -
2. Connect to SharePoint using Kerberos

You cannot authenticate with NTLM because that protocol does not support double hop.

Basic authentication is the simplest option. You can configure basic authentication with SharePoint Central Administration. When you do so, IIS will be configured appropriately. When a user connects to SharePoint using basic authentication, the password is actually sent to IIS. A connection can be made to a third server with the provided credentials using either NTLM or Kerberos.

The Kerberos option takes more work to implement because it requires service principal names in Active Directory. You configure Kerberos authentication from SharePoint Central Administration and that will also configure IIS for Kerberos. Basically, the NTAuthenticationProviders setting will be set to "Negotiate, NTLM". For more info, see this article.

What are the SPNs you need to set? Well, suppose you have the following scenario where UserX connects to SharePoint (with Reporting Services) and a report needs data from a separate SQL Server:

UserX ----------> SRVSP+RS --------> SRVSQL

UserX will type a name to connect to SharePoint, for example: http://sp.domain.com. For Kerberos authentication to succeed, a Kerberos ticket will need to be passed to IIS. Internet Explorer will request a Kerberos ticket for a service and that service is identified by a service principal name. If you would run a network trace, you would see that Internet Explorer request an SPN in the form of http/<servername typed by user>. So in this case: http/sp.domain.com.

Note: if the website is configured on a different port than 80, do not specify the port on the SPN like http/sp.domain.com:8080. Internet Explorer always uses the FQDN only no matter the port number.

Once the ticket has been acquired, it needs to be passed to the IIS process that hosts the SharePoint web application. In IIS speak, that process is an application pool. An application pool should be configured with a process identity and that should be a domain user account. The SPN of http/sp.domain.local needs to be added to that domain user account. Suppose the domain user account is domain\apppool you would need to use the following command to set the SPN:

setspn -a http/sp.domain.com domain\apppool

The setspn.exe tool is part of the Windows Support Tools on the Windows Server cd. To check that the SPN was set correctly, use the following command:

setspn -l domain\apppool.

Setting the SPN is not enough. For UserX's credentials to be passed from SRVSP+RS to SRVSQL, the domain\apppool account needs to be trusted for delegation. You do this with the Active Directory Users and Computers (ADUC) MMC snap-in. Where you find this option in the GUI depends on the Active Directory functional level. If it is Windows 2000, the option is in the Account tab. If it is WIndows 2003, the option is in a separate Delegation tab. That tab is only visible for accounts that have SPNs registered.

Once the account is trusted for delegation, you need to make sure that the account has enough user rights on the server (SRVSP+RS) to perform the actual delegation. The user right Impersonate a client after authentication is the minimum required. When the application pool account (domain\apppool) is part of IIS_WPG everything should be fine.

One last step is to make sure that the user account that runs SQL Server on SRVSQL also has an SPN. The SPN needs to be MSSQLSrv/fqdn:1433. In this example: MSSQLSvc/srvsql.domain.com:1433.

Besides the above requirements at the server and domain level, there are some requirements at the client level. The client needs to be able to talk to a domain controller on port 88/UDP (Kerberos) and the website must be in the Intranet or Trusted Sites zone.

We had a problem with a SharePoint implementation recently. All of a sudden, document icons were missing from document libraries, the New... button did not work, the option "Edit with Microsoft Word" was missing, and so on...

The reason for all of this? Incorrect permissions on docicon.xml on the web front-end server. That file contains definitions of file types, their icon and how these files should be opened. Make sure that the file inherits its permissions from the parent. If only Administrators and SYSTEM have rights, it will not work (obviously).

On the Microsoft SharePoint Products and Technologies Team Blog, Troy Starr is writing a series of blog posts about alternate access mappings (AAM). AAM is something particularly tricky in a SharePoint deployment that you need to get right. Depending on the complexity of your configuration (intranet, extranet, SSL, ...) you need to configure AAM appropriately.

Check out part 1 and part 2. Part 3 is coming later.

Microsoft released a new white paper about database mirroring with MOSS 2007 and WSS v3.0. The key point is that you need to perform some actions when a failover happens. You can do these actions manually or implement them using some scripts. You will also have to do some monitoring to know when a failover has happened.

If you are planning to use database mirroring with SharePoint, all I can say is test, test, test!!!

On pshell.info, I posted an article about SharePoint and PowerShell that shows how to use PowerShell with stsadm.exe. If you have worked with SharePoint a lot, you probably know stsadm. It is used for command line administration of SharePoint and to obtain information about users, sites, installed web parts, etc...

The problem with stsadm is that it returns XML that can be difficult to interpret and work with. PowerShell can help there with its support for XML as a datatype. Take a look at the article to find out more.

And by the way, credit where credit is due, I got inspired by this post on the Adventures in SPWonderland blog. Great blog so check it out. 

When you deploy MOSS 2007, you need to have a SQL server in place for the configuration database, content databases and various other databases. But what if you need to change that SQL server later? In theory, there are several options:

• Use connection aliases and change the alias to use another server.
• Use the stsadm utility with the renameserver option.

A connection alias is setup using the SQL Server Configuration Manager utility. I usually install the SQL management tools on the MOSS server which makes the tool available. Normally, you use aliases for security reasons as documented here.

In the diagram above, there is a simple farm with a MOSS server and a SQL server. The SQL server is configured to listen on TCP port 40000 with SQL Server Configuration Manager. The MOSS server is configured to connect to the SQL server using TCP port 40000. To let the MOSS server connect using TCP port 40000, you need to create an alias on the MOSS server. When you create an alias with SQL Server Configuration Manager, it will store the alias definition in HKLM\SOFTWARE\Microsoft\MSSQLServer\Client\ConnectTo. For the example above, you would find the following value:

• Name: sql
• Type: REG_SZ
• Value: DBMSSOCN,sql.test.com,40000

From practical experience, I do not recommend using an alias to change the SQL server in a MOSS farm. Instead, use the stsadm command as follows:

stsadm -o renameserver -oldservername <oldname> -newservername <newname>

After running this command, restart all services or reboot the server.

Of course, you need to migrate all data from the old SQL server to the new one. You can restore backups to the new server and recreate logins to achieve that goal.

In summary, when you need to change the SQL server in a MOSS 2007 farm, use the stsadm command instead of SQL connection aliases. Use connection aliases to meet security requirements like connecting to SQL with a different port number.

This month's TechNet magazine is devoted to SharePoint. You will find an overview article, information about security features, search and command line administration.

Check it out here.