The Office 2007 Service Pack 2 are here and for the server products (WSS 3.0 and MOSS 2007) we have a new STSAdm command called; preupgradecheck. This command allows you to check any WSS 3.0 SP2 based installation for potential issues that may prevent an upgrade to Windows SharePoint Services 4 (WSS 4.0) or SharePoint Server 2010. For full reference of the command check out KB960577.
The pre-upgrade check command uses a set of rules found in the 12\CONFIG\PreUpgradeCheck\WssPreUpgradeCheck.xml file to check your farm or you can use a custom file.
This is how it looks like on a WSS 3.0 SP2 machine when run:
You will see a summary of all steps while it checks your installation for a few minutes, and when done you can open the HTML log file to dig deeper into your potential problems. There are three categories:
- Passed (in green) - This is when everything looks fine
- Information Only (in yellow) - You have to check the log file for more information. The log file may have references to KB articles that you have to read to fully understand what to do to make the upgrade smooth. All manual upgrades are noted here, such as customized fields, CAML views (which are replaced with the new XSLT-based views), custom site definitions (will require a special Upgrade Definition file) etc etc
- Failed (in red) - This is when there are something that really prevents you from upgrading, read the log file to get the exact reason.
The sample image above contains two failed steps; one is about referenced features that are missing, which needs to be installed to perform an update. The second one is about the OS prerequisites, this sample is taken from a 32-bit Windows 7 which obviously is not a correct machine since only Windows Server 2008 x64 is supported on the next version of SharePoint.
It’s well worth running this command on all your installations even though you don’t plan any upgrade right now. The articles contains a great deal of information on how you can make sure that you finally can upgrade your installation smoothly. All articles does not seem to be available yet though…
Windows Live ID Authentication for SharePoint is a project that has been developed for some time for the upcoming Swedish SharePoint Community Site, which will be an awesome site with some really cool features of which this is one.
I have previously tried some of the available Windows Live ID providers for SharePoint that are out there on the market and the best (previously) one is the provider from the Community Kit for SharePoint, originally developed by Keith Bunge. It has a great basic application design, but had some things that annoyed me and some things I wanted to change, therefore I created my own version, with the CKS version in mind, which I hope that you find useful.
There are a lot of features in the provider and I have some even greater plans…
- All configuration done through the SharePoint web interface; Central Administration or in the sites
- Forces users to register once registered
- Profile information that is more community-like
- Profile images
- Web Parts for displaying last logged in, last registered and all users.
- Users can be locked
- Approval of users can be turned on
- Profile changes can be published to announcement lists
- Four predefined roles for permissions management
You can download it now from http://spwla.codeplex.com/, you will also find a document with installation and configuration instructions. There are a few known bugs on which I work on, but if you can spot them or others, please report an Issue on the CodePlex and if you have any suggestions I really like to hear them.
In upcoming posts I will dig into some of the features a little bit more, but until then here are some screenshots.
Configuration in Central Administration Logged in users menu Configuration of the Live ID enabled Web Application Last logged in members web part Edit personal profile Built-in Live roles
A few days ago I posted a small survey that asks a couple of questions on how you virtualize your SharePoint environments. I will keep the survey open for a couple of more days to get some more results (compared to the number of readers of this blog and number of Twitter followers - the response is really bad…)
Anyways I thought that I should put up some preliminary results.
What virtualization technologies do you use if you virtualize your SharePoint installations
Microsoft Hyper-V and VMWare ESX Server are the most popular virtualization technologies to use. Microsoft Virtual-PC is also very popular, but probably not in production environments :-)
What environments are you virtualizing?
Development is the most popular environment to virtualize, not that unexpected. 51,5% virtualizes their production environment.
What roles are virtualized?
Almost everyone virtualizes their web front ends and also recommends them for virtualization. The database role is virtualized by 37,5% and 72,5% does not recommend virtualizing the database role. 50% of the responses does not recommend virtualizing the Index role.
Why are we virtualizing SharePoint? Almost everyone agrees on that the hardware costs are lower, but the license cost is the same or even higher. Very few users agrees on that the performance is better, but instead the scalability and redundancy is improved.
That development is easier with virtualization is no doubt about (we don’t even need a survey for this…).
I’m also glad that at least 2/3 of the responses agrees on that this is good for the environment.
This was a short preliminary result of the survey, I will run it for a few more weeks, so please pass the survey forward to your friends and colleagues.
Virtualization is a really hot technology right now, and forward and so are SharePoint. I’ve been discussing SharePoint virtualization internally and externally for sometime now and I have my opinions. In order to get a broader view on how SharePoint is virtualized around the globe I put together a small survey that will enlighten this subject.
I would like you to fill out the survey and forward it to your colleagues, partners, clients, friends and better halves.
I will once I get enough answers post them here in full and as well do my analysis of them.
A few weeks back I wrote a post on how to mix Windows Azure and SharePoint Online called Custom code with SharePoint Online and Windows Azure. Since then both Windows Azure and SharePoint online have had some updates.
First of all you no longer need to create the bindings in the code to make it fully trusted. Good to know but it does not affect the solution.
A Bug in SharePoint Online Web Services
More important is the fact that you cannot longer use the Visual Studio Add Service Reference function and add the services from your SharePoint Online site to your solution. You will end up with an error like this:
It says that it cannot recognize the document format of the Lists.asmx?WSDL and Lists.asmx?disco documents. Why?
If you open up the Lists web service in a browser you get the standard auto generated ASMX page:
From this page you can check out all the web service operations, but when you click on the Service Description link, which would take you to the /_vti_bin/Lists.asmx?WSDL page, which contains the definitions of the web service and it’s operations you get an error. The same errors that Visual Studio gets.
This page should contain XML and look like this (taken from a normal WSS 3.0 installation):
So what is happening in SharePoint Online!? If you take a look at the source of the faulty WSDL page you will see an error message saying something like this:
The requested page does not contain a link to the Microsoft Online Services Privacy Statement. The page cannot be displayed until a link to the Privacy Statement is added. Please notify your SharePoint site administrator. Only the site administrator or site owner can add the Privacy Statement. For information on adding the statement, see: Add the Privacy Statement to your SharePoint Online Site.
This error message is shown on all ASPX pages in SharePoint Online that does not contain a link to the Microsoft Online Services Privacy Statement, which is a requirement in SharePoint Online. The link in the error message tells you how to include this message in your custom ASPX pages.
But, we just looked at a ASMX page, I can’t have statements like this in my web services!?
Let’s dig a little bit deeper into the SharePoint 12-folder. In the ISAPI folder you have the Lists.asmx file, as well as a Listsdisco.aspx and a Listswsdl.aspx file. Normally in ASP.NET when you create your own ASMX file the WSDL and DISCO will be created automatically but SharePoint silently uses these other two files, instead of creating them at runtime. Because these two files are ASPX files you need to have that Privacy Statement.
This is in my opinion a real bug in SharePoint Online, and should be corrected as soon as possible.
How to work around the bug?
It’s pretty easy to work around this bug. All you have to do is when adding the service reference is to get the web service from a normal SharePoint installation (WSS or MOSS) and then in your service binding point to your SharePoint Online address.
I hope that the Microsoft Online team come up with a solution to this problem as soon as possible, since it will cause headache for a lot of developers.
The SharePoint 12-hive contains by default a number of interesting files that every developer should be aware of. The more you know the better you understand the inside of SharePoint and it allows you to create more efficient and better solutions.
Here are my top five favorite files:
ctypeswss.xml (in TEMPLATE\FEATURES\ctypes)
This is the feature elements file for all the default WSS Content Types. When creating new content types, most often I find it useful to derive them from existing content types. For example if I need to create a content type that derives from the standard content type Task, i can easily get the content type ID, which is used when creating new content type IDs, and what Site Columns that content type has.
fieldwss.xml (in TEMPLATE\FEATURES\fields)
Second favorite is the elements file for the WSS Site Columns feature. In this file all definitions for the default WSS Site Columns is found. Together with ctypeswss.xml this is really handy when creating custom content types. By finding out the ID’s of the Site Columns you can easily re-use the site columns when creating content types.
Custom List schema.xml in (TEMPLATE\FEATURES\CustomList\CustList)
Whenever I need to create a list definition and need to create a schema.xml I use the schema.xml for the Custom List feature and copy it to my definition.
STS onet.xml in (TEMPLATE\SiteTemplates\STS\Xml)
This is the file to check out when creating Site Definitions. The onet.xml file contains all Site Definitions (althought the folder is called SiteTemplates), which includes navigation, lists etc. Most often I copy this file (and all other files in the STS folder) and remove almost everything except the the blank site def.
DOCICON.xml (in TEMPLATE\XML)
Perhaps not that interesting that the four above, but on nearly all installations you update this file with the PDF icon (at least). What this file does it that it allows you to map an extension (or ProgID) to an icon and optionally specify an editor.
What’s your favorite ones?
What does this mean really?
Anybody can download it and customize their SharePoint installations which is good in some ways, but really bad in others. If the users are not aware of what they are doing they can cause severe damage to your SharePoint, but it can also make really nice enhancements to their installation.
There are a lot of nice things you can do with SPD in your sites that you can’t do using the web interface. The web interface on the other side protects you pretty good from doing some mistakes that even the best can do once in a while, like dragging a file or folder to the wrong place. Of course all of this has been possible to do before with SPD, it’s not a new product, but suddenly you can expect a number of new and untrained end-users fire up the SharePoint Designer and customizing in ways you never prepared your installations for.
What should you do?
First of all make sure that you have the permissions correctly set up in your SharePoint environment and make sure that you have good (and working) backup and restore plans.
Secondly restrict the usage of SharePoint Designer by locking it down. Read this article from the SPD team on how to do it.
What if I already purchased it?
If you have purchased SharePoint Designer 2007 and have Software Assurance coverage then you are eligible for Expression Web 2. Isn’t that sweet! Here are some more reading on the new SharePoint licensing.
If you take a look at the System Requirements for SharePoint Designer, you see that it only supports Windows Server 2003 and Windows XP!?
Mistake or not, I don’t know? If anyone does please comment below. But I’ve “never” had any problems with it on Windows Vista or Windows 7.