The protocol handler cannot be found. Check that the handler has been installed.
After restoring databases from the production servers, I started a crawl. Instead of seeing "Green Messages", I just saw one error message:
The protocol handler cannot be found. Check that the handler has been installed.
I usually restore databases on the dev machine without using the preparetomove command. But today, I was really into the right mood and wanted to follow all the rules religiously. So, before detaching the database, I ran the following command:
stsadm -o preparetomove -contentdb sqlserver:dbname -site http://mymosssite
Then I detached the database using the Central Admin and started the database restoration process. Once done, I added the content database back. I was really happy that everything went smooth without any issues. It was now time to crawl the site and there for I started a full crawl on my site.But as mentioned before the crawl bombed out with the above error message. I went into the eventviewer and saw the following error messages:
The update cannot be started because the content sources cannot be accessed. Fix the errors and try the update again.
The protocol handler cannot be found. Check that the handler has been installed. (0x80040d1a)
I did not understand what was happening and so I started thinking about the changes I made. Before restoring the databases, I stopped the wss help search as I was not using it. Also, I was more inclined towards the sync between the content databases and the ssp. So, I took the following steps expecting to fix the issue:
Also, if you see the error "Error in the Site Data Web Service. (Specified argument was out of the range of valid values. Parameter name: databaseId)", run the synch -deleteolddatabases command and it should fix the error.
The protocol handler cannot be found. Check that the handler has been installed.
I usually restore databases on the dev machine without using the preparetomove command. But today, I was really into the right mood and wanted to follow all the rules religiously. So, before detaching the database, I ran the following command:
stsadm -o preparetomove -contentdb sqlserver:dbname -site http://mymosssite
Then I detached the database using the Central Admin and started the database restoration process. Once done, I added the content database back. I was really happy that everything went smooth without any issues. It was now time to crawl the site and there for I started a full crawl on my site.But as mentioned before the crawl bombed out with the above error message. I went into the eventviewer and saw the following error messages:
The update cannot be started because the content sources cannot be accessed. Fix the errors and try the update again.
The protocol handler cannot be found. Check that the handler has been installed. (0x80040d1a)
I did not understand what was happening and so I started thinking about the changes I made. Before restoring the databases, I stopped the wss help search as I was not using it. Also, I was more inclined towards the sync between the content databases and the ssp. So, I took the following steps expecting to fix the issue:
- Restarted the wss help search
- Restarted the office search - net stop osearch
- Ran the command: stsadm -o synch -deleteolddatabases 0
Also, if you see the error "Error in the Site Data Web Service. (Specified argument was out of the range of valid values. Parameter name: databaseId)", run the synch -deleteolddatabases command and it should fix the error.
2 comments:
Hi Prashanth,
Thanks for the blog post. I had the same error as you. The error occured when trying to import the user profiles from AD.
However after following your instructions the issue still occured.
I ended up looking through the registry for ProtocolHandlers. Then found HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Office Server\12.0\Search\Setup\ProtocolHandlers inside is a key for each of the protocol handlers. Searching for the class ID for SPSImport (Prog ID: OSearch.SPSImportHandler.1) I found that the path being specified was a 8.3 type path (C:\PROGRA~1\MICROS~2\12.0\Bin\SPSIMP~2.DLL) and doing a search found that the correct path was C:\PROGRA~1\MICROS~2\12.0\Bin\SPSIMP~1.DLL
Restarted osearch and the profile import worked beautifully.
Thanks for the post and great blog by the way.
Simon
This was a simple fix for us - stop the Office Search and WSS Search services (which uninstalles them), then configure, install and start them. Of course, this requires a full crawl of all content.
Post a Comment