Hi,

We have created a web service to extract information in XML format from an
Analysis Services 2000 database (cube).

We want to deploy the WebService onto our Web Server which does not (and
should not) have SQL Server or Analysis Services (in full) installed on it.

How do we manage to get the WebService to connect to the OLEDB Provider for
OLAP?

We have installed the "client tools" from the SQL Server 2000 Analysis
Services disc and we have also installed the service pack so that it matchs
our AS server.

However when we try and use UDL to ensure the connection works we get the
following error message
"Test connection failed because of an error in initializing provider.
Unspecified error."

Can anybody tell me what we need to do to get this to work. We don't really
want to have IIS installed on the AS server and we don't really want to have
to have AS installed on the IIS server.

Regards
Jayne

In the files that came with the service pack for Analysis Services there
is a file called PTSLite.exe. This file contains the OLEDB provider for
analysis services. This and MDAC are all you need to make a client
connection to AS. If you are not sure which version of MDAC you have on
the IIS Server there is another file called PTSFull.exe which contains
both the OLEDB Provider for AS and the corresponding version of MDAC.

Note that by default the web service will run as a local user. If you
want to connect to AS 2000 on another box you will need to run the web
service under a domain account that is assigned to an appropriate role
in AS.

--
Regards
Darren Gosbell [MCSD]
Blog: http://www.geekswithblogs.net/darrengosbell

In article <FC4519EF-D4A2-40EC-BDDB-A18DF3F2AE87 (AT) microsoft (DOT) com>,
JayneK (AT) discussions (DOT) microsoft.com says...

Darran,

That didn't fix the problem.

My own account is an OLAP adminstrator on the DB Server. When I log onto my
WebServer using my account the UDL (which has user and password set to a
different domain user account than my own) my connection is successful.

When I log onto the webserver using a local account even with the local
account having "act as part of the os" set I still get the error message
about initialising provider.

Now with the web server, it doesn't work at all regardless. I copied the
exact details of the UDL that works on my machine into the Web Service. I
set impersonate=true and I set the userName and password to the domain ID I
want to use. I also have machine.config ProcessModel set to the same userID
and password, but still it doesn't work.

When I have the webservice installed on the database machine (which is not a
final deployment option) it all works fine.

What should I have as my settings? I have tried so many things now I don't
really know what it should look like on the database server or the webserver.

In article <F61E7036-8744-44A9-9DF3-A230B39EFD58 (AT) microsoft (DOT) com>,
JayneK (AT) discussions (DOT) microsoft.com says...
Unless you are using HTTP authentication any username and password you
used would have been ignored and your own user account would have been
the one used to authenticate to the AS server.

This will not authenticate through to AS properly anyway unless you have
a local account on both the webserver and the AS server with *EXACTLY*
the same username and password . Also this local user on the AS server
needs to be assigned to a role in AS.

This sort of setup should work. Can you copy over the MDX Sample app
onto the webserver and see if it can connect to the AS server when you
are logged in using the domain account you have specified in the
web.config? Is there a

Normally there are only 3 main things to check:

1. That the relevant OLEDB Provider is installed an working

2. Assign your domain user to a role in AS to give it permission to
access the relevant OLAP objects.

3. If you are using IIS 6.0 - set up your application pool to use the
identity of the specified domain account.

If you are using IIS 5.0, either set the identity impersonate info in
web.config or setup the process model account in machine.config (this is
less secure as all asp.net apps on this machine will run under this
identity).


--
Regards
Darren Gosbell [MCSD]
Blog: http://www.geekswithblogs.net/darrengosbell

Hi Darren,

In the end we had to ditch using AdomdClient object and reverted back to
using ADODB connection and a standard record set. We could not get the
Microsoft.AnalysisServices.AdomdClient connection to work.

"Darren Gosbell" wrote: