Registry Permissions for on demand pull subscription

To configure an on-demand pull subscription, the domain user account used by
the SQL Server Agent service must have full control permissions on the
registry key: HKLM\Software\Microsoft\Microsoft SQL
Server\80\Replication\Subscriptions. When I attempt to use the registry
editor to configure the permissions, the subscriptions portion of the key is
not present. I am running Win 2000 Server and SQL Server 2000. I am logged on
as an administrator, and I have sucessfully created a merge publication and a
push subcription. Any thoughts on what may be my problem? What SQL process
creates the subscriptions entry in the registery?
Tom McAvoy, MCP
The subscriptions portion of the key can be filled in by using reg files,
but the preferred way of doing it is having Windows Synchronization Manager,
or the ActiveX Controls make these changes.
When you create your push (only through the procs), or you pull (procs or
wizards), ensure you select on demand pull. This will register your
subscription and make the necessary registry entries.
If you did not do this, you will have to configure your pull subcription
withing WSM.
Hilary Cotter
Looking for a book on SQL Server replication?
http://www.nwsu.com/0974973602.html
"Tom McAvoy" <TomMcAvoy@.discussions.microsoft.com> wrote in message
news:7E02406B-F211-49F4-B1FD-41C2B6127F4A@.microsoft.com...
> To configure an on-demand pull subscription, the domain user account used
by
> the SQL Server Agent service must have full control permissions on the
> registry key: HKLM\Software\Microsoft\Microsoft SQL
> Server\80\Replication\Subscriptions. When I attempt to use the registry
> editor to configure the permissions, the subscriptions portion of the key
is
> not present. I am running Win 2000 Server and SQL Server 2000. I am logged
on
> as an administrator, and I have sucessfully created a merge publication
and a
> push subcription. Any thoughts on what may be my problem? What SQL process
> creates the subscriptions entry in the registery?
> --
> Tom McAvoy, MCP
|||Hillary, thank you for the response. I am unable to create the 'on-demand
pull' subscription due to the lack of permissions on the registry key. I
receive an 'access denied error'. I don't have the exact error info
avaialble right now. I'll review the problem on Monday and post more complete
error info.
"Hilary Cotter" wrote:

> The subscriptions portion of the key can be filled in by using reg files,
> but the preferred way of doing it is having Windows Synchronization Manager,
> or the ActiveX Controls make these changes.
> When you create your push (only through the procs), or you pull (procs or
> wizards), ensure you select on demand pull. This will register your
> subscription and make the necessary registry entries.
> If you did not do this, you will have to configure your pull subcription
> withing WSM.
> --
> Hilary Cotter
> Looking for a book on SQL Server replication?
> http://www.nwsu.com/0974973602.html
>
> "Tom McAvoy" <TomMcAvoy@.discussions.microsoft.com> wrote in message
> news:7E02406B-F211-49F4-B1FD-41C2B6127F4A@.microsoft.com...
> by
> is
> on
> and a
>
>
|||It seems that you need to be a power user or admin on the machine you are
trying to pull the subscription to.
Also the account which is doing the pulling should be in the PAL.
"Tom McAvoy" <TomMcAvoy@.discussions.microsoft.com> wrote in message
news:8518A10B-BFB3-4C4D-A6E4-8A605F129C22@.microsoft.com...
> Hillary, thank you for the response. I am unable to create the 'on-demand
> pull' subscription due to the lack of permissions on the registry key. I
> receive an 'access denied error'. I don't have the exact error info
> avaialble right now. I'll review the problem on Monday and post more
complete[vbcol=seagreen]
> error info.
> "Hilary Cotter" wrote:
files,[vbcol=seagreen]
Manager,[vbcol=seagreen]
or[vbcol=seagreen]
used[vbcol=seagreen]
registry[vbcol=seagreen]
key[vbcol=seagreen]
logged[vbcol=seagreen]
publication[vbcol=seagreen]
process[vbcol=seagreen]

Registry information

