Unable to open Office documents from SharePoint

I started a job recently where the test environment had problems opening, creating or editing documents in document libraries. The documents in question were office documents, and the error we got when trying to create a new one was -

..."requires a windows sharepoint services-compatible application"..

Now I knew that there was nothing wrong with the client pc I was using to browse this site, as I could use the other environments without problem. So trying to track this problem down was a real issue because it is a common issue which manifests itself when office isn't configured correctly on the client... But I knew this wasn't the case.

So I tried to create another web application in this farm to see if the issue went away (which would of suggested configuration within the site)... But the new web app had the same issue. So this led me to believe it was either a central admin setting or an issue with a file in the 12 hive of the web server.

I quickly checked central admin for any settings which could create this issue, but I couldn't really see anything which would. So I concentrated on the 12 hive and had previously checked the C:\Program Files\Common Files\Microsoft Shared\Web Server Extensions\12\TEMPLATE\XML\DOCICON.XML file to see if the service account had enough permissions to read it (as it had been suggested elsewhere) but the service account did have enough permision. So I decided to move onto the rest of the 12 hive as I was convinced that everything else was in place and the only problems could come from the static 12 hive files.

So I used Beyond Compare to compare the 12 hive of the "broken" machine against a working instance of Sharepoint I had elsewhere.

When going through the differences I headed straight for the C:\Program Files\Common Files\Microsoft Shared\Web Server Extensions\12\TEMPLATE\XML\ folder as I had a feeling any issues were likely to be shown up in there... Sure enough when I compared the DOCICON.XML file there was one line that had been inserted by a previous developer -

The line that had been added to the non working xml file was -
<Mapping Key="pdf" Value="pdf.gif">

The tag wasn't closed correctly!!

So I changed it to -
<Mapping Key="pdf" Value="pdf.gif" />

And now my site was back up and working again.

You would think that this typo might have thrown a more obvious error than it did!

