VHD Lifestyle – My SharePoint 2007/2010 Development and Home/Media-Network Setup!

eJugnoo — Wed, 02 Sep 2009 20:15:00 GMT

First - Many thanks to Windows 7 (and 2008 R2), there has been some very useful enhancements in my “Digital Lifestyle” recently!

Windows Vista didn’t fly with me so well as development machine, and I’d always go back to Windows 2003… mostly for SharePoint development setup on my working desktops.

Once Windows 7 was RTM, I was quick to jump off RC (no stability reason really). That also gave me a reason to re-look at my existing setup, which wasn’t working comfortably well for me. So without much ado, let’s see what all I have in my setup and what I did to improve, and what is perhaps missing that you can suggest I can do to further improve...

What do I have and wanted to improve – and did?

Desktop: AMD Quad CPU, 4 GB DDR2 800, 2 SATA-II drives (500 GB each, RAID 1), with a 24” screens.
Server: AMD Dual CPU 64X2, 8 GB DDR2 800, 4 SATA-II drives (2X500GB RAID 1, 2X2TB ~~RAID 1~~ as WHS "duplicated" storage)
Laptop: A Lenovo T-61 laptop with 2 GB RAM!!! Wi-fi connected.
GBit Linksys Router, with Xbox 360 Elite and Epson photo printer on it’s network.

With this primary hardware, I wanted to maximize productivity with ease and flexibility of supporting demanding SharePoint environment needs. So I did following:

Server: Setup my server as Hyper-V (on R2) and instead move my Windows Home Server (WHS) as Virtual. I also host nifty website or two (on demand) from Home (using DynDns) on a 2mbps line! (that’s almost the best in India at the minute, with unlimited bandwidth use) So I also setup a Web Server as virtual. Shared 8 GB amongst the three, with sufficient 2 GB for WHS.
Desktop: I’ve either utilized hack from Bamboo solutions for setting up SharePoint on Vista, or had depended on VPC for Win 2003 SharePoint VMs in past. So I now setup Windows 7 Ultimate on desktop as prime. I also have 4 VHDs created to desired setup, and attached to boot from using BCDEdit. So when I now want to work on SharePoint exclusively, I simply re-boot quickly. (I don’t mind anymore, since its so fast!)
VHD Lifestyle – I was super excited to try new support of VHDs for booting from. There has lot already been said about VHD benefits, and I referred following to get me Native Boot on Server (for Hyper-V) and multiple-boots on desktop (as in diagram). This gave me flexible and on-demand environments that I can kill and build in minutes, not hours. And I’m truly loving the flexibility.

Native VHD Support in Windows 7
Native Boot Scenarios: Advanced deployment – page 29 onwards
Scott Hanselman talks about his lifestyle. Here and here
Wim2VHD – Convert Wim to sysprepped VHD.

Utilized Media Center on desktop and Extender on Xbox, with all Media content centralized and managed by WHS on 2 TB (RAID and duplicated, with self-managed full backup of all my VHDs and drives!!!). Virtual WHS maps physical TB drives.
Laptop, Desktop are Windows 7, Home Server is Windows Home Server, and all others are Windows 2008 R2 (VHD boots or virtual machines).

Planned configuration… (* SP 2010 on Win 7 assumes that hack from Bamboo will be available at the time of public beta, to install on Win 7)

There is so much of goodness, and also feature completeness I now find with combination of Windows 7, 2008 R2, WHS, and updated Xbox Media networking features (with Win 7)… that Digital Lifestyle and desired dev productivity at home is certainly coming full circle! My content is now much more accessible (thanks to HomeGroup and WHS), and with a comfort that it all is being backed up. I’m still missing SSD on my laptop (or perhaps desktop as well), but RAID 1 is keeping me quite happy and works well for SharePoint.

What am I critically missing?

--Sharad

SharePoint 2007 – 12 Hive System-File Changes: One Feature to rule them all!

eJugnoo — Mon, 22 Jun 2009 02:31:55 GMT

