About two months ago I tried to reach out to the SharePoint community with a small survey on how Virtualization is used with SharePoint. The survey was primarily for my own interest to benchmark what others are doing, but I also thought that I should share this with everyone. SharePoint and Virtualization is an interesting piece of discussion; some despise it and some love it. For more information on SharePoint and virtualization read this great article from SharePointMagazine.net.
And now the results
All but one answering this survey said that they were using virtualization in their SharePoint environment. Not that surprising - I guess that if you don't virtualize then you do not even bother to look at the survey.
Since this survey did not specify if it was for production, test, staging or development the answers on what virtualization technology that was used was quite spread. Microsoft Hyper-V and VMWare ESX Server was the two products that most survey participants used. Not surprisingly was Microsoft Virtual PC right behind those two.
What is virtualized?
Almost everyone (95.7%) is virtualizing their development environment and half (50%) of the survey participants is virtualizing their production environment. This was a bit higher than I expected.
But what is virtualized then? The Web Front End was the clear "winner" with the Query service as a runner up. A quite high number of respondents answered that they were virtualizing the database role (73,9%) but only half of them could really recommend it (37,2%). The Excel Services role was something that about half of the participants virtualized (47,8%) and recommended for virtualiztion (44,2%).
The majority did not recommend virtualizing the database role (80%) nor the Index role (43,3%).
Almost everyone was very satisfied (40%) or satisfied (53%) with virtualizing their SharePoint environments and only a few were dissatisfied (7%). 98% of the respondents do recommend virtualizing SharePoint.
One thing that I really wanted to find out was why SharePoint is virtualized and here are what the survey participants thought:
Agrees Neutral Does not agree Lower hardware cost 82% 14% 5% Lower license costs 21% 47% 33% Lower maintenance costs 62% 29% 9% Better performance 7% 52% 40% Improves scalability 64% 24% 12% Improved security 27% 56% 17% Improved redundancy 60% 36% 5% Safe backup 55% 31% 14% Simplifies development 86% 14% 0% Simplifies deployment 73% 20% 7% Positive effect on the environment 74% 26% 0%
Simplified development and lower hardware costs was the two ones that was quite expected. When looking at the license costs most people were neutral or thought that the license costs were higher with virtualization, probably due to the fact that you might need more (virtual) servers to have the same performance (only 7% thought performance was better with virtualization).
The numbers speaks for themselves and I do like that 74% also thinks that this has a positive effect on the environment.
Any other comments on this survey, pleas post a comment below.
Have a nice summer
Just in time for next version of SharePoint to arrive I just completed the final certification exam for SharePoint 2007, the 70-630 Microsoft Office SharePoint Server 2007, Configuring. As always I did think that it should be some tricky questions or problems to solve in the exam, I even installed a MOSS RTM last night just to walk through the admin interfaces before the infrastructure upgrade. But to my disappointment this certification was by no means any challenge. This was by far the easiest of the four exams.
After taking the two developer (70-541 and 70-540) and the configuring exams (70-631 and now 70-630) I really think that Microsoft has failed in creating exams that has any kind of value as a certification. To have some kind of validity on these exams/certifications they should give you a challenge, it should be (must be) hard to pass them. I really hope that Microsoft totally changes how these certifications are outlined and put together for the certifications of the next version of SharePoint. Passing these exams today says nothing (and do not even mention if you failed them). Make the questions into more troubleshooting, especially the configuring exams, have questions on the best practices, make some kind of scenario with linked questions and perhaps even some kind of virtual lab I understand that all problems and best practices are not "invented" when the exams hits the streets, but why not having a level 2 exam coming a year or so later, that has some higher status.
Last week at the SharePoint User Group meeting we had a session with Sweden's first SharePoint Master who told us about the Master certification program - and that is what I call certification. Ok, not everyone will be or even have the chance to be a Master (read Spencer Harbars post) and I do not want the standard exams to be this hard/impossible. Those who passes the MCM are not only Masters they are immortals!
Anyways, I know have the four ones and really looking forward to being acquainted with SharePoint 2010. Not all was bad with these exams though, they made me read through a set of books, making some labs on my own and with that I learned a whole lot.
When developing applications or custom solutions for SharePoint you will on several occasions have to store settings for you application of some kind. When developing database driven or other custom solutions you easily create a database table or make the settings in app/web.config file. You can of course use these approaches when developing for SharePoint, but there are some things to consider when doing this. This post will outline some approaches you can use to store your settings.
What I mean with application or solution settings is some kind of settings that you need for you application to work, such as a Url to a web service or a username and password. These settings are normally only editable by administrators, which requires you to have some security plans, and you need an interface to edit the settings.
Worth to have in mind is that SharePoint can span multiple servers and web applications, it also has the Site Collection and Site scopes which might need different settings if your application runs on several places.
Using a SharePoint List
Creating a database table for storing settings is not the best way in a SharePoint solution - you would use a SharePoint list for this instead. This is the easiest way. Creating a custom list with Title and a Value allows you to store all your settings in one place. There is no need to create a user interface, since you use out-of-the-box functionality and you can secure the list by using permissions on it. The drawback is you need some information (read other setting) that tells you where this list is located, so you're back on square one.
Using web.config is another way to store your settings. It's easy to store information in the appSettings element using a key/value combo. The .NET Framework have built-in functionality to read these settings and SharePoint has some (not so good working) features to deploy the settings in your farm with the SPWebConfigModification class. This approach can only be applied if your settings are web-application wide and you either deploy the settings with the SharePoint object model, which can be quite cumbersome, or manually edit the web.config file on all WFE's.
Using the SPWeb object
The SPWeb object has a Properties property that is persistable StringDictionary stored on the Site (SPWeb) level. This is a perfect solution when you have to store Site specific settings and have the setting available over all your farm. The Properties property is used like this:
Easy and simple when you have to store key/value combinations, but not so good when you have to store more complex objects, then you have to make some Xml serialization/deseralization yourself.
The permissions in this case is controlled by the MangedWeb permission and you have to build your custom interface.
Using the SPSite object
The SPSite object does not have any Properties property like the SPWeb object, so if you have to store your settings on the Site Collection level you just use the SPSite.RootWeb SPWeb object and use the approach above.
Using SPWebApplication Properties
If you need to store your settings on the Web Application level and you don't to make changes to the web.config, then you can use the SPWebApplication object. The SPWebApplication object inherits from the SPPersistedObject which has a Properties property. This property is a HashTable so you can store key/value combos here. The value can be of any type, as long as it can be serialized.
This approach requires the user to be farm administrator and you have to build your own interface.
Using custom SPPersistedObjects
Perhaps the best (imho) way to store settings for your web application is to use custom SPPersistedObjects. This approach is very handy when you have to store multiple settings and more complex values. You create your own class that derives from the SPPersistedObject and add your settings as properties to the class and marks them with the Persisted attribute.
Then you use the SPWebApplication GetChild method to retrieve your settings.
I usually add two static methods to my settings class for easy creating and retrieval of settings:
This also requires farm administrator to persist and you have to create an interface
There you have it; six different ways to store and retrieve settings for you SharePoint custom application. When to use which one is up to you and your needs.
What are you preferred ways or do you have any other suggestions or additions?