My HServer log file is showing the following error message:
HServer | 20070627 10:40:57 | Connecting through datasource harvest using user haradmin... HServer | 20070627 10:41:58 | ERROR: E0302004d: Cannot connect to the datasource harvest as user haradmin. HServer | 20070627 10:41:58 | ERROR: [Microsoft][ODBC SQL Server Driver] [SQL Server]Login failed for user 'MY_DOMAIN\MY_USER_ID'. SQLSTATE=28000HServer | 20070627 10:41:58 | ERROR: Initialization fails
The odd thing is, the Harvest portion of the error message shows one user id ( haradmin ), and the ODBC portion of the error message show another user id ( MY_DOMAIN\MY_USER_ID ). Where are these user ids coming from and which one is really being used?
The user id found in the Harvest portion of the message is coming from either Harvest's hsvr.dfo file (created with the ' svrenc -s ...' command), or the ' -user ' argument in your HServer.arg file, if that exists.
To understand the user id in the ODBC portion of the message, we need to look at the properties of the Harvest data source. To find this info, refer to the %HARVESTHOME%\HServer.arg 's -datasource option. This argument identifies the data source that Harvest uses. Now look at the Windows ODBC Data Sources Control Panel applet, switch to System DSN tab and then identify the data source definition there. Click on Configure to launch the properties of this datasource.
<Please see attached file for image>
If "With Windows NT Authentication..." has been selected on this panel, ODBC will attempt to connect to the database using the Windows user id and password belonging to the user that started the process.
If "With SQL Server Authentication..." has been selected, ODBC will attempt to connect to the database using the user id and password from the hsvr.dfo file, which is passed to it by the broker process.
Either way, the user id must be a valid SQL Server login ID with permissions to the CA MDB database in order for the login to succeed.
In case of the specific error message above, the user had specified "With Windows NT Authentication" in their ODBC properties, but had not set up the user id (that started the broker) inside SQL Server as a valid login ID. Instead the user id he wanted to use was the one in his hsvr.dfo file.
The problem was resolved by changing the ODBC setting to "With SQL Server Authentication..."