MOSS MVP

I've moved my blog to http://blog.falchionconsulting.com!. Please update your links. This blog is no longer in use--you can find all posts and comments at my new blog; I will no longer be posting to this site and comments have been disabled.

Saturday, June 12, 2010

Deploying SharePoint 2010 Solution Packages Using PowerShell

With SharePoint 2010 we can now deploy our Solution Packages using PowerShell. What’s cool about this is that it’s a bit easier than it was with 2007 to check if a package is already deployed and conditionally retract, delete, and then re-add and re-deploy. By now most people already know how to do this as it’s fairly straightforward but I thought I’d go ahead and share the script that I use as it’s great for deploying lots of Solution Packages to my various client environments in bulk.

Like most of my scripts this one is driven by an XML file but I have a core function which can be called directly – I just wrap that in another function which can iterate through the XML file thus facilitating bulk installs of packages. First lets look at the XML file:

<Solutions>
<Solution Path="W:\my.sharepoint.package.wsp" CASPolicies="false" GACDeployment="true">
<WebApplications>
<WebApplication>http://portal</WebApplication>
</WebApplications>
</Solution>
</Solutions>

As you can see the structure is fairly simplistic – just provide the path to the WSP file and whether it contains CAS policies and whether it should be deployed to the GAC or not. If it’s a Farm level solution (no web application resources) then simply omit the <WebApplications /> element. If you have more than one solution just add another <Solution /> element. If you’re deploying to multiple web applications then add as many <WebApplication /> elements as is needed.

Now we’ll take a look at the wrapper function which loops through the XML:

function Install-Solutions([string]$configFile)
{
    if ([string]::IsNullOrEmpty($configFile)) { return }

    [xml]$solutionsConfig = Get-Content $configFile
    if ($solutionsConfig -eq $null) { return }

    $solutionsConfig.Solutions.Solution | ForEach-Object {
        [string]$path = $_.Path
        [bool]$gac = [bool]::Parse($_.GACDeployment)
        [bool]$cas = [bool]::Parse($_.CASPolicies)
        $webApps = $_.WebApplications.WebApplication
        Install-Solution $path $gac $cas $webApps
    }
}

As you can see the code just loads the passed in file as an XmlDocument object and grabs each Solution element ($solutionsConfig.Solutions.Solution) and then iterates through each object using the ForEach-Object cmdlet. For pure convenience I grab each attribute and assign it to a local variable. And finally I call the Install-Solution function which is shown below:

function Install-Solution([string]$path, [bool]$gac, [bool]$cas, [string[]]$webApps = @())
{
    $spAdminServiceName = "SPAdminV4"

    [string]$name = Split-Path -Path $path -Leaf
    $solution = Get-SPSolution $name -ErrorAction SilentlyContinue
    
    if ($solution -ne $null) {
        #Retract the solution
        if ($solution.Deployed) {
            Write-Host "Retracting solution $name..."
            if ($solution.ContainsWebApplicationResource) {
                $solution | Uninstall-SPSolution -AllWebApplications -Confirm:$false
            } else {
                $solution | Uninstall-SPSolution -Confirm:$false
            }
            Stop-Service -Name $spAdminServiceName
            Start-SPAdminJob -Verbose
            Start-Service -Name $spAdminServiceName    
        
            #Block until we're sure the solution is no longer deployed.
            do { Start-Sleep 2 } while ((Get-SPSolution $name).Deployed)
        }
        
        #Delete the solution
        Write-Host "Removing solution $name..."
        Get-SPSolution $name | Remove-SPSolution -Confirm:$false
    }
    
    #Add the solution
    Write-Host "Adding solution $name..."
    $solution = Add-SPSolution $path
    
    #Deploy the solution
    if (!$solution.ContainsWebApplicationResource) {
        Write-Host "Deploying solution $name to the Farm..."
        $solution | Install-SPSolution -GACDeployment:$gac -CASPolicies:$cas -Confirm:$false
    } else {
        if ($webApps -eq $null -or $webApps.Length -eq 0) {
            Write-Warning "The solution $name contains web application resources but no web applications were specified to deploy to."
            return
        }
        $webApps | ForEach-Object {
            Write-Host "Deploying solution $name to $_..."
            $solution | Install-SPSolution -GACDeployment:$gac -CASPolicies:$cas -WebApplication $_ -Confirm:$false
        }
    }
    Stop-Service -Name $spAdminServiceName
    Start-SPAdminJob -Verbose
    Start-Service -Name $spAdminServiceName    
    
    #Block until we're sure the solution is deployed.
    do { Start-Sleep 2 } while (!((Get-SPSolution $name).Deployed))
}

