Here are some more fieldnames you can use:

Title                                    FieldName
-----                                    ------------
Approval Status                   _ModerationStatus
Approver Comments            _ModerationComments
Article Date                         ArticleStartDate
Byline                                 ArticleByLine
Check In Comment              _CheckinComment
Checked Out To                   CheckedOutTitle
Checked Out To                   CheckoutUser
Checked Out To                   LinkCheckedOutTitle
Contact                               PublishingContact
Contact E-Mail Address         PublishingContactEmail
Contact Name                      PublishingContactName
Contact Picture                    PublishingContactPicture

I have come across an issue (bug?) when using SharePoint (SPS and WSS) with Windows XP.

On our network we have a password policy, so users are required to change their password every 45 days.

I have noticed a few times now that some users, after changing their network password are then prompted by SharePoint (SPS and WSS) for their credentials. After entering the information 3 times they are given an "Access Denied" error. This was also then performing an AD "Account Lockout" on their account and preventing them from accessing their email and other network services.

If the user logged onto a different machine with their new network password there would be no problem accessing SharePoint and no prompt was displayed, which meant the problem was a local issue.

It seemed as though the old username and password was being cached somewhere.

This issue only seemed to affect some users and not everyone who changed their password.

After much investigating I found the cause and a workaround to resolve the issue.

Cause:

What seemed to happen was it was storing the old information in the Password list under the Manage Passwords section under "User Accounts". (Start > Settings > Control Panel > User Accounts)

If a user who had ever tried accessing an Area or document library in SharePoint where they didn't have permission, they were getting prompted for their credentials, and the information was being stored in this list.

When the user changed their network password after 45 days, then went to log back on to SharePoint, it was still recognising their old credentials from the cached password list, so when they typed their new password it wasn't authenticating, because the passwords matched.

To resolve this issue:

1. Click "Start" > "Settings" > "Control Panel"
2. Double click "User Accounts"
3. Click on the "Advanced" tab
4. In the "Passwords and .NET Passports" area click "Manage Passwords"
5. Remove everything there.
 
Also, delete everything IN this directory:
C:\Documents and Settings\YOURUSERNAME\Application Data\Microsoft\Credentials
 
and everything IN this directory:
 
C:\Documents and Settings\YOURUSERNAME\Local Settings\Application Data\Microsoft\Credentials

Below is a simple SQL Query to return all documents stored in SharePoint and includes the Title, Directory Name, File Name and Size of each document that sits in the database.

Use it as a starting point for writing your own queries if you want.
Modify the WHERE clause to find specific document types.

I find it comes in handy every now and then.

SELECT 
 UserData.nvarchar7 AS Title,
 DirName AS Directory,
 LeafName AS DocName,
 Docs.Size AS Size

FROM Docs, UserData

WHERE (DoclibRowId > 0)
  AND Docs.ListID = UserData.tp_ListID
  AND Docs.DoclibRowId = UserData.tp_ID
ORDER BY Directory

Wow, it has been a while since I posted anything.

Been unbelieveably busy, migrating users to SharePoint Portal Server 2003.

Last week I migrated about 20,000 Excel workbooks from a corporate file share to SharePoint 2003. The majority of these files were all linked as well, which meant having to write  code to programmatically run through all excel workbooks, find any links, replace the link with the new location the file had been moved to on SPS 2003, then update the link.

What I really wanted to write about though - is more to do with the performance of SPS/WSS.

We have a lot of data sitting inside our portal (about 200 GB and rising), and the peformance has been what you could call "lagging" in the last few weeks. This is mostly to do with another problem with indexes - but that's a whole other story for a whole other post.

I was trying to think of some other ways that could marginally improve the performance of SharePoint, especially in regards to the time taken to load an individual page in both an SPS Area and a WSS Site.
I remembered looking at IIS compression previously, but had never had the need to implement it before. So I decided to give it a try on our staging portal, just to see what results it may produce. I did a bit of investigating in regards to specific configuation settings for IIS 6.0 HTTP Compression and SharePoint and came across a great article written by Maurice. He provides some excellent advice and is a must read before you even think about implementing any compression for your SharePoint installation.

So I followed the advice not expecting much, but to my surprise, this fairly simple configuration seemed to make quite a dramatic improvement in regards to the time taken to load pages in SharePoint.

To cut a long story short - I was so happy with the performance gain on our staging portal that I implemented it on our production portal - and the results are a vast improvement.

There is no point in re-inventing the wheel and have me write the configuration steps involved, so if you want to know more about IIS 6.0 HTTP Compression - read about it over on Maurices Blog

My advice is - check out IIS 6.0 HTTP Compression for some great performance gains on your SharePoint Portal Server or Windows SharePoint Services installation - but make sure you read up on it first, as wrong configurations can actually have negative effects on performance. I pretty much followed Maurice's article to the letter - except I didn't include .dll and .exe files in the compression of dynamic files.

I'm back from spending all of last week in Canberra for work... <W00t!>

The topic I wanted to post about today is: Areas Vs Sites

I have read a few articles on this topic and there a few differing opinions on how to use SharePoint Portal Server Areas versus the use of Windows SharePoint Services Sites and there is also quite a bit of confusion on what they are.

