Bil puts SharePoint Forums Web Part on CodePlex

Bil released his SharePoint Forums Web Part this week, to much fanfare. He has now put the project documentation, install files, and (soon) code onto Microsoft's CodePlex. He explains why he put the Web Part project on CodePlex.

Visit the SharePoint Forums Web Part CodePlex project site.

Recently Updated documents in SharePoint

UPDATE ON 11/22/2008: This was written way back when I was working with WSS 2.0/SharePoint 2003. Please see Ryan's blog post for some updates with regards to WSS 3.0/MOSS 2007.

I came across this tip a while back, and had to reconfigure one of our document libraries today because I broke it. I figured I'd put the tip here in case I forgot it again, since I can't find it again.

How to make a Recently Updated view in a SharePoint Document Library

1. In the document library, click Modify settings and columns


2. Under Columns, click Add a new column


3. Add a column called "Today" as a Single line of text column.


4. Click Add a new column again and add a column called "ViewUntil" with the following settings:




• Type: Calculated (calculation based on other columns)


• Formula: [Today]+7


• Data type returned: Date and Time, Format: Date Only
  
• Unclick Add to default view
  



5. Delete the "Today" column that you created earlier


6. Back on the Customize document library screen, click Create a new view


7. Call the view "Recently Updated" or whatever you want. Choose whatever columns you wish, but make sure to include the "ViewUntil" column. Sort however you like.




• Under Filter, select Show items only when the following is true


• Show the items when column "ViewUntil" "is greater than or equal to" "[Today]" And "Modified" "is greater than or equal to" "5/4/2006" (replace with the date from seven days ago)




8. Click Ok and now you have a list view that shows documents updated in the past week. It will be updated whenever a user adds or modifies a document.
   

PKI and sponsorship with SharePoint

We've been working on some interesting solutions with PKI (public key infrastructure) and SharePoint sites. I can't go into a lot of detail now, but in a nutshell the system:

• Accepts the users PKI identity certificate


• Checks the status of the user's account


• Logs the user into Active Directory without requiring a password


• Forwards the user to the SharePoint site


• The user can access and contribute within the site as a regular SharePoint user

We also included some nifty certificate type checking, and certain users are required to fill out a sponsorship form and getting approved before they are allowed to access the site.

I'll try to put some details of how we accomplished this up at some point. Suffice it to say, it was a long road and many people helped along the way.

Has anyone out there integrated PKI with SharePoint? I'm pretty sure we're not the only ones doing it, so I'm curious how others have accomplished this.

Workaround for opening Office documents as read-only in SharePoint

In an earlier post, I ranted how opening Office documents (Word, Excel, PowerPoint) from SharePoint is a pain when you are using SharePoint from a different domain than your computer is logged in to. We finally found a workaround, which now seems obvious. Here's a review of the situation:

If your Windows machine logs into Active Directory domain "Homer," but the SharePoint site you access is on the domain "Lois" in a different location, you have to deal with login prompts instead of a streamlined integrated login. This is expected behavior.

In addition, Word, Excel, and PowerPoint documents opened from SharePoint need to authenticate the user as well, because the documents are actually opened from the web server, not the local browser cache. This is also intended functionality: the idea is that the user can edit the files and save them back to the server directly from Word, Excel, or PowerPoint. The user must type their username and password when each separate Office application is opened via the link for the document in Internet Explorer. Usually this is not a big deal.

However, opening documents from a SharePoint site in Internet Explorer is sometimes impossible when a third-party single-sign-on system is in place and the user doesn't actually have the Active Directory username and password handy. If the SSO doesn't know how to handle Office applications, it's impossible to open the files at all because they get stuck at the SSO login process. A workaround is to have users right-click the documents in SharePoint and "Save as," but chances are users would not get the message or forget.

So we finally came up with a workaround while we wait for a permanent solution via the SSO: Convert all Office documents to Adobe PDF. For documents that need to be available in the native Office format (.doc, .xls, .ppt, .vsd, etc.), compress them as .zip files. Use the .pdf and .zip files in the document libraries instead of native Office files.

This can work well for sites where SharePoint isn't being used for document collaboration, or where collaboration doesn't rely heavily on document editing. As far as I know, there's no other way around this problem other than converting the documents to non-Office formats or using a browser like Firefox, which doesn't try to open Office documents for editing from the web server.

We will figure out a permanent solution, but for the meantime the workaround will suffice.

Must be possible

It must be possible to allow SharePoint users to open documents from a WSS site without requiring them to authenticate!

Just not possible

I do not think the following scenario is possible using the current version of Windows SharePoint Services 2.0:

We need to have end-users open Office documents (Word, PowerPoint, Excel) from a SharePoint site and NOT have IE and Office open the documents from the web server. E.g. have the Office documents opened from the browser cache, which would not require any authentication against the server.

This works as desired if browsing the SharePoint site with Firefox, for example. It also works as desired for non-Office documents like PDF. But IE makes the Office applications open the document from the server, which we do not want.

There are a few reasons we need this to work this way, which I won't go into now. Suffice it to say, I've been on Google, Yahoo, and the newsgroups and none of the solutions that I've found works the way we desire (htmltransinfo.xml, DOCICON.XML, ONET.XML, etc.).

Database, Shmatabase

Sometimes, the answer has nothing to do with SharePoint.

I'm doing trial by fire with SharePoint on a project that I inherited. Honestly, it's one of the best ways to learn.

We've been having issues with our WSS test server. It kept showing the following error in the Application Event log:
#50070: Unable to connect to the database CONFIGDB on SQLSERVER. Check the database connection information and make sure that the database server is running.

The site would go down all of the time. It would work, then not work. When it didn't work, it was the generic "Cannot connect to configuration database." We tried all of the fixes suggested online (this, this, this, and others), but nothing worked.

Usually we could connect to the config database using the SharePoint Central Admin, even if the SharePoint site is showing the "Cannot connect to the configuration database" error. Sometimes the Central Admin couldn't find the config database, but usually it worked. Very strange.

We tried changing the domain accounts used, creating new config and content databases and restoring the content, restarting a million times, etc. Nothing fixed it for good.

So, I tried an old trick: Switch the authentication to SQL Authentication. Voilà! It appears that our Active Directory and/or SQL Server connection is flaky. So, this time SharePoint wins.