Schema Retrieval Failed? Take Care When Creating Navbar Resources!
Last night, I spent a good 5 hours trying to determine why when a member of the Administrator set logged into the portal, they were receiving the Unable to process your request error page and in the event log on the Portal/Service server, the following entry was created:
Microsoft.ResourceManagement: System.InvalidOperationException: Schema
queryFilter, String queryParameters)
at Microsoft.ResourceManagement.Query.QueryProcessor.BuildSqlCommand(Query query,
at Microsoft.ResourceManagement.Query.QueryProcessor.ExecuteQuery(Query query,
Nullable`1 maximumTime, Boolean& endOfSequence, Boolean countResultsOnly,
Int64& resultCount, Int64& executionTime)
It turns out that the culprit was a nagivation bar resources that I had created to display the results of a search scope that I made only available to the Administrators' set. How is this possible? Well, if you elect to use the neat feature of being able to display the search scope's result count in the parens next to the title of the navbar resource in the portal, be VERY sure that that your Xpath is well formed AND that the set viewing it has the filter permissions to view any attributes used in that Xpath query.
If you do not, then when it comes to load the portal, you will experience what I did.
Ok, so if you are reading this, there is a chance that you already made this mistake, found my blog post (likely by Bing'n the event log entry message), and want to know how I fixed it. Well, you are in luck, because I am going to tell you that you can still access any pop-up window in the portal, because popups windows to do not contain the navigation bar. Luckily, the navigation bar resources can be edited via a popup window. Therefore, you can access the offending navigation bar control by the following URL:
The first question you will ask is: "OK, but what if I don't know the GUID of the Navbar resource?" (Cuz who writes that down right?) Well, if you know the exact display name of the Navigation Bar, there is a stored procedure in the FIMService database called debug.DisplayResourceByDisplayName, which will give you that GUID.
Now if you don't have the exact display name, there are other ways to determine it, but I have already said too much; for poking around in the FIMService database is not only unsupported outside of the explicit direction by Microsoft support, but it is EXTREMELY dangerous. You have been warned!