The reason why there are differing opinions is because not everyones use of Sharepoint is going to be the same. It is an extensible platform and for that reason there is no right or wrong approach to how you should use either Areas or Sites, but there was a concept behind Microsofts design and what their intended purpose was.

I thought I would try to explain the concept of Areas and Sites from how I have seen and used them in my day to day experiences.

As it has been outlined by Microsoft and by a few other SharePoint Gurus, The idea behing SharePoint Portal Server is, that it was designed to be an aggregator. A place you can go to to find information quickly and easily.

There is no point putting ALL of your collaborative documents and lists in a Portal Area, as that would sort of defeat the purpose of what an area was designed for.

Windows SharePoint Services Sites are the place to put ALL your documents and lists relevant to a task, business unit, project etc. They are typically refered to as "Team Sites" because you can allow a team of people to "collaborate" all of their work into one central place.

Let me try and think of a good analogy for Areas and Sites.....

Take for example my old High School Biology text book. You could say that the entire textbook was the portal. Each chapter would be about a different topic - just like each Area is about a different topic or department etc.

At the beginning of each chapter there would be a Chapter Summary, which highlighted the most important information that you needed to know about the topic you were viewing. So if you couldn't remember something and had to cram the night before, you would always go to the Chapter Summary and you would then have a general idea of what you needed to know. This is the equivalent to the content displayed in an Area. It is generally the most used or important information to a particular business unit (or department) and is easily accessible from the Area.

But how about the rest of the information? The stuff that may not be in the Chapter Summary (Area) but evidently, information that you may need to read. Well this is when you would need to read the chapter itself and in contrast to the portal - you would need to actually visit the WSS site related to this Area, to locate information that may be more relevant to your needs. The WSS site contains all the linking information that you may want to know about.

Book = Portal
Chapter Summary = Area
Chapter = Site

Ok...this was probably not the best analogy - but hopefully, you get my drift :)

As a rule of thumb, I would suggest only the dependable, completed, and Information which is relevant to an enterprise wide audience, should be available from a portal area. All other draft, correspondance or collaborative documentation should remain on a team site.

Pros and Cons:

Areas allow only one level of security across the whole area, where as in a site you can set permissions on indivual Libraries and Lists.
So if you have multiple document libraries and lists in an area - The user permissions you set in the "Manage Security" option for the area will be the same across all Lists and Libraries.

Areas are easily located on a portal, where as you will need to know the actual URL, content or have a well designed Site Directory to locate the site.

Sites are better for managing external access to (extranet). You probably won't want third parties accessing your portal to look at information in Areas, as the portal is more of a productivity tool for internal use. Having a separate site can allow you to provide access to external resources, and lock down content to a specific level.

Hope his cears things up for those who are a little bit confused about Areas and Sites.

Something that annoys me greatly when you're in a Windows SharePoint Services site is, when you add a link to the quick launch bar, it appears in the order it was added. You have no control over the order in which it is added. You'd think that it would seem more logical to display the links alphabetically rather than, no order at all?

The problem with this is, when you want a certain link to a document library or list to appear before another, your only real option in WSS is to remove all the links, then add them back in the order you prefer, but usually once you have them in nice logical ordering, someone decides to create a new document library or list, and you will need to change the order all over again - pretty time consuming and annoying.

Q: So what can I do to make this process a easier and less time consuming?
A: Microsoft FrontPage 2003

FrontPage 2003 gives you the option to add and change the order of the links in the quick launch navigation bar, very easily.

NOTE:

If you do change the way the links are displayed by editing them in FrontPage, you will cause the page to become unghosted.

For more information on ghosted and unghosted pages and how this could affect you, read Maurice's article on SharePoint Thoughts.

To edit the quick launch links in FrontPage 2003:

1. Open Microsoft FrontPage 2003
2. Click on File > Open Site
3. Type the url of the site you want to edit and click "Open"
4. Double click on the default.aspx file that is displayed in the folder list.
5. When the default home page appears for the WSS site you opened, double click on the area of the quick launce navigation bar that you want to edit (e.g. Documents, Lists etc.)
6. When you double click on the area you want to edit, a dialog appears like this one.
7. You can then select a specific link and use the "Move Up" or "Move Down" buttons on the right of the list to organize the links in a way that you prefer.
(N.B. If you select the "Styles" tab on this dialog you can also change the appearance of the menu with some pre-defined styles in FrontPage)
8. Click "OK" when you are happy with the way you have organized the links

In my last post I mentioned something about the "Remote Web Site" option in FrontPage 2003.

I have found this option really useful, especially when I have two WSS sites residing on different servers, but I want to keep the same documents and/or lists synchronized on both sites.

This is also a good feature if you have an office located in a different country, running a WSS site in a different language. You can leave all the updating of announcements, events, links etc, up to the local office, but keep all documents/list content which may be used globally up to date and synchronized from the one location.

To use the Remote Web Site feature in FrontPage 2003:

