Migrating Internet Explorer Favorites and RSS Feeds

With Windows 7 releasing soon, it will be time to think about migrating user profile settings to a new operating system build.

Aside from file folders, and desktop files, you may have a bit of time invested in the Internet Explorer favorites and feeds. Even if it only saves a couple minutes of searching in the end, I thought it would be worthwhile to post locations of these items on a source Vista build.

Favorites:
C: (Operating System) \Documents and Settings\UserProfileName\Favorites

RSS Feeds:
C: (Operating System) \Documents and Settings\UserProfileName\AppData\Local\Microsoft\Feeds

SharePoint 3.0: Clarifying Check Out Status on Multiple Document Upload

I found a post on TechArchive.net, "Re: disabling check out on document library upload," in which the author was observing that multiple document uploads were resulting in status of "checked out" after uploading. The author cited a post of mine, "SharePoint V3: Achieving Checked-In Status When Uploading Mulitple Documents," and explained that the post didn't solve the issue.

So, I am posting the two possible reasons why, after uploading multiple documents to a document library, the uploaded documents have the status of "checked out."


1. Require check out is configured on the library

I did a test, configuring six document libraries, and then performed a multiple document upload. Here are the results:

a.
Document library configurations resulting in "checked out" status when multiple documents are uploaded:
Require Check out + No Versioning
Require Check out + Major Versioning
Require Check out + Major and Minor Versioning

b.
Document library configurations resulting in "checked in" status when multiple documents are uploaded:
No Require Checkout + No Versioning
No Require Check out + Major Versioning
No Require Check out + Major and Minor Versioning


2. The document library is configured with a required field. When the document upload completes, the field is not populated and the status for each of the uploaded documents is set to "checked out."

SharePoint 3.0: Custom Permission Levels

When planning site collection security models for SharePoint deployments, there is certainly a case for simplicity and sticking to the out of box permission levels. Doing this requires the least amount of thought, administrative effort, documentation, and training.



As an added benefit of sticking with the out of box, you can leverage many of the Web based training tutorials and end user, computer based training modules, that are available on the Web with since most of these instructional resources are based on out of box configurations.

Having said that, circumstances and business requirements can require something different than the out of box permission levels. For example, you might want to lock out SharePoint Designer from some users by configuring a permission level that excludes the "Use Remote Interfaces" permission. Or, you might want to prevent content contributors from being able to delete by excluding the "Delete Items" permission. In most cases, having thirty three distinct permissions allows enough flexibility to accommodate.

When I need to utilize custom permission levels, I put a good amount of effort into planning for these and ensure to be consistent with their names, descriptions, and definitions. Below is a sample matrix that I used for planning four custom permission levels, instead of using those which are out of box.

Publishing SharePoint Web Applications in ISA Server

Background:

This article assumes SharePoint Web applications are configured with NTLM Authentication, that multiple Web applications are being published outside a company's firewall, and ISA Server is being used as a firewall. The scenario described also assumes that a one set of Windows credentials has access to multiple SharePoint Web applications.


Description:

It is common for a SharePoint environment to include multiple Web Applications. Since each Web Application requires its own IIS Web site and may have its own IP address and host header, having mutliple Web applications does create some complexity and therefore requires some consideration.

It gets a bit more complicated when multiple Web applications need to be made accessible outside of a company's local network, such as an extranet or public internet scenario. In this case, firewall rules and NAT must be configured for each Web application to protect the organization and the application being published.

Then comes the user experience. Inside the network, client computers often times belong to the same domain as the SharePoint servers, or at least a trusted domain. Furthermore, the domain URLs are considered either "Local Intranet" or "Trusted" by the users' internet browser. In this environment, a user can navigate from Web application to Web application without receiving an authentication prompt. Life is good on the local network.

This all changes when Web applications are published outside the company's firewall. First, client computers accessing the sites no longer belong to the same domain as the SharePoint servers. Second, the users' browsers aren't configured to automatically log users into the Web applications. The challenge this creates for the user is if a contiguous user experience requires accessing multiple Web applications, the user is going to receive an authentication prompt for each application.


