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.

Via 43Folders

Not really SharePoint related but still a great article for those who find they are swamped with incoming email and can't seem to keep up.

Hmmm...just got reminded that I haven't really posted anything up here in a while.

Been a little busy and have also just started a new job, so haven't had much time to write alot.

Got a few ideas on what to write about next - going to try and step away from FrontPage a bit and focus more on the SharePoint Platform. Plus I may put up a couple of downloads which are useful with SharePoint.

Hopefully there will be some new content in the next few days.

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