So after building the SharePoint farm, restoring the Content Databases and Shared Services Provider I thought to myself everything is actually going to plan for once, until…… I restarted one of the web front ends!

I had then noticed that the server that I had just restarted was taking an awfully long time for it login, often waiting 5-10 minutes before I would reach the logged in desktop.  First area of troubleshooting was to launch Windows Task Manager, to immediately find out that the OWSTIMER.exe process was utilizing 90-100% of the CPU without any drop.  My first instinct was to kill the process and by default, Windows will restart the process.  Whalla!! The OWSTIMER process was back to normal and the Windows Server was back to its normal responsiveness.  My immediate thoughts were, this is most likely a once off and boy was I wrong!  After restarting the server a second time later that day, I ran into the same issue.  My troubleshooting began and the first area I ventured into was Central Administration / Operations / Timer job status and Timer job definition to see if there were any jobs that were failing, however things seemed to be in order.  Next area of investigation was analysing the SharePoint Logs (fun, fun, fun)… however, everything seemed to be in order there too.  Scratching my head, I ventured into the trusty Windows Event Viewer and analysed the Application and System Logs and there it was, hidden away.  I had noticed a Date and Time change from one event to another around the time the machine was starting up. 

E.g. One event would be dated 15/03/2010 and then the next event would then be dated 16/03/2010!  This sudden change in date and time whilst the machine was starting its services was throwing the OWSTIMER into a frenzy with the culprit being VMware! 

I had just recently introduced a brand spanking new Vsphere 4 ESX host into an existing cluster which had the incorrect Date configured (in my case, it was running one day behind).  In summary, my Windows 2008 R2 SharePoint front end server was picking up the VMware ESX host time when it was starting up and then a second later would synchronise with our Domain Controller and pick up the correct time.  This sudden time shift (literally a single second) would cause the SharePoint Timer Service to have a fit and maxing out the processor.

Fair enough, I immediately amended the Date and Time on the ESX host and I was back in business. 

Please be aware that this may not be the answer to your OWSTIMER CPU issue as I have come across plenty of posts around the same problem with differing causes.

I hope this post saves you some hours, because I had spent plenty, including re-building the SharePoint farm in question.

A couple of enhancements of XP mode and Windows Virtual PC for Windows 7 over legacy Virtual PC 2007 include the ability to run XP compatible applications in what other desktop virtualisation vendors refer to as “unity” mode,  i.e. the ability to launch applications directly from the Windows 7 start menu that are actually installed on the XP virtual machine itself. The second enhancement to Windows Virtual PC for Windows 7 is the ability to utilise HAV to increase performance of your virtual machine which I have been impressed with to date.

As much as we would like to run an application on Windows 7 natively we know that this may not be feasible as there will always be legacy applications that may not work natively with newer operating systems.  Windows “XP mode” is dubbed as the last resort in assisting organisations in migrating to the latest and greatest operating system to date.

So let’s begin the setup by first downloading an Intel utility which will check if the computer processor supports HAV and if this setting is enabled.  You can download this utility from the Intel site here; http://www.intel.com/support/processors/tools/piu/

The utility when launch will look like the below;

Click on the CPU Technologies tab.  Note that in this case the Intel Virtualisation Technology is already enabled.

If you have an AMD processor then you will need to download the AMD Virtualization Technology and Microsoft Hyper-V System Compatibility Check Utility here; http://www.amd.com/us-en/assets/content_type/utilities/AMD-V_Hyper-V_Compatibility_Check_Utility.zip

Microsoft have also released their own detection tool since XP Mode was released to manufacturing and can be downloaded from here; http://www.microsoft.com/downloads/details.aspx?FamilyID=0ee2a17f-8538-4619-8d1c-05d27e11adb2&displaylang=en

This tool is a lot simpler and will look similar to the below when launched;

Please be aware that in some cases you may need to enable HAV from within the computer BIOS.  Now that we have HAV in check we can proceed with the setup of XP Mode on our Windows 7 machine.

The next step is to install Windows Virtual PC  which you will need to download first from the Microsoft site here; http://www.microsoft.com/windows/virtual-pc/download.aspx

Begin by launching the executable.

Click Yes.

Accept the license terms.

Click Restart Now to finalise the installation of Windows Virtual PC for Windows 7.