The code looks more complicated than it really is. I first start out by getting the solution name which I always assume to be the filename of the WSP file. I then use that to get the SPSolution object using Get-SPSolution. If a value comes back then I check if it has been deployed and if it has then I retract it by calling Uninstall-SPSolution. The trick is knowing whether it has web application scoped resources and if it does then we need to retract using the -AllWebApplications parameter. Once retracted I stop the SharePoint Administration Service (SPAdminV4) so that I can call Start-SPAdminJob and force the retraction timer job to execute. Once the Start-SPAdminJob cmdlet returns I then restart the SharePoint Administration Service. With the solution retracted I can now delete the solution from the solution store using Remove-SPSolution (I re-get the solution to make sure that I get no errors due to the current variables state being invalid).

Once deleted I can then add the new solution to the store using the path provided (Add-SPSolution). Now that it’s in the store I can check if it has web application resources or not – if it does not then the deployment is simply a matter of calling Install-SPSolution and specifying whether it should be deployed to the GAC and if it contains CAS policies. If it does contain web application resources then I have to loop through all the web application items in the provided string array ($webApps) and then pass each one into a separate call to Install-SPSolution.

You now have two options for adding your solution: you can call the first function and pass in an XML file or you can call the second function directly. I’ll first show how to call the second function directly:

PS C:\>Install-Solution "w:\my.sharepoint.package.wsp" $true $false @("http://portal","http://mysites")

Now lets look at how to call the first function given an XML file named “solutions.xml” containing a structure similar to that shown above:

PS C:\>Install-Solutions "w:\solutions.xml"

Hopefully you’ll find this script useful for deploying your custom SharePoint 2010 Solution Packages.

Wednesday, June 9, 2010

SharePoint 2010 Service Application Charts

I, along with Paul Stork, recently gave a SharePoint 2010 deployment webcast where we discussed, among other things, Service Applications and some of the considerations that must be taken into account when planning your deployment strategy. We also presented a first look at SharePoint Composer and SharePoint Maestro, the two core products that ShareSquared has been developing for close to a year now.

During the presentation we mentioned that there were some great charts available to help you in planning your Service Applications but that they weren’t the easiest thing to find as they are buried in a series of technical diagrams on TechNet. You can find two of the three charts we referenced at this link, http://technet.microsoft.com/en-us/library/cc263199.aspx. I’ve also added another chart which shows the dependencies of one Service Application to another (note that this particular chart is a work in progress as we are still discovering odd dependency cases that only occur in certain situations).

Chart 1: Service Applications per SKU

The first chart identifies all the core Service Applications and whether they store data, can be used cross-farm, and to which SharePoint SKU they belong. This chart is particularly useful in planning your initial licensing requirements:

Service applications

Description

Stores data?

Cross-farm?

SharePoint Foundation 2010

SharePoint Server 2010 Standard

SharePoint Server 2010 Enterprise

Access Services

View, edit, and interact with Microsoft® Access® 2010 databases in a browser.

Cache

X

Business Data Connectivity

Access line-of-business (LOB) data systems.

DB

X

X

X

X

Excel Services Application

Viewing and interact with Excel files in a browser.

Cache

X

Managed Metadata Service

Access managed taxonomy hierarchies, keywords and social tagging infrastructure as well as Content Type publishing across site collections.

DB

X

X

X

PerformancePoint

Provides the capabilities of PerformancePoint Services.

Cache

X

Search

Crawls content, produces index partitions, and serves search queries.

DB

X

X

X

Secure Store Service

Provides single sign-on authentication to access multiple applications or services.

DB

X

X

X

State Service

Provides temporary storage of user session data for SharePoint Server components.

DB

X

X

Usage and Health Data Collection

Collects farm wide usage and health data and provides the ability to view various usage and health reports.

DB

X

X

X

User Profile

Adds support for My Sites, Profiles pages, Social Tagging and other social computing features.

DB

X

X

X

Visio Graphics Service

Viewing and refresh of published Microsoft® Visio® diagrams in a Web browser.

Blob cache

X

Web Analytics

Provides Web Service interfaces.

X

X

X

Word Automation Services

Performs automated bulk document conversions.

Cache

X

X

Microsoft SharePoint Foundation Subscription Settings Service

