SQL 2005 Sept CTP connection to MSOLAP "Actively refused"

[Bob H.]

I'm sure this is a simple thing that I'm missing, like a setting in the
Surface Area Configuration wizard or some such. Please read on...

I have an x64 server (Windows 2003 Server) with a clean, named instance
(there is no "default instance) install of the Sept. MSSQL 2005 CTP
(9.0.1314) - full install all services, all with same "log on as" domain user
account. This install of the Sept CTP is the first SQL Server to ever be
installed on this machine, thus no uninstall issues.

When I try to register the Analysis Services database or connect to it in
Object Explorer, I get these 2 error messages:

"A connection cannot be made to redirector. Ensure that 'SQL Browser'
service is running. (Microsoft.AnalysisServices.AdomdClient)"

and

"No connection could be made because the target machine actively refused it
(System)"

The SQLBrowser is running. I'm logged on to the machine with a domain
account that is a local administrator. I can connect to the SQL database
engine and Integration Services instance, just not the AS instance.

I have the same problem with a 32-bit XP and a 32-bit Windows 2003 Server
installation of the Sept CTP. I have an Itanium 64-bit server with the April
CTP and do not have this problem (I can also connect successfully to the IA64
April CTP installation from the X64 Sept CTP install of MSSQL Management
Studio). I did not have this problem with the June CTP.

Any solutions, suggestions or ideas would be greatly appreciated!

--
Bob Hodgman

[Bob H.]

Additional Information:

When I install the Sept CTP 32-bit Developer on a 32-bit W2k Server sp4 and
select "local system" for the log on as account for all the 2005 services, I
do not have this problem. I can connect to the SSAS 2005 server in both the
locally installed Management Studio and a Management Studio instance on
another machine (which, incidentally, cannot connect to its own instance of
SSAS 2005).

Note also that in this successful instance, there is a prior SQL 2000
default instance.

I'm going to review the permissions granted to the domain user I used for
the "log on as" accounts for the unsuccessful installations.

More later... Feel free to chime in, everyone.

--
Bob Hodgman