The second installation that is required is Windows XP Mode.  This can also be downloaded from the Microsoft site here; http://www.microsoft.com/windows/virtual-pc/download.aspx (Follow steps 1-3)

Click Next.

Select your location and click Next.

Click Finish to finalise the setup.

We are now ready to launch Windows XP mode for the first time in which it will begin a “one time” configuration process setting up our virtual machine.

We can do so by navigating to the Windows XP Mode shortcut. From the Start menu, click Windows Virtual PC, and then click Windows XP Mode.

Accept the license terms and click next.

Please note that if your machine is not HAV compatible or has not been enabled for HAV you will receive the following error message;

“Unable to start Windows Virtual PC because hardware-assisted virtualization is disabled”

Continuing on with our installation of XP mode you will be prompted for the installation folder and the “XPMUser” password.  This “system created” user is used to log into the Virtual Machine automatically when booted up and run the installation applications within in.

Click Next

Select “Help protect my computer by turning on Automatic Updates now”

Click Next

Click Start Setup.

Setup will begin installing Windows XP with SP3 with the end product looking similar to the below screen capture;

The new virtual machine is now ready for you to customize it by installing the applications you want to use. After you install the applications, you can open them directly from the Start menu of your Windows 7 host operating system as per the below screen capture.  As this is considered as another machine that is connected to the network via NAT (default), I would ensure that the latest Windows Updates are installed and that an antivirus package is also installed to keep the machine secure and clean.

Hope you have found this article useful.  In summary, the setting up of Windows XP Mode consists of  three parts.  The first part installs Windows Virtual PC for Windows 7 with the second part installing Windows XP Mode on the computer. The third and final part to the jigsaw is always required. It sets up a virtual instance of Windows XP Professional with Service Pack 3 (SP3) as a virtual machine, allowing you to install your legacy applications that can then be accessed via your Windows 7 start menu.

Don’t forget to subscribe to future articles via your RSS reader and follow me on twitter @georgekhalil.

First and foremost, all of my servers are running in a virtual environment and have been for quite some time.  Virtualisation is handled by VMware Infrastructure v3.5 across 3 beefy ESX Hosts running dual Quad Core Xeon processors with 32GB RAM each connected to a Fibre Channel Storage Area Network with 15K Disks. The ESX hosts are also housing other virtual machines outside of the SharePoint farm.  VMware Infrastructure is providing native High Availability to my entire infrastructure.

My SharePoint 2007 farm was born almost 18 months ago and initially comprised of only 2 servers. The farm was servicing approximately 100 users with the following specifications/roles;

Role: SharePoint Server 2007 Applications Server and Web Front End 64 Bit
Windows 2008 Enterprise Edition x64
Single vCPU
6GB RAM

Role: SQL 2008 Standard Edition 64 Bit
Windows 2008 Enterprise Edition x64
Single vCPU
8GB RAM

Within 12 months of running in the above configuration we very quickly expanded our SharePoint setup to a “Medium” Farm configuration to incorporate an additional 250 users.

We simply added two additional Windows 2008 Enterprise x64 servers which were configured utilising Windows 2008 Network Load Balancing.  These 2 servers were easily incorporated into the existing SharePoint farm and have become dedicated Web Front End and Query Servers servicing user requests.

Specification is as follows;

Role: 2 x SharePoint Server 2007 64 Bit Web Front End
Windows 2008 Enterprise x64
Single vCPU
4GB RAM

My initial lone SharePoint Server has now become a dedicated Indexing Server with more frequent crawls scheduled and a dedicated Applications Server for Excel Services.  My farm now consists of 4 servers and is servicing over 350 users.

A rule of thumb with VMware ESX vCPU allocation is to always begin with a single vCPU. A physical machine gets a different experience than what multi-cpu does under ESX, because of the way ESX handles multi processors and how these are scheduled. The simple reason is that when you assign multiple vCPU you are trying to split the CPU time between those virtual CPUs which in most cases will add more overhead.

Memory is a different kettle of fish and I have found that more is better in a virtual or physical environment for that matter, especially when running 64 Bit Applications and Operating System. I would allocate as much as you can within reason.

For storage and Disk I/O consideration, RAID 10 works best, especially for your SQL databases.

I have found that the above resource allocations and configuration works well and is a great benchmark to begin with when configuring your Small or Medium SharePoint farm in a virtualised ESX environment. We definitely have not experienced any bottlenecks with our setup.