Sign In
 
Categories
General Talk
Random SharePoint Knowledge
SharePoint Administration
SharePoint 101
PowerShell
Other Blogs
SharePoint Team Blog
Get to the Point
Jason Cahill's Blog
Links
Photos
Archive
Script Library
Master Page CSS Guide
Master Page Elements Guide
 
Go Search
 

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 99795c10c99c756bcbaf97468e327dc4 | Category: SharePoint 101; Random SharePoint Knowledge; SharePoint Administration | Permalink | Email this Post | Comments (1)

3/19/2009

SharePoint 101: Full Width Rich Text Editor
It can be a little frustrating in SharePoint when the "Rich Text Editor" on the edit page of Wiki's, Blogs, or on certain lists is set to fixed column width.  I certainly find it easier to blog in a fullscreen-width editor!
 
Here's the CSS to make it happen (warning, this syntax applies to ALL rich text editors!).   The first does all normal forms and wikis:
 
#onetIDListForm, #onetIDListForm .ms-formbody, #onetIDListForm iframe[title="Rich Text Editor"]{
 width:100% !important;
}
 
And this does the same for Blogs!

.ms-formbody span span div iframe, .ms-formbody span span table.ms-long{
 width:100%; text-align:left;
}

Hope this helps.
Posted at 4:09 PM by 99795c10c99c756bcbaf97468e327dc4 | Category: SharePoint 101 | Permalink | Email this Post | Comments (5)
Your Comments
Many people are leaving comments--and I'm having a hard time finding them! I get hundreds of "Spam" comments a day, so i'm having to filter through them to find the real ones...  I'm working on a fix, but it might take a while.
 
-Zach
Posted at 10:59 AM by 99795c10c99c756bcbaf97468e327dc4 | Category: General Talk | Permalink | Email this Post | Comments (1)

3/13/2009

SharePoint 101: Styling the Site Actions menu

This is a quick one... I wanted to share a "SharePoint 101" tip: Styling the Site Actions Menu.

Here's what i started with--you can tell that the site actions menu (with its Out-Of-The-Box style) wasn't going to work for me:

I wanted something simpler that matches the "welcome" screen! So for starters, i removed the background from the container div:

.ms-siteactionsmenu div div div{
     background:transparent !important;
}

Notice the "!important".  This is so that I can override the inline styles on the control (get ready for a few more of them).  Next I remove the border from this same div:

.ms-siteactionsmenu div div div{
                background:transparent !important;
     border:1px solid transparent !important;
}

So--Getting Better!

Note that I leave the 1 pixel 'transparent' border so that when I show a border on hover I don't get a funky "resize" behavior.  So, on that note--let's add the "hover" behavior:

.ms-siteactionsmenu div div div.ms-siteactionsmenuhover{

     background: green !important;

     border:1px solid white !important;

}

 

On hover now looks like this:

 

 

Simple and clean! To finish it off, I similarly set the Welcome to the same hover style:

.ms-siteactionsmenu div div div.ms-siteactionsmenuhover, .ms-SpLinkButtonActive{

     background: green !important;

     border:1px solid white !important;

}

 

Posted at 10:42 AM by 99795c10c99c756bcbaf97468e327dc4 | Category: SharePoint 101 | Permalink | Email this Post | Comments (1)

2/11/2009

SharePoint+PowerShell is (Usually) a Perfect Match

Today I’m posting about a rather dense technology issue—so please bear with me!  Those of you who read my blog know that I am a huge fan of PowerShell and on occasion talk about various ways to use PowerShell for managing SharePoint deployments.  Additionally I’ve seen projects and people around the web discuss it.  However, it wasn’t until learning about some of the most in-depth inner-workings of PowerShell did an important realization come about.  In short: There was a potential for PowerShell users to constantly leak memory without knowing it!  While this is not a common situation and it would be hard to do so in such large volume to really cause real harm—it is possible, and thus, everyone should know about it.

 

So first, what’s the issue?  Well, first of all it is important to know that SharePoint does an amazing amount of work in relation to the SPSite and SPWeb objects to make sure that they are running for optimal performance—which in terms of native code means working to improve memory allocation.  Thus there is some special code in these objects, but this also comes with some unique requirements—one that should not be new to SharePoint developers: the need to Dispose of these objects.  So what’s changed you ask?  Well—did you know that SPSite and SPWeb objects should never be used across threads?

 

Usually this is not important.  Multiple threads can safely access the same SPSite or SPWeb simultaneously, so there’s no reason for a developer to open a reference to one of these objects and pass it to another thread.  However, if you did try this, the unmanaged Heap (which is thread specific) will be “lost” and a new Heap will be allocated in the new thread.  So if you did this endlessly your machine will eventually run out of memory (though this memory is freed if you close the PowerShell process).

 

So on to the specific PowerShell concern.  I only recently learned that every time a new ‘pipe’ in PowerShell is executed (essentially every time you press ‘enter’), that command is run in a unique thread.  So what does this mean for SharePoint?  Well, it means that saving an SPSite or an SPWeb to a variable will cause memory leaks—no matter what you do. 

 

As an example, let’s take the following syntax:

 

PS>  $S = New-Object Microsoft.SharePoint.SPSite(“http://sharepoint”)

PS>  $S.Title

My SharePoint Site

PS> $S.Dispose()

 

Looks fine, right?  Unfortunately, since each “PS>” line is executed in a new thread, the final $S.Dispose() does not dispose of the unmanaged heap (before you go try to prove me wrong, realize that the managed code is properly disposed—so you will recover some memory).

 

Well, as it turns out this is a simple problem to mitigate.  Since each PowerShell ‘sentence’ is run in a single thread, any loaded function or script is run as a single thread!  So while the syntax above was not healthy, the exact same lines of code run in script work fine.  Or even this is line works great:

 

PS>  $S = New-Object Microsoft.SharePoint.SPSite(“http://sharepoint”);  $S.Title; $S.Dispose()

 

Keep your eye out on this blog for other potential workarounds in the future. 

 

With that in mind, happy scripting!

 

Zach Rosenfield
Program Manager, Microsoft Office SharePoint Server

Posted at 12:57 PM by 99795c10c99c756bcbaf97468e327dc4 | Category: PowerShell; SharePoint Administration | Permalink | Email this Post | Comments (3)

2/9/2009

SharePoint Administration Toolkit v3 is Available
If you haven't already, be sure to check out the 3rd release of the SharePoint Administration Toolkit.  In the latest kit we've introduced the SPDiag tool which provides a simple interface for collecting and analyzing SharePoint Data.
 
More details in the SharePoint Team Blog Post.
 
Download Links:
 
  • Microsoft SharePoint Administration Toolkit v3.0 x86: http://go.microsoft.com/fwlink/?LinkId=141504
  • Microsoft SharePoint Administration Toolkit v3.0 x64: http://go.microsoft.com/fwlink/?LinkId=142035
    • Posted at 9:21 AM by 99795c10c99c756bcbaf97468e327dc4 | Category: SharePoint Administration | Permalink | Email this Post | Comments (0)

    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 99795c10c99c756bcbaf97468e327dc4 | Category: SharePoint Administration; Random SharePoint Knowledge | Permalink | Email this Post | Comments (5)

    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 (15)

    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 (4)

    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)
    1 - 10 Next

     ‭(Hidden)‬ Admin Links
     
     
      This blog is powered by Microsoft Office SharePoint Server 2007