Home   |    About   |    Contact               Twitter   |    Facebook   |    Flickr    MCMSfaq.com: Content Management Server Resources
   MCA | SharePoint 2010
 
   MCM | SharePoint 2010 & 2007
 
MVP - Office SharePoint Server
 
 

 
 
Content Management Server Resources

The posts on this weblog are provided “AS IS” with no warranties, and confer no rights.
The opinions expressed herein are personal and do not represent those of my employer.

 
 

Scripted Farm Deployments

It took a while but the Using scripts to automate SharePoint Server 2007 installation guidance has finally been published. Chris Smith details the release over on ToTheSharePoint. The best thing about this release are the examples and sample code, however I caution you to test appropriately and don’t be fooled into believing the premise that it’s just better. That my friends, isn’t true.

Unfortunately the vendor has a nasty habit of arrogantly saying “you should be doing it like this… [link]” when they took over 18 months to produce and publish the material when others have been doing it all along. In this case, it’s warranted as if there is a mistake in your install script you’re in for big trouble! So you’ve been warned, watch out for “consultants” pimping this approach and place your bets on your capability instead!

It’s also worth noting that in a less formal fashion, SharePoint Infrastructure Guru Ben Curry posted the salient details back in March, after his excellent presentation on the subject at the SharePoint Conference in Seattle.

Oh and one more thing, 50 SharePoint Servers? If you’re doing that you’ve got bigger problems than worrying about how to automate the install and config :)

Print | posted on Wednesday, November 26, 2008 7:58 PM

Feedback

Gravatar

# re: Scripted Farm Deployments

I don't have 50 servers but even with my current project there are 18 servers of which 9 are physical MOSS servers, 2 WSS with Reporting Services and countless virtual images (2 SQL clusters and ESX+Lab Manager servers make up the rest). All built from scripts. It is the only way. For customers with outsourced data centres I even automate the install of prerequisites including IIS and .Net install/configuration. Consistency is very import in a staging/production farm environment.

11/28/2008 4:27 AM | Ian Morrish
Gravatar

# re: Scripted Farm Deployments

Ian:

Sure there's no argument (at least not from me!) that consistency is extremely important. I also agree - automation is my prefered approach.

However it's not appropriate to state that scripted/automated builds "are the only way" when that is patently not the case. It's this type of 'black or white' statement that hurts customers.

There is no black or white, there is no right way. There is always compromise and there is much more that influences the decision - for example the skill of the available resources to produce and test the automation.

It's not about the number of boxes or relative complexity of the farm design. Having done numerous large farms for enterprises, it's all shades of grey mate - there is no single "right way".

11/28/2008 5:00 PM | Spence
Gravatar

# re: Scripted Farm Deployments

I guess what irks me is the "As Build" approach to documentation which results in a 50 page document full of screen shots. This is not a professional approach IT but is all to common.

11/28/2008 9:09 PM | Ian Morrish
Gravatar

# re: Scripted Farm Deployments

Oh yeah - I hear that! 100%!

Apart from the inherent comedy in the screenshot install docs - talk about redundant information - that whole idea of building up say additional boxes or in a DR worst case is a complete joke. Like that install doc is gonna be upto date anyhow. Completely worthless unless used as a "skills transfer" - otherwise it should stay in the desk drawer forever

11/29/2008 1:59 AM | Spence
Gravatar

# re: Scripted Farm Deployments

I guess I would be one of the "consultants" pimping this approach - hey, watch those quotation marks!

I'm 100% convinced of the benefits of investing time in scripted deployments. I can't really visualise a situation where it wouldn't be better, but I do accept that there may be situations where the time and/or skills required aren't available.

In a team of 15 developers working on 15 different VMs, all configured manually (and therefore - inevitably - configured differently) there is huge scope for inconsistency, and trying to pin down the config which leads to the dreaded "it works on my machine, why doesn't it work on yours?" can be a costly and frustrating nightmare.

But then I would say that... :)

12/2/2008 5:35 PM | Anthony Poole

Post Comment

Title  
Name  
Email
Url
Comment   
Please add 6 and 5 and type the answer here: