Access denied when trying to open a site when on the server

I just wasted half a day trying to figure out why some feature code was not working.
The feature code used HTTPRequest to get a file from the layouts folder- and kept failing with “Access Denied”.
It also turned out that when I logged on to the server I couldnt browse to the site - it asked me for credentials all the time.
After wasting a long time debugging and troubleshooting, this support article saved the day - a little registry change and everything works.

Showing "my links" on a web page

You know how users can have a list of links known as "my links" in MOSS? (not WSS) It has a nice web interface for managing favorites and storing them in the user's "my site", and even group them by groups, and display them in every page on the top as a drop down menu:

Well, what if you want to show the list on a page? easy - they exist as web parts, but ones that do not exist in your web part gallery by default.

1. Open Site actions>Site Settings


2. Click on "Web Parts"


3. Click on "New"


4. Scroll down in the list to find "QuickLinksMicroView" and select it
   


5. Click on "populate gallery" and go to the page where you want the web part.


6. Add the web part to the page

The web part has only two properties to customize it:





And at the end it looks like this:

Things to think about when planning a SharePoint solution

Here is a list of things that people seem to forget when planning a sharepoint solution:

1. There will be many users using the solution at the same time. Make sure your solution is able to deal with that.
2. When developing a web part or a custom field control, always remember that more than one instance of it may be on the same page. Lack of testing of what happens if you put two web parts side by side on the same page may cause scripts to clash if you didn't plan right.
3. Most (all) sharepoint implementations have more than one front end server. Plan for your solution to be able to spread across multiple servers, and make sure that when it does, it load-balances!.
4. Dont forget logging of errors in this case should make it easy for the admin (or yourself) to find where the error was- regardless of the server that was serving the client when the error occured.
5. Performance! users do not like to wait more than 3 seconds for a page to load - and if your web parts are not performing well, you will ruin the browsing experience in the site. Use caching techniques to improve page loads.
6. Remember when caching that some things should be cached on a user level, and some can be on the application level.
7. In web controls - remember error trapping. This may be obvious to anyone who ever developed anything, but this happens so often that I have to just say - I don't care what you do with your errors - but don't crash my page! Make sure everything is nicely wrapped up in try-catch, and never throw an error to a page. Remember that other people (controls) are using it as well - it is not yours.
8. Develop for deployment. Make sure you plan a WSP package, and document well the list of all the things that will be required that cannot be deployed using a WSP package (changes to the web.config aside from safecontrols for example)
9. CAS!

A must read blog post -everything about AllowUnsafeUpdates

If you are a sharepoint developer, you have to read this one: What you need to know about AllowUnsafeUpdates. While you are there, take the time to register to that blog. Hristo Pavlov looks like a blogger to watch for!

Tweet - writing code that accesses a site in another application pool

sorry for the tweet - no time to explain.
<TWEET> If you are writing code that accesses (or potentialy accesses) a site in another application pool, make sure that the application pool account for the current application pool has database permissions on the database for the other application. otherwise - you'r objects will not get created. </TWEET>

Access denied when trying to get to shared services

In the last couple of days a person next to me was trying to install SharePoint and failing every time with the shared services. After setting up the shared services, he couldnt open the shared services site - it would "access denied" him, no matter what account he tried to log on as (and we even tried the application pool account).
We immediatly suspected that kerberos wasnt configured correctly, that we didn't give enough local permissions for a system account or that some metaphysical entity just hates us sooo much.

Today I sat with the guy and watched him configure everything correctly. Still - access denied. damn!.
I turned to my trusty friend google, typed "sharepoint ssp access denied" in the search box and the second result had not only a workaround - but also an explanation why it happened and how to avoid it in the future.
So first of all - thank you Faraz for finding a work around, but more importantly - thanks to Scott who wrote the following in the comments:
"DO NOT call you SSP the same name as the AppPool you use for the SSP Admin Site.
The SSP actually uses its name to create an AppPool for use under the Office Search site.
If your SSP Admin AppPool is the same name then MOSS sets it to use the timer svc account.
If your hosting then call the SSP Admin AppPool 'Company - SSPAdmin' and the actual SSP 'Company - SSP'. This will stop MOSS clobbering the accounts."

This was exactly what we did wrong! We created a new SSP and this time made sure the SSP name is different from the application pool name, and here we go! ready to start.
So, if you are the Scott who wrote that comment - I thank you.

A Lookup to the sub sites

