Windows PowerShell and SharePoint Installation: Automating Configuring a SharePoint Farm

Last week, I published a simple script that automates the processes that are performed by the SharePoint Products Configuration Wizard.  The logical “next step” is to configure the farm—to perform tasks similar to those performed by the Configure Your Farm Wizard in Central Administration.

Here is where PowerShell and automation in general really shine. The Wizard allows you to configure service applications, but each application is configured with a single managed account and, as we discussed in previous columns, the Wizard uses the same managed account to configure certain features (such as the crawler) that actually are unmanaged accounts—and that can lead to problems.

Kirk Stark, one of the talented folks behind the excellent content on TechNet, published a detailed article about how to use PowerShell to install and configure SharePoint. A SharePoint Foundation version is also available on TechNet. The process described requires a SharePoint module for PowerShell (SPModule)—a simple download from Microsoft’s site. The article details how to use the module to automate the detailed configuration of a farm and its services, service applications, and managed accounts.

Post-Release Features, Downloads, and CodePlex

 I’d like to point out that this kind of “additional component” (a downloadable SPModule in this case) is not unusual these days with Microsoft. Unlike some of its competitors, whose market is “OK” with products that are always in beta, Microsoft is a company that has become increasingly disciplined about drawing a line in the sand and getting a product out the door. That’s actually a great thing, but it means, at times, putting features aside for “v Next” or for a Service Pack. 

In the case of SharePoint 2010, there are several features related to PowerShell that have already been announced as being “part of a future update” (read: Service Pack or Cumulative Update).  While I don’t know whether this applies specifically to the SPModule for PowerShell, I’d be pretty surprised if it doesn’t.  In other words, SPModule is probably “fully baked,” but just didn’t get done in time for the RTM of the product. 

Don’t be hesitant or dubious about this kind of additional post-release feature/code just because it’s not part of the product’s current version!!  Use what you can to make your job easier! The same applies for certain features and code you’ll find on CodePlex .  Many people don’t realize that CodePlex is a Microsoft web property—you can see that in its copyright notice. 

While CodePlex is a forum for community-submitted solutions, it is also a major outlet for solutions driven by Microsoft itself. In some cases, Microsoft hires vendors to create solutions that it knows the market needs. Some of these solutions become incorporated in “v Next” releases. In other cases, solutions on CodePlex come from the Microsoft product groups themselves. 

In years past, Microsoft would release “Resource Kits” that included numerous unsupported tools that performed important tasks.  Few IT organizations hesitated to use the Resource Kits—in fact I know organizations that add the Windows Resource Kit tools to all servers they deploy. But some of those same organizations are against anything on CodePlex, even though it represents exactly the same “business model” as the Resource Kits did in the past.

Obviously, with any code you download and deploy into production, you want to test first!  That applies whether it’s a community solution, a Microsoft solution, or a retail product like SharePoint itself—always test and validate in a lab! 

But the main point is that you should not discount CodePlex just because it’s a web site—you’ll miss out on a lot, and a lot of important stuff.  Hopefully this discussion will help you, or your management, take a more reasonable and practical approach to locating extensions to SharePoint.