Home - Zach Rosenfield's SharePoint Blog

8/28/2008

SharePoint Administration Toolkit 2.0 is Now Available!

I’m excited to announce that the second version of the Microsoft SharePoint Administration Toolkit is available for download! As I said back in April, we would be offering regular updates to this toolkit with new features and functionality for both Microsoft Office SharePoint Server 2007 and Windows SharePoint Services v3.0. With this release we added functionality to address some of the challenges associated with running a highly available and/or geographically disperse MOSS 2007 deployment—particularly aimed at synchronizing user profiles in the Shared Service Provider (SSP). Let’s look at these two areas:

High Availability
In order to provide a highly available Shared Service Provider, your deployment needs two identical SSPs available at all times. While this is easily done with search (each SSP has its own crawler and can create their own index)—keeping user profile data in sync is a bit more involved. You can see detailed instructions on running a highly available environment on Microsoft TechNet:

Highly Available Architecture Diagram

Geographical Replication
If your company is geographically disperse, you may not want to have a single MySite farm serving your users worldwide since some users may experience significant lag in response times depending on WAN bandwidth and traffic characteristics. Instead, it may be better to have several SSP farms located around the globe. Just like in the highly available environment, this configuration would require that user profile data is kept in sync.

Since synchronizing user profiles is something available in the MOSS 2007 product, some of you might wonder what we’ve done in the toolkit! Well, if you’ve ever tried to use the User Profile web services to achieve synchronized profiles—you’ve noticed it’s a very involved process with lots of code (and therefore a lot of room for mistakes). In this release, we’ve built a supported tool for scheduling partial or full replications of any number of your user profile attributes:

Profile Replication Engine

For a full overview of features and instructions see the official Microsoft TechNet articles for MOSS 2007 and WSS v3.0.

The download links for the SharePoint Administration Toolkit v2.0
x64: http://www.microsoft.com/downloads/details.aspx?FamilyId=F8EEA8F0-FA30-4C10-ABC9-217EEACEC9CE&displaylang=en
x86: http://www.microsoft.com/downloads/details.aspx?FamilyId=263CD480-F6EB-4FA3-9F2E-2D47618505F2&displaylang=en

Zach Rosenfield
Program Manager, Microsoft Office SharePoint Server

Posted at 5:21 PM by 99795c10c99c756bcbaf97468e327dc4 | Category: SharePoint Administration | Permalink | Email this Post | Comments (1)

7/3/2008

SharePoint 101: Managed Paths

I often get asked "What is a managed path?" and thought it would make for a good blog post. However, first I must disambiguate a couple common SharePoint terms. For the remainder of this post I will use Object Model (OM) terms for the following objects listed below. I've given a small explanation of these objects—but it is certainly not all inclusive.

SPWeb: These are referred to in SharePoint UI as a "Site". SPWeb's are a collection of user data (lists, library, docs, pages, etc.) in a database. An SPWeb belongs to one, and only one, SPSite.
SPSite: These are referred to in SharePoint UI as a "Site Collection". SPSites are a grouping of SPWebs that all share the same root URL. The SPWeb that lives at the root url of an SPSite is called the "Root Web". SPSites have settings, but do not contain user data.

SPSites have one very important feature—all SPWebs in an SPSite must be stored in the same Content Database. This is key to how we figure out what database user data is stored in.

Now, on to managed paths! When user types in a URL into their browser—the root domain is directed through DNS to a SharePoint Server (this is the easy part!). Once SharePoint gets a URL, how does it now what data to look up?! Let's take the following url: http://www.foo.com/sites/foo/bar/foobar. The first thing to note is that we know that the user's data (provided he typed a valid URL in) is in an SPWeb somewhere… But where? First we need to figure out the 'containing' SPSite so we know what database to look at—but which part of the URL gives us the address of the SPSite? /sites? /? /sites/foo/bar? This is where Managed Paths play their role.

