This post covers my SharePoint community activities for the Spring of 2011. There’s quite a bit going on, including back-to-back-to-back SharePoint Saturday events!
It’s turning out to be a very busy Spring – more so than I would have originally guessed (or planned). That’s okay, though: there’s very little else I’d rather be doing than getting out and spending time with the SharePoint community at-large! Spending time with the community also means I’m getting out of my basement, and that’s really good for my Vitamin D levels …
Here’s what I have coming up (or just passed) this Spring:
DBTechCon
The SQL Server Worldwide User Group (SSWUG) recently put on their entirely virtual DBTechCon event. One of the original speakers for the event ended up having to cancel just before the event was due to take place, so the SSWUG folks had a gap and asked if I could fill it. It took some scrambling, but I was able to pull together three sessions for them on a combination of SharePoint disaster recovery (DR) and performance topics.
Although the event has passed, it’s still possible to access the sessions on-demand.
SharePoint Saturday Saint Louis
I’ll actually be heading over to Saint Louis today (Friday, April 29th) for tomorrow’s SharePoint Saturday Saint Louis. My co-author and good buddy John Ferringer and I will be getting the band back together to do our “Saving SharePoint” session on SharePoint disaster recovery.
Like all other SharePoint Saturday events, the event is free to the public. Come on out if you’re in the Saint Louis area for a free day of training, socializing, and giveaways!
SharePoint Saturday Houston
Houston, Texas, will be hosting its SharePoint Saturday Houston event next Saturday on May 7th. I’ll be traveling down to Houston on Thursday for some business-related items, but I’ll be speaking at the event on Saturday. I’ll be giving my “’Caching-In’ for SharePoint Performance” talk – now in Prezi form.
Houston’s SharePoint Saturday event is one of the bigger ones that takes place, and the line-up of speakers is phenomenal. I hope to see you there!
Dayton SharePoint User Group
On the evening of Tuesday, May 10th, I’ll be heading up to Dayton to spend some time with the Dayton SharePoint User Group. I met Tony Maddin (who heads up the group) after a Cincinnati SPUG meeting, and Tony asked if I would come up and speak to the recently formed Dayton SPUG. I jump at just about any opportunity to speak, so on Tuesday the 10th I’ll be delivering a SharePoint DR session to the group.
SharePoint Saturday Michigan
To wrap up the SharePoint Saturday hat trick, I’ll be heading up to Troy, Michigan, for SharePoint Saturday Michigan on May 14th. Peter Serzo and crew are sure to put on another stellar event this year, and I’ll be presenting a session on SharePoint disaster recovery – specifics still unknown. Stay tuned, and be sure to head over to the event on 5/14 if you’re in the area.
SPTechCon
I feel very fortunate to have a spot at the mid-year 2011 SPTechCon event in Boston from June 1st through June 3rd. My session (Session 702) will be on June 3rd from 11:30am until 12:45pm, and I’ll be delivering “SharePoint 2010 Disaster Recovery: New Capabilities, New Possibilities” I’m really looking forward to it, and I hope that I’ll see some of you there!
Having recently recovered from a firewall outage using Windows Server 2008’s bare metal restore capabilities, I figured I’d write a quick post to cover how I did it. I also cover one really big learning I picked up as a result of the process.
I had one of those “aw nuts” moments last night.
At some point yesterday afternoon, I noticed that none of the computers in the house could get out to the Internet. After verifying that my wireless network was fine and that internal DNS was up-and-running, I traced the problem back to my Forefront Threat Management Gateway (TMG) firewall. Attempting to RDP into it proved fruitless, and when I went downstairs and looked at the front of the server, I noticed the hard drive activity light was constantly lit.
So, I powered the server off and brought it back on. Problem solved … well, not really. It happened again a couple of hours later, so I repeated the process and made a mental note that I was going to have to look at the server when I had a chance.
Demanding My Attention
Well, things didn’t “stay fixed.” Later in the evening, the same lack of connectivity surfaced again. I went to the basement, powered the server off, and brought it back up. That time, though, the server wouldn’t start and complained about having nothing to boot from.
As I did a reset and watched it boot again, I could see the problem: although the server knew that something was plugged in for boot purposes, it couldn’t tell that what was plugged in was a 250GB SATA drive. Ugh.
When I run into those types of situation, the remedy is pretty clear: a new hard drive. I always have a dozen or more hard drives sitting around (comes from running a server farm in the basement), and I grabbed a 500GB Hitachi drive that I had leftover from another machine. Within five minutes, the drive was in the server and everything was hooked back up.
Down to the Metal
Of course, a new hard drive was only half of the solution. The other half of the equation involved restoring from backup. In this case, a bare metal restore from backup was the most appropriate course of action since I was starting with a blank disc.
For those who may not be familiar with the concept of bare metal restoration, you can get a quick primer from Wikipedia. I use Microsoft’s System Center Data Protection Manager 2010 (DPM) to protect the servers in my environment, so I knew that I had an image from which I could restore my TMG box. I just dreaded the thought of doing so.
Why the worry? Well, I think Arthur C. Clarke summed it up best with the following quote:
Any sufficiently advanced technology is indistinguishable from magic.
The Cold Sweats
Now bare metal restore isn’t “magic,” but it is relatively sophisticated technology … and it’s still an area that seems plagued with uncertainties.
I have to believe that I’m not the only one who feels this way. I’ve co-authored two books on SharePoint disaster recovery, and the second book includes a chapter I wrote that covers bare metal restore on a Windows 2008 server. My experience with bare metal restores can be summarized as follows: when it works, it’s awesome … but it doesn’t always work as we’d want it to. When it doesn’t work, it’s plain ol’ annoying in that it doesn’t explain why.
So, it’s with that mindset that I started the process of trying to clear away my server’s lobotomized state. These are the steps I carried out to get ready for the restore:
I went into the DPM console, selected the most recent bare metal restore recovery point available to me (as shown on the right), and restored the contents of the folder to a network file share– in my case, \\VMSS-FILE1\RESTORE. Note: you’ll notice a couple of restore points available after the one I selected; those were created in the time since I did the restore but before I wrote this post.
The approximately 21GB bare metal restore image was created on the share. I do have gigabit Ethernet on my network, and since I recently built-out a new DPM server with faster hardware, it really didn’t take too long to get the image restored to the designated file share – maybe five minutes or so. The result was a single folder in the designated file share.
I carried out a little manipulation on the folder that DPM created; specifically, I cut out two levels of sub-folders and made sure that the WindowsImageBackup folder was available directly from the top of the share as shown at the left. The Windows Recovery Environment (or WinRE) is picky about this detail; if it doesn’t see the folder structure it expects when restoring from a network share, it will declare that nothing is available for you to restore from – even though you know better.
In Recovery
With my actual restore image ready to go on the file share, I booted into the WinRE using a bootable USB memory stick with Windows 2008 R2 Server on it. I walked through the process of selecting Repair your computer, navigating out to the file share, choosing my restore image, etc. The process is relatively easy to stumble through, but if you want it in a lot of detail, I’d encourage you to read Chapter 5 (Windows Server 2008 Backup and Restore) in our SharePoint 2010 Disaster Recovery Guide. In that chapter, I walk through the restore process in step-by-step fashion with screenshots.
I got to the point in the wizard where I was prompted to select additional options for restore as shown on the left. By default, the WinRE will format and repartition discs as needed. In my case, that’s what I wanted; after all, I was putting a brand new drive in (one that was larger than the original), so formatting and partitioning was just what the doctor ordered. I also had the ability to exclude some drives (through Exclude disks) from the recovery process – not something I had to worry about given that my system image only covered one hard drive. If my hard drive required additional drivers (as might be needed with a drive array, RAID card, or something equivalent), I also had the opportunity to supply them with the Install drivers option. Again, this was a basic in-place restore; the only thing I needed was a clean-up of the hard drive I supplied, so I clicked Next.
I confirmed the details of the operation on the next page, and everything looked right to me. I then paused to mentally double-check everything I was about to do.
In my experience, the dialog on the left is the last point of easily grasped normal wizard activity before the WinRE restore wizard takes off and we enter “magic land.” As I mentioned, when restores work … they just chug right along and it looks easy. When bare metal and system state restores don’t work, though, the error messages are often unintelligible and downright useless from a troubleshooting and remediation perspective. I hoped that my restore would be one of the happy restores that chugged right along and made me proud of my backup and restore prowess.
I crossed my fingers and clicked the Next button.
<Insert Engine Dying Noises Here>
The screenshot on the right shows what happened almost immediately after I clicked next.
Well, you knew this blog post would be a whole lot less interesting if everything went according to plan.
Once I worked through my panic and settled down, I looked a little closer. I understood The system image restore failed without much interpretation, but I had no idea what to make of
Error details: The parameter is incorrect. (0x80070057)
That was the extent of what I had to work with. All I could do was close out and try again. Sheesh.
Head Scratching
Let’s face it: there aren’t a whole lot of options to play with in the WinRE when it comes to bare metal restore. The screenshot on the left shows the Advanced options you have available to you, but there really isn’t much to them. I experimented with the Automatically check and update disk error information checkbox, but it really didn’t have an effect on the process. Nevertheless, I tried restores with all combinations of the checkboxes set and cleared. No dice.
With the Advanced options out of the way, there was really only one other place to look: the Exclude disks dialog. I knew Install drivers wasn’t needed, because I had no trouble accessing my disks and wasn’t using anything like a RAID card or some other advanced disk configuration.
I popped open the disk exclusion dialog (shown on the right) and tried running a restore after excluding all of the disks except the Hitachi disk to which I would be writing data (Disk 2). Again, no dice – I still continued to get the aforementioned error and couldn’t move forward.
I knew that DPM created usable bare metal images, and I knew that the WinRE worked when it came to restoring those images, so I knew that I had to be doing something wrong. After another half an hour of goofing around, I stopped my thrashing and took stock of what I had been doing.
My Inner Archimedes
My eureka moment came when I put a few key pieces of information together:
While writing the chapter on Windows Server 2008 Backup and Restore for the SharePoint 2010 DR book, I’d learned that image restores from WinRE are very persnickety about the number of disks you have and the configuration of those disks.
When DPM was creating backups, only three hard drives were attached to the server: the original 250GB system drive and two 30GB SSD caching drives.
Booting into WinRE from a memory stick was causing a distinctly visible fourth “drive” to show up in the list of available disks.
The bootable USB stick had to be a factor, so I put it away and pulled out a Windows Server 2008 R2 installation disk. I then booted into the WinRE from the DVD and walked through the entire restore process again. When I got to the confirmation dialog and pressed the Next button this time around, I received no The parameter is incorrect errors – just a progress bar that tracked the restore operation.
Takeaway
The one point that’s going to stick with me from here on out is this: if I’m doing a bare metal restore, I need to be booting into the WinRE from a DVD or from some other source that doesn’t affect my drives list. I knew that the disks list was sensitive on restore, but I didn’t expect USB drives to have any sort of effect on whether or not I could actually carry out the desired operation. I’m glad I know better now.
In this self-described “blog post you should never need,” I talk about finding objects with duplicate GUIDs in a client’s SharePoint site collection. I supply the PowerShell script used to find the duplicate GUIDs and offer some suggestions for how you might remedy such a situation.
This is a bit of an oldie, but I figured it might help one or two random readers.
Let me start by saying something right off the bat: you should never need what I’m about to share. Of course, how many times have you heard “you shouldn’t ever really need this” when it comes to SharePoint? I’ve been at it a while, and I can tell you that things that never should happen seem to find a way into reality – and into my crosshairs for troubleshooting.
Disclaimer
The story and situation I’m about to share is true. I’m going to speak in generalities when it comes to the identities of the parties and software involved, though, to “protect the innocent” and avoid upsetting anyone.
The Predicament
I was part of a team that was working with a client to troubleshoot problems that the client was encountering when they attempted to run some software that targeted SharePoint site collections. The errors that were returned by the software were somewhat cryptic, but they pointed to a problem handling certain objects in a SharePoint site collection. The software ran fine when targeting all other site collections, so we naturally suspected that something was wrong with only one specific site collection.
After further examination of logs that were tied to the software, it became clear that we had a real predicament. Apparently, the site collection in question contained two or more objects with the same identity; that is, the objects had ID properties possessing the same GUID. This isn’t anything that should ever happen, but it had. SharePoint continued to run without issue (interestingly enough), but the duplication of object GUIDs made it downright difficult for any software that depended on unique object identities being … well, unique.
Although the software logs told us which GUID was being duplicated, we didn’t know which SharePoint object or objects the GUID was tied to. We needed a relatively quick and easy way to figure out the name(s) of the object or objects which were being impacted by the duplicate GUIDs.
Tackling the Problem
It is precisely in times like those described that PowerShell comes to mind.
My solution was to whip-up a PowerShell script (FindDuplicateGuids.ps1) that processed each of the lists (SPList) and webs (SPWeb) in a target site collection. The script simply collected the identities of each list and web and reported back any GUIDs that appeared more than once.
The script created works with both SharePoint 2007 and SharePoint 2010, and it has no specific dependencies beyond SharePoint being installed and available on the server where the script is run.
[sourcecode language=”powershell”]
########################
# FindDuplicateGuids.ps1
# Author: Sean P. McDonough (sean@sharepointinterface.com)
# Blog: http://SharePointInterface.com
# Last Update: August 29, 2013
#
# Usage from prompt: ".\FindDuplicateGuids.ps1 <siteUrl>"
# where <siteUrl> is site collection root.
########################
#########
# IMPORTS
# Import/load common SharePoint assemblies that house the types we’ll need for operations.
#########
Add-Type -AssemblyName "Microsoft.SharePoint, Version=12.0.0.0, Culture=neutral, PublicKeyToken=71e9bce111e9429c"
###########
# FUNCTIONS
# Leveraged throughout the script for one or more calls.
###########
function SpmBuild-WebAndListIdMappings {param ($siteUrl)
$targetSite = New-Object Microsoft.SharePoint.SPSite($siteUrl)
$allWebs = $targetSite.AllWebs
$mappings = New-Object System.Collections.Specialized.NameValueCollection
foreach ($spWeb in $allWebs)
{
$webTitle = "WEB ‘{0}’" -f $spWeb.Title
$mappings.Add($spWeb.ID, $webTitle)
$allListsForWeb = $spWeb.Lists
foreach ($currentList in $allListsForWeb)
{
$listEntry = "LIST ‘{0}’ in Web ‘{1}’" -f $currentList.Title, $spWeb.Title
$mappings.Add($currentList.ID, $listEntry)
}
$spWeb.Dispose()
}
$targetSite.Dispose()
return ,$mappings
}
function SpmFind-DuplicateMembers {param ([System.Collections.Specialized.NameValueCollection]$nvMappings)
$duplicateMembers = New-Object System.Collections.ArrayList
$allkeys = $nvMappings.AllKeys
foreach ($keyName in $allKeys)
{
$valuesForKey = $nvMappings.GetValues($keyName)
if ($valuesForKey.Length -gt 1)
{
[void]$duplicateMembers.Add($keyName)
}
}
return ,$duplicateMembers
}
########
# SCRIPT
# Execution of actual script logic begins here
########
$siteUrl = $Args[0]
if ($siteUrl -eq $null)
{
$siteUrl = Read-Host "`nYou must supply a site collection URL to execute the script"
}
if ($siteUrl.EndsWith("/") -eq $false)
{
$siteUrl += "/"
}
Clear-Host
Write-Output ("Examining " + $siteUrl + " …`n")
$combinedMappings = SpmBuild-WebAndListIdMappings $siteUrl
Write-Output ($combinedMappings.Count.ToString() + " GUIDs processed.")
Write-Output ("Looking for duplicate GUIDs …`n")
$duplicateGuids = SpmFind-DuplicateMembers $combinedMappings
if ($duplicateGuids.Count -eq 0)
{
Write-Output ("No duplicate GUIDs found.")
}
else
{
Write-Output ($duplicateGuids.Count.ToString() + " duplicate GUID(s) found.")
Write-Output ("Non-unique GUIDs and associated objects appear below.`n")
foreach ($keyName in $duplicateGuids)
{
$siteNames = $combinedMappings[$keyName]
Write-Output($keyName + ": " + $siteNames)
}
}
$dumpData = Read-Host "`nDo you want to send the collected data to a file? (Y/N)"
if ($dumpData -match "y")
{
$fileName = Read-Host " Output file path and name"
Write-Output ("Results for " + $siteUrl) | Out-File -FilePath $fileName
$allKeys = $combinedMappings.AllKeys
foreach ($currentKey in $allKeys)
{
Write-Output ($currentKey + ": " + $combinedMappings[$currentKey]) | Out-File -FilePath $fileName -Append
}
}
Write-Output ("`n")
[/sourcecode]
Running this script in the client’s environment quickly identified the two lists that contained the same ID GUIDs. How did they get that way? I honestly don’t know, nor am I going to hazard a guess …
What Next?
If you’re in the unfortunate position of owning a site collection that contains objects possessing duplicate ID GUIDs, let me start by saying “I feel for you.”
Having said that: the quickest fix seemed to be deleting the objects that possessed the same GUIDs. Those objects were then rebuilt. I believe we handled the delete and rebuild manually, but there’s nothing to say that an export and subsequent import (via the Content Deployment API) couldn’t be used to get content out and then back in with new object IDs.
A word of caution: if you do leverage the Content Deployment API and do so programmatically, simply make sure that object identities aren’t retained on import; that is, make sure that SPImportSettings.RetainObjectIdentity = false – not true.
