Install failure: "Error 29550. Cannot connect to the SQL server instance

I'm trying to install the Dev version of Reporting Services (RS) on one
box and have it use an Sql Server 2000 (w/SP3) instance on another box.
Both the RS and SqlServer boxes are Windows 2000 Servers. Neither are
part of a "windows domain"--neither will they ever be. We only connect
to SqlServer via a user/pwd pair. Additionally, there are 2 instances of
SqlServer running on the box and both of them listen on custom ports. (I
have confirmed that I can successfully connect to the desired SqlServer
instance from the RS box.)
The error I got was the "Login failed for user '(null)'. Reason: Not
associated with a trusted SQL Server connection.". The installer
attempts a domain login when I explicitly told it *not* to. I found no
way to get the installer to successfully connect to the database. The
solutions I've found on the web/Usenet have not worked either.
Since I couldn't get it to install through the GUI, I switched to using
an .ini file. Of course, it's not working either. The (500KB!) log file
the installer produces has only one useful line in it: "Error 29550.
Cannot connect to the SQL server instance ." That meant that the problem
was the RSDATABASESERVER variable. The instructions tell me to specify
an "SQL Server 2000 instance in format MACHINE\INSTANCENAME". I played
around with that value a lot; I wondered how it could figure out what
port to connect to for one thing. While doing so, I tried sniffing the
network to see if that would help me at all--it just got me more
frustrated: no attempt is made to contact the server! Ever.
First off: WHY choose this uncommon, inadequate format for specifying a
server? Why not just use an alias from "cliconfg" like everything else?
Second: why doesn't the installer even *try* to login to the server? If
there's a reason it can't access the network, wouldn't you think that
500KB log file is a good place to mention it?
What do I do? (Hint: don't suggest making either box part of a windows
domain)
GrangerTo have setup use sql auth during setup you must pass in command line
parameters. The params are RSSETUPACCOUNT and RSSETUPPASSWORD
so run this command
setup.exe RSSETUPACCOUNT=foo RSSETUPPASSWORD=bar
This will allow you to use the setup GUI still but all communication with
the backend server will use sql auth. Note that the setup user needs to be
a dbo. You can safely use the sa account as it is only used during setup.
--
-Daniel
This posting is provided "AS IS" with no warranties, and confers no rights.
"Granger Godbold" <granger.godbold@.FILLER.prometric.com> wrote in message
news:e4VCZaIEFHA.3888@.TK2MSFTNGP10.phx.gbl...
> I'm trying to install the Dev version of Reporting Services (RS) on one
> box and have it use an Sql Server 2000 (w/SP3) instance on another box.
> Both the RS and SqlServer boxes are Windows 2000 Servers. Neither are part
> of a "windows domain"--neither will they ever be. We only connect to
> SqlServer via a user/pwd pair. Additionally, there are 2 instances of
> SqlServer running on the box and both of them listen on custom ports. (I
> have confirmed that I can successfully connect to the desired SqlServer
> instance from the RS box.)
> The error I got was the "Login failed for user '(null)'. Reason: Not
> associated with a trusted SQL Server connection.". The installer attempts
> a domain login when I explicitly told it *not* to. I found no way to get
> the installer to successfully connect to the database. The solutions I've
> found on the web/Usenet have not worked either.
> Since I couldn't get it to install through the GUI, I switched to using an
> .ini file. Of course, it's not working either. The (500KB!) log file the
> installer produces has only one useful line in it: "Error 29550. Cannot
> connect to the SQL server instance ." That meant that the problem was the
> RSDATABASESERVER variable. The instructions tell me to specify an "SQL
> Server 2000 instance in format MACHINE\INSTANCENAME". I played around with
> that value a lot; I wondered how it could figure out what port to connect
> to for one thing. While doing so, I tried sniffing the network to see if
> that would help me at all--it just got me more frustrated: no attempt is
> made to contact the server! Ever.
> First off: WHY choose this uncommon, inadequate format for specifying a
> server? Why not just use an alias from "cliconfg" like everything else?
> Second: why doesn't the installer even *try* to login to the server? If
> there's a reason it can't access the network, wouldn't you think that
> 500KB log file is a good place to mention it?
> What do I do? (Hint: don't suggest making either box part of a windows
> domain)
> Granger|||Thanks for trying, but no, that doesn't work; I was already doing that. I was
trying to use the "sa" account from the beginning because the instructions say
the "setup" account is only used during setup.
My problem is still that the installer doesn't even *try* to connect to the
database server. Once I can get around that, my problem will be that it will
want to use Windows Authentication because the connection information only
consists of "server\instance"; that's why it has to login: to figure out the
port the instance lives at.
If anyone knows the person responsible for the decision to use this connection
method, please smack them upside the head for me.
Other ideas?
Granger
Daniel Reib [MSFT] wrote:
> To have setup use sql auth during setup you must pass in command line
> parameters. The params are RSSETUPACCOUNT and RSSETUPPASSWORD
> so run this command
> setup.exe RSSETUPACCOUNT=foo RSSETUPPASSWORD=bar
> This will allow you to use the setup GUI still but all communication with
> the backend server will use sql auth. Note that the setup user needs to be
> a dbo. You can safely use the sa account as it is only used during setup.
>|||Well first of all, if you want it to connect, what does your client
configuration say?
I take it that on the general tab you have TCP/IP listed at the top - click
the properties tab and is the port set correctly for your particular
instance?
I am running reporting services stand-alone - with SQL Server NOT IN A
DOMAIN - and it runs just fine.
You can also create an ALIAS name to the server instance in the SQL Server
Client Network utility.
Finally, just to be sure we are "connecting the dots" here - fire up the SQL
Server Network utility and verify that the TCP/IP properties are also
listening on the correct port. (I bet they are since you are using the
system successfully)
Last but not least, even if you are using SQL Server authentication, you
should be able to use windows authentication only when doing the setup -
since as you said you have full control over the dev box - then you have
local admin rights - therefore you should be able to logon unless you have
modifed the BUILTIN\Administrators security for that machine. (I assume that
this is not the case).
Please let me know if you are still having an issue, I'll be happy to help
you out.
Of course, this may come as a dumb question, but I assume nothing: Did you
install SP3a for SQL Server? (I assume yes), did you install the SQL Server
hotfix 859 ?
=-Chris
"Granger Godbold" <granger.godbold@.invalid.prometric.com> wrote in message
news:ucLN4gZEFHA.3256@.tk2msftngp13.phx.gbl...
> Thanks for trying, but no, that doesn't work; I was already doing that. I
> was trying to use the "sa" account from the beginning because the
> instructions say the "setup" account is only used during setup.
> My problem is still that the installer doesn't even *try* to connect to
> the database server. Once I can get around that, my problem will be that
> it will want to use Windows Authentication because the connection
> information only consists of "server\instance"; that's why it has to
> login: to figure out the port the instance lives at.
> If anyone knows the person responsible for the decision to use this
> connection method, please smack them upside the head for me.
> Other ideas?
> Granger
>
> Daniel Reib [MSFT] wrote:
>> To have setup use sql auth during setup you must pass in command line
>> parameters. The params are RSSETUPACCOUNT and RSSETUPPASSWORD
>> so run this command
>> setup.exe RSSETUPACCOUNT=foo RSSETUPPASSWORD=bar
>> This will allow you to use the setup GUI still but all communication with
>> the backend server will use sql auth. Note that the setup user needs to
>> be a dbo. You can safely use the sa account as it is only used during
>> setup.|||Thanks Chris.
The connectivity is all OK. It appears I'm just going to have to go
sync the administrators on each of the boxes during the install.
However, that won't be for a while; I just gave up and installed
everything on my own box for now. When I've had a chance to play with it
for a while, I'll do another install attempt in a more "proper" DEV
environment.
As far as the updates on the database go, my DBA says he's only done
security bulletin stuff. I looked it over and it seems the DEV box has
SP3 not SP3a (I checked the Ssnetlib.dll; we have 2000.80.760 not
2000.80.766
(http://support.microsoft.com/default.aspx?scid=kb;en-us;819334)). Also,
since Enterprise Manager reports 8.00.760, I gather he's not done any
hotfixes. This KnowledgeBase article
(http://support.microsoft.com/default.aspx?scid=kb;en-us;888007) implies
we should be at least at .977. I'll go tease him for being a slacker. ;)
I wouldn't guess the hotfixes would have anything to do with my
problem, however, since my local database only has SP3 installed on it
and ReportingServices installed fine.
Again, thanks Chris =)
Granger
Christopher Conner wrote:
<snip>
> Last but not least, even if you are using SQL Server authentication, you
> should be able to use windows authentication only when doing the setup -
> since as you said you have full control over the dev box - then you have
> local admin rights - therefore you should be able to logon unless you have
> modifed the BUILTIN\Administrators security for that machine. (I assume that
> this is not the case).
> Please let me know if you are still having an issue, I'll be happy to help
> you out.
> Of course, this may come as a dumb question, but I assume nothing: Did you
> install SP3a for SQL Server? (I assume yes), did you install the SQL Server
> hotfix 859 ?
> =-Chris
>sql