SPSites are limited to being created only where a managed path is defined! For example, "(root)" is one of the default managed paths you see when creating a new web application in SharePoint (visit Central Administration -> Application Management -> Define Managed Paths). This means you can create one site collection at the root of the web app—in our example, this means you can have a site collection at http://foo.com. This is an explicit managed path as it means you can create only one site collection at the exact location specified.

Another default managed path you see is "sites"—which is a wildcard managed path. This allows for unlimited number of site collections to be created directly under the provided path (it is important to note that a site collection, and thus an SPWeb, cannot be created at this explicit url). This means I can create site collection (and only SPSites, not SPWebs) directly under this url (http://foo/sites/foo). This means that any additional path in the given URL is an spweb (created from the root web of this spsite). So in our example, we can split the incoming URL into four pieces to quickly look up the information:

"http://ww.foo.com" + "/Sites" + "/Foo" + "/bar/foobar"
(Web Application) + (managed path) + (SPSite) + (Web/SubWeb)

Whenever a URL is 'received' by SharePoint, the site collection is determined by looking at the list of managed paths for a given Web Application. This means SharePoint has to look at every managed path so try to limit the number of managed paths (<20 is highly recommended). SharePoint always matches the longest pattern possible—we'll look at a more complicated example to explain the reason. Using the following managed paths:

10 (explicit)
10/teams (wildcard)
10/howto (explicit)
10/howto/misc (wildcard)

How do we map out URLs? Site Collections (SPSites) urls are highlighted in Bold:

http://foo.com/10/teams/sites/bar
http://foo.com/10/myteam/sites/bar
http://foo.com/10/howto/team1/foo
http://foo.com/10/howto/misc/team1/foo/bar
http://foo.com/10/howto/misc/team2/foo

The key item to note is in the last three example URLs—notice that the longest managed path (10/howto/misc) takes precedence over the shorter (10/howto). Hopefully this clears up Managed Paths! I'll end by summarizing:

Managed Paths allow SharePoint to determine what portion of a given URL corresponds to the "site collection URL".
Managed Paths can be defined per web application (and cannot be defined for host header site collections)
Managed Paths can be "Explicit" or "Wildcard"
Explicit Managed Paths allow a single spsite to be created at exactly the given url
Wildcard Manage Paths allow unlimited spsites to be created under the given url – no spsite can be created at exactly that URL.
Limit your managed paths to <20 per web application

Posted at 12:32 PM by Zach Rosenfield | Category: SharePoint 101 | Permalink | Email this Post | Comments (1)

6/9/2008

Managing Bulk Site Collection Quotas in PowerShell

It’s been too long since my last post! All the excitement over our first toolkit was appreciated… hope you are all anxiously awaiting the next release!

In the meantime, I saw a couple comments on the SharePoint blog regarding bulk Quota changes (inspired I’m sure by the Batch Site Manager tool). While I can’t promise any new features to address this from the tools effort—I can show you how to do this today in PowerShell! I’ve added three new functions to the functions.ps1 file in the Script Library—Dispose-SPSite, Get-SPQuota, and Set-SPQuota to help me achieve these goals.

First, I needed to add the Dispose-SPSite command so that we can ‘clean up’ directly in the pipeline whatever SPSite we are altering. This function is rather small:

function global:Dispose-SPSite([Microsoft.SharePoint.SPSite]$Site){

PROCESS{

if($_){

$_.Dispose();

}else{

$Site.Dispose();

}

The Get-SPQuota and Set-SPQuota take SPSite objects and get or set the Maximum Size and Warning Size. These cmdlets are not capable of being piped to each other (as they both take SPSites), but you can use these functions to do quota changes like:

PS> Get-SPSite http://localhost | Set-SPQuota -MaxSize 5000000 -WarnSize 3000000 -PassThru -NoRefresh | Dispose-SPSite

PS> Get-SPSite http://localhost | Get-SPQuota

QuotaID : 34643

StorageMaximumLevel : 5000000

InvitedUserMaximumLevel : 0

StorageWarningLevel : 3000000

UpgradedPersistedProperties :

Alternatively, the same goal with:

PS> Set-SPQuota –site http://localhost –MaxSize 5000000 –WarnSize 3000000 –PassThru | Dispose-SPSite

Or set quotas in bulk like:

Get-SPWebApplication | Where {$_.Name -eq "SharePoint - 80" }|%{$_.Sites} | Where{ $_.Owner -eq "DOMAIN\foo" } | Set-SPQuota –MaxSize 500000 –PassThru | Dispose-SPSite

The full syntax is:

Get-SPQuota -Site <SPSite>

Set-SPQuota -Site <SPSite> [-MaxSize <bytes> -WarnSize <bytes> -NoRefresh –PassThru]

Dispose-SPSite -Site <SPSite>

*Note: That these functions all use the SPSite object—which means your user account must have access to the site collection. In a future post I’ll explain how to use the SPSiteAdministration object to still act upon these site collections.

To see the entire function definitions view the full script which is available for download in the Script Library.

Posted at 4:00 PM by Zach Rosenfield | Category: PowerShell; SharePoint Administration | Permalink | Email this Post | Comments (0)

4/30/2008

Announcing the First Release of the Microsoft SharePoint Administration Toolkit

It's with great excitement that I get to be the first to announce the initial release of the Microsoft SharePoint Administration Toolkit! Since shipping SharePoint back in November of 2006 we've been listening to your feedback and requests for more tools to help you run our product. We've been listening and our team is deeply committed to supporting you and our in market products. One of our approaches to better support you is to provide a regular release of additional tools in the new SharePoint Administration Toolkit. This tool pack is oriented towards helping SharePoint administrators with complex or demanding tasks—and we will have updated releases several times each year. Each release of this kit will include new or improved functionality to make managing SharePoint easier and less time consuming. The tools on the top of our list are aimed at the issues that you, our customers, have brought up through Products Support—but this effort won't stop there! If there's something you need to keep your SharePoint deployments running on a daily basis, I want to hear about it! Use the comments below to give us ideas or any other feedback.

Now, shifting focus on to this version of the SharePoint Administration Toolkit—this first release contains two very useful tools which are both supported on Windows SharePoint Services 3.0 and Microsoft Office SharePoint Server 2007.

The first tool, called "Batch Site Manager", adds new functionality through Central Administration. From the new "Move, Lock, and Delete Site Collections" page on Applications Management you can schedule bulk operations against site collections in the farm—including moving site collections between content databases! This is my favorite feature as it is completely new functionality for SharePoint and definitely helps manage deployments simply from the UI rather than requiring administrators to write or use scripts. The development of this feature was quite involved, and is a topic which I intend to blog about in full in the near future. For now, here's a screenshot of the "Batch Site Manager" tool:

Batch Site Manager
*Note: when using the Batch Site Manager, be sure to refresh the site collection list using the "click here" aggregation link before every scheduled operation!

The second tool is actually a new command in STSADM called "updatealert". This command will refresh all alert URLs in a specific site collection, which is extremely important should you change the URL of a web application or after an upgrade. Alerts in SharePoint store the URL which the users used to create them—which is needed so that users of different "zones" get the proper URL in their email—but if the URL changes you can now use "STSADM –o UpdateAlert" to let SharePoint fix these alerts (don't know what a "zone" is? Start here on MSDN). Due to the multiple zones that can exist in a web application, the UpdateAlert command needs to be provided with both the new URL of the site collection to be fixed and the old URL–this operation must be run once per zone, but will update all the subwebs in the given site collection automatically.

UpdateAlert

The full detailed whitepaper about this release of the SharePoint Administration Toolkit is available on MSDN. There are some restrictions regarding the Batch Site Manager tool, so be sure to read the whitepaper!

The download links for the SharePoint Administration Toolkit
x64: http://www.microsoft.com/downloads/details.aspx?FamilyId=F8EEA8F0-FA30-4C10-ABC9-217EEACEC9CE&displaylang=en

x86: http://www.microsoft.com/downloads/details.aspx?FamilyId=263CD480-F6EB-4FA3-9F2E-2D47618505F2&displaylang=en

Zach Rosenfield
Program Manager, Microsoft Office SharePoint Server

Posted at 3:22 PM by Zach Rosenfield | Category: SharePoint Administration; Random SharePoint Knowledge | Permalink | Email this Post | Comments (1)

4/23/2008

Managing SharePoint with PowerShell: Part 2

This is the second of an ongoing set of posts about doing SharePoint management with PowerShell. Part 1 is available here – and as always, use these scripts at your own risk.

In this post, I've added just a couple new functions to my "Functions.ps1" script: Get-SPFarm and Get-SPWebApplication. The goal—to be able to quickly answer simple questions about my farm such as "How many site collections do I have?". So on to the good stuff…

Get SPFarm is extremely simple—it just returns the local site. Here's the code

function global:Get-SPFarm{

return [Microsoft.SharePoint.Administration.SPFarm]::Local

}

More interesting is the Get-SPWebApplication function. We get the list of web applications on the farm from the SPFarm.Services. The function below will include the Central Administration Web Application (*Note that the CA application does not have a name, so using Get-SPWebApplication | Select Name will show 3 names—but return 4 web applications!)

function global:Get-SPWebApplication{

Get-SPFarm |% {$_.Services} | where {'$_.TYPEName -eq "Windows SharePoint Services Web Application"'} |% {$_.WebApplications} |% {Write-Output $_}

}

That's it! The full script is available for download from the Script Library. Once the functions are available, you can get great information like the number of site collections per web application using:

get-spwebapplication | %{$_.sites.count}

And the number of site collections in the farm like this:

get-spwebapplication | %{$tot=0}{$tot+=$_.sites.count}{$tot}

Posted at 10:17 AM by Zach Rosenfield | Category: PowerShell; SharePoint Administration | Permalink | Email this Post | Comments (2)

4/3/2008

SharePoint 101: Alternate RSS Feed

This week, a quick SharePoint 101 session—changing the SharePoint RSS feed to use your favorite alternate. I just set up this blog to use FeedBurner—and wanted to make the RSS button in the browser point people to my FeedBurner URL:

Alternate RSS Feeds

To do this was quite simple! There are two easy steps. First, add the feed links to the <HEAD> tag of your Master Page:

Each entry adds another option to the drop down (the first one defined will be the default option).

Next, we need to remove the default RSS feed link generated by SharePoint—it's a tag called <SharePoint:RssLink runat="server"/>. You'll find it in the 'default.aspx' page (and any other blog post viewing page) inside the "PlaceHolderAdditionalPageHead" content place holder. Remove the tag—but NOT the content placeholder! Repeat this to any page that views a blog post; I removed it from Default.aspx as well as the AllPosts.aspx and Posts.aspx pages under Lists > Posts.

*Side Note: be aware that by editing these pages you are customizing it (also called 'unghosting') to be unique—not relying on the underlying site definition (this is important as it will affect your page during upgrade).

Posted at 12:00 PM by Zach Rosenfield | Category: SharePoint 101 | Permalink | Email this Post | Comments (0)

4/1/2008

New Master Page

As part of a team effort to design a better master page for our blogs, I'm now sharing a base page design with Jason Cahill (visit his new blog here). We will be working on our Master Pages over time--and sharing some of our learning and tips/tricks as we go.

Feel free to leave comments/suggestions in the comments section.

Posted at 5:00 PM by Zach Rosenfield | Category: General Talk | Permalink | Email this Post | Comments (0)

3/31/2008

Navigating STSADM with PowerShell

Just a quick post this week to help out those of you can never remember the exact STSADM command to use. I personally find the '-help' output to be too long to really be useful—so instead I leverage the where statement in PowerShell to find relevant command for whatever I'm doing. For example, when working with SharePoint Solutions I'll first execute this command to see my options (*NOTE: I've created an alias "stsadm" for calling the STSADM.exe application directly):

PS> stsadm -help |where{$_ -like "*solution*"}

addsolution
deletesolution
deploysolution
displaysolution
enumsolutions
removesolutiondeploymentlock
retractsolution
syncsolution
upgradesolution

Leveraging the wildcard match allows you to quickly locate the right command for your needs. I've added this little script to my $PROFILE to quickly reference STSADM commands:

function global:Get-StsadmCmd($in){

Write-Host -foreground "Yellow" "STSADM commands matching $in"

stsadm -help |where{$_ -like $in}

}

Now, for example, I can find Feature related commands by simply typing Get-StsadmCmd "*features*".

Posted at 11:36 AM by Zach Rosenfield | Category: PowerShell; SharePoint Administration | Permalink | Email this Post | Comments (1)

3/25/2008

Cool PowerShell Trick: Remoting in PowerShell V1

I came across this great post by Jeffery Snover (the PowerShell Architect) on how to do remoting in PowerShell V1! It's a very useful (though not exactly pretty) way to do remoting while we all wait for this great new feature in PS v2.

Here's the post: http://blogs.msdn.com/powershell/archive/2008/02/29/remoting-using-powershell-v1.aspx

Posted at 3:20 PM by Zach Rosenfield | Category: PowerShell | Permalink | Email this Post | Comments (0)

3/11/2008

Locking Sites on Backup

I recently noticed Michael Blumenthal's blog post on the need to backup a site collection before backing it up. This is absolutely the recommended practice—and everyone should do it! Since there is a need, I thought I'd throw together a PowerShell script to do the complete operation in a single command. Here's the outline of my design for the "Backup-SPSite" function script:

First, I want to be able to call this as a function, so I create the global function declaration with my parameters and checks:

function global:Backup-SPSite($url,$path, lock="noaccess",$additionalcommands){

$stsadm = "$env:programfiles\Common Files\Microsoft Shared\Web Server Extensions\12\BIN\STSADM.EXE"

#Check Required Vars

If($url -eq "" -or $url -eq $null ){ Write-Host -ForegroundColor "Red" "URL is required"; return; }

If(!($lock -like "none" -or $lock -like "noadditions" -or $lock -like "noaccess" -or $lock -like "readonly" )){

Write-Host -ForegroundColor "Red" "Lock must be 'none', 'readonly', 'noaccess', or 'noadditions'"; return;

}

Next, I store the site's current lock state and then lock the site collection:

$oldlockstate = [xml](&stsadm -o getsitelock -url $url)

$void = &stsadm -o setsitelock -url $url -lock $lock

Then I backup the Site Collection, using any additional parameters the user wants with the "AdditionalCommands" Variable:

$sTemp = &stsadm -o Backup -url $url -filename $path $AdditionalCommands

if(!($sTemp -like "*Operation completed successfully*")){ Write-Host -ForegroundColor "red" -BackgroundColor "white" "Backup of site '$url' Failed! `n $stemp"}

Finally, I reset the lock state and end the function block

$void = &stsadm -o setsitelock -url $url -lock ($oldlockstate.SiteLock.Lock.ToString()) }

That's it! I added this script to my profile 'bootstrap' and then I can backup site collections by simply typing a command like: backup-spsite -url "http://localhost" -path "C:\zbackuptest.bak" -AdditionalCommands "-overwrite". The full script with additional progress information is available here, and as always, use at your own risk!

Posted at 5:22 PM by Zach Rosenfield | Category: PowerShell | Permalink | Email this Post | Comments (2)

RSS Feed

1 - 10

Zach Rosenfield

SharePoint Program Manager, Infrastructure