SP2010 Create site without template

I often let my users decide which site template they want to use for their new site collection. In SharePoint 2007 i did this by creating a site collection using stsadm without specifying a site template. this caused the first user to have to select the site template to use. There was no possibility to create a site collection without specifying a site template through central admin.

Now in SP2010, the possibilty to not specify a site template has been built in to Central Admin. When creating a new site through Central Admin, notice that there is now an entry in the Custom tab, called ‘ < Select Template Later … >

Now when your user hits his/her new site collection, he/she will get redirected to the templatepick.aspx page and has to pick a site template.

SharePoint 2010 Office Web Apps on a single server SharePoint Foundation –> Issues and Fixes

I finally found some time to get the Office Web Apps working on one of my servers running SharePoint Foundation 2010 beta

This is the server that I had upgraded from WSS 3.0 etc. As you may recall, I had completely uninstalled my SharePoint 2010 Foundation and WSS 3.0 after successfully having upgraded my WSS 3.0 site collection to SharePoint 2010. This enabled me to have a “clean” installation of Foundation. After all that,  I decided to give Office Web Apps a try. The installation went smoothly and after running psconfig, all service applications were up and running.

So I gave it a try and as expected it did not work….bummer … That was some weeks ago. I finally found the time to get this fixed. I googled around a bit and found an article by Kylie Richardson.

She had run into the same issue I had, where the Word Viewer refused to render the document. Apparently this is an issue if you are running SharePoint Foundation on a Domain Controller. The system I am running is running so much more than that ūüôā

In my case the solution did not work. I got error messages in the eventlogs stating that my Excel services and Word Services were not properly registered in the Config database.

Finally I decided to follow Kiley’s article all the way where she installed Foundatation and Office Web Apps before running the SharePoint 2010 Products and Configuration Wizard to create the farm.

The steps I took:

  • took a backup of my site collection
  • uninstalled Office Web Apps
  • then uninstalled SharePoint Foundation 2010
  • reinstalled SharePoint Foundation 2010 without running SharePoint 2010 Products and Configuration Wizard
  • reinstalled Office Web Apps
  • ran SharePoint 2010 Products and Configuration Wizard
  • restored my site collection
  • executed the suggested commands by Kylie:

$e = Get-SPServiceApplication | where {$_.TypeName.Equals(“Word Viewing Service Application”)}
$e.WordServerIsSandboxed = $false

#(Please use the below script for PowerPointServiceApplication – You need to enter “Y” for the answer of each cmd)
Get-SPPowerPointServiceApplication | Set-SPPowerPointServiceApplication -EnableSandboxedViewing $false
Get-SPPowerPointServiceApplication | Set-SPPowerPointServiceApplication -EnableSandboxedEditing $false

In the server’s c:\windows\system32\inetsrv\config\applicationHost.config
Add the line below in the end of the dynamicTypes.
<add mimeType=”application/zip” enabled=”false” />


So there I was with my completely reinstalled SharePoint Foundation

Cool. So now Office Web Apps works…..or NOT!

After having doen all these actions, it still didn’t work. I remebered for Excel Services that you need to configure the Trusted File Locations, so I went to the Service Applications, Selected Excel Services and added a trusted file location for my site collection –> No Luck, still didn’t work.

At this point I went back to basic troubleshooting…Eventlog and bam! There was an error indcation that my SharePoint Farm Service account was unable to open my content database, which was not there before having reinstalled everything. As a fix I added my SharePoint Farm Service account in the permissions of my content database and voila, Office Web Apps works!

As it turns out, I am using different accounts for my Application Pools as everyone should and the Excel Services and Word Viewing Service seem to use the default SharePoint Farm Service account for accessing the content.

So again, nice to know, isn’t it ? [:D]

Revert a SharePoint 2010 site to the WSS3.0/MOSS2007 Look after Visual Upgrade

This question came up in one of my comments recently and I wanted to find out if it was even possible to reveert the look back of a SharePoint 2010 site that has been upgraded from WSS 3.0 or MOSS2007

