Where the Heck are my New Icons?

Well now, don’t I feel stupid – it’s always the easy things that sneak up and bite you where it hurts.

So yesterday, I was adding the PDF icon to a SharePoint 2010 farm; simple task, common as dirt, everyone does it.

How you say? Well, there are any number of posts about this (the process has been the same since at least Windows SharePoint Server 2.0/SharePoint Portal Server 2003), so I won’t dive in too deep – suffice it to say, there are two major tasks that need doing:

1. Add the PDF icon to the templates/images folders under the 12 or 14 hive
2. Add the correct syntax to the DOCICON.XML file in the templates/XML folder

So, this is fairly easy; so easy, in fact, that I got the icon from the Adobe site and then searched for the correct XML snippet using my handy-dandy search engine. Like most of you, dutifully made the modifications (read: copied and pasted the code directly from the browser) listed above to my SharePoint Server and ran IISRESET.

Here’s the fun part – Unlike the other 100-200 times I’ve done this, the icon would not show. Not only would it not show, other icons (like the one for Excel, for instance) was broken.

Definitely not my favorite icon…

Hm. So first, I went and checked permissions – nope, not it. Then I went and looked at the original file (yes, kids, it’s always a good idea to back up the original DOCICON.XML file – I had renamed mine DOCICON-Original.XML).

Everything looked ok, nothing out of the ordinary. All the closing brackets were there, etc. Next, I accidentally double-clicked the DOCICON.XML file instead of right-clicking it.

Some folks don’t know this, but for all the kidding Internet Explorer gets (and sometimes deservedly so), it can be a good troubleshooting tool. You can open an XML file in IE, and it will render.

And yes, it will give you the obligatory message that it’s restricted this page from running scripts or ActiveX scripts – to protect you.

But guess what happens when it hits a malformed XML file – it tells you all about it. I remembered this jewel and double-clicked the new DOCICON.XML file, to see if IE saw anything out of the ordinary. It did.

OK, what the heck is going on here. Well, what character comes next in the <Mapping Key= tag? A quote. But I have a quote in my XML file – look, there it is!

Uh, wait – anybody see anything strange? Yep – that’s the issue. When I copied the code off the website, the text was formatted with curly quotes instead of the standard quotes (“ instead of "). Apparently XML still does not have a sense of humor.

I put the standard quotes in place of the curly quotes, then ran an IISRESET to cure the problem.

The moral of the story? Not all quotes are created equal –

Unknown SQL Exception 262 and Central Administration

So, I have been creating a new SharePoint 2010 Farm using guidance from three distinct sources (all of which I highly recommend):

• Todd Klindt’s Service Account Suggestions for SharePoint 2010 – Great guidance for what each account would be used for in a SharePoint 2010 configuration.
• Spence Harbar’s Rational Guide to implementing SharePoint Server 2010 User Profile Synchronization – My UPS worked correctly on the first try because of this document.
• Shane Young’s How to remove the GUIDs from the SharePoint search service application databases and Search Database GUID issue posts – A very good, step-by-step cheat sheet for removing GUIDs from the Search databases

When I built a non-GUID database for Central Administration, moved the Site Collection over to it, then removed the original “GUID” CA database, everything worked like a champ. Still does, by the way.

I recently did a DB attach to upgrade a Content DB which originally belonged to a 2007 farm. The upgrade also worked like a champ, and I thought it went without error. The ULS, however, disagreed with my assessment – from the ULS log:

Unknown SQL Exception 262 occurred. Additional error information from SQL Server is included below. CREATE TABLE permission denied in database (insert your CA DB name here)

I went online to search for a solution to my issue, and came across a post from Jeremy Jameson – “The workbook cannot be opened” Error with SharePoint Server 2010 (and TFS 2010). Although at first this did not seem to be a related post, I noticed that he had exactly the same SQL error message in the ULS, only he was working with TFS and Excel Services.

So I scanned down the article, and he said to verify that your service account had access to the Content Database. Checking the Central Administration DB, I realized that when I built the new Central Administration DB, I had not granted db_owner access to my application service account (sp_webapp in Todd’s post):

So, there you go. I corrected this by selecting db_owner for the account and am now back in business (my ULS log is much happier).