After I ran the Infrastructure updates, which add new search features to MOSS 2007, I received a few errors trying to access the Search Admin interface.
When I clicked the Search administration link at /ssp/admin/default.aspx" href="http:///ssp/admin/default.aspx">/ssp/admin/default.aspx" href="http:///ssp/admin/default.aspx">http://<myserver>/ssp/admin/default.aspx, I first received this error
"The resource object with key 'S2SearchAdminDashboard_Title' was not found"
Also, the other links under the Search heading were all failing (either giving errors or giving the dreaded Unknown Error)
After searching a while on Google, I intuited the fix for this, which was to look in my Default Web Site's App_GlobalResources folder and compare it to the App_GlobalResources folder within my Shared Services Provider virtual directory. I noticed a few files that were in the Default Web Site folder, and not in the SSP folder. They had a newer date of 3/25/2008, so I copied them over to the SSP virtual directory and made a step forward. The files were:
I then tried to open the Search Administration page again, and ran into another error:
Could not find the sitemap node with URL '/SearchAdministration.aspx'.
More digging around led me to discover other files that were newer in my Default Web site that hadn't been copied to the SSP site. Within the _app_bin folder, there is a layouts.sitemap file that needs to be copied over. As soon as that was copied over, the search administration page appeared fine.
One last thing - when the page came up, there were missing images for refresh and the left and right arrows at the bottom of the screen. This was a authorization error and I discovered that my Shared Services Provider Web site was using an incorrect Application Pool. I switched it to the correct one and the images appeared. Some incorrect access rights may be why the infrastructure update failed to copy the files over in the first place.
One other possible reason for the bug in the Infrastructure update is that I changed my SSP's port number after installing SharePoint. The port number conflicted with a backup product that used the same port, and changing the port number on SharePoint was much easier than changing the port on the backup product. As a result, the name of the virtual directory folder, which usually matches the port number for that virtual directory, did not match. Perhaps the install looked for a virtual directory via the port number.