If this doesn't fix your issue the other 2 places I'd check (if it is definitely a server issue) are -
Permissions of DOCICON.XML
Document Template for the Content Type or Doc Library (make sure this isn't corrupt).


Hope this helps someone.

Sharepoint - Activating features in code programatically

I have been working relentlessly on Workflow recently and although you can use the stsadm UpgradeSolution switch to deploy your new workflow sometimes the Association data needs changing which means all instances of the workflow need to be reinstalled.

Easy enough as i have a Workflow Association feature on each SubSite... but I didn't really want to go through each one and manually deactivate and reactivate.... and I also didn't want to use the stsadm command as it is far too slow. So I coded a quick console app to help with the deployment..

Console.WriteLine("Please enter the URL of the sharepoint site to install this against - e.g http://MySharepointSite.com");
string siteUrl = Console.ReadLine();
Console.WriteLine("Please paste the guid of the feature you would like to flush - e.g A7004706-0644-4aab-B097-691A5F51B3D6");
string strFeatureGuid = "" + Console.ReadLine();
Guid FeatureGuid;

try
{
    site = new SPSite(siteUrl);
}
catch (Exception)
{

    Console.WriteLine("ERROR: The site url does not relate to a Sharepoint site on this machine!! Press any key to close.");
    Console.ReadKey();
    return;
}

try
{
    FeatureGuid = new Guid(strFeatureGuid);
}
catch (Exception)
{

    Console.WriteLine("ERROR: The Guid entered is incorrect!! Press any key to close.");
    Console.ReadKey();
    return;
}

Console.WriteLine("Connected to site - " + site.Url.ToString() + ".");

int count = 0;
int flushCount = 0;
int sitesCount = site.AllWebs.Count;

foreach (SPWeb web in site.AllWebs)
{
    foreach (SPFeature feat in web.Features)
    {
        if (feat.DefinitionId == FeatureGuid)
        {
            count++;
            web.Features.Remove(FeatureGuid);
            web.Features.Add(FeatureGuid);
            flushCount++;
            break;
        }
    }
    web.Dispose();
}
Console.WriteLine("Feature is activated on " + count + " sites out of " + sitesCount + " sites.");
Console.WriteLine("Out of those " + count + " the Feature was successfully flushed on " + flushCount + " of them.");

count = 0;
foreach (SPWeb web in site.AllWebs)
{
    foreach (SPFeature feat in web.Features)
    {
        if (feat.DefinitionId == FeatureGuid)
        {
            count++;
            break;
        }
    }

}

Console.WriteLine("Feature is NOW activated on " + count + " sites out of " + sitesCount + ".");
Console.WriteLine("Please make a note of the above and Press any key to close");
Console.ReadKey();

Add this code to a console app and you can now use this to flush already activated features where needed.

Sharepoint Solution Mangement - How will Redeploying my solution affect my Features?

Someone mentioned to me the other day that they were about to make updates to their Live Sharepoint site, this meant editing their Sharepoint Solution package (.wsp file) and redeploying, but they were nervous as they weren't sure what would happen.
The reason for their nerves was that they had a List Feature (with a SFeatureReceiver class) that created a list from a .stp file (with content in it). Since initial deployment their list had been edited and had new items in it, they didn't want the reployment to affect the content of this list.

So their options are -

stsadm -o upgradesolution command

or the following commands one after eachother

stsadm -o retractsolution
stsadm -o execadmsvcjobs
stsadm -o deletesolution
stsadm -o addsolution
stsadm -o deploysolution
stsadm -o execadmsvcjobs


Although there isn't much difference between the two options there are some subtle differences. The first command (stsadm -o upgradesolution) should be used to update what is already there in the solution. i.e Features that are already installed (There is a difference between Features in the 12 hive and Features that are fully installed).
The second set of commands can be used if you are adding a new Feature to your wsp. The new Feature will appear in the manifest.xml (as below).

Old Manifest.xml



New Manifest.xml

If you use the UpgradeSolution command for a new Feature then it will never get installed to your Site. This means you'll never see it from the Site Features or the Site Collection Features pages (Although it may well appear in the 12 hive).


The next question would be "Ok so I have a new Feature, but what happens to the already Installed and Activated Features if I run the above commands? Do they get ReActivated?"

The answer to this would be NO your already installed and Activated Features don't get reActivated... But they do get reinstalled! This means if you have a SPFeatureReceiver class like below then the only part which will be "run" is the Installed part -

This shouldn't affect anything in your site as all the work is done on the activation of the feature... Installing it really just means that the Feature is available throough the UI to activate.

Hope this cleared up a few Sharepoint grey areas.

Information management policy settings to Expire list items by it's Created Date

When I first used Sharepoints Information management policy settings I thought it would be easy to set an Expiration Policy on my list items. This seemed like a perfect fit for the requirement I was working on.

Was it Straight Forward? Yes and No.

But once I sorted out my issues I managed to quickly get it working. Firstly the reason I wanted to do this was because my client had a requirement to delete items in a list once they'd been there a couple of weeks. Easy I thought....

So I went ito the Settings Page of the List

Then I clicked on the Information management policy settings link.

I then selected Define a Policy.

On the following screen I checked the Enable Expiration box.

This gave me futher choices..... But the choice I wanted to select was greyed out! I wanted to select A time period based on the item's properties: ... but it wouldn't let me because I didn't have a date field to select from! This is when I started shouting "What about the Created Date" followed by "What about the Modified Date".

Once I'd calmed down I tried several ways to try and trick this policy by adding hidden fields to my list. It still didn't give me the desired result I was after.

So I needed a new plan....

So my attention turned to Site Collection Policies (Site > Site Settings > Site Collection Policies). This seemed like the way forward. Set a policy at the Site level and then select it from the List settings Information management policy settings page. But surely it will give me the same problem.... won't it?

When I clicked on the Site Collection Policies I got an Access Denied Error! So I started screaming - "I am a *#$%$#@ Site Collection administrator how can I not have access".

Well once I looked into it further I realised that I need some sort of permission to be able to access this page. So I decided to make sure I had all the available permissions assigned to my Web Application. I did this with the code below -

SPWebApplication WebApp = SPWebApplication.Lookup("http://MySitesUrl");

WebApp.RightsMask = WebApp.RightsMask | SPBasePermissions.FullMask;

WebApp.Update() ;

This can just as easily be done through the UI. See Gary Lapoints blog at - http://stsadm.blogspot.com/2007/10/enumerate-effective-base-permissions.html

Once I had done this I had access to the Site Collection Policies page.... Once there I added my expiration policy and then went and added it to my list through the Information management policy settings page.

After waiting for the Policy to run (This happens daily) I went back to double check my expire items had been deleted.... And they had. Success!

Hope this helped.