A question from the forums:
"I'm creating a WSS 3 site which will have a new subsite each time there is a planning application.
From the parent site I want to be able to enter documents and say which application it belongs to but I don't want the user to have to maintain a list of application names when they could just lookup to a list of all the Application subsites that have been created.
Does anyone know if that's possible?"

My Answer:
This is not possible out of the box (unless you use the SiteDirectory template, and create the application sites' there).

To code it, here are several options:

1. either connect a workflow or an event handler to a list of applications, and the workflow\event handler can create the site for you.
2. Develop a custom field control that will load the list of sub sites for the user.
   This should be more robust than option 1, since a workflow\event handler may fail to create the site and you will end up with a mess. however, custom field controls are not supported by office - so you will not be able to set the metadata on documents from within the office applications.
3. Develop a timer job that synchronizes the list of sites into a choice field as choices.
   This will be robust, and will work in office - but will put a load on the server
4. RECOMMENDED: develop a feature for the application sites that will add the name of the site to a list when the feature is activated.
   This will be better than option 1 because you can trigger it again if it fails, without re-creating the site. Also it will have much less load on the server than option 3, and better performance than option 2 since it will not have to check the sites every time someone wants to upload a document. Also - easy development.
5. Develop a BDC application (using a custom web service) to show the list of applications based on the existing sites.
   This may be the second easiest option (after #4) - such a web service is easy to develop. But this will only work if you have MOSS license, as the BDC is not part of WSS.

My TechEd 2008 Presentations are on video

I gave a presentation in TechEd Israel a month ago, and it is now available to view on streaming video from Microsoft Israel.
The presentation is building an end-to-end community solution using the Microsoft Office System (sharepoint+word in this case) - using web services, custom task panes in office and even a bit of WPF thrown in for good measure.
The powerpoint is in english - but is mostly empty since 90% of the presentation was done in visual studio. If you want to see it, download it here.
The video is available for either streaming or download, but be warned - I am talking in Hebrew (and very quickly...sorry about that - wasn't given enough time to do it properly). If you are interested in seeing how to code a sharepoint web service that reads word 2007 documents and exposes their contents to a custom task pane in word, then by all means, download and watch - just mute the sound (I don't like how I sound in recordings anyway).

The other presentation I was involved in was "the 7 great tips of sharepoint deployment" where I gave the winning tip (using WSP to deploy solutions to farms). The other tips are also interesting, and again the powerpoint is in english while the video is in Hebrew - stream or download.

Antarctic pictures

I promised some people I would publish some pictures my girlfriend brought back from Antarctica, so here you are.

Event handlers configuration settings best practices

Where to place configuration settings for event handlers?
I have thought about it and came up with a few options:

Place config information in the event handler registration info
Every time you register an event handler with a list you can specify data specifically for that registration. This can be done with a feature, or using code (see my utility pack for an easy way to do that)
PRO:

1. Can be deployed using a feature. We can have different config per list.

CON:

1. We only have a seperate config per list (no one place to manage all lists).
2. Limited to 256 characters.
3. You will need to run code to change the configuration.

Place config information in the web.config <appSettings> section
I was surprised to find that the event handlers get access to the web.config as if they were web applications. Cool!
PRO:

1. One place to manage per web application. can be deployed using a web application feature and some custom code (http://blog.tedpattison.net/Lists/Posts/Post.aspx?ID=4)

CON:

1. Hard to deploy every time you create a new web application in the farm. This can be resolved by creating a feature and stapling it at the farm level (scope is webapplication) that modifies the web.config to include the section you want, and setting some defaults - so that the event handler finds what it is looking for when a new web application is created.

Place config information in a settings file on the file system
PRO:

1. One place for the enitre farm, can be deployed using a solution package

CON:

1. Location is hard coded in the event handler (unless we use this approach mixed with option one!).
2. Folder must allow users to read, or impersonation will be required.

Place config information in a settings file in the GAC, next to the assembly
I used this a few times. You can put a file right next to the dll, and use a helper class in the dll to deserialize it and read the values.
PRO:

1. one place for the enitre farm, no hard coding of location.
2. Use Mide Woodring's AssemblySettings class to read from it. can probably be deployed as a farm feature

CON:

1. Every time a new dll version is entered, the config will be deleted and will have to be added again.

Place config information in a document library\list in the root sharepoint site of a site collection or in the central administration site or the shared services site for that web application
PRO:

1. Deployable as a feature at the site collection level

CON:

1. still requires custom code to get the config.
2. performance hit on reading the configuration (can be minimized with caching).
3. (if root site collection option) Only supports site collection level configuration.

Special thanks to Reza Alirezaei who pointed out some spelling mistakes and commented on the web.config section.