“Unknown Error” and OOTB SharePoint 2007 builtin Workflows

If you are playing with Approval workflows, and you find that your workflows are erroring out even when you think it should have completed successfully, make sure you aren’t in a situation where you’re updating the approval status without having the approval functionality of your document or workflow library enabled.

It’s all built-in, but it doesn’t all automatically enable itself on need.

I ultimately found my answer on SharePoint Blogs, but my discovery route was circuitous.

First, the Unknown Error statuses on my workflow status page for the workflow. These workflows would error out and require termination from the workflow status page so they’d stop contributing to my active workflow counts. Searching around, I found out (look at Eilene Hao’s response to Misha) that you can get more info about these by going to where your Diagnostic Logs are kept. Find out where those logs are kept by going to SharePoint Central Administration, Operations page/tab, then under the Logging and Reporting section, click the link to Diagnostic Logging. On the next page, you’ll find out where those logs are under Trace Log.

Go to that directory in your front end web server(s) and use a decent directory search/grep (I used Textpad I have installed in portable mode on a USB key) to find log files with the word “workflow”. Upon doing that, I found the string/error, “System.ArgumentNullException: Value cannot be null. Parameter name: name”. Googling eventually led me back to the SharePoint Blogs post above.

So the fix is that if you’re going to use an ootb (out of the box) builtin workflow that updates the approval status of an item, you should also enable the “Require content approval for submitted items?” option in Versioning Settings for the list settings. This will do a lot of things automatically for you:

  • When a list item is changed, the approval status for the item gets automatically changed back to “Pending”.
  • When a person with the permission level to approve items looks at the list, they get a special view option called “Approve/reject Items”. (So they can bypass the approval workflow)
  • The workflow that updates approval status stops erroring out.

It’s all pretty cool, but you have to know how it all hooks together.

Wrangling interesting InfoPath 2003 vs 2007 issues with arcane XPath statements

We have a form at work where the XPath current() function isn’t working properly. It’s supposed to be essentially a pointer to your current execution context, so in InfoPath in general it’s great for finding your way sort of recursively up and out of your current context to sibling controls (for harvesting lookup values, etc.). When it works.

Read on for more details.

Continue reading Wrangling interesting InfoPath 2003 vs 2007 issues with arcane XPath statements

Creating and Administering Site Themes in SPS2003/WSS 2.0

This is probably more for posterity than anything else, as most folks should have been using SharePoint 2003 technologies for almost a year.

But my work site uses 2003 still, with an upgrade coming up in the next few months.

Recently I had to fix some site-wide site templates that had some issues with unghosted and non-functional pages. I’ll look a little into what we think generated the problem, what doing it the “right way” looks like, and how to administer, manage and deploy site themes.

What are site themes? How do they compare to site definitions?

In contrast to site templates, which are a mixture of HTML, ASP.NET and CAML and are difficult to customize and troubleshoot owing to there not being any meaningful testing or debugging configuration, or meaningful development environment – if you decide to go into site definition-land, prepare to use a lot of text editors, lots of incremental testing, and lots of prayer (or whatever substitutes in your life), site templates are actually pretty easy to generate. You use a mixture of the in-SharePoint GUI, themes (which you may have had to generate the hard way) and FrontPage 2003 to create site templates out of a test or design site (you can even use a live site, but it can be more confusing to get it right that way), then use the SharePoint GUI to generate the site template, which then shows up in the site collection site template gallery.

When you’re satisfied with your site template, you can download the *.stp file from the site template gallery and begin to deploy it to other SharePoint site collections via either the global site template gallery (administered with the stsadm.exe utility) or a site collection’s site template gallery (via uploads/deletions through the SharePoint GUI).

If on the other hand you decide to create your own site definitions, you do get slightly better performance, the possibility of creating truly novel sites (site templates, on the other hand, must be based on pre-existing site definitions, most of which are created by either Microsoft or by really big-time development houses that are leveraging SharePoint for the functionality) that do cool things not possible with out of the box site definitions. The problem is that there’s no meaningful development environment for site definitions. In 2005, some of the TechEd presenters got almost cussed out for this failing. I’ve worked with site definitions myself, and let’s just say they’re not for the faint of heart. I worked for 2 weeks on a site definition pilot and I was barely done in time, even though the overall changes to standard definitions we were seeking were really minor. There is no debugging, no testing environment. You just use a VPC running SharePoint and deploy your changes to that and hope they worked, test by creating a new site based on the site definition and cross your fingers and hold your breath. A single error of certain kinds of syntax can keep the entire site from working properly. It can even be difficult to delete a site based on a non-functional site definition.

