Hello again.

Let us jump right into where we left off, shall we?

When logging on to the SharePoint server this morning I was greeted by a couple of error messages, stating that the IIS worker process had gone nutty. This was actually a source of joy as it meant that the error had been reproduced during the week I've been away from the server.

Looking at the Debug Diag tool lowered my spirits rapidly though as it had caught nothing in it's web. Not even the all-encompassing "All IIS related processes" filter had any info about the crashes.

I took a quick stab at the IISState tool I mentioned in my previous post but that didn't help me as it was more or less a command-line version of Debug Diagnostics. Instead I decided to read up on how to use Debug Diagnostics (I know, I should've done that to begin with but hey, I'm only human).

First off I noticed that there's a version 1.1 of Debug Diagnostics available so I grabbed that one and installed instead (you need to either uninstall the entire IIS Debug Toolkit or just Debug Diagnostics 1.0 in order to install version 1.1).

SearchWindowsServer.com has a nice roundup of links relating to this tool, one of them is a Microsoft KB article entitled How to use the Debug Diagnostics tool to troubleshoot an IIS process that stops unexpectedly, which sounds like something I need to read.

First of all I need to turn off health monitoring in IIS:

1. Open the IIS MMC snap-in.
2. Expand Application Pools.
3. Right-click Application Pools, and then click Properties.
4. Click the Recycling tab, and then click to clear all the Recycle worker process check boxes.
5. Click the Performance tab, and then click to clear the Shutdown worker processes after being idle for (time in minutes) check box.
6. Click the Health tab, click to clear the Enable rapid-fail protection and Enable pinging check boxes, and then click OK.
7. Restart IIS. To do this, click Start, click Run, type iisreset, and then click OK.

Creating the actual crash rule is not explained in great detail though and the "Select the desired Target Type, and then click Next." line is not at all helpful as it's what type of target I'm unsure of. Unfortunately the aforementioned SearchWindowsServer.com article only tells me how to analyze an existing dump file.

So I'm going with the "A specific process" option and then selecting the w3wp.exe process. Microsoft tells me that after that all I have to do is the classic "Next, Next, Finish" manoeuvre and I gladly comply as I'm not quite sure what the advanced options do.

And yet again we wait for our unsuspecting prey to stumble into our cunning trap...

I guess most of you have seen an error reporting dialog for the IIS Worker Process from time to time when you log on to your SharePoint (or IIS) server - I know I have and far too often.

There is not a lot of information on how to properly troubleshoot this but there are a lot of people that wants to know what to do about it. I hope that I will be able to shed some light on this through a series of posts, although I will be posting these as I troubleshoot.

This means that I have no real idea where I will be heading or if I even solve the problem. Then again, it makes for a lot more interesting reading. :)

Searching for information about this mainly returns two links:

• An IIS 6.0 application pool may unexpectedly exit when a worker process shuts down or is recycled
• David Wang's HOWTO: Understand and Diagnose an Application Pool Crash

The first one is an IIS-generic knowledgebase article on how to set permissions for applications pools but it is of course applicable to WSS/MOSS as well.

Do the following in order to figure out what identity your SharePoint application pool runs as:

1. Open IIS manager on the SharePoint server
2. Expand the tree under the server and application pools section
3. Right click the correct application pool (in my case it's Sharepoint - 80) and select Properties
4. Select the Identy tab and note down the identity used

I won't go through the KB article but suffice to say that it didn't help me solve the problem as everything already was hunky dory.

The next link above leads to a very comprehensive How-To/philosophical discussion on how to handle application pool related snafus. David Wang has been at Microsoft for five years in the IIS team (if I can read his long winded bio correctly ;) and has put together a very interesting article about how IIS handles processes. Well worth a read, even if it is quite meaty.

Still - there's no real practical information there other than that we need to capture the crash in the wild, so to speak. We can't troubleshoot this error after the fact and he reccommends two applications; IIS State or DebugDiag. I went with DebugDiag myself as it's an official Microsoft tool.

Setting up DebugDiag wasn't entirely straight forward as I didn't want to wade through huge amounts of trace dumps if I could avoid it. This meant that I first created one filter for only the SharePoint - 80 application pool but it seems as if it didn't catch the error (as I did get one in the event viewer during the time DebugDiag was running).

This meant that I set up a new filter - alongside with the old one, just in case - that is meant to catch all IIS related crashes but so far I haven't been able to reproduce the crash.

And here ends this first installment. I know some of you wanted an actual answer but I have to blog it like this or my memory will fade and/or I won't have the time to blog about it at all.

So join me for the next part of the saga, hopefully within a week at the latest.

Hi all.

There has been very little SharePoint consulting for me the past six months which means that this blog was left untouched and abandonded. I'm ashamed to say that I only update it now because I need help. :(

When creating a custom list there's always a default text field created. This is, among other things, used as the "anchor point" for a preview type of view (the one where you hover the mouse pointer over an item in the list to the left and you get a preview of the object to the right).

The list I'm creating now has a person/group field as the main identifier and thusly I want it to be the anchor point for the preview view but I can't for the life of me figure out how to do this (perferably w/o too much coding).

Any thoughts/ideas/pointers regarding this?

TIA!

Ok, one of the worst subject lines ever, I know, but I'm not sure what to put there.

Anyhow, the controls I'm talking about are the ones you use in the MOSS managment web site (this one I'm sure isn't in WSS as it's part of the SSP) after you add a custom property. Those of you that have done this know that in order to move the new property all the way from the bottom to where you need it (in order to get your "Details" page to look as you intended) you click one of two arrows. It's one arrow for up and another for down, both have a snippet of Javascript attached to it.