Making system-file changes in “12 hive” folder of SharePoint is always a hot topic. Microsoft doesn’t recommend that unless you know what you are doing, and also has support clause against it. Despite that, there are numerous KBs at their support site which point to directions of making necessary changes by following steps that leads us to opening a file in “12 hive” and modifying to achieve the desired effect. I think – without much ado – that its important to assess what you intend to do, and when you certainly need to then there should be a manageable way to make changes to system-files that are otherwise part of SharePoint release. In my previous post I gave an example of a case when one needs to make “12 hive” changes; here are the high-level objectives…

Objectives

A uniform, automated, repeatable, efficient and centrally manageable way for making “12 hive” changes.
It should take least of coding or none to introduce changes – be it xml modification, aspx/ascx, masterpage, images, css etc.
It should be possible to roll-back the changes on demand.
It should be possible for changes to be applied to all servers in the farm, not just local.

Note: This is a standard caution that your changes to “12 Hive” may be over-written by subsequent Cumulative Updates (CU) and/or Service Packs. Hence we need to plan for this as well.

One SharePoint Feature to rule them all!

Since the release of SharePoint 2007, I’ve come across numerous tips & tricks, open-source projects, and blog posts that show how to make desired change and most often employ a code-based approach that runs on Feature Activation to open the required file in “12 Hive”, make your changes – via code - and save the file. Reverse the changes on Deactivation of Feature.

Now, one must realize that this requires significant coding effort and consistency checks (testing) to make minor changes in – say – some xml file somewhere. For example, a simple case of enabling PDF file icon support in SharePoint means creating a feature to open DocIcon.xml, parse the elements, make an entry for pdf element, and saving the xml. Many many lines of code to be written for mere single element entry. There should be a simpler way to this!

Another problem is that you have to deal with the issue that where the code runs, it will pick local file only. What about other servers in farm? You have to further write code to make changes on all servers in farm. Than there are propagation concerns to be dealt, should new servers be added to farm later.

Having said that, I think its better to have one universal and generic mechanism (SP Feature) of deploying your changes. To do that, I create a new VS project using WSPBuilder and create a SP Feature and call it HiveSwap with the idea that we’ll have a mechanism of swapping system-files with ours instead of each time writing code to directly modify/merge required files…

So you get the idea – we want to build a generic feature (to rule them all) that becomes central to us for deploying all changes by mechanism of swapping. Deliver desired files (with manual changes already in place) via feature in a solution (.wsp), activate the Farm feature and it will backup system file, replace with its own. When needing to rollback/remove, it will use backup and replace the original file back.

We need a place to keep all “12 Hive” files we want to deliver to swap system files with. I create another /12 folder inside our Feature folder. This will be a place where I just recreate the folder structure where all I want to make desired changes, copy the original file, make the changes – manually – and deploy the solution.

Before that, we need our Feature receiver to do the job of swapping files both ways on Activation and Deactivation. Here is an example code I’ve quickly put together.
Note: Consider this as pseudo code, is not production tested and you’d want to test at your end before finalizing it… (can’t share the complete/tested code for NDA)

That’s it. Your feature is ready for single-server farm. For multi-server farm, you can enhance above code to run with elevated privileges, map C$ of each server in farm (which you can get from object model) at runtime, assuming each server’s “12 hive” is same local path. Since service account is local admin on these servers, system file moves isn’t a issue.

Conclusion

I’d like to hear from readers the pros/cons of above approach, here is my take:

Advantages
1. Modifications are easy to do and simple.
2. Leverage support of VS for things like intellisense for xml, aspx (partial), ascx (partial), master pages, css etc.
3. Control over deployment/rollback with Feature activation/deactivation.
4. Backup of system files. Should the service pack be deployed, simply deactivate the feature to bring “12 hive” to original state, implement MS changes, and reactivate.
5. Scalable to any number of files you need to modify/replace. Lines of code has no proportionality to number of such files!
Disadvantages
1. All “12 Hive” system-file changes/replacements better be done by a single Feature alone. Else you may end up over-stepping with others, changing same files. If you have single administrative solution for your farm you should be okay to use above.
2. If you are using WSPBuilder, beware of using “Copy to 12 hive” command from menu, if feature is already activated in your local Dev farm. It will simply overwrite the backup! Feature deactivation will not rollback to originals as a result.

Hope this SP Feature is productive and of use for most, if not all.

Thanks for reading.