I’d recommend sticking with site templates if at all possible. They’re saner and easier to work with.

If you feel you must work with site definitions, feel free with my blessing (just don’t ask me to help you). Good starting points: 1, 2, 3, 4.

Things to know

Here’s a list of concepts to be familiar with before you start:

  • The difference between site templates ans site definitions, above.
  • Ghosting and unghosting – Ghosted pages are ones that have not been edited and saved in FrontPage. If you edit a page and save it, even if no changes were made, in FrontPage, you immediately unghost it. This makes maintenance tricky – all look and feel customizations need to be made separately to unghosted pages – and also cuts down performance – each unghosted page is rendered separately from ghosted pages, which get performance bonuses from being based on standard pages from site templates or site definitions.
  • GhostHunter, part of the Web Part Toolkit from BlueDog Limited, helps you identify unghosted pages and reset them to ghosted status (losing any specific look & feel customizations possibly made to the page via FrontPage)
  • FrontPage 2003 – be well enough acquainted with FrontPage that you know how to use it to edit Web Parts and other smart parts in SharePoint without saving changes to the page (and unghosting it, causing problems outlined above).

Doing the Dirty Deed

So you want to make a clean, unadulterated, properly ghosted Site Template?

The process requires careful movement, solid thinking, and not clicking any buttons without really thinking about what you’re doing.

What kinds of changes can you make?

Any kinds of changes that are available with site themes (good links: 1, 2), i.e.:

  • Colors – overall site color themes
  • Graphics, including banners at the top and sides of the page
  • Text font, size, color, placement

Additionally, site templates allow you to customize the behavior of default lists as well as the default lists that any site based on them starts with, including:

  • For any list: Default content, default columns, column defintiions, security, URL/path information, view, any other list setting available through “Modify settings and columns”
  • Lists’ appearance in the quick launch area
  • Upper banner navigation
  • Web Part Page libraries and Web Part Pages and their layouts
  • Default look and feel of default.aspx, not the layout of the web part page, but the web parts that are on it, and how they’re configured, including the default view into any list the list view web parts might point to

The only real trick to any of this is keeping in mind where each setting is, and how to go in and set those settings without messing with the proper ghosting of the pages in the template-creation site.

So, to start I make sure I have the right admin permissions to do what I need, then I usually pick whatever standard site definition is the closest match to the behavior of the site I want. If the site definition has been previously locked of out of display in my dev environment, I get my admin to unlock it in WEBTEMP.XML (a little more about that here, though this is for 2007). I then create a new site, usually in a specially designated site collection for building templates, using that site definition to create the site.

My company already put a bunch of time into properly creating some branded site themes for each of our operating companies, so I make sure those are installed in our dev environment, and I go ahead and apply it to the newly-create site. Then I go about primarily using the raw SharePoint GUI to make the site look as close as possible to what I want it to look like. The only things I generally don’t do in the GUI are editing the horizontal nav bar and potentially also editing the Quick Launch bar (these are for later with FrontPage 2003). So examples of changes here that I sometimes do are:

  • Delete the default Shared Documents document library, recreate one initially named “docs” so that’ll be the URL/path name, then go back and rename it to “Shared Documents”, do any tweaking necessary to columns and create a few useful, typical views based on some metadata or another.
  • Delete the default Issues list, and rename it for a better URL/path name. Add/subtract/edit metadata/columns as needed. Create an initial issue as a sample.
  • Edit the shared view of default.aspx and remove the default Windows SharePoint Services image web part entirely. Insert a Content Editor Web Part with some Javascript that overrides the horizontal nav bar with new text/links and hides the Site Settings behind some other web part page.

