Random SharePoint Knowledge - Zach Rosenfield's SharePoint Blog

5/27/2009

SharePoint 101: What’s a Host Header Site Collection?

I often get asked to differentiate the different ways to configure URLs for site collections—most often how Host Header (HH) Site Collections fit into the mix—so I thought I’d try to disambiguate this for everyone. In the simplest explanation, there are three types of Site Collections:

· Load-Balanced URL web application: A single root URL that is shared amongst all contained site collections. For example, you could have http://sharepoint, http://my, or http://teams. There is one root site collection (matches web application URL) and additional site collections can be created at Managed Paths under this URL (http://sharepoint/sites/zach).

· Host header web applications: Similar to a load-balanced URL web application, except the URLs all use a single host header (e.g.: http://www.foo.com).

· Host Header Site Collection: These are site collections that each have their own unique host header. For example, http://foo.com and http://bar.com. These sites are by far the easiest to rename—use STSADM –o RenameSite to change a HH Site Collection host header. These site collections must still be hosted in a web application—but the Web App URL or Host Header is ignored for these sites.

While host header site collections give the most flexibility for offering multiple unique FQDNs, there are some limitations:

· Only 1 site collection can use a unique Host Header

· Managed Paths do no work

· AAMs are not used as part of site lookup for HH Site Collections, so URL re-writing will not work

· SSL Termination at the load balancer will not work (due to lack of AAM support)

It’s important to note that Host Header Site Collections can only be created from the command line—in the STSADM command createsite, provide the Host Header for the SPSite in the URL parameter and then provide the url of the web application that will host the HH Site Collection. The good news is that for those of you familiar with previous versions of SharePoint, there is no longer a “Host Header Mode”; HH Site Collections can be created at anytime on existing web applications.

Posted at 9:55 PM by Zach (SharePoint - MSFT) | Category: SharePoint 101; Random SharePoint Knowledge; SharePoint Administration | Permalink | Email this Post | Comments (2)

10/3/2008

64-Bit and the Admin Toolkit Download Trend

Just over a month ago I announced the release of the second Microsoft SharePoint Administration Toolkit. We’ve been getting great feedback and lots of interest—and I wanted to share our download results:

Toolkit Download Trends

After 5 months we’re just shy of the 29,000 download mark, but more interesting is the disparity between x86 and x64 downloads. We feel like we often talk about the benefits of going 64-bit with your SharePoint deployments—but the download numbers above make us wonder if he advantages are really understood. I’ll take this opportunity to reiterate why we push all our customers to consider the switch to the x64 architecture.

What is wrong with 32-bit?
We’re not saying 32-bit is bad—it’s just that when Windows, IIS, CLR/ASP.NET, WSS, MOSS Core, SSP, and MDAC binaries are all loaded into memory (this is the initial footprint for MOSS 2007) it can leave a 32-bit address space quite fragmented (not to be confused with “too consumed”). When the CLR or SharePoint services request new memory blocks, it can be difficult to find a 64MB slice in the already loaded address space. Below is a snapshot of such an address space:

Sample Memory Footprint (32-Bit)

In many cases where customers are seeing bad performance—it’s not due to a lack of memory but a lack of enough continuous memory to serve additional requests.

Why 64 Can Help?
64-bit is not a cure-all to every performance issue but it does provide a practically unbounded address space for user mode processes. Therefore memory requests (even in 100’s of MB chunks) will not fail due to a lack of un-fragmented space. Not only will 64-bit significantly lower the problems you could potentially face, but once you get your servers into a constantly stable state mitigating other performance issues becomes a much easier task to achieve.

I just wanted to take this opportunity to thank you for your interest in the SharePoint Administration Toolkit and to remind you all to keep the benefits of 64-bit architecture in mind as you look to improve your SharePoint deployments and plan for the future. If you can’t switch immediately (and even if you can) you can still help yourself today by installing the Infrastructure Update and to look at the Best Practices Resource Center.

Zach Rosenfield
Program Manager, Microsoft Office SharePoint Server

Posted at 12:07 PM by Zach (SharePoint - MSFT) | Category: SharePoint Administration; Random SharePoint Knowledge | Permalink | Email this Post | Comments (5)

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)

