As we painfully discovered this month, if you’re getting DB sync errors, (Event ID 5555, 5553) you cannot detach, and reattach to resolve the sync problem.

Basically what we discovered was with most stsadm commands there is an option -hostheaderwebapplicationurl, which does not exist for stsadm -addcontentdb.

After opening a ticket with Microsoft, we did the following to resolve our database sync problems.

1. stsadm -o sync deleteolddatabases 1

2. Restarted the timer service on all servers in the farm.

So anyway, if you go the other route of:

stsadm -o preparetomove

stsadm-o deltecontentdb

stsadm -o addcontentdb

And you have host based site collections residing in their own database you will have no means of reattaching them.  I spent several hours in a support call with Microsoft in the middle of the night trying to get these reattached, and ultimately had to rebuild the affected sites, and restore from backup.

Here’s a Powershell script I’ve managed to piece together that will output all Site Collection Owners (Not Site Collection Administrators) into either a csv or xml file.  In our SharePoint deployment we’re more of a service provider, hosting multiple web applications each containing one to many site collections, and we were looking for an easy way to determine who the site owners were for every site so that we could send notification prior to maintenance windows etc.  I’ve been working on this in my spare time over the past few weeks, feel free to leave any suggestions, I know it’s a bit convoluted.

#Generates a list of all site collections across all Web Applications,
#and outputing them into an array

$sitepath = New-Object System.Collections.ArrayList
$output=stsadm -o enumzoneurls
$x=[xml]$output
$x.ZoneUrls.Collection|
foreach-object -process {$y=stsadm -o enumsites -url $_.Default;$sites=[xml]$y;$sites.Sites.Site}|
foreach-object -Process {$sitepath=$sitepath + $_.Url}
$sitepath | Write-Output

#Define Output file, and labels

$filename = AllSiteUsers.csv
Write-Output “Site Collection,Title,Group,UserID,Email Address” | Out-File $filename -Append

#Loops through all site collections generating a list of Site Owners

[System.Reflection.Assembly]::LoadWithPartialName(”Microsoft.SharePoint”)
foreach ($object in $sitepath) {
$site=new-object Microsoft.SharePoint.SPSite($object)
$web=$site.Rootweb
$groups = $web.groups | ? {$_.Name -match “^.*Owners” }
foreach($group in $groups)
{
foreach($user in $group.users)
{
Write-Output “$($object),$web,$($group.Name),$user,$($user.Email)” | Out-File $filename -Append
$user
}
}}

#Converts the csv ouput to XML

Import-Csv AllSiteUsers.csv | Export-Clixml AllSiteUsers.xml

I take no credit for this, I found it at SearchMarked.com posted by hstagner.

Basically all you need to do is create a batch file that calls your Powershell script and schedule the batch file.  Your batch file should contain something similar to the following:

powershell -command "& 'MyScript.ps1' "

I take no credit for this, I found it at Kirk Hofer’s blog, and thought I would share it as well.

######################################################################
#Assumptions:
#-Running on machine with WSS/MOSS
#-C:\Program Files\Common Files\Microsoft Shared\web server extensions\12\BIN in path
######################################################################

function get-webpage([string]$url,[System.Net.NetworkCredential]$cred=$null)
{
$wc = new-object net.webclient
if($cred -eq $null)
{
$cred = [System.Net.CredentialCache]::DefaultCredentials;
}
$wc.credentials = $cred;
return $wc.DownloadString($url);
}

#This passes in the default credentials needed.  If you need specific stuff you can use something else to
#elevate basically the permissions.  Or run this task as a user that has a Policy above all the Web Applications
#with the correct permissions
$cred = [System.Net.CredentialCache]::DefaultCredentials;
#$cred = new-object System.Net.NetworkCredential(“username”,”password”,”machinename”)