Solution:

ISA Server allows Rules to share Listeners. What this means is that you can create one Listener and add multiple Web applications to that Listener. Then, you can create a Rule for each unique Web application, associating these Rules with the Listener.

The result of this is that users can access multiple, externally facing SharePoint Web applications, without requiring to authenticate to each one.

MSDN: Enterprise Search URL Syntax Reference

One of the most simple, yet powerful features of Microsoft SharePoint Search is the URL syntax. Using URL syntax you can submit a query to a search results page without requiring the use of a SharePoint search box. This means that search results can be rendered on a search results page any way that the proper URL string can be built.

For example, search queries may be submitted implicitly throughout the user experience as a user is navigating a SharePoint Web site. Hyperlinks (dynamic or static) containing search query parameters do all of the work.

The MSDN article, "Enterprise Search URL Syntax Reference, http://msdn.microsoft.com/en-us/library/aa637082.aspx," explains the proper format for submitting keywords, scope, view, and start page information through the query string.

Microsoft's Position on Changing SharePoint Databases

I caught a Twitter message from a colleague, Mauro, today passing along a Microsoft Help and Support article which discusses Microsoft's position on database modifications for SharePoint Products. In short, the article breaks down to Microsoft doesn't support changes to SharePoint databases.

The article, "Support for changes to the databases that are used by Office server products and by Windows SharePoint Services (http://support.microsoft.com/default.aspx?scid=kb;EN-US;841057 )" includes a list of unsupported database changes, shown below:

" Examples of such database changes include, but are not limited to, the following:

• Adding database triggers
• Adding new indexes or changing existing indexes within tables
• Adding, changing, or deleting any primary or foreign key relationships
• Changing or deleting existing stored procedures
• Adding new stored procedures
• Adding, changing, or deleting any data in any table of any of the databases for the products that are listed in the "Applies to" section unless Microsoft protocol documentation is followed exactly
• Adding, changing, or deleting any columns in any table of any of the databases for the products that are listed in the "Applies to" section
• Making any modification to the database schema
• Adding tables to any of the databases for the products that are listed in the "Applies to" section Changing the database collation "

This subject comes up rather frequently during discussions and as a proponent of SQL Server in general and especially its Business Intelligence features such as Reporting Services for extending the capabilities of SharePoint solutions, I feel compelled to chime in.

I completely understand Microsoft's position. How could a software company possibly support custom, schema changes or functional modifications to their application? They cannot. Nor can Microsoft really ensure their software will function (optimally) with any type of foreign database object running on the live databses, even a view.

However, accepting Microsoft's position doesn't change two things:

1. SharePoint information is business intelligence information and often times needs to extract, transform, load, and display in other places than its native content database.
2. Where there's a will there's a way.

Exploring some scenarios...

If you need to add custom functionality to your SharePoint environment, then you might build your own custom database with triggers, functions, sprocs and all, and then use a programmatic methods to move the data you need out of the SharePoint content databases and into your custom database. Then, use Web Parts to deliver the data and functionality from the custom database throughout the SharePoint Web sites. This does not overstep any of the guidelines listed in the article.

Secondly, T-SQL queries are some times necessary for reports when using the Object Model as an XML data source reaches limitations. If you need to integrate SharePoint data with other systems or for reports you can:

1. Create a database snapshot of the SharePoint content datbase (if you have SQL 2005 / 2008 Enterprise Edition)
2. Use programmatic methods to move the data from the SharePoint content database into an intermediary database for abstraction purposes.
3. Move data into an existing data mart or data warehouse during regular intervals.

Any of these three approaches allows you to leverage Views. The benefits of compiling T-SQL queries as Views is that you can secure them, you can use them as data sources in SQL Reporting Services reports, and you can store them on the database where they are accessible, reusable, they get backed up with database backups, you can optimize query performance with Indexes, and querying Views performs better because you are not storing queries nor are you filtering or transforming data in the Web tier.