Verify SP2 Install for MOSS?

Question

I have 12.0.0.6421 showing in Central Admin, which would seem to indicate that SP2 was installed. However, when I run an STSADM command to backup a site collection, I do not see the message informing me that it's "setting the site collection to be-read only for the duration of the backup" as described here:

http://bobfox.securespsite.com/FoxBlog/Lists/Posts/Post.aspx?ID=121

I simply get the "Operation completed successfully" message I used to get pre-SP2. Does this mean that SP2 wasn't installed correctly?

I'm trying to eliminate dangling version tags. SP2 as a tag is useless, because it's not a product (as far as I know, it's something-sp2). Please retag accordingly (Moss-SP2, Sparepoint-SP2, Windows-XP-SP2, whatever seems appropriate). — MPelletier
Many enterprises use MOSS (2007) and have different SP levels for different reasons. SP2 tag is there for a specific reason. Also, if someone using tags in combination to filter a search then this makes sense? — IrishChieftain
I'm not disputing the fact that Moss is widely used. It's simply that SP2 on its own refers to a version, much like 2.0 or 2003 would. It is my understanding that tags are searchable items for technologies or concepts. If users search for Windows-XP-SP2, it's not the same as searching for Moss2007-SP2. Likewise, tags become fields of expertise, and have experts and wiki pages. One can be an expert on c++, moss, moss2007, but hardly on 2.0 or SP2. — MPelletier
I'm no tag overlord, just a guy trying to sort things out and keep things manageable and easy to browse. If you feel I am in error or out of my league, you sir are in your right to wish me a prompt visit to hell. It's just that there's so much haphazard tagging going on that I've started a cleanup effort to correct the issue. With the SP2 tag remaining here, it remains available to new users to use and spread again. — MPelletier

Sean P. McDonough Sean P. McDonough · Accepted Answer · 2009-08-20T02:06:04

Anthony,

Showing a build of 6421 does indeed indicate that SP2 is in-place. Just to make sure, I checked my own farm and VMs as well as a reliable external source (an entry from Todd Klindt's blog: http://www.toddklindt.com/blog/Lists/Posts/Post.aspx?ID=154). I didn't doubt the build number, but it never hurts to confirm :-)

At first, I thought I understood where the issue might be, so I ran some tests. First, I ran an STSADM backup in catastrophic mode to backup my entire farm. Since this isn't a site collection backup, no locking should occur:

stsadm -o backup -directory \\ss-nas3\backups\test -backupmethod full

My catastrophic backup ran without issue, and I didn't receive any message about a lock or read-only behavior. I looked at my ULS logs, as well, and confirmed that no lock was being established (searching for "sitelock" and "lock"). This was as I expected, as I was doing a catastrophic backup -- not a site collection backup.

Next, I tried a site collection backup:

stsadm -o backup -url https://www.sculpted-system.com/pictures -filename \\ss-nas3\backups\test\SiteCollectionBackupTest.bak

Strangely enough, I didn't see a locking message here, either. I took a look at the ULS logs, and I saw nothing to indicate that a lock was put in place. Finally, I performed an

stsadm -o getsitelock ...

... while the backup was running and was greeted with this:

<SiteLock Lock="none" />

ARGH! That's not what I wanted (or expected) to see! Clearly, there was a problem ... so, I tried coming at it from a different angle. I took a look at the MSDN documentation for the STSADM -o backup command, and it clearly indicated that a lock should occur by default. It also indicated that the -nositelock switch should work to override the behavior. So, I tried adding -nositelock to my site collection backup command line.

Guess what: it choked on -nositelock with a command line error (invalid parameter).

Doing an STSADM -help backup indicated that -nositelock was not a valid switch for my environment. None of the new switches I expected (e.g., -nositelock and -force) were present. It's as if my production farm was stuck in pre-SP2 with regard to backups.

I decided to check a development VM I had that was also build 6421 (but different image -- amongst other things, Win2K8 instead of Win2K3 R2), I saw that the -nositelock was a valid command line option. So I checked another development VM that was also build 6421 (but Win2K3 R2 like my "regular farm"). -nositelock was a valid option there, too.

I had applied SP2 the same across all three environments when upgrading (WSSv3 SP2 bits, following by MOSS 2007 SP2 bits, followed by a run of the configuration wizard), so I wasn't sure what was going on.

For fun, I ran a site collection backup on each of the VMs that correctly displayed that -nositelock was a valid command line switch for site collection backups, and I was met with the locking message I didn't see earlier (and that you weren't seeing, either). Clearly, the SP2 updates were operating as I expected them to everywhere except my primary (production) farm.

I concluded I must have somehow done something wrong as part of upgrading my farm, so I tried re-running the WSSv3 SP2 update (first) and MOSS 2007 SP2 update (second) on each box. With each update on each box, I was told the that the update had already been applied. So, I dropped back and punted: I re-ran the configuration wizard to see if it would do anything. I then rebooted the two (virtual) boxes in the farm.

No change.

At this point, I can only confirm that you aren't losing your mind. Two of my all-in-one development VMs with SP2 build 6421 operate as expected, but my two-server/VM farm that is build 6421 that should be locking on site collection backup is not.

I think I'll probably follow up with a friend who is a Microsoft TAM. If I learn anything, I'll post it here and probably on my blog. In the meantime, you might want to follow up with Microsoft, as well. Clearly, something isn't working as expected.

For what it's worth!

Verify SP2 Install for MOSS?

3 Answers