[xml]$x=stsadm -o enumzoneurls
foreach ($zone in $x.ZoneUrls.Collection) {
[xml]$sites=stsadm -o enumsites -url $zone.Default;
foreach ($site in $sites.Sites.Site) {
write-host $site.Url;
$html=get-webpage -url $site.Url -cred $cred;
}
}

We’ve been working condensing the number of web applications that we’re hosting, and have turned to Host Header based site collections.  Doing so over http is quite simple, but since we only host sites via SSL I ran into a few things that I couldn’t really find documented anywhere, and thought I’d share.

The first thing we discovered is that if you use a random port when creating your Web Application you will receive the following error every time you try to create a host header site collection:

“The port specified for the new host header site does not match any known bindings in the specified Web Application.  The new site will not be accessible if the Web Application is not extended to an IIS Web Site serving this port.”

This being said the host header site collection works, but if you try to restore content to it you receive the same error.  What I found was that if you create your web application as http://site.myurl.com:443 and then change the alternate access mapping setting the default to https://site.myurl.com and intranet as http://site.myurl.com:443 you can create any number of host header based site collections error free.

Once your web application is created, creating the host header based site collection is quite simple, you just run the following:

Create Site

stsadm -o createsite -url https://hosted1.myurl.com -ownerlogin DOMAIN\username -owneremail username@myurl.com -sitetemplate STS#1 -hostheaderwebapplicationurl https://site.myurl.com

Create Site in New DB

stsadm -o createsiteinnewdb -url https://hosted1.myurl.com -ownerlogin DOMAIN\username -owneremail username@myurl.com -sitetemplate STS#1 -hostheaderwebapplicationurl https://site.myurl.com -databaseserver sqlsrv.mydomain.com -databasename WSS_Content-HHSite1

Note: you can use either -hostheaderwebapplication or -hhurl for the switch, both work, but currently (with SP1 installed) if you do a stsadm -help createsite it comes back with -hostheaderwebapplicationurl as the switch.

Once the site collection has been created, you now need to setup the SSL host header.  This is rather simple as well, you just open a command prompt and navigate to C:\inetpub\adminscripts (or wherever you’ve placed your inetpub directory) and run the following command:

adsutil.vbs set /w3svc/[identifier]/SecureBindings [IP address]:443:[host header name]

So in example above of having the web app as site.myurl.com and the hosted site as being hosted1.myurl.com. you’d run the following:

adsutil.vbs set /w3svc/123456789/SecureBindings 192.168.1.10:443:site.myurl.com 192.168.1.10:443:hosted1.myurl.com

Note: You seperate each host header with a space.

You also need to ensure that you have a wildcard cert applied to IIS vserver that will cover all Host based site collections that you’re hosting on the associated web application.

Farm Preparation

Before you can successfully backup and restore via the catastrophic backup/restore method you must ensure that your Alternate Access Mapping for the Default is set to the http://url:randomport, as seen below.

Note: This is required if you have multiple Web App’s utilizing SSL, but seems to work fine without doing this if you only have a single Web App.

Backup the IIS Metabase

Logon to the each of the WFE’s as the Farm Admin/Setup User account and run the following command to backup the IIS metabase:

iisback.vbs /backup /e <PASSWORD>

Catastrophic Farm Backup

Now we’re ready to perform the catastrophic farm backup. You can do this one of two ways, either via STSADM as so: stsadm.exe –o backup –directory <UNC Path> -backup full (example stsadm.exe –o backup –directory \\ServerName\ShareName -backupmethod full)

Or you can perform the backup via Central Admin’s Operations tab as shown below:

Insure to check ‘Farm’ which should highlight and check everything, and then click ‘Continue to Backup Options’.

Select ‘Full’, and then enter the UNC path of your backup location and click ‘OK’.

Remove SharePoint Servers from the Farm

Once the backup is completed, you are ready to remove all the servers from the farm, remove each server one at a time, removing the server that hosts Central Admin last via the ‘SharePoint Products and Technologies Configuration’ wizard.

Create a New SharePoint Farm

1. Starting with whatever server will host Central Admin, create a new farm using the ‘SharePoint Products and Technologies Configuration’ wizard. During the setup make sure you name the SharePoint Config database something different, because when you attempt to restore the entire farm, it will not allow you to overwrite and existing database. Also, choose the same port for Central Admin as you used previously for http access.

2. Add all remaining servers to the farm one at a time.

Now that all servers are in the farm, there are few steps you must complete prior to restoring the farm backup. The following services must be started on the appropriate servers, Excel Calculations Services, Office SharePoint Server Search, and Windows SharePoint Services Search.

1. Start Excel Calculations Services.

2. Start Office SharePoint Server Search, like so:

3. Now you need to start the Windows SharePoint Services Search like so:

Note: You need to use a different name for the Search Database than what was used previously.

4. You may now start any other services on which ever servers you would like, but it is not needed at this point. These three must be completed in order run the restore.

Restore From Farm Backup

You can either restore via stsadm with the following command:

stsadm.exe –o restore –directory <UNC Path> -restoremethod new

Ex: stsadm.exe –o restore –directory \\ServerName\ShareName -restoremethod new

Or if you’re restoring to a new database server/instance:

Stsadm –o restore –directory <UNC Path> -restoremethod new –newdatabaseserver <servername>

Ex: stsadm.exe –o restore –directory \\ServerName\ShareName -restoremethod new -newdatabaseserver mysqlserver.mydomain.com

You can also use Central Admin, which I highly recommend if you’re restoring to a new database server/instance, simply because you can verify every setting before continuing, as you’ll see below.

1. From the Operations tab of Central Admin, select ‘Restore from Backup’.

2. Enter the UNC path to the backup, and click ‘OK’.

3. Select the backup that you’d like to use, and then click ‘Continue Restore Process’.

4. Check ‘Farm’, which should check and highlight everything, and then click ‘Continue Restore Process’.

5. From this screen, you define the Login name and passwords for all of the Application Pools, as well as Web App URL’s, Database Server, database name, and db directory. There are three sections to this screen.

a. The fist, make sure that ‘Farm’ is selected, and that ‘New Configuration’ is selected.

b. The next section can be quite long depending on how many application pools you have. Here you need to verify the username and password for each application pool, like so.

c. Finally, you need to verify all URL’s, database server names, database names, and database file locations, and make any necessary changes.

6. Once you’re comfortable that all the information is correct click ‘OK’, and wait for the restore to complete.

Once the restore completes successfully there are a couple additional tasks you have to complete manually before your SharePoint farm will be ready for user access.

1. Set all of your Alternate Access Mappings. The restore only restores the Default mapping, so if you had any additional mappings you will have to manually add them like so:

2. Now you need to configure which IP address each IIS vserver will listen on, as well as add the necessary Cert if the site will use SSL.

3. Finally, for all sites that use SSL you will have to run the following command:

adsutil.vbs set /w3svc/[identifier]/SecureBindings “[IP Address]:443:[host header name]“

example: adsutil.vbs set /w3svc/1234567890/SecureBindings “192.168.1.10:443:wa1.mydomain.com”

At this point your farm should be completely functional.

I thought I’d blog this list since this seems to be quite difficult to find.

GLOBAL#0 = Global template

STS#0 = Team Site

STS#1 = Blank Site

STS#2 = Document Workspace

MPS#0 = Basic Meeting Workspace

MPS#1 = Blank Meeting Workspace

MPS#2 = Decision Meeting Workspace

MPS#3 = Social Meeting Workspace

MPS#4 = Multipage Meeting Workspace

CENTRALADMIN#0 = Central Admin Site

WIKI#0 = Wiki Site

BLOG#0 = Blog

BDR#0 = Document Center

OFFILE#0 = Records Center

OFFILE#1 = Records Center

OSRV#0 = Shared Services Administration Site

SPS#0 = SharePoint Portal Server Site

SPSPERS#0 = SharePoint Portal Server Personal Space

