Contents tagged with Virtual Server
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
The day has come when Microsoft officially started to talk about the next version of Office 2010 clients and SharePoint Server 2010 (no longer Office SharePoint Server). We have since some time known that SharePoint 2010 will be supported only on a 64-bit platform, just as Exchange 2007.
The new stuff revealed yesterday (as preliminary) are that not only is 64-bit required, it will only be supported on the Windows Server 2008 64-bit platform (including R2) and it will require that you have SQL Server 2008 on a 64-bit platform. There are some other interesting facts that you should check out also in the post (and on about 1.000 other blog posts), but this post is not just about these news.
The interesting parts of this announcement is that now is the time to learn the 64-bit platform for real and especially Windows Server 2008 R2 and SQL Server 2008, not everything is the same; registry hives, file system, settings, know when to use int (Int32) or Int64 etc etc. You can start now, it's no time to wait! Make a decision to only install your new SharePoint installations on the required SharePoint 2010 hardware, make sure that you have that in your development environments and on your virtual machines. Yes, it will in many cases cost you a bit in new hardware.
I think that this is the time when 64-bit really will kill the 32-bit era.
As a bonus I can tell you one thing that I didn't know was achievable. My main laptop runs 32-bit Windows 7 and not 64-bit due to that it does not have the 64-bit driver support for the peripherals and I usually use(d) Virtual PC to virtualize my development servers. Downside with Virtual PC is that you guest machines can only be 32-bit and I don't want to have a Hyper-V laptop in 64-bit mode so I thought that I had to get me a new laptop (which is due for later). I was preparing for the worst of having a dual boot. Fortunately I did a test using VMWare Workstation today and found out that as long as you have a 64-bit capable hardware (which I have) you can host 64-bit guests on a 32-bit host OS. Did you know that, I did not! So I will spend this evening preparing my new development VM's. If you are in the same situation as me, stuck with a 32-bit OS for some time, head on over to VMWare and run the 64-bit compatibility checker and then dump Virtual PC and get VMWare Workstation.
Welcome to the 64-bit world!
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 recent discussion about how the licenses of Windows, SQL and SharePoint Servers should be handled when we are developing solutions using Virtual Machines made me throw away a mail to Emma Explains Licensing. The concern was that; do we have to pay licenses for every VM or test server? That would have been insane! But I wanted to have this explained how this licensing works - a lot of you perhaps already know but I always have a hard time getting all the different licensing options and rules.
To make her excellent explanation a bit shorter; if you are a MSDN subscriber or a Visual Studio licensee then you are fully covered. You may use as many copies on any number of devices you like of the server products for developing, testing and demonstrations. You may not use it in live production or for staging environments.
To understand everything, please read Emma's post.
Have a nice weekend…
Remote Debugging is a great feature to use, especially when you work with virtual machines. It allows you to develop and debug locally but have the code running on another machine, virtual or physical. Microsoft SharePoint can't be installed on a Windows Vista or XP workstation, but needs to be installed on Windows Server 2003 or 2008, so the general recommendations has been for developers to have either Windows Server as their main OS or have a virtual machine with Windows Server. None of these work that well; either you have problems debugging your components and you have to rely on traces or message boxes or you have to have a virtual machine with a full development environment, which will not resemble a production machine.
So, Remote Debugging, is my primary way when working with SharePoint development. It allows you to have a smaller virtual machine, and it will allow you to develop in your main OS. But, Remote Debugging has been quite problematic to set up and configure, so here is a guide that you can follow to get it work in a few minutes.
This guide uses Microsoft Visual Studio 2008 and Windows Vista with UAC on the client and a Windows Server 2003 with WSS 3.0 running in a Virtual PC on the client.
Prepare your remote host
First of all you need to prepare your remote host for accepting incoming debugging requests, this is done by running the Visual Studio Remote Debugging Monitor on the remote machine, which is found under C:\Program Files\Microsoft Visual Studio 9.0\Common7\IDE\Remote Debugger\. Copy that folder to your remote host and place a shortcut to the msvsmon.exe on the desktop, so you have fast access to it whenever you need to debug.
The Remote Debugging Monitor is the one accepting your debug calls and the talking back to Visual Studio on your client, so to get these things to work you have to start the client as the user running Visual Studio (or have administrative permissions on the client). You can either log in to the remote host using that user or, as I prefer, right-click on the msvsmon.exe and choose Run As... Make sure that the user you are using to run the monitor with is member of the local Administrators group.
Now the Remote Debugging Monitor has started to waiting for new debugging connections. The debugging server was named with the username that is running the application and the server name, separated with an @-character. You can rename it using Tools->Options.
Prepare your client
Now it's time to prepare your client. First of all you have to run the Visual Studio 2008 Remote Debugger Configuration Wizard, which will open up the correct ports in your firewall. You will find the wizard under the Visual Studio Tools in your start menu. The wizard also allows you to run the Remote Debugger as a service on the machine which the wizard is run on, skip this step for this guide. When the wizard asks you for how you would like to configure your firewall, choose the Allow only computers on the local network... option and the finish the wizard.
Now it's time to start Visual Studio 2008 and load up your solution and hook up the debugger to the remote machine. Prior to this you need to deploy the application to be debugged on the remote machine, including the .pdb files.
In Visual Studio choose Debug->Attach to process. In the Qualifier you have to enter the name that was given to the Remote Debugger Monitor and hit Enter, then all you need to do is attach to the process you would like to debug and set some break points!
That wasn't to hard?
Here are some problems that I have stumbled upon when trying to get these things to work.
Unable to connect to the Microsoft Visual Studio Remote Debugging Monitor named 'XXX. The Visual Studio Remote Debugger on the target computer cannot connect back to this computer. Authentication failed. Please see Help for assistance.
This one is due to the fact that the user running the debugging monitor are not allowed to access the client machine, make sure that the user running the monitor is either the same user running Visual Studio or the member of the Administrators group on your client.
You only see a few processes in the Attach to Process dialog.
First of all make sure you have checked the Show processes from all users check box, then make sure that the user running the monitor has access to the process on the machine, that is you have to make the user member of the local Administrators group. After adding the account to the Administrators group you have to restart the monitor.
Unable to connect to the Microsoft Visual Studio Remote Debugging Monitor named 'ibvsretail'. Logon Failure: The target account name is incorrect.
This one is pretty uncommon, but still I have had it. Somehow the server account in Active Directory had gone wrong so I hade to remove the machine from the domain and add it back.
Don't forget to reinstall the Virtual Machine Additions if you are upgrading from earlier versions or betas.
Virtual PC and Virtual Server uses Virtual Hard Disk which may be dynamically sized, that is they don't occupy the whole size of the disk on the host system. But they may take up much more than the guest operating system reports.
I will show you how to reduce the size of you dynamically expanding virtual disk, using the tools provided with Virtual PC 2007 beta 2 (it's the same on VPC 2004).
I just created a VHD containing Windows XP SP2 and Visual Studio .NET 2003 SP1 and some other dev. tools so I can switch my main laptop to Windows Vista. As you know VS.NET 2003 does not run on Vista but I still have to do some .NET 1.1 development so a VPC will be just perfect. I also wanted this image to fit on a DVD and this is how I did it. I went from a VHD file size from 6.7 GB to 4.0 GB.
1. Prepare the guest OS
First of all I did a Disk Cleanup and removed all unnecessary files.
And to save me some more space I cleaned up the System Restore an removed all the backups of Windows Update (only do this if you are sure on how to do it!).
2. Defragment the guest OS
To get an effective compact of your VHD you must defragment the guest hard disk.
4. Run the Virtual Disk Pre-Compactor
Virtual PC contains a utility to prepare the disk before compacting it, called the Virtual Disk Pre-Compactor. This is run by mounting the Virtual Disk Precompactor.iso on the guest OS, found in the Virtual Macine Additions directory where Virtual PC is installed. Follow the instructions and wait while th VHD is being prepared...
5. Compact the Virtual Disc
Shut down your guest OS and launch the Virtual Disk Wizard from the Virtual PC Console. Follow the instructions;
a) choose to edit a diskb) choose your VHDc) hoose to compact itd) optionally choose to create a new one (I normally choose this in case of any trouble - I'm using VPC 2007 beta here)
Then wait while the disc is compacted...
6. You're done
Now you are all set and done and you should have saved a lot of space.
You can sometime save some more space doing it all over again once again, at least I did.
Since Internet Explorer 7 is on Windows Update and installed as a high-priority update a lot of users have Internet Explorer 7 installed or you are using the brand new Windows Vista, but how do you do when you are a web application developer and have to test it on Internet Explorer 6. Yes, Internet Explorer 6 will be with us for a long time.
You have three options:
1) Have a secondary machine stand by with Internet Explorer 6. An easy but expensive solution.
2) Install IE7 and IE6 side-by-side. Not that easy and not recommended but it can be done.
3) Use Virtual PC to set up a virtual machine with Internet Explorer 6.
Microsoft is doing a great job with all these new VPC images for us developers and testers so we can test new software, betas and now older software in our own sandbox.