12/20/2007

Generating Test Farms

I recently had a reader submit a great concept question for how to possibly use PowerShell to script SharePoint admin tasks. Since I want to dive into his idea in more detail, I first need to setup a new farm to do my testing. Since I want this 'test' farm to be as real as possible, I needed to create endless fake data—especially lots of sites and webs. Then came a bright idea—why not script it! Since everyone needs sample sites, which can take a long to time to manually create, I created this simple PowerShell script. For those interested, the script is available for download here and copied out below (complete with a progress output bar)!

###########################################################
#
# Script to Populate Test Farm Data
#
# Params: -WebApplication <URL> **no trailing '/'
#             -OwnerEmail <Email>
#             -OwnerLogin <User Alias>
#             -SiteCount <Int> #number of sites to create
#             -[SubSites] <Int> #number of webs to create
#             -[RootName] <String> #optional: provide the base name of all custom sites. Default=="Site"
#             -[ManagedPath] <string> #optional: provide the managed path to use. Default=="Sites"
#
# Sample Usage: "Create 1000 sites, each with 2 subsites on "WebApp1":
# .\PopulateTestData.ps1 -WebApplication "http://webapp1" -SiteCount 1000 -OwnerEmail "foo@bar.com" –OwnerLogin "domain\foo" -SubSites 2
###########################################################

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

#process input
$vars=@{}
for($i = 0; $i -lt $args.length; $i++){
if($args[$i].subString(0,1) -ne "-"){ "Did not understand $args[$i]"; return;}
$vars[$args[$i].subString(1)] = $args[$i+1];
$i++;
}

#verify
if($vars['WebApplication'] -eq $null){Write-Host -ForegroundColor "Red" "WebApplication Parameter is required "; Return; }
if($vars['SiteCount'] -eq $null){Write-Host -ForegroundColor "Red" "SiteCount Parameter is required "; Return;}
if($vars['OwnerEmail'] -eq $null){Write-Host -ForegroundColor "Red" "OwnerEmail Parameter is required "; Return;}
if($vars['OwnerLogin'] -eq $null){Write-Host -ForegroundColor "Red" "OwnerLogin Parameter is required "; Return;}

if($vars['RootName'] -eq $null){ $vars['RootName'] = "Site" }
if($vars['ManagedPath'] -eq $null){ $vars['ManagedPath'] = "Sites" }
if($vars['SubSites'] -eq $null){ $vars['SubSites'] = 2 }

#Create Site Collections
for($i=0;$i -lt $vars['SiteCount'];$i++){
$progress = [String]($i/$vars['SiteCount']*100);
$url = $vars['webapplication']+"/"+$vars['ManagedPath']+"/"+$vars['RootName']+$i;

Write-Progress -Id 1 -PercentComplete $progress -Activity "Creating Test Content" -Status "Creating Site ($i): $url";

$sTemp = &stsadm -o createsite -url $url -ownerlogin $vars['OwnerLogin'] -owneremail $vars['OwnerEmail'] -sitetemplate "STS#0"
if(!($sTemp -like "*Operation completed successfully*")){ Write-Host -ForegroundColor "red" "Site '$url' Failed!"}
else{ #Create subsites...
for($j=0;$j -lt $vars['SubSites'];$j++){
$suburl = $url +"/subweb"+$j;
$progress = [String]($j/$vars['SubSites']*100);
Write-Progress -ParentId 1 -PercentComplete $progress -Activity "Creating SubWeb ($j):" -Status "$suburl";

$sTemp = &stsadm -o createweb -url $suburl -sitetemplate "STS#0"

}
Write-Progress -ParentId 1 -PercentComplete 100 -Activity "Creating SubWebs for $url" -Status "Finished";
}
}

Posted at 12:16 PM by Zach Rosenfield | Category: PowerShell; Random SharePoint Knowledge | Permalink | Email this Post | Comments (2)

12/12/2007

Consume SharePoint Web Services From PowerShell