I was getting fed up with having to click the up arrow 35 times in order to move my new property to the correct position so I thought I'd hack the Javascript snippet. It didn't do any good but I though I'd share my findings - albeit minor - with you.

This is the code (sanitized for publishing) for moving the property at position 43 to position 42: javascript ProcessProperty('ctl00$PlaceHolderMain$MgrProperty1_N_43','False','MoveUp','ctl00$PlaceHolderMain$MgrProperty1_U42')

To me it looked like I can replace "U42" with "U14" and have it jump from 43 to 14. No such luck.

The first variable, 'ctl00$PlaceHolderMain$MgrProperty1_N_43', indicates at which position the property you want to move exists. This means that we can't re-use the same link over and over again in order to move the property - it points to a position in the list and not a specific property.

I'm not sure about the second variable so feel free to fill me in if you know anything about it. The third one is pretty self-explanatory - it says "MoveDown" for the down snippet.

Now, the final variable is the most confusing one as one would assume that it tells the script where to move the property. Then again, why would there be a need for the "MoveUp" variable if you could tell the snippet to move between two positions? Huh, didn't think about that did you? Me neither, until just now. :)

So what it does is tell SharePoint where to put the focus when it reloads the page. As you move the property one step up it's logical to focus on the next position in the list. If I replace 42 with 14 all that happens is that the page reloads with focus on the property at position 14 in the list.

So, here's my tip to the SharePoint team at Microsoft; make the code snippet move from position A to position B and skip the direction altogether. This way I, the power user, can hijack it and tell it to move the property at position 42 to position 14 in one fell swoop.

Thoughts?

I love the new Alternate Access Mappings feature in WSS 3.0/MOSS 2007 but it can be a major pain in the behind.

One of the things you probably will stumble upon when installing MOSS is the need to expose some or all of the content to the outside. So far I've been lucky enough to deal with situations where it's all or nothing, making life somewhat easier. Still, there's quite a few things that can foul up the waters, including AAM.

Now, if you're going to expose MOSS, or any web site, to the outside you will want to do this via https (at least not plain old http) which means that you'll need to make sure that MOSS understands https:/... access and, most likely, start using https internally as well. This involves, besides installing certificates, changing the AAM settings.