Tracks subscription IDs and settings for services that are deployed in partitioned mode. Windows PowerShell only.

DB

X

X

X

Source:

Visio (http://go.microsoft.com/fwlink/?LinkID=167090)

PDF (http://go.microsoft.com/fwlink/?LinkID=167092)

XPS (http://go.microsoft.com/fwlink/?LinkID=167091)

 

Chart 2: Databases That Support SharePoint 2010 Products

This next chart takes what was in diagram form in the original TechNet diagram and displays it in a chart so that it’s a bit easier to read. Use this chart when planning your SQL Server storage requirements:

Service Application Database

Database

Relative Size

Size Guidance

Usage and Health Data Collection Service Application

Usage

Extra-large

Scale up. Only one database service application per farm. Place on separate spindle.

Business Data Connectivity Service Application

Business Data Connectivity

Small

Scale up.

Application Registry Service Application

Application Registry (used during upgrade only)

Small

Scale up.

Microsoft SharePoint Foundation Subscription Settings Service

Subscription Settings

Small

Scale up. You can scale out by creating additional service applications.

Search Service Application

Search Administration

Medium

Scale up. You can scale out by creating additional service applications.

Search Service Application

Crawl

Extra-large

Scale out. For large environments, put on a server that does not contain the Property databases.

Search Service Application

Property

Large to Extra-large

Scale out. For large environments, put on its own server for faster query results.

Web Analytics Service Application

Reporting

Extra-large

Scale up.

Web Analytics Service Application

Staging

Medium

Scale out.

State Service Application, Visio Service Application, InfoPath Forms Services

State

Medium-large

Scale out.

User Profile Service Application

Profile

Medium-large

Scale up. You can scale out by creating additional service applications.

User Profile Service Application

Synchronization

Medium-large

Scale up. You can scale out by creating additional service applications.

User Profile Service Application

Social Tagging Small to Extra-large

Scale up. You can scale out by creating additional service applications.

Managed Metadata Service Application

Managed Metadata

Medium

Scale up. You can scale out by creating additional service applications.

Secure Store Service Application

Secure Store

Small

Scale up. You can scale out by creating additional service applications.

Word Automation Service Application

Word Automation Services

Small

Scale up.

PerformancePoint Service Application

PerformancePoint

Small

Scale up. You can scale out by creating additional service applications.

Source:

Visio (http://go.microsoft.com/fwlink/?LinkId=187970)

PDF (http://go.microsoft.com/fwlink/?LinkId=187969)

XPS (http://go.microsoft.com/fwlink/?LinkId=187971)

 

Chart 3: Service Application Dependencies

This last chart is one that we’ve been manually constructing based on our experiences with automating the setup of Service Applications. When doing a scripted install (or even when you use the FCW or manually configure Service Applications) it’s critical to know which Service Applications are dependents for other Service Applications. For example, if you are configuring the User Profile Service Application you must also configure the Managed Metadata Service Application. If you don’t do this you will get errors stating that certain fields cannot be edited when editing a user’s profile – these errors don’t give any indication that what’s missing is the Managed Metadata Service Application – you just have know.

The following chart is an attempt to help users with this hurdle – note that it is still a work in progress as it is very difficult to detect all dependencies as some are only a dependency under certain usage scenarios. Anything with an asterisks (*) next to the “X” indicates that the dependency is conditional based on usage scenarios:

Service Applications

Access

Business Data Connectivity Excel Services Managed Metadata PerformancePoint Foundation Search Enterprise Search Secure Store State Usage and Health Data User Profile Visio Graphics Web Analytics Word Automation Subscription Settings

Access

Business Data Connectivity X* X*
Excel Services X*
Managed Metadata X*
PerformancePoint X*
Foundation Search
Enterprise Search X* X X*
Secure Store X*
State
Usage and Health Data Collection
User Profile X* X* X*
Visio Graphics X* X
Web Analytics X
Word Automation X*
Subscription Settings                              

The way you read this chart is to find the Service Application of interest on the left and follow it to the right to see what Service Application it depends on. As you can see there’s not a lot of dependencies and most of the ones that do exist are conditional (for example, all the ones that depend on the Subscription Settings Service Application only depend on it if using Partitioning Mode, or basically a multi-tenant configuration).

As this chart is a work in progress I appreciate any feedback on it’s accuracy. If anyone notices anything that is incorrect with the chart please add a comment and I will be sure to update it accordingly.