STSADM - "Command line error"

I got this question from a client and its one I've wrestled with before. The solution is quite embarrassing, but not always easy to uncover.

The issue in question was this: 

 The SharePoint admin was trying to do a backup of the current SharePoint site. I had left instructions on how to do this before I left so he just copied/pasted my instructions into the command line. After hitting “enter “he got the lovely "Command Line Error" message. He said he spend the whole morning trying to figure out what the issue was.

What was the Solution?

Microsoft word had modified the dashes in the command to the double dash thing. I told him to simply type it all out instead of pasting in the command.

Success!!

Embarrassing no?

So if you are having a command line error and you are pasting in the command, try to type out the command by hand. 

Enjoy!

Exposing InfoPath Forms via URL

At my current client, we published various InfoPath forms to Forms Libraries. We needed a way to expose the forms as links throughout the site. 

At first I figured this would be easy, but it turns out it is not.

I tried this first:

http://[server]/[site]/[list]/Forms/Template.xsn.

Perfect! Except that this does not work in FireFox. Turns out that even with a link directly to the file, SharePoint runs some javascript behind the scenes to see how the file should be displayed. It attempts to create an ActiveX Object, which fails in Firefox. The function is written poorly as when the ActiveX create fails, it attempts to open the form using Form Services. 

Our form was not Form Services compatible so we were getting errors when Form Services tried to expose the form.

Long story short, it didn't work.

I began digging and found other posts that simply paste the JavaScript that SharePoint uses into a Content editor web part. Unfortunately that wasn't going to work for me as our client utilizes links lists and needed a way to expose them via a URL.

That didn't work either.

After digging around in the javascript files a little more I decided to take a new route. 

I installed and monitored the network traffic with Fiddler. I found that SharePoint actually changes pages a few times before the forms are exposed. I tried the different links it was navigating to until one worked.

Here is the solution!

https://[server]/[site]/[list]/forms/template.xsn?OpenIn=PreferClient&NoRedirect=true&XsnLocation=/[site]/[List]/forms/template.xsn

Hope this saves someone else some headache!

CQWP and RSS Feeds

I decided to do a SharePoint blog, so here goes!

At my current client, we have a well defined Content Type structure. On the home page of their intranet they have CQWP's that roll up announcements, alerts etc from all over the site.

They needed a way for users to subscribe to the alerts. Since they were rolling up the content, having the users go to each list and subscribe to alerts was not going to work.

Since we were using CQWP's I decided to enable the RSS feed functionality of the CQWP. In the presentation section of the web part I checked the "Enable feed for this web part" and gave it a name.

I saved the web part and now a new shiny RSS icon appeared at the bottom of the web part:

Easy enough right? Not so fast.

I clicked on the RSS feed icon and got an ugly SharePoint error.

"Guid should contain 32 digits with 4 dashes (xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx). at System.Guid..ctor(String g) at Microsoft.SharePoint.Publishing.Internal.CodeBehind.FeedPage.OnLoad(EventArgs e) at System.Web.UI.Control.LoadRecursive() at System.Web.UI.Page.ProcessRequestMain(Boolean includeStagesBeforeAsyncPoint, Boolean includeStagesAfterAsyncPoint) "

I did some research into this and I saw a few people with the error, but no one with any cut and dry solution. I continued to try a few things and came across the solution (for me at least)

In my current implementation, we have the publishing Infrastructure Site collection features turned on, but not the Office SharePoint Server Publishing features at the site level. Therefore my CQWP was on the default page (http://server/default.aspx). By adding a pages library called "Pages", adding a page to it and dropping my CQWP onto that page, the RSS feed works!

Turns out the CQWP is assuming it's situated on a web part page in a "Pages" page library.

So as a workaround, created a small Content Editor web part that sits below the CQWP on the default page, and linked to the RSS feed page of the identical CQWP that resides on the Web Part page that is in the pages library...

Works like a charm!

Enjoy!!

Hopefully there will be many more to come!