registering SQL Server not in domain

Hi all,

We have standardized on Hyperion as our reporting tool.  So far I have
only set up a couple of Access databases as data sources for it.  Now
there is a request to report off our eOn (telephony management) SQL
Server database using Hyperion.  The eOn SQL Server box is in a
workgroup that is not part of the rest of our domain.  (We only have
one domain because we don't have a "forest", whatever that means.)  It
is behind a router owned by eOn along with a PBX and some other stuff.


Setting up a data source for Hyperion requires creating a special data
source file called an .oce on the box where the Hyperion fat client
(required for most administrative tasks) resides, and also setting up a
different special data source file called a .das on the server where
the Hyperion services run.  (The analysts and end-users do not have the
fat client, their access is web-based.)

I have to register the eOn SQL Server by using the IP address and SQL
Server authentication.  (I was told that I can't use Windows
authentication because it is not in the domain.)   From the box on
which the Hyperion fat client resides, I cannot register the eOn SQL
Server.  The error message is "timeout expired".  Tracerting indicates
there are no intermediate hops when attempting to connect from this
VLAN.  From my desktop, which is on a different VLAN, I can connect to
and register it.  This trip includes one hop at our 6509.  From one of
my servers which is on the same VLAN as the fat-client box, I am able
to connect and register.   On the fat-client box I tried deleting and
re-registering another SQL Server and there was no problem.

The IP address I have to use to connect to the eOn SQL Server is *NOT*
the actual IP address of the box it resides on, but rather the eOn
router, which translates it to the address of the server.  We have no
control over this, eOn creates this setup.  I'm not sure how it knows
which of the devices behind it a given message is for.

Ideas?

From your description I pulled this sentence.

"From my desktop, which is on a different VLAN, I can connect to
and register it."

This indicates that you have a valid SQL login, password, protocol, and ip
address.  Analyse you desktop and figure out what these are.  In particular
the protocol.
The protocol, Network routing, and possibly the firewall will be the issue.

The two most common protocols for SQL is Named Pipes and TCP.

If you can get to the SQL Server from your desktop, look at the SQL Server
Log for what protocols are supported.
From the Hyperion services server use this information to configure an ODBC
DSN and test the connection.  You may want to install the SQL client only
option on your Hyperion server to give you more control over the connection
setup (AKA a SQL Alias)


"Ellen K" <ekaye2002@yahoo.com> wrote in message
news:1129150328.960539.76600@g47g2000cwa.googlegroups.com...
> Hi all,
>
> We have standardized on Hyperion as our reporting tool.  So far I have
> only set up a couple of Access databases as data sources for it.  Now
> there is a request to report off our eOn (telephony management) SQL
> Server database using Hyperion.  The eOn SQL Server box is in a
> workgroup that is not part of the rest of our domain.  (We only have
> one domain because we don't have a "forest", whatever that means.)  It
> is behind a router owned by eOn along with a PBX and some other stuff.
>
>
> Setting up a data source for Hyperion requires creating a special data
> source file called an .oce on the box where the Hyperion fat client
> (required for most administrative tasks) resides, and also setting up a
> different special data source file called a .das on the server where
> the Hyperion services run.  (The analysts and end-users do not have the
> fat client, their access is web-based.)
>
> I have to register the eOn SQL Server by using the IP address and SQL
> Server authentication.  (I was told that I can't use Windows
> authentication because it is not in the domain.)   From the box on
> which the Hyperion fat client resides, I cannot register the eOn SQL
> Server.  The error message is "timeout expired".  Tracerting indicates
> there are no intermediate hops when attempting to connect from this
> VLAN.  From my desktop, which is on a different VLAN, I can connect to
> and register it.  This trip includes one hop at our 6509.  From one of
> my servers which is on the same VLAN as the fat-client box, I am able
> to connect and register.   On the fat-client box I tried deleting and
> re-registering another SQL Server and there was no problem.
>
> The IP address I have to use to connect to the eOn SQL Server is *NOT*
> the actual IP address of the box it resides on, but rather the eOn
> router, which translates it to the address of the server.  We have no
> control over this, eOn creates this setup.  I'm not sure how it knows
> which of the devices behind it a given message is for.
>
> Ideas?
>

Hi,

Thanks very much for your response.    :)

I think network routing has been eliminated as the cause because I was
able to register the eOn server from one of "my" SQL Servers which is
on the same VLAN as the fat client box that can't register it.  And it
can't be a firewall issue because the eOn box is behind our firewall,
it's just not in our domain.  I did not think to check the protocols,
that is definitely worth a try.  It did occur to me to set up the eOn
database as an ODBC connection for Hyperion instead of using the SQL
Server option, which if it works would solve the current problem.
However, I am also concerned because I am meanwhile building a data
warehouse in SQL Server for which Hyperion is supposed to be the
reporting tool and I would hate to have make a choice that I know up
front is going to diminish performance.

Thanks again, I will report back.

Ellen

Hi again,

Well, it's not the network protocols.

I did notice that the eOn box is running the original version of SQL
Server, i.e. no service packs have been applied.  I will take care of
that, but would be surprised if it's causing the problem.

Meanwhile I did succeed in setting up an ODBC connection, so I've
solved my immediate problem.

Thanks again,

Ellen