I’ve been getting some questions about how to consume web services from PowerShell – so I wanted to give a quick overview. PowerShell offers some great tools for working with web services, but first, you must load the Visual Studio tools into your PS Environment. To do so, copy the following code into a script file:

$env:VSINSTALLDIR="C:\Program Files\Microsoft Visual Studio 8"

$env:VCINSTALLDIR="C:\Program Files\Microsoft Visual Studio 8\VC"

$env:DevEnvDir="$env:VSINSTALLDIR\Common7\IDE"

$env:FrameworkSDKDir="$env:VSINSTALLDIR\SDK\v2.0"

$FrameworkPath=$([System.Runtime.InteropServices.RuntimeEnvironment]::GetRuntimeDirectory())

$env:FrameworkDir=$(split-path $FrameworkPath -Parent)

$env:FrameworkVersion=$(split-path $FrameworkPath -Leaf)

$env:PATH="$env:VSINSTALLDIR\Common7\IDE;$env:VCINSTALLDIR\BIN;$env:VSINSTALLDIR\Common7\Tools;$env:VSINSTALLDIR\Common7\Tools\bin;$env:VCINSTALLDIR\PlatformSDK\bin; $env:FrameworkSDKDir\bin;$env:FrameworkDir\$env:FrameworkVersion;$env:VCINSTALLDIR\VCPackages;$env:PATH"

$env:INCLUDE="$env:VCINSTALLDIR\ATLMFC\INCLUDE; $env:VCINSTALLDIR\INCLUDE;$env:VCINSTALLDIR\PlatformSDK\include;$env:FrameworkSDKDir\include;$env:INCLUDE"

$env:LIB="$env:VCINSTALLDIR\ATLMFC\LIB; $env:VCINSTALLDIR\LIB;$env:VCINSTALLDIR\PlatformSDK\lib;$env:FrameworkSDKDir\lib;$env:LIB"

$env:LIBPATH="$FrameworkPath; $env:VCINSTALLDIR\ATLMFC\LIB"

*IMPORTANT: on a 64 bit machine you need to put the first variable ($env:VSINSTALLDIR) to be "C:\Program Files (x86)\Microsoft Visual Studio 8"

I put this in my Profile (“notepad $profile”) so that it loads every time I open PowerShell. You can load the script into your active Shell by “Dot Source” the script:

PS>. $profile

(Notice there is a space between the period and the name of the file).

Now we are ready to consume a web service. The following steps will consume the web service an create local .CS and .DLL files (in your active directory) which you can reuse later to communicate with the service. In this example, I’m getting the “Lists” web service from http://intranet, compiling the Lists.cs file, and then loading the Lists.dll into the shell:

PS>wsdl http://intranet/_vti_bin/Lists.asmx

PS>csc /t:library Lists.cs

PS>[Reflection.Assembly]::LoadFrom("Lists.dll")

The above steps do not need to be repeated (unless the web service code has changed) so you can add the following line to your $profile to always have the web service available (but you should put the full path to the “Lists.dll” file):

[void][Reflection.Assembly]::LoadFrom("Lists.dll")

Now we have the dll loaded (you can browse the .dll file using the .NET reflector to see all the available classes) and we can consume the web service. First we need to create a new “Lists” object:

PS> $list = New-Object Lists

We need to be authenticated to contact the web service, so type:

PS> $list.Credentials=[System.Net.CredentialCache]::DefaultCredentials

Now we are ready to use the web service – so call any member of the $list command to get the service data. The resulting objects can be managed just like any other PowerShell variable, so for example:

PS> $docs = $list.GetLists(“Shared Documents”)

PS> $docs.Title

Shared Documents

PS> $docs.Description

Share a document with the team by adding it to this document library.

PS> $docs.ItemCount

PS> $docs | Select Title,Description,ItemCount

Title Description ItemCount

----- ----------- ---------

Shared Documents Share a document with the team by ad... 27

If you want to know all the methods and properties available off an individual object, use the Get-Member command:

PS> $docs | Get-Member

That’s it! Here’s a list of some of the available web services:

Administration Service : http://<server-url:port-number>/_vti_adm/admin.asmx

Alerts Service : http://<server-url>/_vti_bin/alerts.asmx

