Archive for the ‘Issue Resolution’ category

Service Pack 2 Issue and Admitting a Mistake

May 22, 2009

First of all, for anyone out there that doesn’t know Service Pack 2 for SharePoint causes the expiration date to be incorrectly activated so that it will expire in 180 days. Here is the announcement on the SharePoint team blog: can check if you are effected by looking at the services enabled in your farm. To fix it you just basically reset your key.

While it is sort of funny, and can cause concern (minor, since it’s easily resolved) it is important to note that Microsoft responded to it and accepted responsibility for the issue. This is a good reminder to everyone of us at a personal level to admit when a mistake has been made (and any of us who have used SharePoint in any capacity have almost certainly made some while we were learning) and to take steps as soon as possible to correct it.

If I look back at the first solutions I built, or the first time I installed/configured SharePoint there are things I am sure I did wrong or may have missed. There were better ways I could have built my code (such as missing dispose methods on my webs in my very first SharePoint application), or I didn’t know to change the index, and log save locations from the smaller C: drive to the larger and more spacious D: drive of my server. Sometimes it’s funny and gets caught before it can cause an issue (such as saving SharePoint Disaster Recovery documentation on SharePoint) or it can be found after when it’s already causing trouble.

What is important when a mistake is found though is that we accept it and work to resolve it. Being honest and responsible are good business traits. Trying to cover things up almost always causes more trouble than it avoids. In technology there area so many complications and ways we can try and hide things, or adjust blame when approached with situations like this. I often hear developers blaming environments, administrators blaming users, users blaming management for poor training or support, users blaming technology etc etc. In almost all of these cases the individual or group blaming can resolve the issue, or might have made a mistake.

Anyways I just thought it would be good to look at this as a reminder. We all make mistakes. It’s how we react as people and businesses that really matters,
Richard Harbridge

User Unable to Create Page (User has Full Control)

April 30, 2009

Ran into an odd little issue this morning where my users in a publishing site could not create new pages. The reason they couldn’t create a new page turned out to be because they did not have read rights on the masterpage gallery.

The symptoms are basically access denied pages when any user with full control or design rights chooses to create a page in a publishing site. When they create the page they get the typical “Error: Access Denied” page and can either sign in as another user or request access.

Hope this helps save someone a bit of time troubleshooting this specific issue in the future,
Richard Harbridge

Renaming Root “Title” Site Column – Powershell Example

February 12, 2009

The other day I had to correct a friends SharePoint site column and feel like tossing out a quick blog about it. Sometimes what happens is you begin digging into a content type, go a bit too far and modify the wrong site column, not the inherited one, but the actual title column used for an entire site collection.

Ok, so just change it back right? Unfortunately that’s when you will run into the message: “The column name that you entered is already in use or reserved.”