When going ahead and using FrontPage 2003, I open, for instance, the site and then default.aspx (make sure editing is enabled in ONET.XML). ONCE default.aspx is open, DO NOT CLICK SAVE or in any way save from this view. When you are done with changes here, just close the page without saving. It’s trippy, I know, but if you don’t do this right, you have to go back and use ghost hunter to undo your unghosting, which is a pain. Anyway, once FrontPage has opened default.aspx, just right-click and choose to edit properties of the various navbars you wish to edit. Use the in-FrontPage GUI to make the changes, click Apply and OK as needed, but DO NOT CLICK SAVE. Once this part is done, close FrontPage to deny yourself the temptation of clicking save.

If you do make a mistake and do click save, you can install the Web Part Toolkit from Blue Dog and then use the GhostHunter Web Part to find and reset any unghosted pages. I’ll defer to the developers’ documentation here for how to do that.

Now that, finally, your site looks exactly like it should, you save it as a template. To do that, go to Site Settings, then Go to Site Administration, and finally Save site as template. If you created any custom content while creating your template site, you need to save that to the template as well. Follow the prompts and your site will be saved to the site collection template gallery (a link will be provided). Follow that link and administer the template’s name there, download a copy as an *.stp file that can be copied to other SharePoint Farms (as long as the destination has the site definition you used to create the template, and the theme you used to create the graphical changes). You can also delete the template from the site collection site template gallery if you like.

If you want to deploy this to a virtual server’s site template gallery (and not have to deploy to every single site collection you may have, which could be quite a few), you can use the stsadm -o addtemplate and stsadm -o deletetemplate to add and subtract, and stsadm -o enumtemplates to list them. You can do this on any SharePoint farm server where SharePoint is installed, so Search, Index and Web Front End servers work. The changes you make affect the whole farm, but only go into effect on an iisreset. So you can single one server out in the farm, use host files to make sure you test against it, deploy your changes and test against that site after issuing an iisreset there, then do iisreset on the rest of the farm servers when you’re satisfied your deployment worked.

A word of warning: The list of active templates is displayed to uses and to the stsadm -o enumtemplates in the order they were added, so if you want the templates to display alphabetically, you need copies of all of the templates that are deployed, plus the one(s) you are deploying, and you need to add them in alphabetical order, by template title. There is no other way to sort them. We ended up writing a couple of utilities to do this. You could script such a thing, maybe working against an XML file that keeps track of site template titles, descriptions and template file names, with the cscript Windows Scripting Host and Javascript, or really handily in PowerShell, if you can install .NET 2.0 on your front end web servers.

Related Resources

Here are some related resources:


Feel free to leave questions in the comments!

Interesting tidbit for getting your VPC-borne development environments to run properly

This tip from Kevin Kelly (not of kevinkelly.org, btw, but my co-worker – Hi Kev!).

Anyhow, if, like us, you need to do your development in a single-server installation that’s network-isolated (either SPS2003 or MOSS2007), you may have found that there are some issues when you install and try to use some SharePoint/Visual Studio features. You get what look like network name-resolution issues and other related issues. (I’ll provide more specific error information when I next see it.)

It turns out that the Visual Studio/SharePoint features that raise the errors are using the same COM model/object and raising contention issues with the System Event Notification Service. If you stop the System Event Notification Service then the features you’re trying to use start working fine.

The problem is of course that if you disable the System Event Notification Service, your code may not log events properly to the event logs. So be sure you know whether the thing is on or off while you’re doing troubleshooting!

I’ll play with this more and try to come up with some screenshots/error messages when I get the new MOSS 2007 VPC to play with (a few weeks) that my company’s creating.

MOSS 2007 Site Definitions Links

Am now doing research on how to make Site Definitions for MOSS 2007/WSS 3.0. The main reason to do this, is as far as I can now determine (this may change) still the same reason you made one for SPS 2003.

You can use Site Templates (which are entirely different animals) within any particular top level site/site collection by installing them after the top level site is running, and then base new subsites on those within the gallery of the site collection.

In contrast, if you want a thing that acts like a Site Template but applies to the root, top level site in a site collection while you are creating the site collection for the first time, you need to have already created and installed a site definition that looks/feels/behaves the way you want it to.

Anyhow, here are the how-to links:

Workflow dev in MOSS 2007/WSS 3.0