Document Workspace Service : http://<server-url>/_vti_bin/dws.asmx

Forms Service : http://<server-url>/_vti_bin/forms.asmx

Imaging Service : http://<server-url>/_vti_bin/imaging.asmx

List Data Retrieval Service : http://<server-url>/_vti_bin/dspsts.asmx

Lists Service : http://<server-url>/_vti_bin/lists.asmx

Meetings Service : http://<server-url>/_vti_bin/meetings.asmx

Permissions Service : http://<server-url>/_vti_bin/permissions.asmx

Site Data Service : http://<server-url>/_vti_bin/sitedata.asmx

Site Service : http://<server-url>/_vti_bin/sites.asmx

Users and Groups Service : http://<server-url>/_vti_bin/usergroup.asmx

Versions Service : http://<server-url>/_vti_bin/versions.asmx

Views Service : http://<server-url>/_vti_bin/views.asmx

Web Part Pages Service : http://<server-url>/_vti_bin/webpartpages.asmx

Webs Service : http://<server-url>/_vti_bin/webs.asmx

Area Service : http://<server-url>/_vti_bin/areaservice.asmx

Query Service : http://<server-url>/_vti_bin/search.asmx

User Profile Service : http://<server-url>/_vti_bin/userprofileservice.asmx

SPS Crawl Service : http://<server-url>/_vti_bin/spscrawl.asmx

Outlook Adapter Service : http://<server-url>/_vti_bin/outlookadapter.asmx

Posted at 2:30 PM by Zach Rosenfield | Category: Random SharePoint Knowledge; PowerShell | Permalink | Email this Post | Comments (3)

10/4/2007

To Dispose, or To Dispose

Yes, I know I got the quote wrong... but hopefully it got your attention.

I really want to spend some time on shear importance of disposing of IDisposable objects. Not disposing of SharePoint objects, most notably the SPWeb and SPSite objects, can lead to extremely big problems when your code is in use.

A quick side note -- even if you are an admin and you don't write code, you should understand this issue. The code that runs on your farms needs to follow the Disposal guidance or you'll be left to pick up the pieces. Make sure you understand the rules of disposal and that you don't deploy code that doesn't.

The Real Issue

So what's the big deal? When code is written that doesn't properly handle the disposal of SPSite and SPWeb objects, there is essentially a large amount of information left in memory for each object opened. This issue is compounded when the code is iterating through a large number of sites -- and in most production environments will take the server down!

An Example

Lets look at this seemingly simple piece of code for iteration that you could put in a web part (before you copy and paste, please don't!). The following code will return the title of all the SPWebs in the active site collection:

Foreach(SPWeb w in SPContext.Site.AllWebs){

_lbl.Text += w.Title;

}

So, lets say you drop this web part into site on your dev farm -- and it prints the name of 10 SPWebs. No big deal, right? Well, the 10 spwebs will sit in memory till the GC comes along. But drop this web part onto a production farm with 100,000 spwebs (not an uncommon case) and every time a user hits this, that front end server will grind to a halt!

So what should you do? The easiest rule to follow -- always use "Using" statements. So the previous would be:

  Using(SPSite s = SPContext.Site){
    for(int i = 0;i < SPContext.Site.AllWebs.Count; i++)
    {
      using(SPWeb w = s.AllWebs[i])
      {
       _lbl.Text += w.Title;
      }
    }

}

This is essentially calling .Dispose() on each web at the end of the loop.

Sounds Easy, Right?

This seemingly small difference is missed all the time in SharePoint code. Every time you access an object, think about what needs to be disposed. For example, if you access a list item -- don't forget that the SPSite and SPWeb that this list item lives in have been opened as well (and you need to call .dispose() on them).

I'm Not Going to let up, and neither should you!

All over the web I see code that fails to mention or properly use disposable objects. I'll be sure to try and call out all the dispose cases I can in my blog -- but be your own policeman. make sure you look for and solve the dispose case in all your code and in all the knowledge you share with others.

Posted at 11:00 AM by Zach Rosenfield | Category: Random SharePoint Knowledge | Permalink | Email this Post | Comments (7)