SPSMSITE#0 = Personalization Site

SPSTOC#0 = Contents area Template

SPSTOPIC#0 = Topic area template

SPSNEWS#0 = News Site

CMSPUBLISHING#0 = Publishing Site

BLANKINTERNET#0 = Publishing Site

BLANKINTERNET#1 = Press Releases Site

BLANKINTERNET#2 = Publishing Site with Workflow

SPSNHOME#0 = News Site

SPSSITES#0 = Site Directory

SPSCOMMU#0 = Community area template

SPSREPORTCENTER#0 = Report Center

SPSPORTAL#0 = Collaboration Portal

SRCHCEN#0 = Search Center with Tabs

PROFILES#0 = Profiles

BLANKINTERNETCONTAINER#0 = Publishing Portal

SPSMSITEHOST#0 = My Site Host

SRCHCENTERLITE#0 = Search Center

SRCHCENTERLITE#1 = Search Center

SPSBWEB#0 = SharePoint Portal Server BucketWeb Template

This month I’d like to discuss a few things we’ve learned over the past year while trying to deploy MOSS 2007.

Our SharePoint deployment is more of an ASP model; each business unit that utilizes our SharePoint deployment wants their own unique URL. One of the things that we’ve discovered is when you create a Web App, (and create a new application pool for the web app) MOSS doesn’t give the application pool the appropriate permissions on the SharePoint Servers, which leads to a series of DCOM errors in the event log (Event ID 10016), to resolve this issue we’ve done the following.

• Add the application pool account to the local WSS_WPG group on each SharePoint server.
• Also, you need to Add the WSS_WPG group to the ‘IIS WAMREG admin Service’ in ‘Component Services’ browse to ‘Computers/My Computer/DCOM Config’ right click, go to properties, and click edit under ‘Launch and Activation Permissions’ add the account, and give ‘Allow’ to ‘Local Launch’, ‘Remote Launch’, ‘Local Activation’, and ‘Remote Activation’.
• You can either follow this route, or explicitly add each individual application pool account to the IIS WAMREG admin Service.
• Also, in our installation, we’ve removed anonymous access from the ‘Access this computer from the network’ in the local security policy, if you do the same, then you will either need to allow the WSS_WPG group, or the individual application pool accounts to this as well.

Setting up Host Header for SSL, this is another one that took a bit of research. Ultimately what we found was that there is a vb script in the Inetpub/AdminScripts directory called adsutil.vbs which allows you to define the host header for the site. You simply run the following command:

• adsutil.vbs set /w3svc/[identifier]/SecureBindings “IP:443:[host header name]“

So for example you’d run:

Adsutil.vbs set /w3svc/123456789/SecureBindings “192.168.1.10:443:mysharepointsite.com”

The [identifier] is the unique IIS Id of the virtual server.

We’ve also run into some crawling issues. Our WFE’s sit behind a hardware based load balancer (Cisco CSM). Currently our load balancer will not allow traffic to pass from behind it and then back in again. So basically when SharePoint tries to do a crawl, it does a DNS query for all of the SharePoint sites it needs to crawl. It then updates the HOSTS file with that information. So then when it attempts to do a crawl it tries to crawl via the Load Balanced IP address instead of the local address, which in turn our Load Balancer won’t allow. In order to work around the issue, we had to edit the HOSTS file on all of our SharePoint servers and add all of our URL’s with the actual local IP address instead, and then set it to read only otherwise every time SharePoint attempted to do a crawl it would overwrite our manual changes. Of course now we get hundreds of errors a day in the event log because SharePoint can’t edit the HOSTS file, go figure.

On a positive note, we’ve managed to resolve our SP1 issues, though not by actually fixing the problem. After 5 failed attempts based on Microsoft supports recommendations, we decided to completely rebuild the farm, and restore all the content manually. At the same time we migrated to 64bit hardware. We circumvented the SP1 issues by slipstreaming SP1 into our WSS/MOSS and Project 2007 installs.