Registration failure in Enterprise Manager

I am in Enterprise Manager on ComputerA, logged in as user xyz. I am
attempting to add a new SQL Server registration for the SQL Server on
ComputerB, using SQL Server authentication based on SQL Server login abc. Th
e
registration fails, stating that the SQL Server does not exist or access is
denied. The Security Event Log on ComputerB indicates a login failure to the
account xyz, which does not exist on ComputerB. Why is the registration
attempt trying to log into a non-existent Windows account when I have
requested SQL Server authentication? TIA...Sounds like it could be that it's trying to connect using
named pipes. Check the order of the protocols using the
client network utility and try setting TCP/IP as the first
protocol if it already isn't the first one listed.
Or use the client network utility and create a TCP/IP alias
to ComputerB on ComputerA
-Sue
On Tue, 5 Jul 2005 12:19:05 -0700, "Steve B."
<SteveB@.discussions.microsoft.com> wrote:

>I am in Enterprise Manager on ComputerA, logged in as user xyz. I am
>attempting to add a new SQL Server registration for the SQL Server on
>ComputerB, using SQL Server authentication based on SQL Server login abc. T
he
>registration fails, stating that the SQL Server does not exist or access is
>denied. The Security Event Log on ComputerB indicates a login failure to th
e
>account xyz, which does not exist on ComputerB. Why is the registration
>attempt trying to log into a non-existent Windows account when I have
>requested SQL Server authentication? TIA...|||Thanks for your reply. Per your suggestion, I changed the order of the
protocols listed in the Client Network Utility, and I had already tried
creating the TCP/IP alias for ComputerB, but I tried it again. All to no
avail... :-(
"Sue Hoegemeier" wrote:

> Sounds like it could be that it's trying to connect using
> named pipes. Check the order of the protocols using the
> client network utility and try setting TCP/IP as the first
> protocol if it already isn't the first one listed.
> Or use the client network utility and create a TCP/IP alias
> to ComputerB on ComputerA
> -Sue
> On Tue, 5 Jul 2005 12:19:05 -0700, "Steve B."
> <SteveB@.discussions.microsoft.com> wrote:
>
>|||I thought I'd close this loop, in case others might benefit. The problem was
resolved by creating synchronized accounts on ComputerA and ComputerB.
ComputerB is a W2K3 system, and it appears that account synchronization is
required on W2K3 even when you're using SQL Server authentication. So I
wonder why you'd ever bother with SQL Server authentication on W2K3?
"Steve B." wrote:
[vbcol=seagreen]
> Thanks for your reply. Per your suggestion, I changed the order of the
> protocols listed in the Client Network Utility, and I had already tried
> creating the TCP/IP alias for ComputerB, but I tried it again. All to no
> avail... :-(
> "Sue Hoegemeier" wrote:
>|||It's not a requirement. Synching the accounts and passwords
is in non-domain settings sometimes but it's to allow
Windows authentication. If you are specifying SQL
authentication and Windows is used instead then you have
something else that's a problem. You may want to check what
protocol you are actually connecting with - the net library
is listed in sysprocesses. You may also want to run
component check to verify your MDAC installation. You can
download it from:
http://msdn.microsoft.com/data/mdac...ds/default.aspx
-Sue
On Tue, 12 Jul 2005 08:44:05 -0700, "Steve B."
<SteveB@.discussions.microsoft.com> wrote:
[vbcol=seagreen]
>I thought I'd close this loop, in case others might benefit. The problem wa
s
>resolved by creating synchronized accounts on ComputerA and ComputerB.
>ComputerB is a W2K3 system, and it appears that account synchronization is
>required on W2K3 even when you're using SQL Server authentication. So I
>wonder why you'd ever bother with SQL Server authentication on W2K3?
>"Steve B." wrote:
>