Configuration - From The Field

9/11/2009

Back in SharePoint 2007 Service Pack 1, a new command “stsadm –o mergecontentdbs” was released to help administrators move a site collection from one content database to another. (Despite its name it doesn’t actually merge content databases, just moves the data from one content database to another.) This was fine as long as the size of the site collection being moved was not too big.

It might take several hours to perform the whole move for a large site collection. Plus if for any reason the job crashed out during its run you could be left with orphans in either of your content databases or neither of them in working state. See http://support.microsoft.com/kb/969242/ for more information.

Recently I helped a customer upgrade their SharePoint system to SP2 with the June 09 Cumulative Update and once this was done, to move a 20Gb site collection to a new content database.

The move worked correctly and the “stsadm –o mergecontentdbs” command returned without error. Looking in the new content database I could see the data and an entry in the “sites” table which showed that this contentdb did in fact contain the moved site collection. Looking in the old contentdb at its “sites” table indeed showed that the site collection was gone.

So what was the problem?

It became clear that once the move was over, we were unable to shrink the size of the old content database. It still contained over 20Gb of data and I had no idea why it was still there.

Running a “stsadm –o databaserepair” command against the old content database showed 1000’s of orphans and upon closer inspection these where all individual sites (SPWeb objects) which had been part of the moved site collection. Running “stsadm –o databaserepair” this time again with the “-deletecorruption” switch did the job of removing the orphans after which we could shrink the old content database.

Therefore it would seem that the way the “stsadm –o mergecontentdbs” command works between SP1 and SP2 + June 09 CU seems to have changed. Indeed it seems to deliberately create orphans as part of the move.

After speaking to some of the guys on my team (hat tip to Andy D) the following blog posting came to light from the team at Microsoft who maintains the documentation you see on TechNet.

http://blogs.technet.com/tothesharepoint/archive/2009/05/21/3244169.aspx

It makes mention of the way the mergecontentdbs command was changed in the April 09 Cumulative Update and that it is now the default behaviour to leave the data in the old content database and rely on a new timer job to delete the data automatically in the background. The role of this job is to simply clean up orphans of a particular type which are generated as part of the call to mergecontentdbs.

In summary: Systems which have at least Service Pack 2 and the April 09 Cumulative Update will by default rely on a timer job to remove data from old content databases when the “stsadm –o mergecontentdbs” command is used to move a site collection from one database to another.

Posted at 3:20 AM by David Little | Category: Administration; Configuration; General; SP2; SP1; stsadm; Troubleshooting | Permalink | Email this Post | Comments (0)

9/9/2009

Create Managed Properties - The Easy Way

OK, so I got to publish another script to the SharePoint Management PowerShell scripts project - this one is called Set-ManagedProperty. Does exactly what the name suggests - allows you to automate creation of managed properties in Search configuration and mapping them onto crawled properties.

You may find this especially useful if you are planning to install Podcasting Kit for SharePoint (or have to re-build it regularly). One of the most tedious steps in the installation and configuration of PKS has always been having to create over a dozen of managed properties - now all you have to do is download and run this script, as it even defaults to properties required by PKS if given no other input!

Posted at 4:16 AM by Sergey Zelenov - MSFT | Category: Configuration; PowerShell; Search | Permalink | Email this Post | Comments (0)

4/29/2009

A Common Alternate Access Mapping (AAM) Mistake Revisited....

A question often asked when exposing an internal site out to the Internet is, "why do I have to extend my original web app into a new zone with an intermediary internal URL to publish to a public URL, can't I simply add a public URL to a new zone for the already existing web app?"

The answer is no as described in mistake #3 in the Plan alternate access mappings article.

In short, if a web application was created with a host header then IIS will only listen on that host header and the request for the new URL will never get to SharePoint. The recommended approach would be to make the web application listen on a different URL by extending the web application into a different zone which creates a second IIS site and provides the opportunity to configure a host header for the extended site to listen on (this would form the internal URL, and a public URL in the same zone should be defined).

Although technically speaking, if a host header wasn't defined when the web application was originally created, and IIS was blindly listening on port 80 this wouldn't be a problem and we could simply add a public URL in the same zone as the original web application.....so we may believe.....

Whilst a fellow PFE was onsite with a customer, some strange behaviour in SharePoint was experienced.

The customer was reporting that even though they had multiple web applications serving content and that all the web applications were hosted under their own application pools, only one w3wp.exe process was on each of their web front end servers.

We had initially thought that this was because of their AAM configuration, as they had entries pointing to specific servers. In other words, we thought we would find that only certain servers would have multiple w3wp.exe processes as the AAM redirected the users to a specific server and not to NLB.

However, after digging into AAM, DNS name resolution, application pool configuration and so on, it turns out that in fact, only one w3wp.exe process was serving content for all the web applications in the environment.

The following diagram explains the configuration of web applications, worker processes, AAMs and Content DBs in the environment:

The problem was that although users were hitting content hosted on WEB APPLICATION 2 we could only see 1 w3wp.exe process with PID (6148). That worker process corresponded to WEB APPLICATION 1, not WEB APPLICATION 2 – Don’t get me wrong, users were requesting data from WEB APPLICATION 1, but they were also requesting data from CONTENT DB 2 which was attached to WEB APPLICATION 2.

Long story short, it turns out that the AAM mapping for WEB APPLICATION 2 (INTERNET ZONE) was created in the AAM page. They never extended the web application to use the loadbalancedurl2.net address. They just created the new zone via AAM page. Because it was never extended, when the client resolved the loadbalancedurl2.net address from WEB APPLICATION 2, the address was resolved to their WFEs IP address, but IIS would accept the request via the website on PORT 80 (http://loadbalancedurl2.net:80) – which corresponds to WEB APPLICATION 1. This essentially meant that WEB APPLICATION 1, listening on port 80 was accepting all requests from users that used the load balanced URLs for all the web applications in the environment.

WSS_Content2 is only actually served thanks to the absence of host header on WEB APPLICATION 1 thus permitting PID 6148 to receive all incoming requests on port 80 and route as “best effort”. And as you may have guessed by now, this only works because both web applications are using an application pool with the same login. If each web application’s application pool had a unique login, then WEB APPLICATION 1 would not be able to access the content database for WEB APPLICATION 2 and vice versa.

As outlined in the second paragraph of this post, the proposed resolution and recommended approach would be to have an extension of each of the applications into another zone, ideally having hostheader mapped to public url (or whatever it might be http://mossserver:85 in this case), if the reverse proxy device exposing the web application is NOT forwarding the host header. This will isolate user / proxy traffic on a specific process and no longer serve the multiple Content DBs through the single web application.

Many thanks to Leandro Iacono for the useful customer example.

Posted at 1:14 AM by samhassa | Category: Administration; Authentication; Central Administration; Configuration; General; IIS; Permissions; Security; Troubleshooting | Permalink | Email this Post | Comments (0)

12/30/2008

Awesome article on Central Admin High Availability and Security - too good to miss

We try to keep our material on this blog as original as possible but sometime a post comes along elsewhere that is simply too good not to mention.

Spence Harbar has posted on Central Admin high availability, load balancing, security and other recommendations. If you want something good to read in the new year make this your first port of call.

http://www.harbar.net/articles/spca.aspx

Happy holidays everyone.

Posted at 4:42 PM by Neil Hodgkinson | Category: Configuration; Central Administration | Permalink | Email this Post | Comments (0)

12/9/2008

Adobe release 64-Bit PDF iFilter

Adobe have finally released a 64-Bit version of their PDF iFilter which is compatible with MOSS 2007, this can be downloaded from the following site - http://www.adobe.com/support/downloads/detail.jsp?ftpID=4025

This page also includes installation instructions.

Posted at 10:44 AM by Brendan Griffin | Category: Configuration | Permalink | Email this Post | Comments (0)

12/3/2008

Changing a web application URL and dealing with requests for the old URL

I recently had a discussion with a customer who was planning on changing the URL of their MOSS 2007 Intranet Web application. This is generally a straightforward procedure that is easily achieved either by amending the alternate access mapping configuration of the web application in question OR extending the web application into a new zone. The customer was comfortable with this and had a plan in place for this change. In this particular case the customer wanted to change the URL from http://sharepoint.company.com to http://intranet.company.com

The customer was particularly concerned about the the myriad of links that end users had to content that was held in Internet Explorer favorites’ and embedded in work documents that referenced the old URL - http://sharepoint.company.com and they wanted to put a mechanism in place that would automatically redirect end users to the new URL when a link that referenced the old URL was selected.

For example a user could click a link that referenced a site collection named Marketing using the URL http://sharepoint.company.com/sites/marketing they wanted this to be automatically redirected to http://intranet.company.com/sites/marketing.

This objective was easily achieved using a redirect site in IIS 6.0 and involved the following steps.

· Creating a new website in IIS on each WFE in the farm using the default application pool as it has no need to communicate with any component of MOSS 2007.

· Configuring the redirect site to listen on the host header sharepoint.company.com (it's important the MOSS 2007 specific configuration changes are performed prior to this to avoid any conflicts in IIS)

· Selecting the Home Directory tab of the properties of the redirect site and selecting the following settings, this not only redirects the host name portion of the URL but also the path within the URL :) using the $S and $Q variables. A full reference on these variables can be found at - http://www.microsoft.com/technet/prodtechnol/WindowsServer2003/Library/IIS/41c238b2-1188-488f-bf2d-464383b1bb08.mspx?mfr=true

Posted at 8:33 AM by Brendan Griffin | Category: Configuration; IIS | Permalink | Email this Post | Comments (0)

11/6/2008

Configuring Usage Analysis Processing using stsadm

I ran into a problem recently when attempting to enable and configure Usage Analysis Processing (UAP)using stsadm, I needed to do this as part of a fully scripted installation of MOSS 2007 that I was assisting a customer with. Looking at the stsadm documentation, the following commands are available:

stsadm -o setproperty

-propertyname usageprocessingenabled

-propertyvalue {Yes | No}

stsadm -o setproperty

-propertyname job-usage-analysis

-propertyvalue {Yes | No}

I then ran the following two commands to configure UAP:

stsadm -o setproperty -pn job-usage-analysis -pv "daily between 08:00 and 09:00" To configure the time that the process runs.

stsadm -o setproperty -pn usageprocessingenabled -pv "Yes” To enable Usage Analysis Processing.

However when I browsed to Central Administration – Operations – Usage analysis processing the following was displayed L

If you look closely you can see that the time has been set correctly but it hasn’t enabled usage analysis processing. As you can see this is grayed out meaning that Enable logging must be selected before it can be enabled – but how do I enable logging? After much investigation I eventually found out (from a colleague- thanks Kirk) that the following stsadm can be used to enable this.

stsadm -o setproperty -pn loggingenabled -pv "Yes”

To put this all together I need to run the commands in this order to achieve my objective:

· stsadm -o setproperty -pn loggingenabled -pv "Yes”

· stsadm -o setproperty -pn job-usage-analysis -pv "daily between 08:00 and 09:00"

· stsadm –o setproperty -pn usageprocessingenabled -pv "Yes”

Success!

Brendan Griffin

Posted at 8:41 AM by Brendan Griffin | Category: Configuration; stsadm; Usage Analysis | Permalink | Email this Post | Comments (0)

10/21/2008

Running Central Admin on Multiple Servers within a Farm

One of the best practices that the Premier Field Engineering (PFE) team always recommend is to run the Central Administration Web application on multiple servers (at least 2) within the farm. Then if anything happens to one of the servers hosting Central Administration you can still manage MOSS 2007 - the alternative is provision and configure Central Administration on an existing server using stsadm - not a good situation to be in, especially if you desperately need access!

Whilst this is fairly easy to setup either during the Post Setup Configuration GUI, via the command line and even via Central Admin itself (targeted at other servers within the farm though obviously) customers often run into issues when trying to access the second instance of Central Administration.

For example my farm includes three servers:

· Server1 – Web Front End

· Server2 – Web Front End

· Server3 – Application

When I originally created the farm I configured Server1 to host Central Administration (this was the first server that was built) I then built Server2 and choose to host Central Administration on this server too. It was decided that Server3 would be completely dedicated as an application server so Central Administration was not provisioned on this server.

If I look in IIS Manager on Server1 I can see a Web site for Central Administration, listening on port 40000 with no host header, therefore available via the URL http://server1:40000

If I look in IIS Manager on Server2 I can also see an identical Web site listening on the same port, therefore available via http://server2:40000

If I then launch Internet Explorer from my desktop and browse to http://server1:40000 Central Administration is displayed within my browser and I can configure MOSS 2007 as I please!

Now one day I decide that I don’t want to access Central Admin on server1 and would prefer to use server2, so I type http://server2:40000 in my browser and connect to the site – but wait a minute it has redirected me to http://server1:40000 this isn’t very good, what would I do If server1 was unavailable and I needed to access Central Administration!

The behavior that you are seeing is expected and is the default behavior; with a minor configuration change to Alternate Access Mappings (AAM) you can configure Central Administration to be available on both URLs without it doing the pesky re-direct J

To accomplish this you will need to Launch Central Administration and select the Operations tab, then select Alternate Access Mappings from within the Global Configuration section.

In the top right there is an option for Alternate Access Collection, select this and choose the Central Administration Web application.

In my example I then see the following:

As you can see server2 has an entry within the Internal URL section but not within the Public URL for Zone. I won’t bore you with the technicalities of AAM, if you are interested you may find the following useful - http://technet.microsoft.com/en-us/library/cc263521.aspx

To get this to work as expected we need to add a public URL entry for server 2; this can be done as follows:

1. Select Edit Public URLs

2. Add an entry for server 2 – I generally use the Intranet zone and then click Save

3. Alternate Access Mapping should now look as follows

You should now be able to access Central Administration on server1 and server2. One thing to note is that the link within the Start Menu to Central Administration will always point to the first server that Central Administration was installed on, which is the server that was used to create the farm (in my case server1) although this can be changed via the registry.

Brendan Griffin

Posted at 9:01 AM by Brendan Griffin | Category: Configuration; Central Administration | Permalink | Email this Post | Comments (0)

10/20/2008

The SharePoint Update Resource Centre

To help us all make sense of the many SharePoint software updates, there is now a site on TechNet.

http://technet.microsoft.com/en-us/office/sharepointserver/bb735839.aspx

Posted at 3:10 AM by Matt M | Category: Configuration | Permalink | Email this Post | Comments (0)

9/24/2008

Checking User Permissions in a Site Hierarchy

My customer was asking me today about a tool that would show a list of the site collections and all permissions assigned to all groups/users on that site collection.

There is a free tool from Codeplex:

http://www.codeplex.com/AccessChecker

This tool allows you to add a user name and see what access they have at different levels in the site hierarchy.

Access Checker.png