After trying to install a quarterly update CU on a server in our SharePoint farm, a coworker came to me today with the following errors:
- Configuration of SharePoint Products failed. Configuration must be performed in order for this product to operate properly. To diagnose the problem, review the extended error information located at C:\Program Files\Common Files\Microsoft Shared\Web Server Extensions\15\LOGS\PSCDiagnostics … .log, fix the problem, and run this configuration wizard again.
- System.Xml.XmlException: Root element is missing.
- One or more configuration tasks has failed or some tasks were not run
- Total number of successful configuration settings: {0}
- Failed to install the application content files.
- Last message from task applicationcontent is An exception of type System.Xml.XmlException was thrown. Additional exception information: Root element is missing. Resource retrieved id ApplicationContentTaskFailConfigDisplayLabel is Failed to install the application content files.
- Task applicationcontent has failed friendlyMessage for task applicationcontent is An exception of type System.Xml.XmlException was thrown. Additional exception information: Root element is missing.
- debugMessage for task applicationcontent is An exception of type System.Xml.XmlException was thrown. Additional exception information: Root element is missing.
None of this information is very helpful. It also doesn’t describe the actual problem very well. My favorite is “….DisplayLabel is Failed to install the application content files.” What does that even mean?
I see your lips moving, and English words are coming out, but I clearly not be understandable what said you are?
And searching online was no help at all.
So I said to myself, self, you need to figure out which XML file SharePoint not be understand-a-bab-bling.
So I wrote a script that checks xml files, whether they are valid and if they can be parsed. I had to figure out what SharePoint was trying to read (and couldn’t). Hopefully it wasn’t a temporary file.
This is what it looks like:
param([parameter(Mandatory=$true)] [string]$InputDir, [parameter(Mandatory=$false)] [bool] $NoOutput=$false ) # Given a path, loop through each xml and config file, read, and parse to check for errors function Check-XMLfiles { $inputdir = (get-item $inputdir).FullName write-host "Recursing directory: $inputdir" $dirtree = dir -recurse $InputDir | where { ($_ -is [IO.FileInfo]) -and (@(".xml", ".config") -contains $_.extension) } write-host "Parsing" @($dirtree).count "files..." $prevlinelength = 0 foreach ($filename in $dirtree) { $xml = New-Object Xml.XmlDocument; if (!$nooutput) { write-host -NoNewline `r "Checking:" (" "*$prevlinelength) `r "Checking:" $filename.basename $prevlinelength = $filename.BaseName.length } # check/parse file try { $xml.Load($filename.FullName) } catch { write-host write ("File: " + $filename.fullname) write-host ($_.Exception.Message) } } write-host -NoNewline `r "Done. " (" "*$prevlinelength) `r write-host }
Okay, this is great, but where do I run it?
I figured out that SharePoint keeps a directory of XML config files.
So I did what the article said, cleared the cache, and tried rerunning the update. Still no luck. Then I ran my script against the directory. Still not feeling the love.
Must be somewhere else.
I learned years ago that SharePoint didn’t like it when IIS web config files were broken. Sometimes a system crashes, more often, a developer pushes out a bad build. But either way, web.config file errors will eventually catch up with you and breaken your SharePointen farmen.
Well, it was worth a try. I ran my script against all of the IIS SharePoint virtual directories.
Well, what do you know? We be thinking that blinken lights, it’s not might be workin every, well very, in them thar’s IIS sitezen.
But all of my sites are working!
Aren’t they?
Hm. I backed up the bad web.config files and copied over the same AND correct ones from another server in the farm.
And magically, the upgrade worked!
Turns out this particular server had been broken for some time. SharePoint’s redundancy had kept SharePoint running, but one of the servers in the farm was broken. And we didn’t know about it until we did an update. Hm. Better go look at how the ops folks are validating that our sites ARE ACTUALLY up…
The reason SharePoint admins don’t like running patches and updates very often, is because “there are always problems. Just about every time.”
This is completely the wrong way of looking at it. Updates fail because their environment is broken and they don’t have good strategies and processes in place to prevent bad things from happening to good people (i.e the SharePoint Admin). So they don’t find out about problems until the next patch cycle.
I figure you might as well figure it out now. Because you are going to have to upgrade some day. Aren’t you?
It’s like a person I knew who knew they had cancer but didn’t do anything about it. When they finally went in, it was almost too late. They survived, and are doing well today, but it was a very painful experience and took quite a while. Kind of like the long weekends so many SharePoint Admins experience.
My strategy is different. Update more often. Put a process in place that will give you very quick update cycles. It’s safer that way anyway. Never mind the security benefits. And then put better testing in place to make sure you can validate that EVERYTHING works. If you don’t, you are just waiting for the next update to break your farm. Again.
And besides, the sooner you find out you have a problem, the sooner you can start beating on the people who are breaking your environment. It is counterintuitive, but once you think about it, it really does make sense.
And once again, I was also reminded that redundancy is NOT a good backup strategy. In this case it saved me, but what would have happened if the bad files instead of the good ones had been copied all over the farm and to the other servers?
Busted IT 