Hi All:



I am trying to setup HTTP access (msmdpump.dll) to SSAS on a web server box
where there is no Analysis Services installed. The goal is to prevent IIS
running on SSAS box itself. I have no luck so far. Is this configuration
even possible?

I have installed the following components on the web server in the order
below:

1. msmdpump.dll:
http://www.microsoft.com/technet/pro.../httpasws.mspx

2. MSXML 6.0

3. Microsoft SQL Server 2005 Analysis Services 9.0 OLE DB Provider

4. Microsoft SQL Server Native Client

5. Microsoft SQL Server 2005 Management Objects Collection



When I try to connect and execute a query against msmdpump.dll via ascmd
utility I am getting an error "ascmd: AMO connection error on connect string
(Provider=MSOLAP.3;Data
Source="http://webserver/olap/msmdpump.dll";SspropInitAppName=ascmd): An
error was encountered in the transport layer. The peer prematurely closed
the connection."



Everything is OK in case msmdpump.dll is setup on SSAS server.



Has anyone succeeded in this?

I think the ascmd utility cannot be used with the HTTP access.
the HTTP (XML/A) is designed for client access not administrative access.

can you access your server using a client tool through the HTTP connection?
(Like from Excel)
If no, verify your Kerberos setup.
If yes, then the problem is related to the ascmd utility which cannot access
through HTTP.

Also, have you try to remove the " (quote) around the HTTP server name?

"Mitak" <dkfake (AT) hotmail (DOT) com> wrote

It is OK to use ascmd with http.

No, I can't access the server through http with the setup described in my
initial post. However, I can access the server with no http.

I have http access setup on two other SSAS servers and it works in both
cases. What I have tried is to point the http setup on one of the servers to
the other and it didn't work. This kind of convinces me that http connection
setup on a different server than the one which hosts SSAS is not possible.

Thanks

"Jéjé" <willgart_A_ (AT) hotmail_A_ (DOT) com> wrote

you can use 2 different servers.
but you have to setup the kerberos delegation system if you use the NTLM
authentication

using the basic authentication method the access should works fine.

which authentication method do you use for your /OLAP virtual directory?

"Mitak" <dkfake (AT) hotmail (DOT) com> wrote

I use integrated windows authentication. So you are suggesting to try basic
authentication?
How would I setup this kerberos delegation system? I have never done this so
far.

"Jéjé" <willgart_A_ (AT) hotmail_A_ (DOT) com> wrote

search on the MS website these keywords:
IIS Kerberos.

the 2 servers must be member of the same domain.
you have to download the setspn tool

after this,
change the IIS configuration :
cscript adsutil.vbs set w3svc/<1>/NTAuthenticationProviders "Negotiate,NTLM"
where <1> is the IIS virtual server ID

this cause that your virtual server support both kerberos and NTLM security.

setspn:
http://www.microsoft.com/downloads/d...displaylang=en

execute this command:
Setspn -A HTTP/<URLUsedbytheenduser> <webserver1>

<URLUsedbytheenduser> like "www.mydomain.com"
<webserver1> is the server name on the network, registered in the Active
directory.
if your application pool use a domain user and NOT the network service or
local service account replace <webserver1>
by <domain\username of the app pool>
you MUST use the same account for ALL the applications deployed on an IIS
virtual server because the kerberos is applied only at the domain name level
(<URLUsedbytheenduser>) and NOT at the application level
(<URLUsedbytheenduser>/myxmla)
if you have some application which use 1 account and another application
which used another account this can break the kerberos delegation.
take care its HTTP/ and NOT HTTP://
if you are using a port which is not the default 80 port add it:
Setspn -A HTTP/<URLUsedbytheenduser>:<myport> <webserver1>


and finally, trust the server for delegation:
http://support.microsoft.com/kb/326985/en-us#4
If this IIS server is a member of the domain but is not a domain controller,
the computer must be trusted for delegation for Kerberos to work properly.
To enable this, follow these steps:
1. On the domain controller, click Start, point to Settings, and then click
Control Panel.
2. Double-click the Administrative Tools folder, and then double-click
Active Directory Users and Computers.
3. Under your domain, click the Computers folder.
4. In the list, locate the IIS server. Right-click the server name, and then
click Properties.
5. Click the General tab, click to select the Trusted for delegation check
box, and then click OK.


now, when you access SSAS thourgh this IIS connection, make sure that the
URL is <URLUsedbytheenduser>
if the name is not EXACTLY the same, the kerberos delegation will not work.
you can add aliases using the setspn utility like HTTP/<mynetbiosname> or
HTTP/<mynetbiosname.mylocaldomain.local> ...

also, if you change your application pool's account from the machine to a
domain user AFTER the kerberos setup, make sure you'll remove ALL the
entries using the setspn utility and then add them again to the new account.
if you don't do this you'll suffer issues because the system will detect
duplicates entries.

and to finish...
kerberos is really sensitive to the network architecture, users outside a
firewall will not be authorized. Generally firewalls dislike this protocol.

good luck!!!!

"Mitak" <dkfake (AT) hotmail (DOT) com> wrote