All,
If I wanted to establish the versions of a SQL Server installs
programatically throughout my domain, what in your opinion would be the best
method WITHOUT connecting to SQL. I can connect to each machine without
issue, but I need to now gather the information on SQL.
I've been looking at registry keys, but am not confident this can provide
the information I need. Can anybody please advise?
Many Thanks
Adam
--
Adam J WarneYou can get the version info from registry. But it's messy, probably not
supported, and changes from version to version. If all possible, I'd try to
get the version info from within the SQL instance usign the SERVERPROPERTY
function. (I'd reason that if you can access registry directly, you probably
should be able to get a login to access the SQL instances for their verison
info. But then having the login for the SQL instances is a different
practical story.)
Having said that, if you really want to get the version info from registry
for SQL2000, you may find it here (No guarantee and you need to verify it
yourself):
1. Get the installed instances from HKLM\Software\Microsoft\Microsoft SQL
Server\InstalledInstances
2. Loop through the registry entries for the installed named instances to
get their versions
HKLM\Software\Microsoft\Microsoft SQL
Server\<InstanceName>\MSSQLServer\CurrentVersion\CSDVersion
For SQL2005, look in:
HKLM\Software\Microsoft\Microsoft SQL
Server\MSSQL.<#>\MSSQLServer\CurrentVersion\CurrentVersion
Again, it's better not to directly lookup registry for the SQL verison info.
Linchi
"Adam Warne" wrote:
> All,
> If I wanted to establish the versions of a SQL Server installs
> programatically throughout my domain, what in your opinion would be the best
> method WITHOUT connecting to SQL. I can connect to each machine without
> issue, but I need to now gather the information on SQL.
> I've been looking at registry keys, but am not confident this can provide
> the information I need. Can anybody please advise?
> Many Thanks
> Adam
> --
> Adam J Warne

Registry information

All,
If I wanted to establish the versions of a SQL Server installs
programatically throughout my domain, what in your opinion would be the best
method WITHOUT connecting to SQL. I can connect to each machine without
issue, but I need to now gather the information on SQL.
I've been looking at registry keys, but am not confident this can provide
the information I need. Can anybody please advise?
Many Thanks
Adam
--
Adam J WarneYou can get the version info from registry. But it's messy, probably not
supported, and changes from version to version. If all possible, I'd try to
get the version info from within the SQL instance usign the SERVERPROPERTY
function. (I'd reason that if you can access registry directly, you probably
should be able to get a login to access the SQL instances for their verison
info. But then having the login for the SQL instances is a different
practical story.)
Having said that, if you really want to get the version info from registry
for SQL2000, you may find it here (No guarantee and you need to verify it
yourself):
1. Get the installed instances from HKLM\Software\Microsoft\Microsoft SQL
Server\InstalledInstances
2. Loop through the registry entries for the installed named instances to
get their versions
HKLM\Software\Microsoft\Microsoft SQL
Server\<InstanceName>\MSSQLServer\CurrentVersion\CSDVersion
For SQL2005, look in:
HKLM\Software\Microsoft\Microsoft SQL
Server\MSSQL.<#> \MSSQLServer\CurrentVersion\CurrentVersi
on
Again, it's better not to directly lookup registry for the SQL verison info.
Linchi
"Adam Warne" wrote:

> All,
> If I wanted to establish the versions of a SQL Server installs
> programatically throughout my domain, what in your opinion would be the be
st
> method WITHOUT connecting to SQL. I can connect to each machine without
> issue, but I need to now gather the information on SQL.
> I've been looking at registry keys, but am not confident this can provide
> the information I need. Can anybody please advise?
> Many Thanks
> Adam
> --
> Adam J Warne

registering sql server problem