Microsoft has a nice support article on it here: and many SharePoint community members have blogged about workarounds such as Bob Mixon ( Bob does a great job of outlining a Powershell script here that can be easily used to update the column.

Here is the script Bob provides. I have tweaked it to ensure the web and site objects are properly disposed of (

#Replace the siteurl with your targeted site collection url.
$siteurl = “URL of top-level site”

$spsite=new-object Microsoft.SharePoint.SPSite($siteurl)
$spfield.Title = “Title”

PowerShell for Windows 2003 SP1 can be downloaded from here:
X86 –
X64 –

Hope this helps someone,
Richard Harbridge

Query list with Excel Error (Windows cannot find .iqy)

February 10, 2009

A great many people experience this issue and it’s hard to find an answer/resolution for it. When you open the task pane in a SharePoint list and choose Query list with Excel you receive an error with something similar to the following: “Windows cannot find ‘C:\Users\Username\AppData\Local\Temp\Low\list6856.iqy’. Make sure you typed the name correctly, and then try again.”



The reason you get this message? Odds are your Internet explorer settings have protected mode on, and/or you don’t have the SharePoint address set as a trusted location.

So it’s VERY easy to fix, just turn off protect mode, or add it to trusted sites, or local intranet (if that makes sense) and set those zones to have protected mode off (you don’t need protected mode on a local intranet, trust me).


Do this and you should be golden and the issue should go away.

Hope this helps someone,
Richard Harbridge

Calculated Column Limits (1024 Characters)

February 10, 2009

So hopefully many people out there know there is an 8 level nesting limit on Calculated columns (see Microsoft’s article here: The way to get around this is to probably use choose statements, or to use multiple calculated columns.

I also think I discovered a 1024 character limit today (it’s a huge pain in my butt), but I could only find one comment response that agrees with that being a limit. I honestly can’t guess as to why it’s limited to 1024 characters (query string/url limitation?) but it is a definite limit from what I can see. You can create multiple calculated columns still (in my case I had a 7000 character extremely complex formula, so I probably won’t do this and will just use excel and push it up with excel services) to get around the limit. 🙂

Just wanted to share this with anyone wondering why they keep getting the “The formula contains a syntax error or is not supported.” when they have a large number of characters (over 1024) in their calculation formula.
Richard Harbridge

Modifying XSN Files (InfoPath)

January 24, 2009

So the other morning apparently one of my ‘eval’ functions in an InfoPath form I was working on caused an infinite loop (my best guess: This causes the InfoPath form to crash and then error out everytime you try and open it afterwards.

When working in SharePoint you could restore to the previous version and redo the work (without the infinite loop, or whatever caused your error and inability to use/modify the form) if you had it stored in SharePoint, but my last save was hours ago. So I decided I would extract the XSN, modify what I think the offending expression function was (eval statements) in a specific view and then put it all back together again. That way I could avoid redoing work.

First of all you CAN save a form template’s form file’s to a folder, modify them, and combine them again into an XSN using InfoPath. However you MUST be able to open the form in design mode. Doing this is pretty simple just follow the directions at the bottom of this Microsoft article:

In my circumstance I could not even open the form in design mode as it would error out. In case anyone else runs into this I am hoping this helps them.

First off an XSN file is just a container (CAB file) of many other files. So even without InfoPath this should be easy.

  1. In order to modify these files you can just rename the .XSN file to .CAB and then extract its contents using WinRAR. You could also use renaming the .XSN file to .CAB I would be able to extract it’s contents to a folder on my local drive. (I used WinRAR for this, you could use many other programs and alternatives (
  2. I then modified my file and saved it. (Removing the evil eval loop.)
  3. I then created a Directive file so that I could use it to make a CAB. (This allows me to add many items to a cab rather than doing it individually.)To do this I just created a simple .txt file and populated it similar to the following:
    ; MSDN Sample Source Code MakeCAB Directive File


    .Set CabinetNameTemplate=ReCreated.XSN

    ; Change DiskDirectoryTemplate to where you want the CAB/XSN saved.

    .set DiskDirectoryTemplate=”C:\InfoPath XSN”
    .Set Cabinet=on
    .Set Compress=on

    ; List Every File You Want Added To The CAB (XSN)

    “C:\Users\rharbrid\Desktop\OpportunityProfile – Copy\Example.xsd”
    “C:\Users\rharbrid\Desktop\OpportunityProfile – Copy\manifest.xsf”
    “C:\Users\rharbrid\Desktop\OpportunityProfile – Copy\sampledata.xml”
    “C:\Users\rharbrid\Desktop\OpportunityProfile – Copy\Template.xml”
    “C:\Users\rharbrid\Desktop\OpportunityProfile – Copy\upgrade.xsl”
    “C:\Users\rharbrid\Desktop\OpportunityProfile – Copy\view1.xsl”

    ; End Of The File

  4. Next you run the makecab command with the directive files. Example: “makecab /f DirectiveForXSN.txt”The MakeCab.exe file should exist in the Windows\System32 folder. If it doesn’t for any reason you can download the CAB SDK from Microsoft located here: and for information on the tools located in it see this article here:

And that’s it. You should now have a corrected and functioning XSN, and resolved the error that caused InfoPath to crash each time it opened the form in design mode.

Hope this helps someone out there,
Richard Harbridge

Retrieve Any Fields for InfoPath from Another SharePoint List

January 15, 2009

So I have used owssvr.dll before to export excel documents of lists etc on the fly but the other day when I was exploring InfoPath workarounds for SharePoint lists (related to issues with Managed Paths and a bunch of other things) I found out that there are even more functions to the wonderful URL protocol!

Let me explain.

Way back in the 2001 SharePoint days the OWSSVR.dll was extremely important to remotely invoke functions against SharePoint data. In 2003, and now 2007 it’s not as important, but still used by applications like SharePoint Designer and InfoPath.

What I am going to describe is how I used it to resolve a specific InfoPath need, but you can also use it for XML webparts, or any other systems that can interpret XML 🙂

In InfoPath if you try and connect to SharePoint lists when using Managed Paths (This may be resolved in SP2) InfoPath will give you errors and all sorts of trouble. The ‘workaround’ for this is to simply reference the SharePoint lists using owssvr.dll and set it up in InfoPath as a data connection receiving XML (since that’s what the address we use will return).

The method is outlined in pretty good detail in this article: (which is also great if you want to implement a master detail relationship *wink wink*).

We use a URL similar to the one shown below:


This is specified as the source in a new data connection which retrieves data. Complete the data connection wizard (after adding the url) and you should now have the SharePoint data available for use in the InfoPath form (this can be used in expression controls, drop downs and other fun InfoPath controls).

Some Quick Notes:

Using the above url line will cause an XML file of the list’s contents to be returned.

To retrieve the list GUID or the view GUID for use in the url command simply navigate to the list of choice, select list settings and in the top URL bar will be the List GUID (converted for web etc) and if you scroll down to where views are listed in list settings you can click on any specific view and you will get the view GUID showing in the top URL bar (again converted).

If you are having trouble transforming the values of the GUID follow these basic steps:

  1. Copy the URL into notepad.
  2. Replace all “%7B” with {
  3. Replace all “%2D” with –
  4. Replace all “%7D” with }

That should make it easy to copy and paste the GUID’s into the URL properties of the owssvr.dll address. 🙂

The OWSSVR.dll can also do more than what I have described here and I highly recommend being aware of it for use in third party applications and for quick tricks:

Hope this helps someone else,
Richard Harbridge

Trust for Delegation and the List Web Part for Dynamics

January 15, 2009

A little while ago I posted about how cool the new changes to the Dynamics CRM List Web Part were:

When I tested and played with this I had everything on one box, and it wasn’t a very secure or realistic environment. However there have been people who have experienced issues related to ‘trust’ where CRM and SharePoint are on different machines (which is recommended in my opinion *wink wink*). And since most of you (who have this running in production environments) probably have it set up on separate machines… this new CRM blog article (by Suraj Supekar) is definitely something you should read.

Basically (and I quote): “If the SharePoint Server is not setup for Trust for Delegation then the user’s Active Directory credentials are not passed to the MS CRM server. The LWP deployed on SharePoint does not receive the CRM authentication ticket from SharePoint and displays the sign on form used with an IFD installation.”

So if you are experiencing this issue, the resolution is in that blog post. 🙂

Hope this helps someone,

December Cumulative Update for SharePoint

December 18, 2008

For those administrators out there please read over this new annoucement entry on the SharePoint blog:

Keep in mind these are only to fix the issues if you have them, if not I would recommend waiting until SP2.

Not sure what the cumulative updates are? Here is my previous post on it or check out Microsoft’s initial announcement on it:

Oh and before installing any updates to SharePoint or any Microsoft product keep in mind how their lifecycle/support system works. As this can impact you if you experience issues as a result of an update like this.

Hope this helps someone,
Richard Harbridge

Name.dll Prompt in IE 7 Fix (Feature, and Easy Deployment)

December 1, 2008

Great news! Ever receive that name.dll prompt on a SharePoint site of yours when viewing in IE 7?

This issue occurs if the Name ActiveX control (Name.dll) is not added to the list of preapproved controls in Internet Explorer 7. The Name ActiveX control is included in the 2007 Microsoft Office system.

The way to fix it? They have 3 ways, add the site to trusted sites, change the registry, or modify each master page.

Typically option 3 is most appealing. (Quick note, make sure you comment all function lines in their example, it is wrong and if you don’t will result in a js error.) However it has a significant drawback. Imagine how much effort it would take to update hundreds of site collections with many customized master pages?

The good news is that just a short time ago Larry J. Riemann wrote a terrific feature for codeplex based off of Randy Drisgill’s workaround (in response to issues people were having):

The feature (which makes me happy) is located here:

What is great about this feature is that it is scoped to the web application level so the number of site collections, and sub sites don’t matter. What’s more the way it’s designed should not be effected by any customizations or the number of master pages. Making it a very appealing resolution.

Find out more about the codeplex activex override at Larry’s blog here:

Warning: Through testing this feature I have noticed it causes critical errors when using InfoPath Form Services.

Thank you Randy and Larry we all appreciate it,
Richard Harbridge