The thing with AAM is that it (AFAIK, correct me if I'm wrong) controls all the automatic URL generation throughout that collection. This means that if you need to change the My Site location from http://mysite.corporate.com to https://mysite.corporate.com you need to update the AAM to reflect this. To do this you change the Default mapping for the My Site AAM collection from http://mysite... to https://mysite...

If you fail to change the AAM before you update the My Site location MOSS happily and without telling you changes back to http://mysite... If you're really lucky you'll get something along the lines of https://mysite.corporate.com:80 which, of course, doesn't go over very well.

Another thing to keep in mind is that when installing certificates for both the main MOSS web application and the My Site web application they need to be assigned specific IP-addresses or one of the applications will fail to start, most likely the My Site application. This is because even if you can use host headers for port 80 this doesn't work with SSL traffic.

In conclusion; be mindful of your AAM settings as they dictate quite a bit of what's happening in your MOSS server.

Addendum: After tinkering some more with my My Site and AAM woes (I got "Unknown error" when browsing the My Site URL) I realised that I needed AAM entries for https://mysite.corporate.com (Default) as well as http://mysite.corporate.com (Intranet). I can't explain this but I'm suspecting that there are some residue from the initial setup at http://... that requires MOSS to allow access to items even though we're actually using https.

Also, don't forget to update your trusted My Site settings so that both https://... and http://... are trusted.

While fooling around with the search result page I decided that it would be useful if my employees would be able to search explicit on these custom properties. I found a couple of tutorials on how to modify the "normal" advanced search page but not much on the people search page so I dug around a bit.

This is what I came up with (sorry for the rush job but I'm in a rush):

1. Browse to your advanced people search page.
2. Edit the page.
3. Modify the People Search Box web part.
4. Expand the Miscellaneous section.
5. Click in the Properties text field and open it up in the "builder" (click the ... to the right of the field).
6. Add the custom property you want to be able to search on where you want it to show up in the form. Use the following syntax:
   <Property Name="YourPropertyHere" ManagedName="YourPropertyHere" ProfileURI="urn:schemas-microsoft-com:sharepoint:portal:profile:YourPropertyHere"/>
7. Click OK to save the modified form.
8. Test or publish your page as needed.

You should probably use Notepad or a similar text editor when editing the properties as some of the code that SharePoint spits out is quite messy.

EDIT: You need to modify both the search page (people.aspx) as well as the result page (peopleresults.aspx) if you want consistency in the search options.

Let me know if you have any problems with this and I'll do my best to help you out.

I've been trying to get my modified people search result web part to behave for some time. My problem was that my custom properties wouldn't show up no matter what i did. I followed Henry Ong's guide to the T without success.

After some searching I finally stumbled upon this post and, more importantly, the final comment of the post wich solved the problem for me.

When adding custom properties to your search result you must use lower case in the XSL-editor!

If you use "BeginnerSkills" the column will not be found and you have to use "beginnerskills" as your parameter name - even if you called the column "BeginnerSkills" when you included it in the Results Query Options section.

I have created a number of templates for various types of sites for our internal MOSS. One of these are a customer site that - among other things - has a subsite for all our projects related to this customer.

When I save this site as a template I include all the content as I've created a number of custom web part pages in a document library that we use but there is no way for me to include the project subsite.

Would it be possible to use a solution file for this? According to this MSDN article it doesn't sound like a solution file is the answer.

Is there an easy way to accomplish this or am I forced to create the project subsite manually for each new customer?

From time to time I need to elevate the permissions of a group of users. A recent example was when I created a FAQ discussion forum on our top level site in MOSS. Normally all our employees are visitors to the main site as we have special content managers for this site (it's a publishing site) but for this list they needed to be able to add content (contributor rights).

I've read a couple of different ways to handle situations where permission rights conflict like this and one golden rule I've heard is never to change the rights of a predefined group, such as giving visitors contributor rights. If you violate this rule you end up with a number of lists, sites and what have you where a visitor no longer is a visitor.

The "proper" solution, I would guess, is to create a new SharePoint group and call it "Contributors to this list" or some such, give it the proper rights and then add the users to this group. This is a rather cumbersome process though.

You could also add the users to the "Contributors" group but that would give them contributor rights to the entire site and that's a no-no - at least for me.

Lately I've found myself violating my golden rule more often than not by breaking permissions inheritance from the site the list resides in and then giving the orphaned visitors group the proper rights - simply because it's the easy way out.

How do you handle situations like this? Quick and dirty or by the book? Or maybe some other way?

While searching for information about web services in WSS 3.0 I noticed that MSDN didn't have a certain page in English so I got the Japanese one instead.

I'm not sure how they figure that it was a good replacement as my knowledge of the Japanese language is in no way related to my knowledge of the English language...

Edit: Grabbing the WSS SDK provided me with the information I wanted in a language I could understand, by the way.

I'm currently creating a rather extensive list for a customer. Extensive as in "contains a lot of columns". We could've created a list based on a spreadsheet but that didn't feel as organic as creating the columns as we go along so I'm doing it one by one.

There are two minor gripes with this approach and the problem with minor gripes is that they become major gripes when encountered often enough.

First off the "Create new column" link slowly moves down and off the page as the new columns pile up in the list above it. This means that you need to scroll down more and more as you're looking for that link.

Secondly you might want to check out the actual form for various reasons and although you can (and should) have a separate tab/window/instance for this I know I'm going to confuse them sooner or later and end up with the "New column" form in both tabs/windows/instances.

My solution is to simply drag the link for the new column form to the quick links bar in IE/FF/your favorite browser. It's a lot easier to find and it's a lot easier to hit. Plus it doesn't matter what page I'm on - I can always get to the new column form quickly.

Much ado about nothing perhaps but it might make someone's day a bit more endurable.

As I needed to tamper with a customer site in a virtual lab environment I decided to do a one-off backup of it via the admin GUI.

After selecting the farm I decided to back this up to \\sharepointtest\c$\backup - a directory that I as administrator has full access to. To my frustration I got numerous errors that in ways indicated that the SQL databases was broken.

Panic ensued until I calmed down and started troubleshooting.

It turns out that you can not use the administrative share of C: (or perhaps any path with $ in it, I haven't had time to test yet) any drive in order to make a backup. Once I shared the backup directory on it's own and changed the path to \\sharepointtest\backup the backup went through without a hitch.

All the help has to say about backup locations is "The file share must be configured with the correct permissions and be a valid backup location." - something my first choice of backup path lived up to (depending on what a "valid" backup location is, I guess).

I guess that there's information about this out there somewhere but it was such a frustrating error that I thought it merited a post of it's own here as well.

Edit: I've checked and there's no restriction when it comes to hidden file shares - administrative shares are off limits though.

I've been struggling with the top link tabs for a customers WSS 3.0 site for some time now. Some of the tabs would be highlighted properly when selected and some would not - reverting to highlighting the first tab in the list when selected.

Searching for a solution to this yielded nothing of value (this is as close as I got) so I set out to try and figure out the logic behind it all.

It turns out that the reason some of the tabs didn't highlight properly was twofold;

• All links need to end with an actual web page. That is, you can not link to /sitename/listname/, you need to link to /sitename/listname/view.aspx.
• The link can not contain any spaces - not even if you subsitute them with %20.

After changing the faulty links so that they complied with the above guidelines they all highlighted properly when selected.

If you find this post helpful, please link to it so that it climbs up the ranks in Google - I had a hell of a time finding anything relating to this when searching.