Missing Icon Images in SharePoint 2010 Lists

After installing the 64-bit Adobe PDF iFilter on Windows Server 2008, an odd thing happened.  Some of the document icons for items in SharePoint lists disappeared.  The icons were not being referenced in the HTML.  The URL would appear as:

http://site_name/_layouts/images/

with no actual image specified.  Typically there would be a generic document icon, such as the image file icgen.gif.  Instead there was just a horrifically ugly broken image link.

I had followed the directions for installing the Adobe PDF iFilter to the letter. 

• I added all the appropriate registry keys.
• I copied the PDF icon image to the appropriate folder in the SharePoint hive at \14\template\images
• I modified the docicon.xml file to include a mapping key value for the PDF image in the 14 hive folder at \14\template\xml
• I restarted the SharePoint Foundation Search V4 service and the SharePoint Server Search 14 service. 

The searching and indexing of PDF files worked correctly, and the PDF files in my document libraries had the proper PDF icon displayed in List view.  But the icons for generic list items failed to display.

Some advice online suggested checking the permissions of the application pool associated with the SharePoint site.  I did this, but the permissions on both the app pool and the site itself were fine (and they had worked previously).

As a last resort, I changed the location of the mapping key in the docicon.xml file located at \14\template\xml

I moved the reference for:

<Mapping Key="pdf" Value="pdf.gif"/>

to the bottom of the <ByExtension> section of the XML document.   After restarting the IIS service, the PDF image icon continued to display correctly, and the icgen.gif image rendered properly as well in all of my SharePoint lists. 

In honesty I can’t explain why moving the Mapping Key to the bottom of the <ByExtension> section of the docicon.xml file worked, but if you find yourself in a similar predicament, it may help.

SharePoint Alerts to AD Security Groups Do not Work

We’ve experience the following behavior with SharePoint 2010.

In SharePoint 2007, when creating an email alert on a SharePoint list, you can specify an Active Directory Security Group as the recipient of the alerts.  (AD Distribution Groups do not work, and that is by design).

In SharePoint 2010, this capability does not seem to exist, or at least it does not work.  You can create the alert, add an AD Security Group as the recipient of the alert, and save the alert.  This will notify the group members that the alert has been created, and that they have been added.   However, when performing an action that would generate an alert (a new SharePoint List item, for example) the email alerts are never sent.

We knew that SharePoint and Exchange are communicating, as the notification of the creation of the alert gets sent out. 

The quick fix is to add users individually to the Alert.  This will work as expected for small groups but will get tedious for groups with a lot of members.  

Monitoring Alerts in SharePoint 2010

I was experiencing some trouble with SharePoint 2010 alerts.   The SMTP relay was already configured and may would send, so we knew the infrastructure piece of this was configured correctly.  My work-group was testing various options for alert criteria from the SharePoint end user UI. 

In order to see what was actually taking place, I enabled monitoring.  This can be accomplished using Central Admin by selecting Monitoring -> Configure Diagnostic Logging -> SharePoint Foundation -> and selecting Alerts.  At the bottom of the page, select your Event Log Levels and Trace Log levels.  

Now you can start using Event Viewer and the SharePoint logs to diagnose Alert errors.

InoPath 2010 Forms Not Working in SharePoint 2010

I created a new InfoPath form (not very well, but serviceable).  When I tried to publish the form to a SharePoint 2010 Server, I received the following error message:


The form cannot be rendered. This may be due to a misconfiguration of the Microsoft SharePoint Server State Service. For more information, contact your server administrator.

After some research I was able to figure out that the State Service was not set up to allow InfoPath Forms to be stored or rendered within SharePoint.  I wasn't able to find a way to do this through the GUI so I resorted to the SharePoint 2010 Management Shell (PowerShell).

•     Run the SharePoint Management Shell as an Administrator. - Start ->  All Programs -> Microsoft SharePoint 2010 Products -> SharePoint 2010 Management Shell
• After the module(s) load and you have a prompt, type:  $serviceApp = New-SPStateServiceApplication -Name “State Service”
  The command will execute and you'll be returned to a prompt.
•  Type: New-SPStateServiceDatabase -Name “StateServiceDatabase” -ServiceApplication $serviceApp
  This creates a state server database and service application.  You will see the name of the service database, the ID (in the form of a long string of characters) and the type presented in the PowerShell window
• Type: New-SPStateServiceApplicationProxy -Name “State Service” -ServiceApplication $serviceApp -DefaultProxyGroup
  This creates a State Service Application Proxy

