One of the more common critical iMIS errors involves a failed attempt to build the sitemap. In the currently released version of iMIS, the errors discussed below will result in the application server being unable to load. In an upcoming update, iMIS will at least continue to work until the application pool is recycled, giving you a little bit of time to resolve the problem.

In existing versions, the problem will manifest itself either as errors publishing a website or navigation item(s), or as an ASP.NET worker pool crash with no error message. In the upcoming version, iMIS will log an error similar to the following in the Windows Application Event log rather than crashing:

Event code: 150001
Event message: An attempt to build the sitemap failed: The parent hierarchy object for document MyAccount (DocumentVersionKey 1cdda849-dad9-49a4-b3b7-930339e84bf1, HierarchyKey 462d7837-9974-4719-be3b-a2e79c43ddc6) is missing.

This error is generally due to a navigation item becoming orphaned (literally losing the information that connects it to its parent navigation item). The problem may be due to some versions of iMIS mishandling drag-and-drop operations on navigation items.

The steps below can be used to diagnose and resolve the issue.

Earlier versions (no helpful error message)

If you do not have a helpful error message like the above, you'll need to do some basic digging to uncover the problematic navigation item. The query below will identify any orphaned items to give you a starting point:

SELECT * FROM [dbo].[vBoNavigationHierarchy] WHERE [ParentHierarchyKey] IS NULL AND [HierarchyKey] <> [RootHierarchyKey]

This query should not return any rows if things are working correctly. It will return any orphaned rows that exist.

Assuming this query does return one or more rows, note the HierarchyKey of the offending row(s).

After identifying the problematic HierarchyKey

Substitute the HierarchyKey(s) of the problematic rows into this query. What this will do is give you a complete layout of how the website should look (i.e. in Manage sitemaps, if you were to expand all nodes):

SELECT [HierarchyKey], [ParentHierarchyKey], [Depth], [DocumentName] FROM [dbo].[vBoNavigationHierarchy] 
WHERE [RootHierarchyKey] =
    (SELECT [RootHierarchyKey] FROM [dbo].[vBoNavigationHierarchy] WHERE [HierarchyKey] = ?)
ORDER BY [RootHierarchyKey],[SortOrder]

This will give you a result set similar to this:

The orphaned item(s) are any that have a NULL ParentHierarchyKey that are not the root node (~).

There are two ways to fix the problem. The simplest is just to reparent the orphaned nodes under the root; however, if the orphan was not originally directly under the root, you will then need to drag the repaired node to the correct point in the hierarchy and republish. The SQL below will reparent the item; make sure you substitute in the correct HierarchyKey (of the orphaned item).

UPDATE [dbo].[Hierarchy] SET [ParentHierarchyKey] = [RootHierarchyKey] WHERE [HierarchyKey] = ?

The slightly more involved solution is to identify the original parent and reparent the item correctly. To identify the parent, look at the resultset you got above and locate the last item in the list which appears above the orphaned item whose Depth is less than the Depth of the orphaned item. In the screenshot above, this is the MemberServices item, because it is the last item before the orphaned MyAccount item whose Depth (1) is less than MyAccount's Depth (2).

You can then use the following SQL, setting the orphaned item's ParentHierarchyKey to the HierarchyKey of its correct parent:

UPDATE [dbo].[Hierarchy] SET [ParentHierarchyKey] = ? WHERE [HierarchyKey] = ?

The sitemap should now build correctly; you can either recycle IIS or the app pool (if the application has crashed or won't start) or wait for the site to attempt another rebuild (if it is currently working, it will pick up the changes within 15 minutes).