Thanks to Corey Roth and a comment on his post about I found out the following:

“In SharePoint 2010, there is the concept of a UI Version and it has a value of 3 or 4.  When you upgrade your existing site, it will leave you at Version 3 which looks just like WSS3.  However, you have the capability to upgrade to the new SharePoint 2010 visualizations which is version 4.  If the administrators have the options enabled, you can change your UI version using the UI itself.  It provides the capability to run on Version 3 but get a preview of 4 and then ultimately they can convert to version 4 completely.  However, you may want to do this programmatically or you may want to revert back to version 3 after you have turned off preview mode.  “

So there are already two possible ways of doing it:

1. Using Code: (thanks to Corey Roth)

using (SPSite siteCollection = new SPSite(“http://server/site“))
    SPWeb site = siteCollection.OpenWeb()
        site.UIVersion = 3;
        site.UIVersionConfigurationEnabled = true;

2. Using Powershell: (thanks to Tobias Zimmergren)

$site = Get-SPSite(“http://portal“)
$web = $site.OpenWeb()
$web.UIVersion = 3

Tip of the day: The best way for finding your downloads on microsoft.com/downloads –> USE GOOGLE !!

This is my frustration of the week!

Don’t you just hate it when you are on the nice Microsoft Download Center¬†www.microsoft.com/downloads¬†website, that when you search for a download, like Sharepoint Language Pack, that you get a blank page? Well I do!

I blame it on Bing….

¬†That’s why I decided to kill my Bing ringtones from my cell phone and use Google by default for my Microsof Download searches


SQL Query to identify Kerberos or NTLM connection (by Marc Valk)

 I found myself looking for this query for the second time now and finally decided to post it on my blog [8-|]

This query enables you to find out if your connections towards your SQL server are using Kerberos instead of NTLM. This may help in your troubleshooting or confirmation for your Kerberos implementation on SharePoint.

 If found it back this time on the blog of Marc Valk (http://www.marcvalk.net/2009/04/sql-query-to-identify-kerberos-or-ntlm-connection/)

FROM sys.dm_exec_sessions s
JOIN sys.dm_exec_connections c
ON s.session_id = c.session_id

Find out which language packs are installed and the build version

I was asked this question yesterday and I remember having tried to find out how to do it. Finally I took some time to search around on the net and found a post by Patrick Heyde.



which says the following:

3. Which SharePoint language packs were installed?

Answer: check registry

HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Shared Tools\Web Server Extensions\12.0\WSS\InstalledLanguages\<LCID>

here you will see something like this:

LCID – Reg_SZ – {language pack build level}

1033 – Reg_SZ – 12.0.4518.1000

1031 – Reg_SZ – 12.0.4518.1000


LCID – Reg_SZ – {language pack build level}

1033 – Reg_SZ – 12.0.6219.1000

1031 – Reg_SZ – 12.0.6219.1000

Note: It’s important to have all language packs on the same build level!

To get an overview about all Microsoft LCIDs you can use this article: Local ID (LCID) chart

Thanks Patrick, in my case the build version was set to 12.0.6425.1000 which turns out to be SP2

Saving Document to SharePoint using Office 2003 resets choice metadata fields to default values

I was recently facing an issue as described in http://stackoverflow.com/questions/809179/saving-a-document-to-sharepoint-brings-up-web-file-properties-dialog-with-incor

Recap from original post:


  • A custom “Master Document” content type inherits from Document
  • The “Master Document” content type has five additional choice fields
  • There are five custom “Document Template” content types that inherit from the “Master Document” content type
  • Each of the “Document Template” content types uses a different Word document template (.dot) file
  • Each of the “Document Template” content types have been added to a document library


  1. I click on a document in the library
  2. Document opens up in Word 2003 for me to edit
  3. I make some changes and save
  4. A box pops up called “Web File Properties”. The window contains all of my custom metadata properties and the ContentType field. The ContentType field is set correctly to the current content type. The other fields are reset to their default values. This same window can apparently be opened by going to File -> Properties

This window by itself would be fine except for two reasons:

  • It includes the ContentType column
  • All of my custom metadata properties are visible but are reset to their default values instead of whatever values were previously selected. This means, every time the user wants to save the document, they have to remember what properties were tagged and set them back.


  1. Can I disable this Web File Properties box?
  2. If no… can I get the fields that show up to be populated to their correct values?
  3. If no… is there a way to disable my fields from displaying in this window?
  4. If no… is this a SharePoint page that I can modify?

***Edit with some more information***

It looks like this only happens in Office 2003 and looks like it affects Choice fields. If I create the same column as a Lookup field, it seems to work.

Edit again

Looks like if the lookup field is a multi-select field then it will not show up in the Web File Properties box at all (single select lookups still work).

edit 10/14/2009

Link to the KB Article mentioned below by Brenda: http://support.microsoft.com/kb/971500/

My Solution:

Of Course the suggested hotfix, which in fact is the June Cumulative Update for WSS did not fix my issue, but I did find a solution at the end.

What really happens when you call the Web File Properties box is that your client will download 3 javascript files from the server:  bform.js, core.js and init.js. You can check this by by opening up the document library causing the issue and clearing your temporary internet files at that time. When you now call the Web File Properties in Word 2003 through File –> Properties, you will notice these 3 script files being downloadin in your temprary internet files folder.

On the SharePoint front-end servers, you can find these files in the 12-hive\Template\Layouts\<LCID> folders, where you have  to replace <LCID> with your language codes installed (1033, English; 1043, Dutch; …. you get the picture, right?)

So the problem is most likely caused by one of those javascript files. Now we have had the issue since we had installed SP2 and the June Cumulative Update. So I decided to restore these 3 script files and play aroun with these files for a while.

As it happens, my problem went away by replacing the bform.js file with a pre-SP2 version and clearing my

So if your issue does not get resolved by the suggested method of Microsoft, which is installing the latest Cumulative Update, then try restoring a previous version of this file and remember that you will need to clear this file from your client’s Temporary Internet Folder to force a download of the latest version from the server.


Update a SharePoint farm with minimal site downtime

It was the time of the year again to do an upgrade of several SharePoint farms for my customer. This upgrade was for installing SP2 and the June cumulative update on an entire farm and the requirement was to avoid too many downtime by the installation. This post will cover the process that I used to upgrade the entire farm.

Farm setup:
– 1 hardware load balancer
– 2 Web Front End servers (I will call the WFE1 and WFE2)
– 1 index server
– 1 SQL cluster

What I needed for upgrading the farm smoothly was a way to put a maintenance page for all web applications to appear when the content is really down. I used the simple ASP .Net trick by creating a – in my case custom –  App_Offline.htm file which mentions that the site is down for maintenance. Copying this file into the root location of each IIS website used by SharePoint Web Applications will show this message instead of the SharePoint content.

Another thing I wanted to do is to detach the databases before running the Configuration Wizard. Why? To avoid the upgarde to fail on a single content database and shorten the upgrade time. Once the config wizard completes, I reattach the content databases one by one, causing them to be upgraded at that moment.

preparation tasks:
– create a custom App_Offline.htm file for showing a maintenance page
– create a batch file that conveniently copies the App_Offline.htm file to all Web Applications (make sure not to copy it to the Central Admin WebApp) 
– create a batch file that conveniently deletes the App_Offline.htm file from all Web Applications 
– create a batch file that detaches all content databases for all Web applications with the exception of the Central Admin and SSP Web Apps ( add stsadm -o preparetomove command before detach database if you are still running MOSS SP1 pre-Infrastructure Update) 
– create a batch file that attaches the content databases

Upgrade process:

1.  Make sure that the hardware load balancers stops the services for WFE1 and only uses WFE2 to service user requests. We have an internal procedure that allows for manipulation of the load balancer. Actually we simply need to stop a custom IIS web site on the WFE server which will cause the load balancer to failover to the second WFE automatically.
   Availability Result: Users are still able to access SharePoint content through WFE2.
   Timing result: this operation took 2 minutes

2. Install the binaries for your SharePoint upgrade on WFE1. In my case WSS SP2 + MOSS SP2 +  all SP2 versions of the WSS and SharePoint Language Packs and finally installing the June Cumulative Update for WSS and MOSS. When installation completes, reboot the server.
   Availability Result: Users are still able to access SharePoint content through WFE2.
   Timing result: this operation took 50 minutes

3. Simultaneously install the same binaries on the index server. When installation completes, reboot the server.
   Availability Result: Users are still able to access SharePoint content through WFE2.
   Timing result: this operation took 40 minutes

OK So far so good. So basically, at this point, I have installed the binaries on 2 servers and I still have 1 to go, which is WFE2 that is still serving the SharePoint sites. I have two possibilities to continue:
– option1: install the binaries on WFE2 and reboot
– option2: run the configuration wizard on the upgraded WFE1 or the index server.

Option 1 will take all the sites down, because the installation of new binaries will stop IIS = Downtime and 404 errors. I cannot redirect my users to the upgraded WFE1, because the configuration Wizard has not run yet. So I am working with option 2

4. on WFE2 I launch my script that sets all my sites in maintenance mode (copies the App_Offline.htm file, that is)
   Availability Result: Users are not able to access SharePoint content, but they receive a nice page stating that their site is down for maintenance through WFE2.
   Timing result: this operation took 1 minute

5. on WFE2 I launch my script for detaching all content databases
   – this script launches a stsadm -o preparetomove command for each content database (except Central Admin and SSP databases). This command is no longer required if you have at least SP1 with the Infrastructure Update installed.
   – this script launches a stsadm -o deletecontentdb command for each content database (except Central Admin and SSP databases)
   Availability Result: Users are still not able to access SharePoint content, but they receive a nice page stating that their site is down for maintenance through WFE2.
   Timing result: this operation took 5 minutes ( I had 5 content databases)

6. on WFE1, run the SharePoint Products and Technologies Configuration Wizard.
If the upgrade process fails, investigate the log specified by the wizard, but also check 12-Hive\LOGS\Upgrade.log and the default SharePoint ULS logs. I have already seen that the SharePoint logs are written to the 12-Hive\LOGS folder instead of the location you specified in Central Admin during this upgrade process. After the upgrade your specified Logging location is used again.
   Availability Result: Users are still not able to access SharePoint content, but they receive a nice page stating that their site is down for maintenance
   Timing result: this operation took 15 minutes

7. Now that the farm configuration databases have been upgraded, your WFE1 is ready to start serving users again as soon as the content databases have been reattached. So, on WFE1 I launch my script to reattach the content databases. If one the operations generate an error, you can find the specific error in the 12-Hive\LOGS\Upgrade.log file.
   Availability Result: Users are still not able to access SharePoint content, but they receive a nice page stating that their site is down for maintenance
   Timing result: this operation took 10 minutes.

8. Make sure that the hardware load balancers starts the services for WFE1 and stops the services for WFE2 to service user requests.
   Availability Result: Users are again able to access SharePoint content through WFE1.
   Timing result: this operation took 2 minutes

My upgrade status is now complete with regards to the SharePoint content. My farm is servicing users again through a single Web Frontend Server for the moment, but it is servicing which is my main concern at this point. I no longer have downtime towards my users. If you add up all the minutes, then I have had a downtime towards my users of 33 minutes, which can be considered a small downtime. Now I continue with the rest of the upgrade process.

9. WFE2 is free now to do with whatever I want since it is no longer included in the load balancer pool.
– first, I launch my script to deactivate the site maintenance which simply deletes all App_Offline.htm files
– Next, I Install the binaries for the SharePoint upgrade on WFE2 + Reboot the server
   Availability Result: Users are able to access SharePoint content through WFE1.
   Timing result: this operation took 50 minutes

10. While WFE2 is installing the new binaries, I can run the SharePoint Products and Configuration Wizard on the index server.
   Availability Result: Users are able to access SharePoint content through WFE1.
   Timing result: this operation took 6 minutes

11. Run SharePoint Products and Configuration Wizard on WFE2
   Availability Result: Users are able to access SharePoint content through WFE1.
   Timing result: this operation took 8 minutes

12. Final step: Add WFE2 back into the load balancer pool

Although the entire operation took about 4 hours, there was a downtime of only 33 minutes for our users and furthermore our users did not hit any 404 pages, but received a nice site maintenance page telling them exactly what is going on. Needless to say, that my customer was satisifed with the result for the downtime

Hopefully this process is of any use to you guys.


Sample of my script files as requested by KbNk:

The maintenance mode script and the de-reattach scripts are simple batch files (*.bat).

Here is a sample for the scripts:

example data:

-> 1 Web Application with url http://webapp1.contoso.local
-> SQL server name: sqlserver01
-> content database name for the webapp: wss_content_webapp1
-> IIS Site directory location on file system: E:\IIS\mywebapp

– maintenance mode on script = simple copy command, no rocket science
   copy e:\App_Offline.htm E:\IIS\mywebapp\

– maintenance mode off script
   del e:\IIS\mywebapp\App_Offline.htm

– detach database batch file sample:
   stsadm -o preparetomove -contentdb sqlserver01:wss_content_webapp1 -Site http://webapp1.contoso.local  (Remove this line if you have SP1 wth Infrastructure Update or later installed)
   stsadm -o deletecontentdb -url http://webapp1.contoso.local -databaseserver sqlserver01 -databasename wss_content_webapp1

– attach database bacth file sample:
   stsadm -o addcontentdb -url http://webapp1.contoso.local -databaseserver sqlserver01 -databasename wss_content_webapp1

MOSS Auto-Install at Codeplex

I was once again installing a test machine from scratch with MOSS and while I was waiting for the setrup to complete, I wondered if anyone had come up yest with a fully automated install and configuration script. Well actually there is a set of scripts that can be found on Codeplex.

MOSS 2007 Automated Installation scripts

Project Description
This project is a set of CMD/BAT and PowerShell scripts which together provide a quick and near-unattended installation and initial config (SSP, MySites) of Microsoft Office SharePoint Server 2007.
Works on Windows 2003/2008, both x86 and x64 platforms.

This set of batch scripts is based on (but significantly extends) the scripts originally found in the Office SharePoint Server 2007 farm automated setup Codeplex project.

No more hunting around for your ‘latest’ MOSS installation doc/guidelines, squinting over screen captures, or worrying about whether so-and-so remembered to select that option while entering that username on that particular screen – all now merely relics of The Dark Age of MOSS Installations.

The scripts will:

  • Check whether the target server is running Windows 2003 or 2008, and whether the platform is x86 or x64
  • Prompt you to start at a specific point in the process, or simply run the entire script. Useful for 2nd, 3rd etc. servers in the farm, or subsequent attempts
  • Prompt you to enter all service account passwords (should you choose not to specify them in the script, for security reasons)
  • Automatically install platform-specific pre-requisites (e.g. IIS, .Net Framework)
  • Disable some unnecessary Windows services (configurable by editing DisableUnneededServices.ps1)
  • Install the MOSS build binaries with no user input
  • Run the SharePoint Products and Technologies Configuation Wizard (psconfig.exe) in order to create the Farm (Config/Central Admin content databases, Central Admin site, help collections, etc.) – no user input
  • Configure and start SharePoint services (WSS Search, MOSS Search, Excel Services) – no user input
  • Create/configure your SSP and My Sites web apps, and create the SSP – again, no user input
  • Create the main Portal – you guessed it, no user input
  • Restart IIS, and launch IE to view the results of your hard work (just in time for your return from lunch)
  • Log all of this to %TEMP% and pop open the log file for review, when finished.