Can anyone help me. I work in a workgroup environment as opposed to domain
controlled. The minute I do anything with reporting services or analysis
services that is between machines I get problems.
I can't deploy to SSAS or SSRS from my machine unless I log into my machine
with a username and account that is the same as the machine being deployed
to. How do I tell BIDS what credentials to use.
Can anyone give me an overview of how credentials are passed in a non domain
environment.On Sep 25, 2:47 pm, "Fresno Bob" <nos...@.nospam.com> wrote:
> Can anyone help me. I work in a workgroup environment as opposed to domain
> controlled. The minute I do anything with reporting services or analysis
> services that is between machines I get problems.
> I can't deploy to SSAS or SSRS from my machine unless I log into my machine
> with a username and account that is the same as the machine being deployed
> to. How do I tell BIDS what credentials to use.
> Can anyone give me an overview of how credentials are passed in a non domain
> environment.
This article is off topic; however, gives a general explanation
similar to your scenario. http://msdn2.microsoft.com/en-us/library/ms252507(VS.80).aspx
It seems that this is more of an OS security level/authentication
issue. As far as I know, you may not be able to control the BIDS
credentials. At a Report Server level, you should be able to change
credentials once the report is deployed in the Report Mgr. You might
try looking in the ReportProjectName.rptproj.user file to see if you
can possibly modify something there. Sorry that I could not be of
greater assistance.
Regards,
Enrique Martinez
Sr. Software Consultant|||SSAS Requires Windows Authentication to work and does not accept SQL
Authentication. If you are in a workgroup the only way to get your scenario
to work is to create identical local accounts on both machines. When I say
identical I mean has the same name and password. Since you are not in a
domain there isn't a way for the remote server to validate your credentials
and will therefore always get a user of "null".
--
SQL Server Developer Support Engineer
"Fresno Bob" wrote:
> Can anyone help me. I work in a workgroup environment as opposed to domain
> controlled. The minute I do anything with reporting services or analysis
> services that is between machines I get problems.
> I can't deploy to SSAS or SSRS from my machine unless I log into my machine
> with a username and account that is the same as the machine being deployed
> to. How do I tell BIDS what credentials to use.
> Can anyone give me an overview of how credentials are passed in a non domain
> environment.
>
>
Showing posts with label domain. Show all posts
Showing posts with label domain. Show all posts
Monday, March 19, 2012
Friday, February 24, 2012
Can't connect via HTTP remotely...
Hello-
I've just set up HTTP Access to SSAS and can connect locally, but when trying to connect remotely, as the same domain user, I receive the message:
The connection either timed out or was lost
Unable to connect to the remote server
No connection could be made because the target machine actively refused it
I can connect remotely if I connect using just the servername (rather than http://...)
Anyone else runinto this one?
Hi Tristan,
For troubleshooting connectivity problems, one great resource is Edward's blog at: http://www.sqljunkies.com/WebLog/edwardm/.
If you still have connectivity issues after following the guidelines described in this blog, please let us know and give more details.
Hope this helps,
Artur
Sunday, February 19, 2012
Cant connect to SQL server 2000 instance from domain machines
Hi
We currently have installed sql2005 (installed first as default
instance) and sql 2000 with a named instance. When developing sites
and using connection strings, we can access the sql2000 db fine by
using SERVERNAME\INSTANCENAME.
However, if we try to connect via enterprise manager from any other
machine on the domain, we cannot seem to use SERVERNAME\INSTANCENAME
and the instance name alone wont work either.
How do we get round this as at present, we are having to log into the
database server to make any changes etc!!!
Novice here so excuse me if I have missed anything obvious!
Cheers
RajThe easiest workaround would be to connect to the instance using its IP
address followed by a comma and then the port number. You should not use just
hte instance name alone. The SQL Server instance name is not a newtwork name
and won't get resolved to an IP/port number.
Can you connect to the default instance (SQL2005) from a machine where you
can't connect to the SQL2000 instance using ServerName\Instance?
Linchi
"karwalr@.hotmail.com" wrote:
> Hi
> We currently have installed sql2005 (installed first as default
> instance) and sql 2000 with a named instance. When developing sites
> and using connection strings, we can access the sql2000 db fine by
> using SERVERNAME\INSTANCENAME.
> However, if we try to connect via enterprise manager from any other
> machine on the domain, we cannot seem to use SERVERNAME\INSTANCENAME
> and the instance name alone wont work either.
> How do we get round this as at present, we are having to log into the
> database server to make any changes etc!!!
> Novice here so excuse me if I have missed anything obvious!
> Cheers
> Raj
>|||Managed to sort it. I set it up on my client machine Client Network
Alias to map to the server and the port as suggested. Found the
documentation at Microsoft..
http://support.microsoft.com/kb/265808/en-us
Many thanks!
We currently have installed sql2005 (installed first as default
instance) and sql 2000 with a named instance. When developing sites
and using connection strings, we can access the sql2000 db fine by
using SERVERNAME\INSTANCENAME.
However, if we try to connect via enterprise manager from any other
machine on the domain, we cannot seem to use SERVERNAME\INSTANCENAME
and the instance name alone wont work either.
How do we get round this as at present, we are having to log into the
database server to make any changes etc!!!
Novice here so excuse me if I have missed anything obvious!
Cheers
RajThe easiest workaround would be to connect to the instance using its IP
address followed by a comma and then the port number. You should not use just
hte instance name alone. The SQL Server instance name is not a newtwork name
and won't get resolved to an IP/port number.
Can you connect to the default instance (SQL2005) from a machine where you
can't connect to the SQL2000 instance using ServerName\Instance?
Linchi
"karwalr@.hotmail.com" wrote:
> Hi
> We currently have installed sql2005 (installed first as default
> instance) and sql 2000 with a named instance. When developing sites
> and using connection strings, we can access the sql2000 db fine by
> using SERVERNAME\INSTANCENAME.
> However, if we try to connect via enterprise manager from any other
> machine on the domain, we cannot seem to use SERVERNAME\INSTANCENAME
> and the instance name alone wont work either.
> How do we get round this as at present, we are having to log into the
> database server to make any changes etc!!!
> Novice here so excuse me if I have missed anything obvious!
> Cheers
> Raj
>|||Managed to sort it. I set it up on my client machine Client Network
Alias to map to the server and the port as suggested. Found the
documentation at Microsoft..
http://support.microsoft.com/kb/265808/en-us
Many thanks!
Cant connect to SQL server 2000 instance from domain machines
Hi
We currently have installed sql2005 (installed first as default
instance) and sql 2000 with a named instance. When developing sites
and using connection strings, we can access the sql2000 db fine by
using SERVERNAME\INSTANCENAME.
However, if we try to connect via enterprise manager from any other
machine on the domain, we cannot seem to use SERVERNAME\INSTANCENAME
and the instance name alone wont work either.
How do we get round this as at present, we are having to log into the
database server to make any changes etc!!!
Novice here so excuse me if I have missed anything obvious!
Cheers
RajThe easiest workaround would be to connect to the instance using its IP
address followed by a comma and then the port number. You should not use jus
t
hte instance name alone. The SQL Server instance name is not a newtwork name
and won't get resolved to an IP/port number.
Can you connect to the default instance (SQL2005) from a machine where you
can't connect to the SQL2000 instance using ServerName\Instance?
Linchi
"karwalr@.hotmail.com" wrote:
> Hi
> We currently have installed sql2005 (installed first as default
> instance) and sql 2000 with a named instance. When developing sites
> and using connection strings, we can access the sql2000 db fine by
> using SERVERNAME\INSTANCENAME.
> However, if we try to connect via enterprise manager from any other
> machine on the domain, we cannot seem to use SERVERNAME\INSTANCENAME
> and the instance name alone wont work either.
> How do we get round this as at present, we are having to log into the
> database server to make any changes etc!!!
> Novice here so excuse me if I have missed anything obvious!
> Cheers
> Raj
>|||Managed to sort it. I set it up on my client machine Client Network
Alias to map to the server and the port as suggested. Found the
documentation at Microsoft..
http://support.microsoft.com/kb/265808/en-us
Many thanks!
We currently have installed sql2005 (installed first as default
instance) and sql 2000 with a named instance. When developing sites
and using connection strings, we can access the sql2000 db fine by
using SERVERNAME\INSTANCENAME.
However, if we try to connect via enterprise manager from any other
machine on the domain, we cannot seem to use SERVERNAME\INSTANCENAME
and the instance name alone wont work either.
How do we get round this as at present, we are having to log into the
database server to make any changes etc!!!
Novice here so excuse me if I have missed anything obvious!
Cheers
RajThe easiest workaround would be to connect to the instance using its IP
address followed by a comma and then the port number. You should not use jus
t
hte instance name alone. The SQL Server instance name is not a newtwork name
and won't get resolved to an IP/port number.
Can you connect to the default instance (SQL2005) from a machine where you
can't connect to the SQL2000 instance using ServerName\Instance?
Linchi
"karwalr@.hotmail.com" wrote:
> Hi
> We currently have installed sql2005 (installed first as default
> instance) and sql 2000 with a named instance. When developing sites
> and using connection strings, we can access the sql2000 db fine by
> using SERVERNAME\INSTANCENAME.
> However, if we try to connect via enterprise manager from any other
> machine on the domain, we cannot seem to use SERVERNAME\INSTANCENAME
> and the instance name alone wont work either.
> How do we get round this as at present, we are having to log into the
> database server to make any changes etc!!!
> Novice here so excuse me if I have missed anything obvious!
> Cheers
> Raj
>|||Managed to sort it. I set it up on my client machine Client Network
Alias to map to the server and the port as suggested. Found the
documentation at Microsoft..
http://support.microsoft.com/kb/265808/en-us
Many thanks!
Thursday, February 16, 2012
can't connect to SQL 6.5 server in different domain
Is there any trick to setting up a System DSN to connect to a SQL 6.5 Sever
that is in a different domain. The domains are trusted. I've tried every t
ype of authentication but my Win XP system just can't get a DSN to connect a
gain the SQL Server that is running Win NT4 SP6. Is there a trick?
Thanks,
ChuckHi,
Can you create a alias name using "CLIENT NETWORK UTILITY" from your WIN XP
System by providing the
1. Protocol as TCP/IP
2. Provide the SQL 6.5 IP address
3. Define the Port number
Then use the ALIAS server name to connect.
--
Thanks
Hari
SQL Server MVP
"Charles MacLean" <charlesmaclean@.sbcglobal.net> wrote in message news:ziWkd
.18733$Rf1.10698@.newssvr19.news.prodigy.com...
Is there any trick to setting up a System DSN to connect to a SQL 6.5 Sever
that is in a different domain. The domains are trusted. I've tried every t
ype of authentication but my Win XP system just can't get a DSN to connect a
gain the SQL Server that is running Win NT4 SP6. Is there a trick?
Thanks,
Chuck|||If SQL Server 6.5 is set to use Windows only authentication, this will not
work. With SQL Server 6.5 NT authentication only works with named pipes.
Also by default SQL Server 6.5 does not enable TCP/IP. It has to be done
after setup. So use SQL Server setup to see if tcp/ip is enabled. Then set
SQL Server to use mixed security and then configure your DSN to use SQL
authentication. This is just a test to see if you can connect. With this
configuration the alias that Hari suggests should work.
What error are you getting when you try to connect?
Rand
This posting is provided "as is" with no warranties and confers no rights.
that is in a different domain. The domains are trusted. I've tried every t
ype of authentication but my Win XP system just can't get a DSN to connect a
gain the SQL Server that is running Win NT4 SP6. Is there a trick?
Thanks,
ChuckHi,
Can you create a alias name using "CLIENT NETWORK UTILITY" from your WIN XP
System by providing the
1. Protocol as TCP/IP
2. Provide the SQL 6.5 IP address
3. Define the Port number
Then use the ALIAS server name to connect.
--
Thanks
Hari
SQL Server MVP
"Charles MacLean" <charlesmaclean@.sbcglobal.net> wrote in message news:ziWkd
.18733$Rf1.10698@.newssvr19.news.prodigy.com...
Is there any trick to setting up a System DSN to connect to a SQL 6.5 Sever
that is in a different domain. The domains are trusted. I've tried every t
ype of authentication but my Win XP system just can't get a DSN to connect a
gain the SQL Server that is running Win NT4 SP6. Is there a trick?
Thanks,
Chuck|||If SQL Server 6.5 is set to use Windows only authentication, this will not
work. With SQL Server 6.5 NT authentication only works with named pipes.
Also by default SQL Server 6.5 does not enable TCP/IP. It has to be done
after setup. So use SQL Server setup to see if tcp/ip is enabled. Then set
SQL Server to use mixed security and then configure your DSN to use SQL
authentication. This is just a test to see if you can connect. With this
configuration the alias that Hari suggests should work.
What error are you getting when you try to connect?
Rand
This posting is provided "as is" with no warranties and confers no rights.
can't connect to SQL 6.5 server in different domain
Is there any trick to setting up a System DSN to connect to a SQL 6.5 Sever that is in a different domain. The domains are trusted. I've tried every type of authentication but my Win XP system just can't get a DSN to connect again the SQL Server that is running Win NT4 SP6. Is there a trick?
Thanks,
Chuck
Hi,
Can you create a alias name using "CLIENT NETWORK UTILITY" from your WIN XP System by providing the
1. Protocol as TCP/IP
2. Provide the SQL 6.5 IP address
3. Define the Port number
Then use the ALIAS server name to connect.
Thanks
Hari
SQL Server MVP
"Charles MacLean" <charlesmaclean@.sbcglobal.net> wrote in message news:ziWkd.18733$Rf1.10698@.newssvr19.news.prodigy. com...
Is there any trick to setting up a System DSN to connect to a SQL 6.5 Sever that is in a different domain. The domains are trusted. I've tried every type of authentication but my Win XP system just can't get a DSN to connect again the SQL Server that is running Win NT4 SP6. Is there a trick?
Thanks,
Chuck
|||If SQL Server 6.5 is set to use Windows only authentication, this will not
work. With SQL Server 6.5 NT authentication only works with named pipes.
Also by default SQL Server 6.5 does not enable TCP/IP. It has to be done
after setup. So use SQL Server setup to see if tcp/ip is enabled. Then set
SQL Server to use mixed security and then configure your DSN to use SQL
authentication. This is just a test to see if you can connect. With this
configuration the alias that Hari suggests should work.
What error are you getting when you try to connect?
Rand
This posting is provided "as is" with no warranties and confers no rights.
Thanks,
Chuck
Hi,
Can you create a alias name using "CLIENT NETWORK UTILITY" from your WIN XP System by providing the
1. Protocol as TCP/IP
2. Provide the SQL 6.5 IP address
3. Define the Port number
Then use the ALIAS server name to connect.
Thanks
Hari
SQL Server MVP
"Charles MacLean" <charlesmaclean@.sbcglobal.net> wrote in message news:ziWkd.18733$Rf1.10698@.newssvr19.news.prodigy. com...
Is there any trick to setting up a System DSN to connect to a SQL 6.5 Sever that is in a different domain. The domains are trusted. I've tried every type of authentication but my Win XP system just can't get a DSN to connect again the SQL Server that is running Win NT4 SP6. Is there a trick?
Thanks,
Chuck
|||If SQL Server 6.5 is set to use Windows only authentication, this will not
work. With SQL Server 6.5 NT authentication only works with named pipes.
Also by default SQL Server 6.5 does not enable TCP/IP. It has to be done
after setup. So use SQL Server setup to see if tcp/ip is enabled. Then set
SQL Server to use mixed security and then configure your DSN to use SQL
authentication. This is just a test to see if you can connect. With this
configuration the alias that Hari suggests should work.
What error are you getting when you try to connect?
Rand
This posting is provided "as is" with no warranties and confers no rights.
Friday, February 10, 2012
Can't connect to / see cube
Need some input please.
I have a development domain, with one server running SQL Server 2000 sp
3 Enterprise edition, Analysis Services Sp 3 Enterprise Edition and
REporting Services.
I used to be able to connect to my databases in Analysis Services, but
today I updated one of them, and now I can't connect to it. I can log
into the server, and see my Foodmart demo base. But I can't see my new
database.
I restored the database from a cab-file, and it restored OK. I can
prosess 2 out of 4 individual cubes. If I right-click the database and
choose "Process the Database", it fails to process. There seems to be a
problem with the database.
Is this why I can't connect to the database / cubes from other
computers? I can log on using http and the right username and password,
and I get to see Foodmart, but not the database / cubes I want to work
with.
Please advise, or at least give a hint on where I can find more info.
Kaisa
*** Sent via Developersdex http://www.codecomments.com ***
Don't just participate in USENET...get rewarded for it!Two possibilities typically occur:
1) either you have an old version of PTS on your client machine (run
ptslite.exe from the SP3 Analysis Services distribution), or
2) you don't have security rights to the cube, i.e. if you've not included
the everyone role. Foodmart has such a role, and thus you can see it.
--
Dave Wickert [MSFT]
dwickert@.online.microsoft.com
Program Manager
BI SystemsTeam
SQL BI Product Unit (Analysis Services)
--
This posting is provided "AS IS" with no warranties, and confers no rights.
"Kaisa" <kaisaremoveml@.hotmail.com> wrote in message
news:%23QRcNQpuEHA.2804@.TK2MSFTNGP14.phx.gbl...
> Need some input please.
> I have a development domain, with one server running SQL Server 2000 sp
> 3 Enterprise edition, Analysis Services Sp 3 Enterprise Edition and
> REporting Services.
> I used to be able to connect to my databases in Analysis Services, but
> today I updated one of them, and now I can't connect to it. I can log
> into the server, and see my Foodmart demo base. But I can't see my new
> database.
> I restored the database from a cab-file, and it restored OK. I can
> prosess 2 out of 4 individual cubes. If I right-click the database and
> choose "Process the Database", it fails to process. There seems to be a
> problem with the database.
> Is this why I can't connect to the database / cubes from other
> computers? I can log on using http and the right username and password,
> and I get to see Foodmart, but not the database / cubes I want to work
> with.
> Please advise, or at least give a hint on where I can find more info.
> Kaisa
>
> *** Sent via Developersdex http://www.codecomments.com ***
> Don't just participate in USENET...get rewarded for it!|||"Dave Wickert [MSFT]" <dwickert@.online.microsoft.com> wrote in message news:<O8F#B6ruEHA
.684@.TK2MSFTNGP10.phx.gbl>...
> Two possibilities typically occur:
> 1) either you have an old version of PTS on your client machine (run
> ptslite.exe from the SP3 Analysis Services distribution), or
> 2) you don't have security rights to the cube, i.e. if you've not included
> the everyone role. Foodmart has such a role, and thus you can see it.
> --
Hey Dave!
Thanks a lot! I added the Everyone role and now I can use my database.
I'm so happy right now!
:D
Kaisa M. Lindahl
I have a development domain, with one server running SQL Server 2000 sp
3 Enterprise edition, Analysis Services Sp 3 Enterprise Edition and
REporting Services.
I used to be able to connect to my databases in Analysis Services, but
today I updated one of them, and now I can't connect to it. I can log
into the server, and see my Foodmart demo base. But I can't see my new
database.
I restored the database from a cab-file, and it restored OK. I can
prosess 2 out of 4 individual cubes. If I right-click the database and
choose "Process the Database", it fails to process. There seems to be a
problem with the database.
Is this why I can't connect to the database / cubes from other
computers? I can log on using http and the right username and password,
and I get to see Foodmart, but not the database / cubes I want to work
with.
Please advise, or at least give a hint on where I can find more info.
Kaisa
*** Sent via Developersdex http://www.codecomments.com ***
Don't just participate in USENET...get rewarded for it!Two possibilities typically occur:
1) either you have an old version of PTS on your client machine (run
ptslite.exe from the SP3 Analysis Services distribution), or
2) you don't have security rights to the cube, i.e. if you've not included
the everyone role. Foodmart has such a role, and thus you can see it.
--
Dave Wickert [MSFT]
dwickert@.online.microsoft.com
Program Manager
BI SystemsTeam
SQL BI Product Unit (Analysis Services)
--
This posting is provided "AS IS" with no warranties, and confers no rights.
"Kaisa" <kaisaremoveml@.hotmail.com> wrote in message
news:%23QRcNQpuEHA.2804@.TK2MSFTNGP14.phx.gbl...
> Need some input please.
> I have a development domain, with one server running SQL Server 2000 sp
> 3 Enterprise edition, Analysis Services Sp 3 Enterprise Edition and
> REporting Services.
> I used to be able to connect to my databases in Analysis Services, but
> today I updated one of them, and now I can't connect to it. I can log
> into the server, and see my Foodmart demo base. But I can't see my new
> database.
> I restored the database from a cab-file, and it restored OK. I can
> prosess 2 out of 4 individual cubes. If I right-click the database and
> choose "Process the Database", it fails to process. There seems to be a
> problem with the database.
> Is this why I can't connect to the database / cubes from other
> computers? I can log on using http and the right username and password,
> and I get to see Foodmart, but not the database / cubes I want to work
> with.
> Please advise, or at least give a hint on where I can find more info.
> Kaisa
>
> *** Sent via Developersdex http://www.codecomments.com ***
> Don't just participate in USENET...get rewarded for it!|||"Dave Wickert [MSFT]" <dwickert@.online.microsoft.com> wrote in message news:<O8F#B6ruEHA
.684@.TK2MSFTNGP10.phx.gbl>...
> Two possibilities typically occur:
> 1) either you have an old version of PTS on your client machine (run
> ptslite.exe from the SP3 Analysis Services distribution), or
> 2) you don't have security rights to the cube, i.e. if you've not included
> the everyone role. Foodmart has such a role, and thus you can see it.
> --
Hey Dave!
Thanks a lot! I added the Everyone role and now I can use my database.
I'm so happy right now!
:D
Kaisa M. Lindahl
Can't connect to / see cube
Need some input please.
I have a development domain, with one server running SQL Server 2000 sp
3 Enterprise edition, Analysis Services Sp 3 Enterprise Edition and
REporting Services.
I used to be able to connect to my databases in Analysis Services, but
today I updated one of them, and now I can't connect to it. I can log
into the server, and see my Foodmart demo base. But I can't see my new
database.
I restored the database from a cab-file, and it restored OK. I can
prosess 2 out of 4 individual cubes. If I right-click the database and
choose "Process the Database", it fails to process. There seems to be a
problem with the database.
Is this why I can't connect to the database / cubes from other
computers? I can log on using http and the right username and password,
and I get to see Foodmart, but not the database / cubes I want to work
with.
Please advise, or at least give a hint on where I can find more info.
Kaisa
*** Sent via Developersdex http://www.codecomments.com ***
Don't just participate in USENET...get rewarded for it!
Two possibilities typically occur:
1) either you have an old version of PTS on your client machine (run
ptslite.exe from the SP3 Analysis Services distribution), or
2) you don't have security rights to the cube, i.e. if you've not included
the everyone role. Foodmart has such a role, and thus you can see it.
Dave Wickert [MSFT]
dwickert@.online.microsoft.com
Program Manager
BI SystemsTeam
SQL BI Product Unit (Analysis Services)
This posting is provided "AS IS" with no warranties, and confers no rights.
"Kaisa" <kaisaremoveml@.hotmail.com> wrote in message
news:%23QRcNQpuEHA.2804@.TK2MSFTNGP14.phx.gbl...
> Need some input please.
> I have a development domain, with one server running SQL Server 2000 sp
> 3 Enterprise edition, Analysis Services Sp 3 Enterprise Edition and
> REporting Services.
> I used to be able to connect to my databases in Analysis Services, but
> today I updated one of them, and now I can't connect to it. I can log
> into the server, and see my Foodmart demo base. But I can't see my new
> database.
> I restored the database from a cab-file, and it restored OK. I can
> prosess 2 out of 4 individual cubes. If I right-click the database and
> choose "Process the Database", it fails to process. There seems to be a
> problem with the database.
> Is this why I can't connect to the database / cubes from other
> computers? I can log on using http and the right username and password,
> and I get to see Foodmart, but not the database / cubes I want to work
> with.
> Please advise, or at least give a hint on where I can find more info.
> Kaisa
>
> *** Sent via Developersdex http://www.codecomments.com ***
> Don't just participate in USENET...get rewarded for it!
|||"Dave Wickert [MSFT]" <dwickert@.online.microsoft.com> wrote in message news:<O8F#B6ruEHA.684@.TK2MSFTNGP10.phx.gbl>...
> Two possibilities typically occur:
> 1) either you have an old version of PTS on your client machine (run
> ptslite.exe from the SP3 Analysis Services distribution), or
> 2) you don't have security rights to the cube, i.e. if you've not included
> the everyone role. Foodmart has such a role, and thus you can see it.
> --
Hey Dave!
Thanks a lot! I added the Everyone role and now I can use my database.
I'm so happy right now!
:D
Kaisa M. Lindahl
I have a development domain, with one server running SQL Server 2000 sp
3 Enterprise edition, Analysis Services Sp 3 Enterprise Edition and
REporting Services.
I used to be able to connect to my databases in Analysis Services, but
today I updated one of them, and now I can't connect to it. I can log
into the server, and see my Foodmart demo base. But I can't see my new
database.
I restored the database from a cab-file, and it restored OK. I can
prosess 2 out of 4 individual cubes. If I right-click the database and
choose "Process the Database", it fails to process. There seems to be a
problem with the database.
Is this why I can't connect to the database / cubes from other
computers? I can log on using http and the right username and password,
and I get to see Foodmart, but not the database / cubes I want to work
with.
Please advise, or at least give a hint on where I can find more info.
Kaisa
*** Sent via Developersdex http://www.codecomments.com ***
Don't just participate in USENET...get rewarded for it!
Two possibilities typically occur:
1) either you have an old version of PTS on your client machine (run
ptslite.exe from the SP3 Analysis Services distribution), or
2) you don't have security rights to the cube, i.e. if you've not included
the everyone role. Foodmart has such a role, and thus you can see it.
Dave Wickert [MSFT]
dwickert@.online.microsoft.com
Program Manager
BI SystemsTeam
SQL BI Product Unit (Analysis Services)
This posting is provided "AS IS" with no warranties, and confers no rights.
"Kaisa" <kaisaremoveml@.hotmail.com> wrote in message
news:%23QRcNQpuEHA.2804@.TK2MSFTNGP14.phx.gbl...
> Need some input please.
> I have a development domain, with one server running SQL Server 2000 sp
> 3 Enterprise edition, Analysis Services Sp 3 Enterprise Edition and
> REporting Services.
> I used to be able to connect to my databases in Analysis Services, but
> today I updated one of them, and now I can't connect to it. I can log
> into the server, and see my Foodmart demo base. But I can't see my new
> database.
> I restored the database from a cab-file, and it restored OK. I can
> prosess 2 out of 4 individual cubes. If I right-click the database and
> choose "Process the Database", it fails to process. There seems to be a
> problem with the database.
> Is this why I can't connect to the database / cubes from other
> computers? I can log on using http and the right username and password,
> and I get to see Foodmart, but not the database / cubes I want to work
> with.
> Please advise, or at least give a hint on where I can find more info.
> Kaisa
>
> *** Sent via Developersdex http://www.codecomments.com ***
> Don't just participate in USENET...get rewarded for it!
|||"Dave Wickert [MSFT]" <dwickert@.online.microsoft.com> wrote in message news:<O8F#B6ruEHA.684@.TK2MSFTNGP10.phx.gbl>...
> Two possibilities typically occur:
> 1) either you have an old version of PTS on your client machine (run
> ptslite.exe from the SP3 Analysis Services distribution), or
> 2) you don't have security rights to the cube, i.e. if you've not included
> the everyone role. Foodmart has such a role, and thus you can see it.
> --
Hey Dave!
Thanks a lot! I added the Everyone role and now I can use my database.
I'm so happy right now!
:D
Kaisa M. Lindahl
Can't connect remotely when SQL services running as a domain account
I'm running SQL 2000 SP4 on 2003 server. I'm trying to setup email alerts. I
configured the sql service and sql agent service to run as a domain account.
I made that account a member of the administrators group on the SQL server,
and restarted the services. Everything looked fine. The problem is, some of
my remote applications cannot connect when it is running as a domain
account, but they are fine when it is running as a local system account. On
a remote Microsoft WSUS server, it breaks when the SQL services on the SQL
server use a domain account. Osql on the remote box generates this:
Cannot generate SSPI context
I did try to research this before posting here, but I couldn't find anything
that described this problem. Everything was referring to PCs connecting from
a different domain. That is not the case here.
Thanks,
MatthewCannot Generate SSPI context is almost always related to there not being a
Service Principal Name defined for that server, account and port in a
Kerberos environment.
Domain accounts do not create an SPN, whereas Domain Admins and Local System
do.
Test this by making (temporarily) your startup account a domain admin and
the resetting in in SQL Enterprise Manager. restart and test connectivity.
If it connects, have your domain admin (must be a domain admin) create an
SPN for the MSSQLSvc in Active Directory.
See the Books Online article "Security Account Delegation" for formot of
what the resulting SPN should look like.
Also, make sure the SQL Server is listening on TCP...make that your first
step.
Kevin Hill
3NF Consulting
www.3nf-inc.com/NewsGroups.htm
"Matthew Kitchin (Usenet/Lists)" <mkitchin.public@.gmail.com> wrote in
message news:%231cmKJ33GHA.1300@.TK2MSFTNGP05.phx.gbl...
> I'm running SQL 2000 SP4 on 2003 server. I'm trying to setup email alerts.
> I configured the sql service and sql agent service to run as a domain
> account. I made that account a member of the administrators group on the
> SQL server, and restarted the services. Everything looked fine. The
> problem is, some of my remote applications cannot connect when it is
> running as a domain account, but they are fine when it is running as a
> local system account. On a remote Microsoft WSUS server, it breaks when
> the SQL services on the SQL server use a domain account. Osql on the
> remote box generates this:
> Cannot generate SSPI context
> I did try to research this before posting here, but I couldn't find
> anything that described this problem. Everything was referring to PCs
> connecting from a different domain. That is not the case here.
> Thanks,
> Matthew
>|||I am the domain admin, so that won't be a problem. As soon as some of the
current activity dies down, I will try this. Thanks!
"Kevin3NF" <Kevin@.DontNeedNoSpam3NF-inc.com> wrote in message
news:OxBRke33GHA.1288@.TK2MSFTNGP03.phx.gbl...
> Cannot Generate SSPI context is almost always related to there not being a
> Service Principal Name defined for that server, account and port in a
> Kerberos environment.
> Domain accounts do not create an SPN, whereas Domain Admins and Local
> System do.
> Test this by making (temporarily) your startup account a domain admin and
> the resetting in in SQL Enterprise Manager. restart and test
> connectivity.
> If it connects, have your domain admin (must be a domain admin) create an
> SPN for the MSSQLSvc in Active Directory.
> See the Books Online article "Security Account Delegation" for formot of
> what the resulting SPN should look like.
> Also, make sure the SQL Server is listening on TCP...make that your first
> step.
> --
> Kevin Hill
> 3NF Consulting
> www.3nf-inc.com/NewsGroups.htm
>
>
> "Matthew Kitchin (Usenet/Lists)" <mkitchin.public@.gmail.com> wrote in
> message news:%231cmKJ33GHA.1300@.TK2MSFTNGP05.phx.gbl...
>|||Thanks! Adding the SPN took care of it. I thought I was there, but now I'm
having problems configuring the alerts. Outlook 2003 SP2 is installed. I
logged in with he SQL service account, and setup the MAPI profile. That
worked fine. When I set up an operator logged in as the service account,
clicking Test email generates this error:
http://img167.imageshack.us/my.php?...sqlerroran3.png
If I log in as my self, it acts like it went through when I click test, but
no email is generated.
Any ideas?
Thanks again for your help.
-Matthew
"Kevin3NF" <Kevin@.DontNeedNoSpam3NF-inc.com> wrote in message
news:OxBRke33GHA.1288@.TK2MSFTNGP03.phx.gbl...
> Cannot Generate SSPI context is almost always related to there not being a
> Service Principal Name defined for that server, account and port in a
> Kerberos environment.
> Domain accounts do not create an SPN, whereas Domain Admins and Local
> System do.
> Test this by making (temporarily) your startup account a domain admin and
> the resetting in in SQL Enterprise Manager. restart and test
> connectivity.
> If it connects, have your domain admin (must be a domain admin) create an
> SPN for the MSSQLSvc in Active Directory.
> See the Books Online article "Security Account Delegation" for formot of
> what the resulting SPN should look like.
> Also, make sure the SQL Server is listening on TCP...make that your first
> step.
> --
> Kevin Hill
> 3NF Consulting
> www.3nf-inc.com/NewsGroups.htm
>
>
> "Matthew Kitchin (Usenet/Lists)" <mkitchin.public@.gmail.com> wrote in
> message news:%231cmKJ33GHA.1300@.TK2MSFTNGP05.phx.gbl...
>|||All I can tell you is that SQL mail is profiel specific...could be a
permissions issue on the profile itself?
That's not my area :-)
Kevin Hill
3NF Consulting
www.3nf-inc.com/NewsGroups.htm
"Matthew Kitchin (Usenet/Lists)" <mkitchin.public@.gmail.com> wrote in
message news:eMiLlw33GHA.5000@.TK2MSFTNGP02.phx.gbl...
> Thanks! Adding the SPN took care of it. I thought I was there, but now I'm
> having problems configuring the alerts. Outlook 2003 SP2 is installed. I
> logged in with he SQL service account, and setup the MAPI profile. That
> worked fine. When I set up an operator logged in as the service account,
> clicking Test email generates this error:
> http://img167.imageshack.us/my.php?...sqlerroran3.png
> If I log in as my self, it acts like it went through when I click test,
> but no email is generated.
> Any ideas?
> Thanks again for your help.
> -Matthew
> "Kevin3NF" <Kevin@.DontNeedNoSpam3NF-inc.com> wrote in message
> news:OxBRke33GHA.1288@.TK2MSFTNGP03.phx.gbl...
>|||This thing is baffling. I read a couple posts that just the 'Test' button
has issues. I scheduled some maintenance to run at 4 AM last night. It ran,
sent me the results, and the log indicated the job failed because the last
step, the email, failed.
The job failed. The Job was invoked by Schedule 4 (Schedule 1). The last
step to run was step 1 (Step 1). NOTE: Failed to notify 'SQL Alerts' via
email.
"Kevin3NF" <Kevin@.DontNeedNoSpam3NF-inc.com> wrote in message
news:uFBi8n43GHA.4924@.TK2MSFTNGP05.phx.gbl...
> All I can tell you is that SQL mail is profiel specific...could be a
> permissions issue on the profile itself?
> That's not my area :-)
> --
> Kevin Hill
> 3NF Consulting
> www.3nf-inc.com/NewsGroups.htm
>
>
> "Matthew Kitchin (Usenet/Lists)" <mkitchin.public@.gmail.com> wrote in
> message news:eMiLlw33GHA.5000@.TK2MSFTNGP02.phx.gbl...
>
configured the sql service and sql agent service to run as a domain account.
I made that account a member of the administrators group on the SQL server,
and restarted the services. Everything looked fine. The problem is, some of
my remote applications cannot connect when it is running as a domain
account, but they are fine when it is running as a local system account. On
a remote Microsoft WSUS server, it breaks when the SQL services on the SQL
server use a domain account. Osql on the remote box generates this:
Cannot generate SSPI context
I did try to research this before posting here, but I couldn't find anything
that described this problem. Everything was referring to PCs connecting from
a different domain. That is not the case here.
Thanks,
MatthewCannot Generate SSPI context is almost always related to there not being a
Service Principal Name defined for that server, account and port in a
Kerberos environment.
Domain accounts do not create an SPN, whereas Domain Admins and Local System
do.
Test this by making (temporarily) your startup account a domain admin and
the resetting in in SQL Enterprise Manager. restart and test connectivity.
If it connects, have your domain admin (must be a domain admin) create an
SPN for the MSSQLSvc in Active Directory.
See the Books Online article "Security Account Delegation" for formot of
what the resulting SPN should look like.
Also, make sure the SQL Server is listening on TCP...make that your first
step.
Kevin Hill
3NF Consulting
www.3nf-inc.com/NewsGroups.htm
"Matthew Kitchin (Usenet/Lists)" <mkitchin.public@.gmail.com> wrote in
message news:%231cmKJ33GHA.1300@.TK2MSFTNGP05.phx.gbl...
> I'm running SQL 2000 SP4 on 2003 server. I'm trying to setup email alerts.
> I configured the sql service and sql agent service to run as a domain
> account. I made that account a member of the administrators group on the
> SQL server, and restarted the services. Everything looked fine. The
> problem is, some of my remote applications cannot connect when it is
> running as a domain account, but they are fine when it is running as a
> local system account. On a remote Microsoft WSUS server, it breaks when
> the SQL services on the SQL server use a domain account. Osql on the
> remote box generates this:
> Cannot generate SSPI context
> I did try to research this before posting here, but I couldn't find
> anything that described this problem. Everything was referring to PCs
> connecting from a different domain. That is not the case here.
> Thanks,
> Matthew
>|||I am the domain admin, so that won't be a problem. As soon as some of the
current activity dies down, I will try this. Thanks!
"Kevin3NF" <Kevin@.DontNeedNoSpam3NF-inc.com> wrote in message
news:OxBRke33GHA.1288@.TK2MSFTNGP03.phx.gbl...
> Cannot Generate SSPI context is almost always related to there not being a
> Service Principal Name defined for that server, account and port in a
> Kerberos environment.
> Domain accounts do not create an SPN, whereas Domain Admins and Local
> System do.
> Test this by making (temporarily) your startup account a domain admin and
> the resetting in in SQL Enterprise Manager. restart and test
> connectivity.
> If it connects, have your domain admin (must be a domain admin) create an
> SPN for the MSSQLSvc in Active Directory.
> See the Books Online article "Security Account Delegation" for formot of
> what the resulting SPN should look like.
> Also, make sure the SQL Server is listening on TCP...make that your first
> step.
> --
> Kevin Hill
> 3NF Consulting
> www.3nf-inc.com/NewsGroups.htm
>
>
> "Matthew Kitchin (Usenet/Lists)" <mkitchin.public@.gmail.com> wrote in
> message news:%231cmKJ33GHA.1300@.TK2MSFTNGP05.phx.gbl...
>|||Thanks! Adding the SPN took care of it. I thought I was there, but now I'm
having problems configuring the alerts. Outlook 2003 SP2 is installed. I
logged in with he SQL service account, and setup the MAPI profile. That
worked fine. When I set up an operator logged in as the service account,
clicking Test email generates this error:
http://img167.imageshack.us/my.php?...sqlerroran3.png
If I log in as my self, it acts like it went through when I click test, but
no email is generated.
Any ideas?
Thanks again for your help.
-Matthew
"Kevin3NF" <Kevin@.DontNeedNoSpam3NF-inc.com> wrote in message
news:OxBRke33GHA.1288@.TK2MSFTNGP03.phx.gbl...
> Cannot Generate SSPI context is almost always related to there not being a
> Service Principal Name defined for that server, account and port in a
> Kerberos environment.
> Domain accounts do not create an SPN, whereas Domain Admins and Local
> System do.
> Test this by making (temporarily) your startup account a domain admin and
> the resetting in in SQL Enterprise Manager. restart and test
> connectivity.
> If it connects, have your domain admin (must be a domain admin) create an
> SPN for the MSSQLSvc in Active Directory.
> See the Books Online article "Security Account Delegation" for formot of
> what the resulting SPN should look like.
> Also, make sure the SQL Server is listening on TCP...make that your first
> step.
> --
> Kevin Hill
> 3NF Consulting
> www.3nf-inc.com/NewsGroups.htm
>
>
> "Matthew Kitchin (Usenet/Lists)" <mkitchin.public@.gmail.com> wrote in
> message news:%231cmKJ33GHA.1300@.TK2MSFTNGP05.phx.gbl...
>|||All I can tell you is that SQL mail is profiel specific...could be a
permissions issue on the profile itself?
That's not my area :-)
Kevin Hill
3NF Consulting
www.3nf-inc.com/NewsGroups.htm
"Matthew Kitchin (Usenet/Lists)" <mkitchin.public@.gmail.com> wrote in
message news:eMiLlw33GHA.5000@.TK2MSFTNGP02.phx.gbl...
> Thanks! Adding the SPN took care of it. I thought I was there, but now I'm
> having problems configuring the alerts. Outlook 2003 SP2 is installed. I
> logged in with he SQL service account, and setup the MAPI profile. That
> worked fine. When I set up an operator logged in as the service account,
> clicking Test email generates this error:
> http://img167.imageshack.us/my.php?...sqlerroran3.png
> If I log in as my self, it acts like it went through when I click test,
> but no email is generated.
> Any ideas?
> Thanks again for your help.
> -Matthew
> "Kevin3NF" <Kevin@.DontNeedNoSpam3NF-inc.com> wrote in message
> news:OxBRke33GHA.1288@.TK2MSFTNGP03.phx.gbl...
>|||This thing is baffling. I read a couple posts that just the 'Test' button
has issues. I scheduled some maintenance to run at 4 AM last night. It ran,
sent me the results, and the log indicated the job failed because the last
step, the email, failed.
The job failed. The Job was invoked by Schedule 4 (Schedule 1). The last
step to run was step 1 (Step 1). NOTE: Failed to notify 'SQL Alerts' via
email.
"Kevin3NF" <Kevin@.DontNeedNoSpam3NF-inc.com> wrote in message
news:uFBi8n43GHA.4924@.TK2MSFTNGP05.phx.gbl...
> All I can tell you is that SQL mail is profiel specific...could be a
> permissions issue on the profile itself?
> That's not my area :-)
> --
> Kevin Hill
> 3NF Consulting
> www.3nf-inc.com/NewsGroups.htm
>
>
> "Matthew Kitchin (Usenet/Lists)" <mkitchin.public@.gmail.com> wrote in
> message news:eMiLlw33GHA.5000@.TK2MSFTNGP02.phx.gbl...
>
Can't connect remotely when SQL services running as a domain account
I'm running SQL 2000 SP4 on 2003 server. I'm trying to setup email alerts. I
configured the sql service and sql agent service to run as a domain account.
I made that account a member of the administrators group on the SQL server,
and restarted the services. Everything looked fine. The problem is, some of
my remote applications cannot connect when it is running as a domain
account, but they are fine when it is running as a local system account. On
a remote Microsoft WSUS server, it breaks when the SQL services on the SQL
server use a domain account. Osql on the remote box generates this:
Cannot generate SSPI context
I did try to research this before posting here, but I couldn't find anything
that described this problem. Everything was referring to PCs connecting from
a different domain. That is not the case here.
Thanks,
Matthew
Cannot Generate SSPI context is almost always related to there not being a
Service Principal Name defined for that server, account and port in a
Kerberos environment.
Domain accounts do not create an SPN, whereas Domain Admins and Local System
do.
Test this by making (temporarily) your startup account a domain admin and
the resetting in in SQL Enterprise Manager. restart and test connectivity.
If it connects, have your domain admin (must be a domain admin) create an
SPN for the MSSQLSvc in Active Directory.
See the Books Online article "Security Account Delegation" for formot of
what the resulting SPN should look like.
Also, make sure the SQL Server is listening on TCP...make that your first
step.
Kevin Hill
3NF Consulting
www.3nf-inc.com/NewsGroups.htm
"Matthew Kitchin (Usenet/Lists)" <mkitchin.public@.gmail.com> wrote in
message news:%231cmKJ33GHA.1300@.TK2MSFTNGP05.phx.gbl...
> I'm running SQL 2000 SP4 on 2003 server. I'm trying to setup email alerts.
> I configured the sql service and sql agent service to run as a domain
> account. I made that account a member of the administrators group on the
> SQL server, and restarted the services. Everything looked fine. The
> problem is, some of my remote applications cannot connect when it is
> running as a domain account, but they are fine when it is running as a
> local system account. On a remote Microsoft WSUS server, it breaks when
> the SQL services on the SQL server use a domain account. Osql on the
> remote box generates this:
> Cannot generate SSPI context
> I did try to research this before posting here, but I couldn't find
> anything that described this problem. Everything was referring to PCs
> connecting from a different domain. That is not the case here.
> Thanks,
> Matthew
>
|||I am the domain admin, so that won't be a problem. As soon as some of the
current activity dies down, I will try this. Thanks!
"Kevin3NF" <Kevin@.DontNeedNoSpam3NF-inc.com> wrote in message
news:OxBRke33GHA.1288@.TK2MSFTNGP03.phx.gbl...
> Cannot Generate SSPI context is almost always related to there not being a
> Service Principal Name defined for that server, account and port in a
> Kerberos environment.
> Domain accounts do not create an SPN, whereas Domain Admins and Local
> System do.
> Test this by making (temporarily) your startup account a domain admin and
> the resetting in in SQL Enterprise Manager. restart and test
> connectivity.
> If it connects, have your domain admin (must be a domain admin) create an
> SPN for the MSSQLSvc in Active Directory.
> See the Books Online article "Security Account Delegation" for formot of
> what the resulting SPN should look like.
> Also, make sure the SQL Server is listening on TCP...make that your first
> step.
> --
> Kevin Hill
> 3NF Consulting
> www.3nf-inc.com/NewsGroups.htm
>
>
> "Matthew Kitchin (Usenet/Lists)" <mkitchin.public@.gmail.com> wrote in
> message news:%231cmKJ33GHA.1300@.TK2MSFTNGP05.phx.gbl...
>
|||Thanks! Adding the SPN took care of it. I thought I was there, but now I'm
having problems configuring the alerts. Outlook 2003 SP2 is installed. I
logged in with he SQL service account, and setup the MAPI profile. That
worked fine. When I set up an operator logged in as the service account,
clicking Test email generates this error:
http://img167.imageshack.us/my.php?i...qlerroran3.png
If I log in as my self, it acts like it went through when I click test, but
no email is generated.
Any ideas?
Thanks again for your help.
-Matthew
"Kevin3NF" <Kevin@.DontNeedNoSpam3NF-inc.com> wrote in message
news:OxBRke33GHA.1288@.TK2MSFTNGP03.phx.gbl...
> Cannot Generate SSPI context is almost always related to there not being a
> Service Principal Name defined for that server, account and port in a
> Kerberos environment.
> Domain accounts do not create an SPN, whereas Domain Admins and Local
> System do.
> Test this by making (temporarily) your startup account a domain admin and
> the resetting in in SQL Enterprise Manager. restart and test
> connectivity.
> If it connects, have your domain admin (must be a domain admin) create an
> SPN for the MSSQLSvc in Active Directory.
> See the Books Online article "Security Account Delegation" for formot of
> what the resulting SPN should look like.
> Also, make sure the SQL Server is listening on TCP...make that your first
> step.
> --
> Kevin Hill
> 3NF Consulting
> www.3nf-inc.com/NewsGroups.htm
>
>
> "Matthew Kitchin (Usenet/Lists)" <mkitchin.public@.gmail.com> wrote in
> message news:%231cmKJ33GHA.1300@.TK2MSFTNGP05.phx.gbl...
>
|||All I can tell you is that SQL mail is profiel specific...could be a
permissions issue on the profile itself?
That's not my area :-)
Kevin Hill
3NF Consulting
www.3nf-inc.com/NewsGroups.htm
"Matthew Kitchin (Usenet/Lists)" <mkitchin.public@.gmail.com> wrote in
message news:eMiLlw33GHA.5000@.TK2MSFTNGP02.phx.gbl...
> Thanks! Adding the SPN took care of it. I thought I was there, but now I'm
> having problems configuring the alerts. Outlook 2003 SP2 is installed. I
> logged in with he SQL service account, and setup the MAPI profile. That
> worked fine. When I set up an operator logged in as the service account,
> clicking Test email generates this error:
> http://img167.imageshack.us/my.php?i...qlerroran3.png
> If I log in as my self, it acts like it went through when I click test,
> but no email is generated.
> Any ideas?
> Thanks again for your help.
> -Matthew
> "Kevin3NF" <Kevin@.DontNeedNoSpam3NF-inc.com> wrote in message
> news:OxBRke33GHA.1288@.TK2MSFTNGP03.phx.gbl...
>
|||This thing is baffling. I read a couple posts that just the 'Test' button
has issues. I scheduled some maintenance to run at 4 AM last night. It ran,
sent me the results, and the log indicated the job failed because the last
step, the email, failed.
The job failed. The Job was invoked by Schedule 4 (Schedule 1). The last
step to run was step 1 (Step 1). NOTE: Failed to notify 'SQL Alerts' via
email.
"Kevin3NF" <Kevin@.DontNeedNoSpam3NF-inc.com> wrote in message
news:uFBi8n43GHA.4924@.TK2MSFTNGP05.phx.gbl...
> All I can tell you is that SQL mail is profiel specific...could be a
> permissions issue on the profile itself?
> That's not my area :-)
> --
> Kevin Hill
> 3NF Consulting
> www.3nf-inc.com/NewsGroups.htm
>
>
> "Matthew Kitchin (Usenet/Lists)" <mkitchin.public@.gmail.com> wrote in
> message news:eMiLlw33GHA.5000@.TK2MSFTNGP02.phx.gbl...
>
configured the sql service and sql agent service to run as a domain account.
I made that account a member of the administrators group on the SQL server,
and restarted the services. Everything looked fine. The problem is, some of
my remote applications cannot connect when it is running as a domain
account, but they are fine when it is running as a local system account. On
a remote Microsoft WSUS server, it breaks when the SQL services on the SQL
server use a domain account. Osql on the remote box generates this:
Cannot generate SSPI context
I did try to research this before posting here, but I couldn't find anything
that described this problem. Everything was referring to PCs connecting from
a different domain. That is not the case here.
Thanks,
Matthew
Cannot Generate SSPI context is almost always related to there not being a
Service Principal Name defined for that server, account and port in a
Kerberos environment.
Domain accounts do not create an SPN, whereas Domain Admins and Local System
do.
Test this by making (temporarily) your startup account a domain admin and
the resetting in in SQL Enterprise Manager. restart and test connectivity.
If it connects, have your domain admin (must be a domain admin) create an
SPN for the MSSQLSvc in Active Directory.
See the Books Online article "Security Account Delegation" for formot of
what the resulting SPN should look like.
Also, make sure the SQL Server is listening on TCP...make that your first
step.
Kevin Hill
3NF Consulting
www.3nf-inc.com/NewsGroups.htm
"Matthew Kitchin (Usenet/Lists)" <mkitchin.public@.gmail.com> wrote in
message news:%231cmKJ33GHA.1300@.TK2MSFTNGP05.phx.gbl...
> I'm running SQL 2000 SP4 on 2003 server. I'm trying to setup email alerts.
> I configured the sql service and sql agent service to run as a domain
> account. I made that account a member of the administrators group on the
> SQL server, and restarted the services. Everything looked fine. The
> problem is, some of my remote applications cannot connect when it is
> running as a domain account, but they are fine when it is running as a
> local system account. On a remote Microsoft WSUS server, it breaks when
> the SQL services on the SQL server use a domain account. Osql on the
> remote box generates this:
> Cannot generate SSPI context
> I did try to research this before posting here, but I couldn't find
> anything that described this problem. Everything was referring to PCs
> connecting from a different domain. That is not the case here.
> Thanks,
> Matthew
>
|||I am the domain admin, so that won't be a problem. As soon as some of the
current activity dies down, I will try this. Thanks!
"Kevin3NF" <Kevin@.DontNeedNoSpam3NF-inc.com> wrote in message
news:OxBRke33GHA.1288@.TK2MSFTNGP03.phx.gbl...
> Cannot Generate SSPI context is almost always related to there not being a
> Service Principal Name defined for that server, account and port in a
> Kerberos environment.
> Domain accounts do not create an SPN, whereas Domain Admins and Local
> System do.
> Test this by making (temporarily) your startup account a domain admin and
> the resetting in in SQL Enterprise Manager. restart and test
> connectivity.
> If it connects, have your domain admin (must be a domain admin) create an
> SPN for the MSSQLSvc in Active Directory.
> See the Books Online article "Security Account Delegation" for formot of
> what the resulting SPN should look like.
> Also, make sure the SQL Server is listening on TCP...make that your first
> step.
> --
> Kevin Hill
> 3NF Consulting
> www.3nf-inc.com/NewsGroups.htm
>
>
> "Matthew Kitchin (Usenet/Lists)" <mkitchin.public@.gmail.com> wrote in
> message news:%231cmKJ33GHA.1300@.TK2MSFTNGP05.phx.gbl...
>
|||Thanks! Adding the SPN took care of it. I thought I was there, but now I'm
having problems configuring the alerts. Outlook 2003 SP2 is installed. I
logged in with he SQL service account, and setup the MAPI profile. That
worked fine. When I set up an operator logged in as the service account,
clicking Test email generates this error:
http://img167.imageshack.us/my.php?i...qlerroran3.png
If I log in as my self, it acts like it went through when I click test, but
no email is generated.
Any ideas?
Thanks again for your help.
-Matthew
"Kevin3NF" <Kevin@.DontNeedNoSpam3NF-inc.com> wrote in message
news:OxBRke33GHA.1288@.TK2MSFTNGP03.phx.gbl...
> Cannot Generate SSPI context is almost always related to there not being a
> Service Principal Name defined for that server, account and port in a
> Kerberos environment.
> Domain accounts do not create an SPN, whereas Domain Admins and Local
> System do.
> Test this by making (temporarily) your startup account a domain admin and
> the resetting in in SQL Enterprise Manager. restart and test
> connectivity.
> If it connects, have your domain admin (must be a domain admin) create an
> SPN for the MSSQLSvc in Active Directory.
> See the Books Online article "Security Account Delegation" for formot of
> what the resulting SPN should look like.
> Also, make sure the SQL Server is listening on TCP...make that your first
> step.
> --
> Kevin Hill
> 3NF Consulting
> www.3nf-inc.com/NewsGroups.htm
>
>
> "Matthew Kitchin (Usenet/Lists)" <mkitchin.public@.gmail.com> wrote in
> message news:%231cmKJ33GHA.1300@.TK2MSFTNGP05.phx.gbl...
>
|||All I can tell you is that SQL mail is profiel specific...could be a
permissions issue on the profile itself?
That's not my area :-)
Kevin Hill
3NF Consulting
www.3nf-inc.com/NewsGroups.htm
"Matthew Kitchin (Usenet/Lists)" <mkitchin.public@.gmail.com> wrote in
message news:eMiLlw33GHA.5000@.TK2MSFTNGP02.phx.gbl...
> Thanks! Adding the SPN took care of it. I thought I was there, but now I'm
> having problems configuring the alerts. Outlook 2003 SP2 is installed. I
> logged in with he SQL service account, and setup the MAPI profile. That
> worked fine. When I set up an operator logged in as the service account,
> clicking Test email generates this error:
> http://img167.imageshack.us/my.php?i...qlerroran3.png
> If I log in as my self, it acts like it went through when I click test,
> but no email is generated.
> Any ideas?
> Thanks again for your help.
> -Matthew
> "Kevin3NF" <Kevin@.DontNeedNoSpam3NF-inc.com> wrote in message
> news:OxBRke33GHA.1288@.TK2MSFTNGP03.phx.gbl...
>
|||This thing is baffling. I read a couple posts that just the 'Test' button
has issues. I scheduled some maintenance to run at 4 AM last night. It ran,
sent me the results, and the log indicated the job failed because the last
step, the email, failed.
The job failed. The Job was invoked by Schedule 4 (Schedule 1). The last
step to run was step 1 (Step 1). NOTE: Failed to notify 'SQL Alerts' via
email.
"Kevin3NF" <Kevin@.DontNeedNoSpam3NF-inc.com> wrote in message
news:uFBi8n43GHA.4924@.TK2MSFTNGP05.phx.gbl...
> All I can tell you is that SQL mail is profiel specific...could be a
> permissions issue on the profile itself?
> That's not my area :-)
> --
> Kevin Hill
> 3NF Consulting
> www.3nf-inc.com/NewsGroups.htm
>
>
> "Matthew Kitchin (Usenet/Lists)" <mkitchin.public@.gmail.com> wrote in
> message news:eMiLlw33GHA.5000@.TK2MSFTNGP02.phx.gbl...
>
Can't connect remotely when SQL services running as a domain account
I'm running SQL 2000 SP4 on 2003 server. I'm trying to setup email alerts. I
configured the sql service and sql agent service to run as a domain account.
I made that account a member of the administrators group on the SQL server,
and restarted the services. Everything looked fine. The problem is, some of
my remote applications cannot connect when it is running as a domain
account, but they are fine when it is running as a local system account. On
a remote Microsoft WSUS server, it breaks when the SQL services on the SQL
server use a domain account. Osql on the remote box generates this:
Cannot generate SSPI context
I did try to research this before posting here, but I couldn't find anything
that described this problem. Everything was referring to PCs connecting from
a different domain. That is not the case here.
Thanks,
MatthewCannot Generate SSPI context is almost always related to there not being a
Service Principal Name defined for that server, account and port in a
Kerberos environment.
Domain accounts do not create an SPN, whereas Domain Admins and Local System
do.
Test this by making (temporarily) your startup account a domain admin and
the resetting in in SQL Enterprise Manager. restart and test connectivity.
If it connects, have your domain admin (must be a domain admin) create an
SPN for the MSSQLSvc in Active Directory.
See the Books Online article "Security Account Delegation" for formot of
what the resulting SPN should look like.
Also, make sure the SQL Server is listening on TCP...make that your first
step.
--
Kevin Hill
3NF Consulting
www.3nf-inc.com/NewsGroups.htm
"Matthew Kitchin (Usenet/Lists)" <mkitchin.public@.gmail.com> wrote in
message news:%231cmKJ33GHA.1300@.TK2MSFTNGP05.phx.gbl...
> I'm running SQL 2000 SP4 on 2003 server. I'm trying to setup email alerts.
> I configured the sql service and sql agent service to run as a domain
> account. I made that account a member of the administrators group on the
> SQL server, and restarted the services. Everything looked fine. The
> problem is, some of my remote applications cannot connect when it is
> running as a domain account, but they are fine when it is running as a
> local system account. On a remote Microsoft WSUS server, it breaks when
> the SQL services on the SQL server use a domain account. Osql on the
> remote box generates this:
> Cannot generate SSPI context
> I did try to research this before posting here, but I couldn't find
> anything that described this problem. Everything was referring to PCs
> connecting from a different domain. That is not the case here.
> Thanks,
> Matthew
>|||I am the domain admin, so that won't be a problem. As soon as some of the
current activity dies down, I will try this. Thanks!
"Kevin3NF" <Kevin@.DontNeedNoSpam3NF-inc.com> wrote in message
news:OxBRke33GHA.1288@.TK2MSFTNGP03.phx.gbl...
> Cannot Generate SSPI context is almost always related to there not being a
> Service Principal Name defined for that server, account and port in a
> Kerberos environment.
> Domain accounts do not create an SPN, whereas Domain Admins and Local
> System do.
> Test this by making (temporarily) your startup account a domain admin and
> the resetting in in SQL Enterprise Manager. restart and test
> connectivity.
> If it connects, have your domain admin (must be a domain admin) create an
> SPN for the MSSQLSvc in Active Directory.
> See the Books Online article "Security Account Delegation" for formot of
> what the resulting SPN should look like.
> Also, make sure the SQL Server is listening on TCP...make that your first
> step.
> --
> Kevin Hill
> 3NF Consulting
> www.3nf-inc.com/NewsGroups.htm
>
>
> "Matthew Kitchin (Usenet/Lists)" <mkitchin.public@.gmail.com> wrote in
> message news:%231cmKJ33GHA.1300@.TK2MSFTNGP05.phx.gbl...
>> I'm running SQL 2000 SP4 on 2003 server. I'm trying to setup email
>> alerts. I configured the sql service and sql agent service to run as a
>> domain account. I made that account a member of the administrators group
>> on the SQL server, and restarted the services. Everything looked fine.
>> The problem is, some of my remote applications cannot connect when it is
>> running as a domain account, but they are fine when it is running as a
>> local system account. On a remote Microsoft WSUS server, it breaks when
>> the SQL services on the SQL server use a domain account. Osql on the
>> remote box generates this:
>> Cannot generate SSPI context
>> I did try to research this before posting here, but I couldn't find
>> anything that described this problem. Everything was referring to PCs
>> connecting from a different domain. That is not the case here.
>> Thanks,
>> Matthew
>|||Thanks! Adding the SPN took care of it. I thought I was there, but now I'm
having problems configuring the alerts. Outlook 2003 SP2 is installed. I
logged in with he SQL service account, and setup the MAPI profile. That
worked fine. When I set up an operator logged in as the service account,
clicking Test email generates this error:
http://img167.imageshack.us/my.php?image=sqlerroran3.png
If I log in as my self, it acts like it went through when I click test, but
no email is generated.
Any ideas?
Thanks again for your help.
-Matthew
"Kevin3NF" <Kevin@.DontNeedNoSpam3NF-inc.com> wrote in message
news:OxBRke33GHA.1288@.TK2MSFTNGP03.phx.gbl...
> Cannot Generate SSPI context is almost always related to there not being a
> Service Principal Name defined for that server, account and port in a
> Kerberos environment.
> Domain accounts do not create an SPN, whereas Domain Admins and Local
> System do.
> Test this by making (temporarily) your startup account a domain admin and
> the resetting in in SQL Enterprise Manager. restart and test
> connectivity.
> If it connects, have your domain admin (must be a domain admin) create an
> SPN for the MSSQLSvc in Active Directory.
> See the Books Online article "Security Account Delegation" for formot of
> what the resulting SPN should look like.
> Also, make sure the SQL Server is listening on TCP...make that your first
> step.
> --
> Kevin Hill
> 3NF Consulting
> www.3nf-inc.com/NewsGroups.htm
>
>
> "Matthew Kitchin (Usenet/Lists)" <mkitchin.public@.gmail.com> wrote in
> message news:%231cmKJ33GHA.1300@.TK2MSFTNGP05.phx.gbl...
>> I'm running SQL 2000 SP4 on 2003 server. I'm trying to setup email
>> alerts. I configured the sql service and sql agent service to run as a
>> domain account. I made that account a member of the administrators group
>> on the SQL server, and restarted the services. Everything looked fine.
>> The problem is, some of my remote applications cannot connect when it is
>> running as a domain account, but they are fine when it is running as a
>> local system account. On a remote Microsoft WSUS server, it breaks when
>> the SQL services on the SQL server use a domain account. Osql on the
>> remote box generates this:
>> Cannot generate SSPI context
>> I did try to research this before posting here, but I couldn't find
>> anything that described this problem. Everything was referring to PCs
>> connecting from a different domain. That is not the case here.
>> Thanks,
>> Matthew
>|||All I can tell you is that SQL mail is profiel specific...could be a
permissions issue on the profile itself?
That's not my area :-)
--
Kevin Hill
3NF Consulting
www.3nf-inc.com/NewsGroups.htm
"Matthew Kitchin (Usenet/Lists)" <mkitchin.public@.gmail.com> wrote in
message news:eMiLlw33GHA.5000@.TK2MSFTNGP02.phx.gbl...
> Thanks! Adding the SPN took care of it. I thought I was there, but now I'm
> having problems configuring the alerts. Outlook 2003 SP2 is installed. I
> logged in with he SQL service account, and setup the MAPI profile. That
> worked fine. When I set up an operator logged in as the service account,
> clicking Test email generates this error:
> http://img167.imageshack.us/my.php?image=sqlerroran3.png
> If I log in as my self, it acts like it went through when I click test,
> but no email is generated.
> Any ideas?
> Thanks again for your help.
> -Matthew
> "Kevin3NF" <Kevin@.DontNeedNoSpam3NF-inc.com> wrote in message
> news:OxBRke33GHA.1288@.TK2MSFTNGP03.phx.gbl...
>> Cannot Generate SSPI context is almost always related to there not being
>> a Service Principal Name defined for that server, account and port in a
>> Kerberos environment.
>> Domain accounts do not create an SPN, whereas Domain Admins and Local
>> System do.
>> Test this by making (temporarily) your startup account a domain admin and
>> the resetting in in SQL Enterprise Manager. restart and test
>> connectivity.
>> If it connects, have your domain admin (must be a domain admin) create an
>> SPN for the MSSQLSvc in Active Directory.
>> See the Books Online article "Security Account Delegation" for formot of
>> what the resulting SPN should look like.
>> Also, make sure the SQL Server is listening on TCP...make that your first
>> step.
>> --
>> Kevin Hill
>> 3NF Consulting
>> www.3nf-inc.com/NewsGroups.htm
>>
>>
>> "Matthew Kitchin (Usenet/Lists)" <mkitchin.public@.gmail.com> wrote in
>> message news:%231cmKJ33GHA.1300@.TK2MSFTNGP05.phx.gbl...
>> I'm running SQL 2000 SP4 on 2003 server. I'm trying to setup email
>> alerts. I configured the sql service and sql agent service to run as a
>> domain account. I made that account a member of the administrators group
>> on the SQL server, and restarted the services. Everything looked fine.
>> The problem is, some of my remote applications cannot connect when it is
>> running as a domain account, but they are fine when it is running as a
>> local system account. On a remote Microsoft WSUS server, it breaks when
>> the SQL services on the SQL server use a domain account. Osql on the
>> remote box generates this:
>> Cannot generate SSPI context
>> I did try to research this before posting here, but I couldn't find
>> anything that described this problem. Everything was referring to PCs
>> connecting from a different domain. That is not the case here.
>> Thanks,
>> Matthew
>>
>|||This thing is baffling. I read a couple posts that just the 'Test' button
has issues. I scheduled some maintenance to run at 4 AM last night. It ran,
sent me the results, and the log indicated the job failed because the last
step, the email, failed.
The job failed. The Job was invoked by Schedule 4 (Schedule 1). The last
step to run was step 1 (Step 1). NOTE: Failed to notify 'SQL Alerts' via
email.
"Kevin3NF" <Kevin@.DontNeedNoSpam3NF-inc.com> wrote in message
news:uFBi8n43GHA.4924@.TK2MSFTNGP05.phx.gbl...
> All I can tell you is that SQL mail is profiel specific...could be a
> permissions issue on the profile itself?
> That's not my area :-)
> --
> Kevin Hill
> 3NF Consulting
> www.3nf-inc.com/NewsGroups.htm
>
>
> "Matthew Kitchin (Usenet/Lists)" <mkitchin.public@.gmail.com> wrote in
> message news:eMiLlw33GHA.5000@.TK2MSFTNGP02.phx.gbl...
>> Thanks! Adding the SPN took care of it. I thought I was there, but now
>> I'm having problems configuring the alerts. Outlook 2003 SP2 is
>> installed. I logged in with he SQL service account, and setup the MAPI
>> profile. That worked fine. When I set up an operator logged in as the
>> service account, clicking Test email generates this error:
>> http://img167.imageshack.us/my.php?image=sqlerroran3.png
>> If I log in as my self, it acts like it went through when I click test,
>> but no email is generated.
>> Any ideas?
>> Thanks again for your help.
>> -Matthew
>> "Kevin3NF" <Kevin@.DontNeedNoSpam3NF-inc.com> wrote in message
>> news:OxBRke33GHA.1288@.TK2MSFTNGP03.phx.gbl...
>> Cannot Generate SSPI context is almost always related to there not being
>> a Service Principal Name defined for that server, account and port in a
>> Kerberos environment.
>> Domain accounts do not create an SPN, whereas Domain Admins and Local
>> System do.
>> Test this by making (temporarily) your startup account a domain admin
>> and the resetting in in SQL Enterprise Manager. restart and test
>> connectivity.
>> If it connects, have your domain admin (must be a domain admin) create
>> an SPN for the MSSQLSvc in Active Directory.
>> See the Books Online article "Security Account Delegation" for formot of
>> what the resulting SPN should look like.
>> Also, make sure the SQL Server is listening on TCP...make that your
>> first step.
>> --
>> Kevin Hill
>> 3NF Consulting
>> www.3nf-inc.com/NewsGroups.htm
>>
>>
>> "Matthew Kitchin (Usenet/Lists)" <mkitchin.public@.gmail.com> wrote in
>> message news:%231cmKJ33GHA.1300@.TK2MSFTNGP05.phx.gbl...
>> I'm running SQL 2000 SP4 on 2003 server. I'm trying to setup email
>> alerts. I configured the sql service and sql agent service to run as a
>> domain account. I made that account a member of the administrators
>> group on the SQL server, and restarted the services. Everything looked
>> fine. The problem is, some of my remote applications cannot connect
>> when it is running as a domain account, but they are fine when it is
>> running as a local system account. On a remote Microsoft WSUS server,
>> it breaks when the SQL services on the SQL server use a domain account.
>> Osql on the remote box generates this:
>> Cannot generate SSPI context
>> I did try to research this before posting here, but I couldn't find
>> anything that described this problem. Everything was referring to PCs
>> connecting from a different domain. That is not the case here.
>> Thanks,
>> Matthew
>>
>>
>
configured the sql service and sql agent service to run as a domain account.
I made that account a member of the administrators group on the SQL server,
and restarted the services. Everything looked fine. The problem is, some of
my remote applications cannot connect when it is running as a domain
account, but they are fine when it is running as a local system account. On
a remote Microsoft WSUS server, it breaks when the SQL services on the SQL
server use a domain account. Osql on the remote box generates this:
Cannot generate SSPI context
I did try to research this before posting here, but I couldn't find anything
that described this problem. Everything was referring to PCs connecting from
a different domain. That is not the case here.
Thanks,
MatthewCannot Generate SSPI context is almost always related to there not being a
Service Principal Name defined for that server, account and port in a
Kerberos environment.
Domain accounts do not create an SPN, whereas Domain Admins and Local System
do.
Test this by making (temporarily) your startup account a domain admin and
the resetting in in SQL Enterprise Manager. restart and test connectivity.
If it connects, have your domain admin (must be a domain admin) create an
SPN for the MSSQLSvc in Active Directory.
See the Books Online article "Security Account Delegation" for formot of
what the resulting SPN should look like.
Also, make sure the SQL Server is listening on TCP...make that your first
step.
--
Kevin Hill
3NF Consulting
www.3nf-inc.com/NewsGroups.htm
"Matthew Kitchin (Usenet/Lists)" <mkitchin.public@.gmail.com> wrote in
message news:%231cmKJ33GHA.1300@.TK2MSFTNGP05.phx.gbl...
> I'm running SQL 2000 SP4 on 2003 server. I'm trying to setup email alerts.
> I configured the sql service and sql agent service to run as a domain
> account. I made that account a member of the administrators group on the
> SQL server, and restarted the services. Everything looked fine. The
> problem is, some of my remote applications cannot connect when it is
> running as a domain account, but they are fine when it is running as a
> local system account. On a remote Microsoft WSUS server, it breaks when
> the SQL services on the SQL server use a domain account. Osql on the
> remote box generates this:
> Cannot generate SSPI context
> I did try to research this before posting here, but I couldn't find
> anything that described this problem. Everything was referring to PCs
> connecting from a different domain. That is not the case here.
> Thanks,
> Matthew
>|||I am the domain admin, so that won't be a problem. As soon as some of the
current activity dies down, I will try this. Thanks!
"Kevin3NF" <Kevin@.DontNeedNoSpam3NF-inc.com> wrote in message
news:OxBRke33GHA.1288@.TK2MSFTNGP03.phx.gbl...
> Cannot Generate SSPI context is almost always related to there not being a
> Service Principal Name defined for that server, account and port in a
> Kerberos environment.
> Domain accounts do not create an SPN, whereas Domain Admins and Local
> System do.
> Test this by making (temporarily) your startup account a domain admin and
> the resetting in in SQL Enterprise Manager. restart and test
> connectivity.
> If it connects, have your domain admin (must be a domain admin) create an
> SPN for the MSSQLSvc in Active Directory.
> See the Books Online article "Security Account Delegation" for formot of
> what the resulting SPN should look like.
> Also, make sure the SQL Server is listening on TCP...make that your first
> step.
> --
> Kevin Hill
> 3NF Consulting
> www.3nf-inc.com/NewsGroups.htm
>
>
> "Matthew Kitchin (Usenet/Lists)" <mkitchin.public@.gmail.com> wrote in
> message news:%231cmKJ33GHA.1300@.TK2MSFTNGP05.phx.gbl...
>> I'm running SQL 2000 SP4 on 2003 server. I'm trying to setup email
>> alerts. I configured the sql service and sql agent service to run as a
>> domain account. I made that account a member of the administrators group
>> on the SQL server, and restarted the services. Everything looked fine.
>> The problem is, some of my remote applications cannot connect when it is
>> running as a domain account, but they are fine when it is running as a
>> local system account. On a remote Microsoft WSUS server, it breaks when
>> the SQL services on the SQL server use a domain account. Osql on the
>> remote box generates this:
>> Cannot generate SSPI context
>> I did try to research this before posting here, but I couldn't find
>> anything that described this problem. Everything was referring to PCs
>> connecting from a different domain. That is not the case here.
>> Thanks,
>> Matthew
>|||Thanks! Adding the SPN took care of it. I thought I was there, but now I'm
having problems configuring the alerts. Outlook 2003 SP2 is installed. I
logged in with he SQL service account, and setup the MAPI profile. That
worked fine. When I set up an operator logged in as the service account,
clicking Test email generates this error:
http://img167.imageshack.us/my.php?image=sqlerroran3.png
If I log in as my self, it acts like it went through when I click test, but
no email is generated.
Any ideas?
Thanks again for your help.
-Matthew
"Kevin3NF" <Kevin@.DontNeedNoSpam3NF-inc.com> wrote in message
news:OxBRke33GHA.1288@.TK2MSFTNGP03.phx.gbl...
> Cannot Generate SSPI context is almost always related to there not being a
> Service Principal Name defined for that server, account and port in a
> Kerberos environment.
> Domain accounts do not create an SPN, whereas Domain Admins and Local
> System do.
> Test this by making (temporarily) your startup account a domain admin and
> the resetting in in SQL Enterprise Manager. restart and test
> connectivity.
> If it connects, have your domain admin (must be a domain admin) create an
> SPN for the MSSQLSvc in Active Directory.
> See the Books Online article "Security Account Delegation" for formot of
> what the resulting SPN should look like.
> Also, make sure the SQL Server is listening on TCP...make that your first
> step.
> --
> Kevin Hill
> 3NF Consulting
> www.3nf-inc.com/NewsGroups.htm
>
>
> "Matthew Kitchin (Usenet/Lists)" <mkitchin.public@.gmail.com> wrote in
> message news:%231cmKJ33GHA.1300@.TK2MSFTNGP05.phx.gbl...
>> I'm running SQL 2000 SP4 on 2003 server. I'm trying to setup email
>> alerts. I configured the sql service and sql agent service to run as a
>> domain account. I made that account a member of the administrators group
>> on the SQL server, and restarted the services. Everything looked fine.
>> The problem is, some of my remote applications cannot connect when it is
>> running as a domain account, but they are fine when it is running as a
>> local system account. On a remote Microsoft WSUS server, it breaks when
>> the SQL services on the SQL server use a domain account. Osql on the
>> remote box generates this:
>> Cannot generate SSPI context
>> I did try to research this before posting here, but I couldn't find
>> anything that described this problem. Everything was referring to PCs
>> connecting from a different domain. That is not the case here.
>> Thanks,
>> Matthew
>|||All I can tell you is that SQL mail is profiel specific...could be a
permissions issue on the profile itself?
That's not my area :-)
--
Kevin Hill
3NF Consulting
www.3nf-inc.com/NewsGroups.htm
"Matthew Kitchin (Usenet/Lists)" <mkitchin.public@.gmail.com> wrote in
message news:eMiLlw33GHA.5000@.TK2MSFTNGP02.phx.gbl...
> Thanks! Adding the SPN took care of it. I thought I was there, but now I'm
> having problems configuring the alerts. Outlook 2003 SP2 is installed. I
> logged in with he SQL service account, and setup the MAPI profile. That
> worked fine. When I set up an operator logged in as the service account,
> clicking Test email generates this error:
> http://img167.imageshack.us/my.php?image=sqlerroran3.png
> If I log in as my self, it acts like it went through when I click test,
> but no email is generated.
> Any ideas?
> Thanks again for your help.
> -Matthew
> "Kevin3NF" <Kevin@.DontNeedNoSpam3NF-inc.com> wrote in message
> news:OxBRke33GHA.1288@.TK2MSFTNGP03.phx.gbl...
>> Cannot Generate SSPI context is almost always related to there not being
>> a Service Principal Name defined for that server, account and port in a
>> Kerberos environment.
>> Domain accounts do not create an SPN, whereas Domain Admins and Local
>> System do.
>> Test this by making (temporarily) your startup account a domain admin and
>> the resetting in in SQL Enterprise Manager. restart and test
>> connectivity.
>> If it connects, have your domain admin (must be a domain admin) create an
>> SPN for the MSSQLSvc in Active Directory.
>> See the Books Online article "Security Account Delegation" for formot of
>> what the resulting SPN should look like.
>> Also, make sure the SQL Server is listening on TCP...make that your first
>> step.
>> --
>> Kevin Hill
>> 3NF Consulting
>> www.3nf-inc.com/NewsGroups.htm
>>
>>
>> "Matthew Kitchin (Usenet/Lists)" <mkitchin.public@.gmail.com> wrote in
>> message news:%231cmKJ33GHA.1300@.TK2MSFTNGP05.phx.gbl...
>> I'm running SQL 2000 SP4 on 2003 server. I'm trying to setup email
>> alerts. I configured the sql service and sql agent service to run as a
>> domain account. I made that account a member of the administrators group
>> on the SQL server, and restarted the services. Everything looked fine.
>> The problem is, some of my remote applications cannot connect when it is
>> running as a domain account, but they are fine when it is running as a
>> local system account. On a remote Microsoft WSUS server, it breaks when
>> the SQL services on the SQL server use a domain account. Osql on the
>> remote box generates this:
>> Cannot generate SSPI context
>> I did try to research this before posting here, but I couldn't find
>> anything that described this problem. Everything was referring to PCs
>> connecting from a different domain. That is not the case here.
>> Thanks,
>> Matthew
>>
>|||This thing is baffling. I read a couple posts that just the 'Test' button
has issues. I scheduled some maintenance to run at 4 AM last night. It ran,
sent me the results, and the log indicated the job failed because the last
step, the email, failed.
The job failed. The Job was invoked by Schedule 4 (Schedule 1). The last
step to run was step 1 (Step 1). NOTE: Failed to notify 'SQL Alerts' via
email.
"Kevin3NF" <Kevin@.DontNeedNoSpam3NF-inc.com> wrote in message
news:uFBi8n43GHA.4924@.TK2MSFTNGP05.phx.gbl...
> All I can tell you is that SQL mail is profiel specific...could be a
> permissions issue on the profile itself?
> That's not my area :-)
> --
> Kevin Hill
> 3NF Consulting
> www.3nf-inc.com/NewsGroups.htm
>
>
> "Matthew Kitchin (Usenet/Lists)" <mkitchin.public@.gmail.com> wrote in
> message news:eMiLlw33GHA.5000@.TK2MSFTNGP02.phx.gbl...
>> Thanks! Adding the SPN took care of it. I thought I was there, but now
>> I'm having problems configuring the alerts. Outlook 2003 SP2 is
>> installed. I logged in with he SQL service account, and setup the MAPI
>> profile. That worked fine. When I set up an operator logged in as the
>> service account, clicking Test email generates this error:
>> http://img167.imageshack.us/my.php?image=sqlerroran3.png
>> If I log in as my self, it acts like it went through when I click test,
>> but no email is generated.
>> Any ideas?
>> Thanks again for your help.
>> -Matthew
>> "Kevin3NF" <Kevin@.DontNeedNoSpam3NF-inc.com> wrote in message
>> news:OxBRke33GHA.1288@.TK2MSFTNGP03.phx.gbl...
>> Cannot Generate SSPI context is almost always related to there not being
>> a Service Principal Name defined for that server, account and port in a
>> Kerberos environment.
>> Domain accounts do not create an SPN, whereas Domain Admins and Local
>> System do.
>> Test this by making (temporarily) your startup account a domain admin
>> and the resetting in in SQL Enterprise Manager. restart and test
>> connectivity.
>> If it connects, have your domain admin (must be a domain admin) create
>> an SPN for the MSSQLSvc in Active Directory.
>> See the Books Online article "Security Account Delegation" for formot of
>> what the resulting SPN should look like.
>> Also, make sure the SQL Server is listening on TCP...make that your
>> first step.
>> --
>> Kevin Hill
>> 3NF Consulting
>> www.3nf-inc.com/NewsGroups.htm
>>
>>
>> "Matthew Kitchin (Usenet/Lists)" <mkitchin.public@.gmail.com> wrote in
>> message news:%231cmKJ33GHA.1300@.TK2MSFTNGP05.phx.gbl...
>> I'm running SQL 2000 SP4 on 2003 server. I'm trying to setup email
>> alerts. I configured the sql service and sql agent service to run as a
>> domain account. I made that account a member of the administrators
>> group on the SQL server, and restarted the services. Everything looked
>> fine. The problem is, some of my remote applications cannot connect
>> when it is running as a domain account, but they are fine when it is
>> running as a local system account. On a remote Microsoft WSUS server,
>> it breaks when the SQL services on the SQL server use a domain account.
>> Osql on the remote box generates this:
>> Cannot generate SSPI context
>> I did try to research this before posting here, but I couldn't find
>> anything that described this problem. Everything was referring to PCs
>> connecting from a different domain. That is not the case here.
>> Thanks,
>> Matthew
>>
>>
>
Can't connect from Server A to B but B to A
I have two machines with SQL2000 on both machines.
Machine A is a member of the domain, Machine B is in a workgroup with
the same name as the domain.
Using Enterprise manager I can connect from Machine B and manage the
SQL server on machine A.
When trying to connect from Machine A to manage SQL server on Machine
B I get an error 'SQL Server does not exist or access denied'.
I have double checked username/password several times.
Client Network Utility are set to TCP/IP and Named Pipes on both
machines.
Ping works fines. I can also access shared folders from A to B and
vice versa.
What else could be the problem?Can you connect via SQL Login.
If you're connecting via Windows Login, be sure the account has the same
name and password on both side. Also, check to see if BUILTIN\<account> is
allowed access on serverB. If not, take a look at 'sp_grantlogin' in book
online and give it access.
-oj
"Tosch" <tosch_nospam@.swissonline.ch> wrote in message
news:9hbl51pm68gln1gmqp2ckpk5h1d7a5q7r4@.
4ax.com...
>I have two machines with SQL2000 on both machines.
> Machine A is a member of the domain, Machine B is in a workgroup with
> the same name as the domain.
> Using Enterprise manager I can connect from Machine B and manage the
> SQL server on machine A.
> When trying to connect from Machine A to manage SQL server on Machine
> B I get an error 'SQL Server does not exist or access denied'.
> I have double checked username/password several times.
> Client Network Utility are set to TCP/IP and Named Pipes on both
> machines.
> Ping works fines. I can also access shared folders from A to B and
> vice versa.
> What else could be the problem?
>|||I have tried connecting with SQL Login, no luck. I even tried sa and I
could not connect.
On Mon, 11 Apr 2005 13:54:05 -0700, "oj" <nospam_ojngo@.home.com>
wrote:
>Can you connect via SQL Login.
>If you're connecting via Windows Login, be sure the account has the same
>name and password on both side. Also, check to see if BUILTIN\<account> is
>allowed access on serverB. If not, take a look at 'sp_grantlogin' in book
>online and give it access.|||Hi
What happens if you try to do a telnet to server B using the port specified
in server B's TCP/IP Clinet configuration? By doing this, you can determine
if server B listen's properly on the correct port.
Regards
Steen
Tosch wrote:[vbcol=seagreen]
> I have tried connecting with SQL Login, no luck. I even tried sa and I
> could not connect.
>
> On Mon, 11 Apr 2005 13:54:05 -0700, "oj" <nospam_ojngo@.home.com>
> wrote:
>
Machine A is a member of the domain, Machine B is in a workgroup with
the same name as the domain.
Using Enterprise manager I can connect from Machine B and manage the
SQL server on machine A.
When trying to connect from Machine A to manage SQL server on Machine
B I get an error 'SQL Server does not exist or access denied'.
I have double checked username/password several times.
Client Network Utility are set to TCP/IP and Named Pipes on both
machines.
Ping works fines. I can also access shared folders from A to B and
vice versa.
What else could be the problem?Can you connect via SQL Login.
If you're connecting via Windows Login, be sure the account has the same
name and password on both side. Also, check to see if BUILTIN\<account> is
allowed access on serverB. If not, take a look at 'sp_grantlogin' in book
online and give it access.
-oj
"Tosch" <tosch_nospam@.swissonline.ch> wrote in message
news:9hbl51pm68gln1gmqp2ckpk5h1d7a5q7r4@.
4ax.com...
>I have two machines with SQL2000 on both machines.
> Machine A is a member of the domain, Machine B is in a workgroup with
> the same name as the domain.
> Using Enterprise manager I can connect from Machine B and manage the
> SQL server on machine A.
> When trying to connect from Machine A to manage SQL server on Machine
> B I get an error 'SQL Server does not exist or access denied'.
> I have double checked username/password several times.
> Client Network Utility are set to TCP/IP and Named Pipes on both
> machines.
> Ping works fines. I can also access shared folders from A to B and
> vice versa.
> What else could be the problem?
>|||I have tried connecting with SQL Login, no luck. I even tried sa and I
could not connect.
On Mon, 11 Apr 2005 13:54:05 -0700, "oj" <nospam_ojngo@.home.com>
wrote:
>Can you connect via SQL Login.
>If you're connecting via Windows Login, be sure the account has the same
>name and password on both side. Also, check to see if BUILTIN\<account> is
>allowed access on serverB. If not, take a look at 'sp_grantlogin' in book
>online and give it access.|||Hi
What happens if you try to do a telnet to server B using the port specified
in server B's TCP/IP Clinet configuration? By doing this, you can determine
if server B listen's properly on the correct port.
Regards
Steen
Tosch wrote:[vbcol=seagreen]
> I have tried connecting with SQL Login, no luck. I even tried sa and I
> could not connect.
>
> On Mon, 11 Apr 2005 13:54:05 -0700, "oj" <nospam_ojngo@.home.com>
> wrote:
>
Can't connect from Server A to B but B to A
I have two machines with SQL2000 on both machines.
Machine A is a member of the domain, Machine B is in a workgroup with
the same name as the domain.
Using Enterprise manager I can connect from Machine B and manage the
SQL server on machine A.
When trying to connect from Machine A to manage SQL server on Machine
B I get an error 'SQL Server does not exist or access denied'.
I have double checked username/password several times.
Client Network Utility are set to TCP/IP and Named Pipes on both
machines.
Ping works fines. I can also access shared folders from A to B and
vice versa.
What else could be the problem?
Can you connect via SQL Login.
If you're connecting via Windows Login, be sure the account has the same
name and password on both side. Also, check to see if BUILTIN\<account> is
allowed access on serverB. If not, take a look at 'sp_grantlogin' in book
online and give it access.
-oj
"Tosch" <tosch_nospam@.swissonline.ch> wrote in message
news:9hbl51pm68gln1gmqp2ckpk5h1d7a5q7r4@.4ax.com...
>I have two machines with SQL2000 on both machines.
> Machine A is a member of the domain, Machine B is in a workgroup with
> the same name as the domain.
> Using Enterprise manager I can connect from Machine B and manage the
> SQL server on machine A.
> When trying to connect from Machine A to manage SQL server on Machine
> B I get an error 'SQL Server does not exist or access denied'.
> I have double checked username/password several times.
> Client Network Utility are set to TCP/IP and Named Pipes on both
> machines.
> Ping works fines. I can also access shared folders from A to B and
> vice versa.
> What else could be the problem?
>
|||I have tried connecting with SQL Login, no luck. I even tried sa and I
could not connect.
On Mon, 11 Apr 2005 13:54:05 -0700, "oj" <nospam_ojngo@.home.com>
wrote:
>Can you connect via SQL Login.
>If you're connecting via Windows Login, be sure the account has the same
>name and password on both side. Also, check to see if BUILTIN\<account> is
>allowed access on serverB. If not, take a look at 'sp_grantlogin' in book
>online and give it access.
|||Hi
What happens if you try to do a telnet to server B using the port specified
in server B's TCP/IP Clinet configuration? By doing this, you can determine
if server B listen's properly on the correct port.
Regards
Steen
Tosch wrote:[vbcol=seagreen]
> I have tried connecting with SQL Login, no luck. I even tried sa and I
> could not connect.
>
> On Mon, 11 Apr 2005 13:54:05 -0700, "oj" <nospam_ojngo@.home.com>
> wrote:
Machine A is a member of the domain, Machine B is in a workgroup with
the same name as the domain.
Using Enterprise manager I can connect from Machine B and manage the
SQL server on machine A.
When trying to connect from Machine A to manage SQL server on Machine
B I get an error 'SQL Server does not exist or access denied'.
I have double checked username/password several times.
Client Network Utility are set to TCP/IP and Named Pipes on both
machines.
Ping works fines. I can also access shared folders from A to B and
vice versa.
What else could be the problem?
Can you connect via SQL Login.
If you're connecting via Windows Login, be sure the account has the same
name and password on both side. Also, check to see if BUILTIN\<account> is
allowed access on serverB. If not, take a look at 'sp_grantlogin' in book
online and give it access.
-oj
"Tosch" <tosch_nospam@.swissonline.ch> wrote in message
news:9hbl51pm68gln1gmqp2ckpk5h1d7a5q7r4@.4ax.com...
>I have two machines with SQL2000 on both machines.
> Machine A is a member of the domain, Machine B is in a workgroup with
> the same name as the domain.
> Using Enterprise manager I can connect from Machine B and manage the
> SQL server on machine A.
> When trying to connect from Machine A to manage SQL server on Machine
> B I get an error 'SQL Server does not exist or access denied'.
> I have double checked username/password several times.
> Client Network Utility are set to TCP/IP and Named Pipes on both
> machines.
> Ping works fines. I can also access shared folders from A to B and
> vice versa.
> What else could be the problem?
>
|||I have tried connecting with SQL Login, no luck. I even tried sa and I
could not connect.
On Mon, 11 Apr 2005 13:54:05 -0700, "oj" <nospam_ojngo@.home.com>
wrote:
>Can you connect via SQL Login.
>If you're connecting via Windows Login, be sure the account has the same
>name and password on both side. Also, check to see if BUILTIN\<account> is
>allowed access on serverB. If not, take a look at 'sp_grantlogin' in book
>online and give it access.
|||Hi
What happens if you try to do a telnet to server B using the port specified
in server B's TCP/IP Clinet configuration? By doing this, you can determine
if server B listen's properly on the correct port.
Regards
Steen
Tosch wrote:[vbcol=seagreen]
> I have tried connecting with SQL Login, no luck. I even tried sa and I
> could not connect.
>
> On Mon, 11 Apr 2005 13:54:05 -0700, "oj" <nospam_ojngo@.home.com>
> wrote:
Can't connect from Server A to B but B to A
I have two machines with SQL2000 on both machines.
Machine A is a member of the domain, Machine B is in a workgroup with
the same name as the domain.
Using Enterprise manager I can connect from Machine B and manage the
SQL server on machine A.
When trying to connect from Machine A to manage SQL server on Machine
B I get an error 'SQL Server does not exist or access denied'.
I have double checked username/password several times.
Client Network Utility are set to TCP/IP and Named Pipes on both
machines.
Ping works fines. I can also access shared folders from A to B and
vice versa.
What else could be the problem?Can you connect via SQL Login.
If you're connecting via Windows Login, be sure the account has the same
name and password on both side. Also, check to see if BUILTIN\<account> is
allowed access on serverB. If not, take a look at 'sp_grantlogin' in book
online and give it access.
--
-oj
"Tosch" <tosch_nospam@.swissonline.ch> wrote in message
news:9hbl51pm68gln1gmqp2ckpk5h1d7a5q7r4@.4ax.com...
>I have two machines with SQL2000 on both machines.
> Machine A is a member of the domain, Machine B is in a workgroup with
> the same name as the domain.
> Using Enterprise manager I can connect from Machine B and manage the
> SQL server on machine A.
> When trying to connect from Machine A to manage SQL server on Machine
> B I get an error 'SQL Server does not exist or access denied'.
> I have double checked username/password several times.
> Client Network Utility are set to TCP/IP and Named Pipes on both
> machines.
> Ping works fines. I can also access shared folders from A to B and
> vice versa.
> What else could be the problem?
>|||I have tried connecting with SQL Login, no luck. I even tried sa and I
could not connect.
On Mon, 11 Apr 2005 13:54:05 -0700, "oj" <nospam_ojngo@.home.com>
wrote:
>Can you connect via SQL Login.
>If you're connecting via Windows Login, be sure the account has the same
>name and password on both side. Also, check to see if BUILTIN\<account> is
>allowed access on serverB. If not, take a look at 'sp_grantlogin' in book
>online and give it access.|||Hi
What happens if you try to do a telnet to server B using the port specified
in server B's TCP/IP Clinet configuration? By doing this, you can determine
if server B listen's properly on the correct port.
Regards
Steen
Tosch wrote:
> I have tried connecting with SQL Login, no luck. I even tried sa and I
> could not connect.
>
> On Mon, 11 Apr 2005 13:54:05 -0700, "oj" <nospam_ojngo@.home.com>
> wrote:
>> Can you connect via SQL Login.
>> If you're connecting via Windows Login, be sure the account has the
>> same name and password on both side. Also, check to see if
>> BUILTIN\<account> is allowed access on serverB. If not, take a look
>> at 'sp_grantlogin' in book online and give it access.
Machine A is a member of the domain, Machine B is in a workgroup with
the same name as the domain.
Using Enterprise manager I can connect from Machine B and manage the
SQL server on machine A.
When trying to connect from Machine A to manage SQL server on Machine
B I get an error 'SQL Server does not exist or access denied'.
I have double checked username/password several times.
Client Network Utility are set to TCP/IP and Named Pipes on both
machines.
Ping works fines. I can also access shared folders from A to B and
vice versa.
What else could be the problem?Can you connect via SQL Login.
If you're connecting via Windows Login, be sure the account has the same
name and password on both side. Also, check to see if BUILTIN\<account> is
allowed access on serverB. If not, take a look at 'sp_grantlogin' in book
online and give it access.
--
-oj
"Tosch" <tosch_nospam@.swissonline.ch> wrote in message
news:9hbl51pm68gln1gmqp2ckpk5h1d7a5q7r4@.4ax.com...
>I have two machines with SQL2000 on both machines.
> Machine A is a member of the domain, Machine B is in a workgroup with
> the same name as the domain.
> Using Enterprise manager I can connect from Machine B and manage the
> SQL server on machine A.
> When trying to connect from Machine A to manage SQL server on Machine
> B I get an error 'SQL Server does not exist or access denied'.
> I have double checked username/password several times.
> Client Network Utility are set to TCP/IP and Named Pipes on both
> machines.
> Ping works fines. I can also access shared folders from A to B and
> vice versa.
> What else could be the problem?
>|||I have tried connecting with SQL Login, no luck. I even tried sa and I
could not connect.
On Mon, 11 Apr 2005 13:54:05 -0700, "oj" <nospam_ojngo@.home.com>
wrote:
>Can you connect via SQL Login.
>If you're connecting via Windows Login, be sure the account has the same
>name and password on both side. Also, check to see if BUILTIN\<account> is
>allowed access on serverB. If not, take a look at 'sp_grantlogin' in book
>online and give it access.|||Hi
What happens if you try to do a telnet to server B using the port specified
in server B's TCP/IP Clinet configuration? By doing this, you can determine
if server B listen's properly on the correct port.
Regards
Steen
Tosch wrote:
> I have tried connecting with SQL Login, no luck. I even tried sa and I
> could not connect.
>
> On Mon, 11 Apr 2005 13:54:05 -0700, "oj" <nospam_ojngo@.home.com>
> wrote:
>> Can you connect via SQL Login.
>> If you're connecting via Windows Login, be sure the account has the
>> same name and password on both side. Also, check to see if
>> BUILTIN\<account> is allowed access on serverB. If not, take a look
>> at 'sp_grantlogin' in book online and give it access.
Subscribe to:
Posts (Atom)