Virtualisation: Poor performance in VMWare Player or Workstation

Since Microsoft have decided to throw us a curve ball with regard to 64-bit desktop virtualisation, I have recently been experimenting with VMWare Player as a replacement to MS VPC for SharePoint 2010 development. I noticed that almost every speaker at the SharePoint 2010 Evolution conference earlier this year was using the workstation version (required for commercial use) for demonstration purposes.

Whilst I am generally very happy with the VMWare software, one issue troubled me today. While the majority of the time my Virtual Machine performed satisfactorily, it did seem to "freeze" or hang every minute or so. During this time, the mouse and keyboard were unresponsive and I had no choice but to wait a few seconds for the machine to sort itself out.

After putting up with this for a few hours I became frustrated and decided to delve into the VMWare log (simply called "vmware") contained on the host machine, only to find the following:

============

May 30 17:31:49.154: vcpu-0| FLOPPYLIB-LIB : Win32Ioctl: syserror The device is not ready.

May 30 17:32:42.095: vcpu-0| FLOPPYLIB-LIB : Win32Ioctl: syserror The device is not ready.

May 30 17:32:42.107: vcpu-0| FLOPPYLIB-LIB : Win32Ioctl: syserror The device is not ready.

May 30 17:32:46.692: vcpu-0| FLOPPYLIB-LIB : Win32Ioctl: syserror The device is not ready.

============

To resolve this, I simply opened up the virtual machine settings and tweaked a few settings:

• Unchecked "Connected" and "Connect at power on" for the Floppy device
• Unchecked "Connected" and "Connect at power on" for the Sound Card device
• Unchecked "Connected" and "Connect at power on" for the Printer device

Lo and behold - the problem disappeared instantly and I am now happily using my 64-bit VMWare VM!

Benjamin Athawes

Subscribe to the RSS feed

Follow me on Twitter

Follow my Networked Blog on Facebook

My Quest SharePoint 2010 Virtual Expo notes

Yesterday I had the pleasure of “attending” the Quest Virtual Expo for SharePoint 2010. Many thanks to Quest for hosting a very useful expo and to the presenters for answering almost every one of my questions. For those of you that attended, the slides and presentations are still available at unisfair.

Amongst the various presentations, I found these two particularly useful:

• A Practical Guide to Managing SharePoint ( Joel Oleson)
• Are you sure your deployment is ready for SharePoint 2010? (Rick Taylor and Joel Oleson)

Below are the notes I made from both of these sessions along with the Q&As that followed:

Presentation Notes:

• In SharePoint 2010, each service application has its own database as opposed to the per-SSP model in MOSS. Spencer Harber wrote a good post about service applications which I encourage you to read through. My first thoughts on this are that while additional databases should mean greater flexibility and scalability, it may also mean additional storage requirements and administrative overheads. One benefit that springs to my mind is the ability to place service applications on different spindles based on predicted usage patterns which should mean better SQL performance.
• The health monitoring and management capabilities in SP2010 look very useful for administrators. Joel showed us the automated password management capability within Central Admin which effectively means SharePoint can ensure password strength and renewal with no user intervention. This was a headache in MOSS and with new service applications I can imagine this will be a welcome new feature to ease administrative burden. Another new feature is a set of health rules which can be modified – these encourage Microsoft best practises to be followed and can be configured to send alerts through email or SMS. Not sure I would appreciate a text from our SharePoint farm alerting me to a best practise being broken but it’s a nice feature to include.
• PowerShell allows management of SharePoint to be scripted – therefore allowing common administrative tasks to be repeated with less chance of human error. Joel mentioned that STSADM is still present in SP2010 but emphasised that PowerShell includes over 500 commandlets and should prove very useful.
• Joel described the Microsoft SharePoint team’s “do no harm” upgrade planning philosophy in relation to PreUpgradeCheck and also mentioned that he is writing a book on migrations to SP2010.
• Database upgrade methods were discussed – the general message was that in place upgrades are only really appropriate for small environments and even then should only be performed where a fall-back is possible. We certainly won’t be upgrading our physical servers using the in place approach any time soon! The DB attach method allows for a gradual upgrade process – and less downtime – making it (or a close hybrid) the approach we will be going with.
• Separation of binary and visual upgrades in SP2010 mean that MOSS look and feel can be retained (2010 ships with MOSS master pages)
• List throttling includes a “happy hour” feature that allows limits to be exceeded at a certain time of day. This should be useful for running intensive list item operations out of hours whilst retaining high performance during peak hours. Joel mentioned that “5000 is the new 2000″ (regarding the limit on the number of items in a list) – something that has been echoed in the Twitter community (e.g. @MirjamvanOlst). This is the maximum number of list or library items that a DB query can process at one time – more info here.
  Sandboxed solutions are disabled by default
• The dev dashboard includes an “ondemand” setting that allows it to be switched on and off. Enabled it displays debugging information at the bottom of a page that should be useful for identifying the cause of slow performance (e.g. SQL delay, rendering issues).
• The OOB reporting capability in Central Administration allows the slowest pages across the entire farm to be identified, as well as “top users”.
• Joel finished up by emphasising the benefits in running the PreUpgradeCheck tool that is available in MOSS SP2 and onwards, and mentioned that SP2010 Beta 2 VHD is available now for download.

Q&A Notes:

• It is possible to exceed the 2 million user profile limit
• It is not possible to migrate straight from SPS 2003 to SP2010
• Virtualisation for SharePoint should start with WFE servers – you should hold off on virtualising SQL and index servers for now
• The Microsoft recommendation of 16GB RAM per production server is recommended for Enterprise deployments but not necessarily a requirement for smaller farms. Rich Taylor gave an example of a 30,000 user deployment, predicting that 4 WFE servers each with 8GB may well be sufficient. The key message was that estimating hardware requirements is not straightforward and should be based on actual usage data (number of users, requests per second etc). Joel mentioned that there are performance and capacity case studies on TechNet – I believe he was referring to this information.
• IE 6 is not supported for SP2010 but may be usable for a publishing environment with primarily read only content. A quick Google afterwards revealed this link that quite clearly depicts what various SP2010 sites look like in IE6 (awful!).
  Rick and Joel gave no indication as to when SP2010 SP1 would be released but referred to the historical trend of “around every 9 months”. We were assured that there definitely will be an SP1
• Licensing was briefly discussed – unfortunately it gets no easier with SP2010 and Joel mentioned that there are new SKUs with 2010 (I heard “Internet Standard Edition” mentioned but couldn’t confirm this online). Prices should be released next month.

I hope these notes are helpful – let me know if you have any feedback or queries.

Benjamin Athawes

Subscribe to the RSS feed

Follow me on Twitter

Follow my Networked Blog on Facebook

Development: Common MOSS coding issues based on MS recommendations

Hi All,

Whilst browsing Sample code acceptance checklist for IT organizations on Technet, I realised that in several places we as an organisation were not always following best practises. As stated in this article, this probably means that we could do a few things to improve the performance and security of our product - and who doesn't want to write faster, safer code?

Here are the items that rang alarm bells and I thought it might be worth sharing them in case anyone else still has a few BP boxes to check:

1. Plain text passwords are not present in Web.config, Machine.config, or any files that contain configuration settings. Utilities such as Aspnet_setreg.exe and Trustee or the identity setting in AppPool on IIS 6.0 or IIS 7.0 are used to encrypt credentials.
   
   This often seems to slip through the net, reason being that administrators tend to think "Users can't get on our servers so what's the point?". The point, I think is that we as developers should always try to implement defence in depth security practises and this is a good example. OK - if an attacker somehow obtains RDP access to your server farm a plain text password for a Web application may well be the least of your worries but this is not a tricky one to fix. Grab Aspnet_setreg.exe and get to work!
   
   