1. Open Microsoft FrontPage 2003
2. Click on File > Open Website
3. Type the url of the local site you want to open. E.g. http://server/site/
4. Click "Open"
5. When the local web site opens, click on the "Remote Web Site" tab directly underneath the folder list window.
6. You will then be prompted to click on the "Remote Web Site Properties" button
7. When you select the properties button a dialog will appear like this.
8. Make sure the "Remote Web server type" selected is "FrontPage or SharePoint Services"
9. Type the url of your remote web site at the bottom and click "OK"
10. You will then see a window like this.
11. At the bottom of the window you will see that you have 3 different options under the "Publish all changed pages" heading:
  - Local to remote
  - Remote to local
  - Synchronize

These are pretty self-explanatory, but you can see it gives you an easy way of handling the published content on both sites.

12. Once you have made a selection, click on "Publish Web site" and the options you chose will then be published.

There are quite a few settings that you can modify with the Remote Web Site feature, such as publishing changed pages only, publishing all pages, including sub sites etc. but I will let you take a look for your self.

More information on FrontPage and it's features can be found here

One thing I have noticed when dealing with clients is that they like to know what is happening with their SharePoint sites on a regular basis.

A lot of people want statistics on a particular site, mostly they want to know who is accessing the site.

If you want to know what kind of impact your Web site has, you need to track how many users visit your site, the type and number of hits your site receives, and other site-usage information. Windows SharePoint Services includes features that analyze the usage of your site. Summary and detailed usage reports supply information

such as:

- Number of page hits for each individual page
- Number of unique users
- Browser and operating system information
- Referring domains and URLs

This is all well and good, but what about taking it a step further?

If you have a copy of Microsoft FrontPage 2003, then you can.

To open a site in FrontPage, do the following:

1. Click on the "File" menu
2. Select "Open Site...
3. In the "Open Site" dialog that appears, type the url of the site you want to analyze
(e.g. http://server/site1)
4. Click "Open"

It will open the site like this.

Once the site is open in FrontPage you will notice a few options underneath the list of files and folders.
One of these options is "Reports".

If you click on the "Reports" option you will get a page similar to this.

You have a whole lot of options to look at in regards to the site analysis but the one I want to look at is the "Usage Data" option at the top.

If you click on the "Usage Data" link you are presented with a few different views:

e.g.

Date of first data
Date last updated
Total Visits
Total Page hits
Top referrer
Top web browser
Top search terms
top user

As you can see you get a lot more options than the site usage in WSS site administration.

Let's say your boss wants to know how many people have visited the site since it was created and has given you the task of compiling a report to show at the next departmental meeting.

Once you're in the "Usage Data" section of the Reports, select "Total Visits"
It will display a view with the information you need.

If you right click on any of the white space around the data, you get an option to "Copy Report", which you can then paste directly into Excel.

Now this is all well and good, but what about a graphical representation of this data, it's friday afternoon and the last thing you want to do is read a lot of numbers....

Easy....

At the top right hand side you will see a toolbar.
One of the options on this toolbar, is for charting.

Depending on the data you are analysing, you are presented with a number of different charting styles.

Select on, e.g. "Area Chart" and it will automatically generate an area chart for you.

Very cool.

FrontPage has a lot of hidden features which are extremely useful for SharePoint (i.e. Windows SharePoint Services). Hidden meaning - these features are native to FrontPage and not included with SharePoint documentation so if you don't own FrontPage, you will probably never know about them.

In my next post I will discuss the "Remote Web site" option in FrontPage, which allows you to synchronize files between a local site and remote site. This option is extremely useful if you have two SharePoint servers in different locations (e.g. countries) but want to keep the same content on each.

Have you ever been using Windows SharePoint Services and the search functionality will just fail and not return any results at all?

I have seen this problem a few times and experienced it myself.

If the full text search functionality fails, do the following:

Note: Backup your registry before trying any of the following steps!

1. Open the Registry Editor (RegEdit)

2. Go to the following registry key
    - HKEY_LOCAL_MACHINE\Software\Microsoft\MSSQLServer\Tracking

3. Find the item named:
    - {E07FDDA7-5A21-11d2-9DAD-00C04F79D434}
    ......and delete it

This tricks SQL server into thinking that the Full text service is not installed.

If you have not previously installed SQL Server SP4 continue at step 4.
If you have previously installed SQL Server SP4 continue at step 7.

4. Run the SQL Server 2000 install program from the CD and run through it until you get to a dialog that asks if you want to "Add components to your existing installation"

5. Select "Server Components". The sub-component "Full Text Search" should not be check marked.

6. Check the "Full Text Search" box and click on Next to continue the installation taking all other defaults you previously selected during your initial installation.

7. Apply SQL Server SP4 (even if it has already been applied).

8. Open "SharePoint Central Administration" and select the "Windows SharePoint Services" link from the left hand navigation bar.

9. Under the "Search Settings and Indexed Content" section, click on "Configure full-text search"

10. Un-check the box "Enable full-text search and index component", then click "OK"

11. Re-check the "Enable full-text search and index component", then click "OK"

NOTE: You may also need to open a command line and type "IISRESET" to stop and restart IIS before search will work. It may also take a couple of
minutes to work correctly as it needs to update the catalogs.

<Updated to reflect changes in service packs 19/12/2006>