Trying to register a sql server in enterprise manager and
the server is on another domain which is trusted. The
server doesn't show up in the 'available servers' list
but I can register with ip address but *not* if I use
Client Network utility with exactly the correct netbios
name. Any ideas? Thanks.If the server isn't appearing in the list of available servers, chances are
that you need to add the IP address and server name to your hosts file. In
Win2k, the hosts file is located in c:\winnt\system32\driver\etc.
Open the hosts file in notepad, go to the end of the file, enter the IP
address, tab once and add the server name as follows:
xxx.xxx.xxx.xxx <tab> servername
John
"Dave Wilce" wrote:
> Trying to register a sql server in enterprise manager and
> the server is on another domain which is trusted. The
> server doesn't show up in the 'available servers' list
> but I can register with ip address but *not* if I use
> Client Network utility with exactly the correct netbios
> name. Any ideas? Thanks.
>|||We have tried 3 things :-
Using the Client Network utility does make the server
show up in the list but it will not register.
Using IP address it will allow registration but we hit
problems later (and we think it's because we use IP
address rather than NETBios name.
Using host file doesn't help...|||"Dave Wilce" wrote:
> We have tried 3 things :-
> Using the Client Network utility does make the server
> show up in the list but it will not register.
> Using IP address it will allow registration but we hit
> problems later (and we think it's because we use IP
> address rather than NETBios name.
> Using host file doesn't help...
Thinking out loud here...
Are you going through a firewall? Are you using the default port in the
Client Network utility (1433), and is the firewall open to that port? Can
you ping the other server using the server name? Can you have the your
network people make sure the server is listed in their DNS database correctly?
John

registering sql server problem

Trying to register a sql server in enterprise manager and
the server is on another domain which is trusted. The
server doesn't show up in the 'available servers' list
but I can register with ip address but *not* if I use
Client Network utility with exactly the correct netbios
name. Any ideas? Thanks.
If the server isn't appearing in the list of available servers, chances are
that you need to add the IP address and server name to your hosts file. In
Win2k, the hosts file is located in c:\winnt\system32\driver\etc.
Open the hosts file in notepad, go to the end of the file, enter the IP
address, tab once and add the server name as follows:
xxx.xxx.xxx.xxx <tab> servername
John
"Dave Wilce" wrote:

> Trying to register a sql server in enterprise manager and
> the server is on another domain which is trusted. The
> server doesn't show up in the 'available servers' list
> but I can register with ip address but *not* if I use
> Client Network utility with exactly the correct netbios
> name. Any ideas? Thanks.
>
|||We have tried 3 things :-
Using the Client Network utility does make the server
show up in the list but it will not register.
Using IP address it will allow registration but we hit
problems later (and we think it's because we use IP
address rather than NETBios name.
Using host file doesn't help...
|||"Dave Wilce" wrote:

> We have tried 3 things :-
> Using the Client Network utility does make the server
> show up in the list but it will not register.
> Using IP address it will allow registration but we hit
> problems later (and we think it's because we use IP
> address rather than NETBios name.
> Using host file doesn't help...
Thinking out loud here...
Are you going through a firewall? Are you using the default port in the
Client Network utility (1433), and is the firewall open to that port? Can
you ping the other server using the server name? Can you have the your
network people make sure the server is listed in their DNS database correctly?
John

registering sql server problem

Trying to register a sql server in enterprise manager and
the server is on another domain which is trusted. The
server doesn't show up in the 'available servers' list
but I can register with ip address but *not* if I use
Client Network utility with exactly the correct netbios
name. Any ideas? Thanks.If the server isn't appearing in the list of available servers, chances are
that you need to add the IP address and server name to your hosts file. In
Win2k, the hosts file is located in c:\winnt\system32\driver\etc.
Open the hosts file in notepad, go to the end of the file, enter the IP
address, tab once and add the server name as follows:
xxx.xxx.xxx.xxx <tab> servername
John
"Dave Wilce" wrote:

> Trying to register a sql server in enterprise manager and
> the server is on another domain which is trusted. The
> server doesn't show up in the 'available servers' list
> but I can register with ip address but *not* if I use
> Client Network utility with exactly the correct netbios
> name. Any ideas? Thanks.
>|||We have tried 3 things :-
Using the Client Network utility does make the server
show up in the list but it will not register.
Using IP address it will allow registration but we hit
problems later (and we think it's because we use IP
address rather than NETBios name.
Using host file doesn't help...|||"Dave Wilce" wrote:

> We have tried 3 things :-
> Using the Client Network utility does make the server
> show up in the list but it will not register.
> Using IP address it will allow registration but we hit
> problems later (and we think it's because we use IP
> address rather than NETBios name.
> Using host file doesn't help...
Thinking out loud here...
Are you going through a firewall? Are you using the default port in the
Client Network utility (1433), and is the firewall open to that port? Can
you ping the other server using the server name? Can you have the your
network people make sure the server is listed in their DNS database correctl
y?
John

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?Hi
Which version of SQL Server is on the telephony management system? At a
guess it is MSDE with no network protocols installed! Use svrnetcn.exe to
enable the network protcols. If they are running you may want to use the
SQLRecon tool to see what servers are available on your network
http://www.sqlsecurity.com/DesktopDefault.aspx?tabid=26
John
"Ellen K" wrote:
> 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 John,
Thanks for your response. I will check the version and also check
which network protocols are enabled on it, assuming I can get to the
box. But if the problem were no network protocols installed on the eOn
box then how would the other two boxes that CAN register it be able to
do so?
Thanks,
Ellen|||Hi
I hadn't realised that it could be registered elsewhere! This indicates that
there are network protocols, but they still may not be the same as the ones
on the client that can't register!! You may still want to try running
SQLRecon and also try to telnet into the port being used.
John
"Ellen K" wrote:
> Hi John,
> Thanks for your response. I will check the version and also check
> which network protocols are enabled on it, assuming I can get to the
> box. But if the problem were no network protocols installed on the eOn
> box then how would the other two boxes that CAN register it be able to
> do so?
> Thanks,
> Ellen
>|||Hi John,
Yes, I mentioned in my original post that I could register it from both
my desktop and from one of "my" servers.
The network protocols are the same on the eOn box as on "my" servers:
named pipes and tcp. Since the fat client can connect to "my" servers,
I think it's safe to say this isn't the problem.
I have now succeeded in creating an ODBC connection, which would not
have been my first choice, but right now if it works I'm happy.
Thanks,
Ellen

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?
Hi
Which version of SQL Server is on the telephony management system? At a
guess it is MSDE with no network protocols installed! Use svrnetcn.exe to
enable the network protcols. If they are running you may want to use the
SQLRecon tool to see what servers are available on your network
http://www.sqlsecurity.com/DesktopDefault.aspx?tabid=26
John
"Ellen K" wrote:

> 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 John,
Thanks for your response. I will check the version and also check
which network protocols are enabled on it, assuming I can get to the
box. But if the problem were no network protocols installed on the eOn
box then how would the other two boxes that CAN register it be able to
do so?
Thanks,
Ellen
|||Hi
I hadn't realised that it could be registered elsewhere! This indicates that
there are network protocols, but they still may not be the same as the ones
on the client that can't register!! You may still want to try running
SQLRecon and also try to telnet into the port being used.
John
"Ellen K" wrote:

> Hi John,
> Thanks for your response. I will check the version and also check
> which network protocols are enabled on it, assuming I can get to the
> box. But if the problem were no network protocols installed on the eOn
> box then how would the other two boxes that CAN register it be able to
> do so?
> Thanks,
> Ellen
>
|||Hi John,
Yes, I mentioned in my original post that I could register it from both
my desktop and from one of "my" servers.
The network protocols are the same on the eOn box as on "my" servers:
named pipes and tcp. Since the fat client can connect to "my" servers,
I think it's safe to say this isn't the problem.
I have now succeeded in creating an ODBC connection, which would not
have been my first choice, but right now if it works I'm happy.
Thanks,
Ellen

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.googlegro ups.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

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?Hi
Which version of SQL Server is on the telephony management system? At a
guess it is MSDE with no network protocols installed! Use svrnetcn.exe to
enable the network protcols. If they are running you may want to use the
SQLRecon tool to see what servers are available on your network
http://www.sqlsecurity.com/DesktopDefault.aspx?tabid=26
John
"Ellen K" wrote:

> 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 John,
Thanks for your response. I will check the version and also check
which network protocols are enabled on it, assuming I can get to the
box. But if the problem were no network protocols installed on the eOn
box then how would the other two boxes that CAN register it be able to
do so?
Thanks,
Ellen|||Hi
I hadn't realised that it could be registered elsewhere! This indicates that
there are network protocols, but they still may not be the same as the ones
on the client that can't register!! You may still want to try running
SQLRecon and also try to telnet into the port being used.
John
"Ellen K" wrote:

> Hi John,
> Thanks for your response. I will check the version and also check
> which network protocols are enabled on it, assuming I can get to the
> box. But if the problem were no network protocols installed on the eOn
> box then how would the other two boxes that CAN register it be able to
> do so?
> Thanks,
> Ellen
>|||Hi John,
Yes, I mentioned in my original post that I could register it from both
my desktop and from one of "my" servers.
The network protocols are the same on the eOn box as on "my" servers:
named pipes and tcp. Since the fat client can connect to "my" servers,
I think it's safe to say this isn't the problem.
I have now succeeded in creating an ODBC connection, which would not
have been my first choice, but right now if it works I'm happy.
Thanks,
Ellen

Registered Servers in EM disappear after your machine login changes

We recently migrated from a domain authentication structure to an Active Directory structure in my office and the 90+ SQL Servers that I had registered in SQL Server Enterprise Manager are no longer registered when I enter Enterprise Manager under my new AD login. If I go to [HKEY_USERS\S-1-5-21-10907285-1067259047-1047869632-3055\Software\Microsoft\Microsoft SQL Server\80\Tools\SQLEW\Registered Servers X\SQL Server Group] in the registry I do see all of my servers registered there, but can't access them via EM, unless I re-register each one.
Can I access these servers without re-registering each of them? Is the server registration process linked to my old SID, thus why I can't see them in EM with my new AD userID?
Thanks,
DaveYes, it has to do with the SID. I have some scripts that can export
registrations to a file, from which you can import them onto another/same
machine. But they are not useful anymore, as we don't have the old login
anymore.
--
HTH,
Vyas, MVP (SQL Server)
http://vyaskn.tripod.com/
What hardware is your SQL Server running on?
http://vyaskn.tripod.com/poll.htm
"Dave" <anonymous@.discussions.microsoft.com> wrote in message
news:59A20FD6-C194-412C-998D-E45E17C204E1@.microsoft.com...
We recently migrated from a domain authentication structure to an Active
Directory structure in my office and the 90+ SQL Servers that I had
registered in SQL Server Enterprise Manager are no longer registered when I
enter Enterprise Manager under my new AD login. If I go to
[HKEY_USERS\S-1-5-21-10907285-1067259047-1047869632-3055\Software\Microsoft\
Microsoft SQL Server\80\Tools\SQLEW\Registered Servers X\SQL Server Group]
in the registry I do see all of my servers registered there, but can't
access them via EM, unless I re-register each one.
Can I access these servers without re-registering each of them? Is the
server registration process linked to my old SID, thus why I can't see them
in EM with my new AD userID?
Thanks,
Dave

Register server wizard malfunction

Hi,
I installed sql server 2000 enterprise edition on windows 2000 advanced server undera domain account that had the sys admin privileges. However i logged in with my domain account and installed the sql server on a remote machine.The installation completed
successfully. i have also set the 'sa' p/w. Now when i go into the log lifes for sqlserveragent, i see an error like 'data area is less than...' and also it is showing that the sql server is running in single user mode. Also when i opened the enterprise
manager i am able to see the <local> server but when i try to register a new server, the wizard after the initial screen is getting disabled and is closing the entire enterprise manager window. Except for the regiser sql server wizard, all the other wizar
ds are working fine, i am able to setup replication etc.
I would hate to uninstall and reinstall, is their any way to correct the installtion?
Also, the domain a/c that is used by sql server will not allow me to do a remote destop connection(some corporate agreement), hence i have to login with my own domain a/c. Also i have done the default 1433 port installation.
1. Please check the sqlstp.log to make sure that sql server was properly
installed. You'll find this file in your WinNT folder.
2. About uninstalling SQL Server, the best would be trhough Control panel,
Add-Remove Programs. Should that fail, please refer to
290991 HOW TO: Manually remove SQL Server 2000 default, named, or virtual
http://support.microsoft.com/?id=290991
Thanks.
Vikram Jayaram
Microsoft, SQL Server
This posting is provided "AS IS" with no warranties, and confers no rights.
Subscribe to MSDN & use http://msdn.microsoft.com/newsgroups.

Register server wizard malfunction

Hi,
I installed sql server 2000 enterprise edition on Windows 2000 advanced serv
er undera domain account that had the sys admin privileges. However i logged
in with my domain account and installed the sql server on a remote machine.
The installation completed
successfully. i have also set the 'sa' p/w. Now when i go into the log lifes
for sqlserveragent, i see an error like 'data area is less than...' and al
so it is showing that the sql server is running in single user mode. Also wh
en i opened the enterprise
manager i am able to see the <local> server but when i try to register a new
server, the wizard after the initial screen is getting disabled and is clos
ing the entire enterprise manager window. Except for the regiser sql server
wizard, all the other wizar
ds are working fine, i am able to setup replication etc.
I would hate to uninstall and reinstall, is their any way to correct the ins
talltion?
Also, the domain a/c that is used by sql server will not allow me to do a re
mote destop connection(some corporate agreement), hence i have to login with
my own domain a/c. Also i have done the default 1433 port installation.1. Please check the sqlstp.log to make sure that sql server was properly
installed. You'll find this file in your WinNT folder.
2. About uninstalling SQL Server, the best would be trhough Control panel,
Add-Remove Programs. Should that fail, please refer to
290991 HOW TO: Manually remove SQL Server 2000 default, named, or virtual
http://support.microsoft.com/?id=290991
Thanks.
Vikram Jayaram
Microsoft, SQL Server
This posting is provided "AS IS" with no warranties, and confers no rights.
Subscribe to MSDN & use http://msdn.microsoft.com/newsgroups.

Register server wizard malfunction

Hi,
I installed sql server 2000 enterprise edition on windows 2000 advanced server undera domain account that had the sys admin privileges. However i logged in with my domain account and installed the sql server on a remote machine.The installation completed successfully. i have also set the 'sa' p/w. Now when i go into the log lifes for sqlserveragent, i see an error like 'data area is less than...' and also it is showing that the sql server is running in single user mode. Also when i opened the enterprise manager i am able to see the <local> server but when i try to register a new server, the wizard after the initial screen is getting disabled and is closing the entire enterprise manager window. Except for the regiser sql server wizard, all the other wizards are working fine, i am able to setup replication etc.
I would hate to uninstall and reinstall, is their any way to correct the installtion?
Also, the domain a/c that is used by sql server will not allow me to do a remote destop connection(some corporate agreement), hence i have to login with my own domain a/c. Also i have done the default 1433 port installation.1. Please check the sqlstp.log to make sure that sql server was properly
installed. You'll find this file in your WinNT folder.
2. About uninstalling SQL Server, the best would be trhough Control panel,
Add-Remove Programs. Should that fail, please refer to
290991 HOW TO: Manually remove SQL Server 2000 default, named, or virtual
http://support.microsoft.com/?id=290991
Thanks.
Vikram Jayaram
Microsoft, SQL Server
This posting is provided "AS IS" with no warranties, and confers no rights.
Subscribe to MSDN & use http://msdn.microsoft.com/newsgroups.