2. If cookies contain sensitive data, they are marked secure.
   
   The severity of missing this item depends on the sensitivity of your application and your supporting infrastructure. If your data must be secure during transit, then you need to either ensure that all cookies are marked secure, or you must ensure the channel is encrypted via some other means. Options that spring to mind are forcing this via IIS (straightforward in version 6.0 and later) and / or forcing an SSL redirect via a reverse proxy server such as ISA Server 2006. In our case, we implemented the last 2 options which ticked the corporate security check box when we conducted an external security review recently.
   
   
3. Input surfaces in Web parts and other customizations include boundary checks, input data integrity checks, and appropriate exception handling to protect from cross-site scripting and SQL injection.
   
   OK, XSS and SQL injection are both well known security problems in Web applications. However, its always worth bearing these two common issues in mind and applying protective measures such restricting input (must be server side - think regular expressions) and using parametrised stored procedures. See How To: Protect From SQL Injection in ASP.NET for more info.
   
   
4. You avoid using AllowUnsafeUpdates. You use ValidateFormDigest() and, if necessary, use elevated privileges to interact with SharePoint objects. In cases where AllowUnsafeUpdates must be used, you ensure that AllowUnsafeUpdates is set to False in your try-catch-finally block, or you use a Dispose() method (as required by the IDisposable interface) to avoid security issues.
   
   In the SharePoint development world, I believe it is relatively common knowledge that using AllowUnsafeUpdates liberally is a big no-no. However, there are places where it is unavoidable (sometimes whilst using SPLimitedWebPartManager) so ensure you utilise that finally block.
   
   
5. The ASP.NET validateRequest option is enabled, if possible.
   
   Based on my experience, this appears to be a favourite item for penetration testers to pick on whilst testing ASP.NET forms applications. Enabling this option is a step toward preventing XSS (see How To: Prevent Cross-Site Scripting in ASP.NET).
   
   
6. The application consistently uses standardized input validation such as RegEx throughout.
   
   I would like to confidently tell you that this requirement is a given and that I haven't come across an example where standardised input validation is neglected in recent years. However, that is simply not the case and I would encourage you to rigorously check and confirm that your ASP.NET controls are all validated using a white list input validation approach.
   
   
7. The application uses a standardized approach to structured error and exception handling throughout.
8. 1. The code uses exception handling. The code catches only the exceptions that you know about. For example, do not use try{} catch(Exception ex){}unless you throw the error again.
      
      1. 
         I think that although many organisations do use a standardised approach to error and exception handling, it is sometimes an approach that is consistently wrong. For example, I have been guilty of doing this in the past:
         
         catch (Exception ex)
         {
         throw (ex); // do NOT do this!
         }
         
         1. 
            (this lesson here is that if you want to re-throw the exception currently handled by a parameter-less catch clause, use the throw statement without arguments see here)
            
            The main point here is that you should review your code and ensure that your exception handling procedure is both consistent and follows best practises.
            
            
9. Application errors do not contain sensitive information or information that could be used to exploit the fault.
   
   Quite often, this is viewed as a negative point as far as the end user experience is concerned. If a user fails to logon, they often want to know why they can't logon. As always, the problem here is striking a balance between usability and security. We want to help the user out by providing useful error messages, we really do. But we also want to prevent unauthorised access to your application and that has to take priority.
   
   Throw generic error messages on-screen, but make sure you log as much detail about the error as possible to the log. Use proper exception handling to ensure the stack trace isn't lost.
   
   
10. Customizations are accompanied by a list of all dependencies. This could include account/passwords, Web services, databases, other solutions or Features, patches, tool sets or libraries, and other dependencies.
    
    This might appear to be a relatively obvious point but I'm often surprised at how much information is retained in a developers head rather than correctly documented. The acid test is ensuring that someone outside of the development team can deploy the customisation without any issues.
    
    
11. When using the Count property of a SPListItemCollection, you only call it once and then store it in a variable that you can refer to when looping. You do not call it inside a loop.
    
    I think this one speaks for itself, although this was a recent revelation for me.

I think that just about covers it. Please let me know if these items rang any alarm bells or if you have any comments.

Cheers, Ben.

Subscribe to the RSS feed

Follow me on Twitter

Follow my Networked Blog on Facebook