I’m doing research into developing “simple” workflows in MOSS 2007/WSS 3.0.

This is mostly a linkdump post, but I wanted to say that the “simple” workflow I have to work with (publishing documents from a private workspace/subsite to a public parent site, seemingly cannot be accomplished with SharePoint Designer 2007, which seems to be limited to publishing from one Document Library to another within the same site.

Thus, I’m investigating how to do workflow dev in Visual Studio 2005.

Site Definition and Themes Customization Research Links

I’m doing some research into Site Definitions and Themes in MOSS 2007/WSS 3.0. My goal: Determine how similar or different the mechanisms are from SPS 2003/WSS 2.0. Answer: looks pretty similar!


I’m doing research today to answer multiple questions.


  1. I recreated my MOSS 2007 SSP a while back and now MySite creations aren’t working for anyone. It’s not working exactly like the discussion at Technet Forums. Still researching this one.
  2. On a related note, I need to nail down exactly how to create personalized MySite services scoped to a particular web application on the MOSS 2007 farm. No articles yet.
  3. How do we federate/rollup content (if possible, what’s best practice?) from multiple sites? Client has security policies that require internet/extranet servers/farms be separate from intranet servers/farms, but they also have a requirement (it’s thankfully more of a “nice to have”, since even they are not sure it’s possible) to make it so that a single user doesn’t have to go to multiple sites to see all of their content, especially their personalized content. I’m aware that this is possible in many ways in SharePoint, but not sure if any implementation is ideal. The first really helpful link I’ve found along these lines of thinking is Joel Oleson’s blog entry about managing Global and Multifarm deployments. Another good one from Mr. Oleson. I’m reading it right now.
  4. I have to do some research on the best ways to integrate outside LDAP, AD and custom-schema organizational directories for user information into MOSS 2007. No links there yet.
  5. I need to get on the stick and do Workflows in VS 2005 against WSS 3.0/MOSS 2007. I did try SharePoint Designer for my needs and while it does address most of them, one thing I couldn’t figure out how to do was to make a workflow that publishes documents across sites (up, down, sideways, between sites, subsites and unrelated sites). All I could figure out how to do was publish from one document library to another in the same site. There are other options:
    1. Major/Minor versions in Document Libraries: Probably the most elegant of the solutions, since it’s already built-in to SharePoint 2007, the major down-side is that this may be too complicated a new feature for users to learn given that check in/check out is already foreign to them (unless they’re developers). I know the pat answer is learn, but honestly that doesn’t cut any ice with client-focused business analysts. They have a point. The “learn” answer just offloads the effort on another group: either training or support. Not everyone is as technically focused as implementors are. Not everyone wants to learn a new feature every version upgrade just to do their jobs right.
    2. The Send-To->Other Location option on document libraries’ documents works just fine with Firefox 2.0 but barfs completely with IE7. See my discussion of it on the Microsoft Newsgroups (I think you’ll need a passport identity – alternate link via Google Groups) for more information. It’s possible I’ll call MS support about this, but only if the client says it’s critical path and means it. It’s too risky to burn a support call on a bug. I wish MS really provided other meaningful ways of reporting bugs.
  6. I also need to find out whether the helpful Weather and other free, useful, fuzzy good feelings web parts exist any more, like they do in SPS 2003. Weather’s a big request these days. If they’re a download/install I need to do that. No research here yet either.
  7. Finally, I asserted to a friend/co-worker a few days ago that from a programmer’s perspective, I can’t see why Perfmon would, as his manager asserted, bring a server to its knees. Given that in the programming I’ve done that does create Perfmon counter objects, I never check to see if any monitors are running, I just throw the stats over the wall for the OS to do with it as it will. The guy’s job would be made so much simpler if his manager relaxed about this, and I simply don’t have the resources myself to do the exhaustive system profiling and performance monitoring this might take to convince anyone. So maybe someone else has. No research here yet.

So what do you think? Do I have enough to do?

Simple read-write connection of a database table (non-SharePoint) to a DataView Web Part in MOSS 2007

Test this out/play with it in a test area. Don’t do this in production. Duh.


  • SQL Server 2005
  • SharePoint v3 (I don’t honestly know, but I think just WSS 3.0 w/o MOSS 2007)
  • SharePoint Designer 2007
  • A SQL account with db_datareader and db_datawriter permissions on the database in question, and the account’s password
  • A table in the database with a primary key
  • Sufficient SharePoint rights to use SharePoint Designer to create DataViews on Web Part Pages somewhere

(Italics are steps added after MS Support helped me out with this.)

  1. Make sure you have the SQL account name and password at the ready (for this example, account is sqlmossupdatetest)
  2. Make sure you know the SQL Server name/instance name (if any – for this example, the server name is DEV1 and the instance name is MOSS)
  3. Make sure that the table in the database has an autoincrementing primary key (Column settings for this are related to Identity properties w/in SQL Management Studio).
  4. Create a new Web Part Page in one of your document libraries. Exit Edit Mode.
  5. Open the site where your Web Part Page resides in SharePoint Designer 2007.
  6. Next, open up the Web Part Page you just created by browsing to it and double-clicking it in SharePoint Designer.
  7. In SharePoint Designer’s default upper right toolbox pane, choose the Data Source Library tab.
  8. Under the Database Connections group, click the link for Connect to a database…
  9. Click the Configure Database Connection… button.
  10. In the server name textbox, type the server name, or server name\instance name if you’ve got an instance name (i.e. in my case, it was DEV1\MOSS).
  11. Keep Microsoft .NET Framework Data Provider for SQL Server for the Provder Name.
  12. For Authentication choose (not very secure) the first radio button, Save this username and password in the data connection, and enter the username and password you have in the Database.
  13. Click Next. If you get an alert about how other authors can see the user/password information, click OK.
  14. Choose the proper Database and Table for your Data View.
  15. Click Finish. Then click OK.
  16. Click and drag the new Database Connection to a Web Part Zone in your Web Part Page.
  17. Use the right menu-arrow on the Data View Web Part to bring up the menu items for the web part and choose Edit Columns… .
  18. Remove the Identity/PK column from the Display section. Click OK. 
  19. Use the right menu-arrow on the Data View Web Part to bring up the various menu items for the web part and choose Data View Properties… .
  20. Choose the Editing tab and enable the checkboxes for Show edit item links, Show delete item links & Show insert item links.
  21. Save the page in SharePoint Designer and click Yes if prompted about changing the site definition.
  22. Close SharePoint Designer and refresh the Web Part Page in IE. Be sure to populate your ID field with a unique value. Obviously this cries out for more work to actually dynamically create a unique key, etc.

Update: Oddly enough, while T-SQL INSERTs & DELETEs seem to work, UPDATEs don’t, so I’m now digging further and seeing whether I can write custom SQL in the connection definition to do the UPDATE properly.

Update 2: A support ticket (via my employer, a Microsoft Gold Manged Regional Partner) has been opened about the UPDATEs issue. I’ll report back when we have a fix.

Update 3: The support issue is closed. The issue with updates was caused by trying to edit the PK value. To keep the web part from trying to edit/update the PK value, you remove it from sight and then it doesn’t bother with trying to change it on update, so the update is successful. I added a couple of steps to the procedure to do that. Also, I forgot to say that I brought up the question of documentation for custom SQL and apparently there is no such documentation currently at MS for the Parameters features.

Web Part Packager – Link Salad

I went looking for a Web Part Packager install walkthrough with screenshots that a co-worker might find useful, but was unsuccessful. I did however find a bunch of links I wanted to save for myself. 

So if you don’t know about the Web Part Packager and you’re running SharePoint 2003 and developing/deploying web parts, learn about it! I understand from the folks at Blue Dog Limited that the tool’s going away for MOSS 2007, but I don’t have it verified. Given that 2007 is still in Beta, though, knowing about the Web Part Packager is probably still a good thing.

Without the Web Part Packager (which generates msi files for installation), you can do a Web Part deployment the CAB file way or the manual way.

You can automate a Web Part Packager build as part of your Visual Studio 2003 project(s), too, which is cool. I know at least two developers in my group who already do this.

Using WPPackager also installs an entry into the Add/Remove Programs box, which makes your install friendly to system administrators should they need to remove the web part. Speaking of which, here’s the Managing Web Parts on Virtual Servers section of the WSS 2003 Admin Guide.