The screenshot below shows the commands and the expected output.

You should now be able to publish your InfoPath form to SharePoint.

SharePoint Pre-Upgrade Checker Fails

The Pre-Upgrade Checker for Microsoft Office SharePoint Server 2007 is designed to verify that your existing installation of SharePoint 2007 is ready for the upgrade to SharePoint 2010.  It verifies that the OS is the correct version, that there are no orphan sites or sub-sites, it verifies the web config file, the SQL database version and a host of other items. 

When going to run the Pre-Upgrade Checker included with SharePoint 2007, Service Pack 2, we got a nasty little surprise.  The Pre-Upgrade Checker told us that there was a problem with the database schema.  Uh-oh. 

It returned a potential blocking issue that our SQL database schema had some serious user modifications.  It read, in part:

Potential Upgrade Blocking Issues
Issue : Content database with modified database schemas
User modifications to the SharePoint content database, including but not limited to table schemas, index, stored procedures, are not supported and will cause upgrade to future versions of SharePoint to fail.  The databases in the following list seem to have been modified from the original schema:
Data Source=SERVER\SHAREPOINT;Initial Catalog=Content_Database;Integrated Security=True;Enlist=False;Connect Timeout=15


That could be a problem.  We went to the logs and had a look:

[InvalidDatabaseSchema] [DEBUG] [6/14/2010 10:39:19 AM]: Checking schemas in content database Content_Database...
[DatabaseSchema] [ERROR] [6/14/2010 10:39:32 AM]: [Content_Database].[sysdiagrams] EXTRA Table
[DatabaseSchema] [ERROR] [6/14/2010 10:39:36 AM]: [Content_Database] NON EQUAL Property Tables
[SPObjectProcessor] [DEBUG] [6/14/2010 10:39:42 AM]: The rule failed.


It appeared as if there was an extra table inserted into the database, one that was not present in the original SharePoint database schema.  Somehow, there was a table called sysdiagrams that was not created by SharePoint, and it was causing a mismatch with the Pre-Upgrade Checker.

Upon a little investigation within the SQL Server, the dbo.sysdiagrams table was located at Content_Database -> Tables -> System Tables. 

How was the dbo.sysdiagrams table created?  A little bit of searching revealed the answer.  If someone clicks on the Database Diagrams within your database, it will immediate prompt you to create the necessary objects for for database diagramming.  Clicking “Yes” to this prompt will result in the creation of the dbo.sysdiagrams tables and some related stored procedures.  While these don’t pose any obvious risks to SharePoint as the diagrams relate only to the database, the Pre-Upgrade Checker will throw an error if they are present. 

To correct the error, and allow the Pre-Upgrade Checker to run successfully, we performed the following:

• We backed up the SharePoint_Content Database before making any changes.  This is critical in case something goes wrong.
• I deleted the dbo.sysdiagrams table from Content_Database -> Tables -> System Tables
• I deleted the following stored procedures from Content_Database –> Programmability -> Stored Procedures -> System Stored Procedures

• sp_upgraddiagrams
• sp_helpdiagrams
• sp_helpdiagramdefinition
• sp_creatediagram
• sp_renamediagram
• sp_alterdiagram
• sp_dropdiagram

The screenshot  below illustrates these a little better.


After deleting the table and the stored procedures, we were able to run the SharePoint Pre-Upgrade Checker and our SharePoint site passed every check.

Missing User Name in SharePoint 2010

This situation occurred after the upgrade from MOSS 2007 to MSS 2010.  When adding a document, or listing a document owner, the user ID of the author of the document does not appear.  Typically a list item will read "Added By domain\username".  In this case it read "Added by [blank].  Permissions within the document library and across the SharePoint Farm are still enforced, and there appears to be no loss in functionality, other than the User ID is simply not displayed.  The picture below is from a site that had not had the visual upgrade applied.

To correct this, I logged in as an Administrator and added the user account (domain\user_acct) to the Site Collections Administrators group in SharePoint. This was in

Site Home -> Site Settings -> Site Collection Administrators

and added the user account temporarily to the Site Collection Admin group.  I resolved the name to be sure it was spelled correctly, and then clicked OK.

The 'modified by' field / attribute now displays properly.

I then removed the user account from the Site Collections Administrators group, and the 'modified by' attribute continued to display the user name correctly.

I still don’t know what caused this, but at least the problem has been corrected.