Showing posts with label version. Show all posts
Showing posts with label version. Show all posts

Friday, February 24, 2012

client-requested SSL encryption errors

I did not get any useful response the last time I posted this, so now I'm
posting a more detailed version of the question.
We are having difficulty getting client-requested SSL encryption to work
with SQL Server 2000 Enterprise SP4.
Using "Force All Clients to Use SSL" is not an option for us. We need to be
able to have certain clients (extranet)use encryption without forcing other
clients (intranet) to also use encryption. Hence, we need to know how to
make "Force Protocol Encryption" work from the Client Network Utility with
SQL Query Analyzer.
Ultimately, our goal is to enable encryption in certain connection requests
from custom client applications we are writing. However, we will be happy
for now if we can at least get it working from a standard MS tool as
described in the SQL Server documentation and KB articles.
Has anyone else managed to make client-requested encryption work without
using a commercial CA? For that matter, has anyone suceeded in making it
work *with* a commercial CA?
When I connect using SQL Query Analyzer without Force Protocol Encryption in
the Client Network Utility, everything works fine. When I select Force
Protocol Encryption, then I get the following error:
====
unable to connect to server
server: msg 18, level 16, state 1
[microsoft][ODBC SQL Server Driver][DBNETLIB]SSL Security error
====
The server is running Windows Server 2003 Enterprise SP1. As mentioned
earlier, MSSQLSERVER version is SQL Server 2000 Enterprise SP4.
The Server Authentication certificate is installed correctly on the SQL
Server 2000 machine. It was generated by Microsoft Certificate Services
configured as a stand-alone root CA. The certificate chain is OK according
to MMC snap-in and works fine with no warnings for HTTPS connections to IIS,
so I don't see how the certificate could be malformed. There definitely is
only one certificate installed on the server (at least according to the MMC
snap-in for Certificates). The Root CA chain is installed on the client and
is OK according to MMC. This seems to be validated by the fact that IE
doesn't give any warnings when making an HTTPS connection to the server
(i.e., it recognizes the certificate chain as a trusted source).
I've read every KB article I can find on the subject, followed all the
instructions with meticulous care, and reinstalled everything from scratch
twice already (including the CA, thus generating a new root certificate and
new server authentication certificate). The client still fails to connect
whenever I force client encryption (it's not feasible for us to set force
encryption on the server).
I've even tried creating various aliases for the server in the Client
Network Utility, as suggested in one KB article, but that doesn't seem to
help either.
Perhaps I'm overlooking something really obvious, but I'm seriously
beginning to doubt whether SQL Server really supports client-initiated SSL
connections at all. Has anyone else gotten this to work? If so, what was the
trick to making it work?
Any suggestions would be greatly appreciated.
Hello Aubrey,
I don't think you need a commercial certfiicate to do this.
If you want to enable Force Protocol Encryption on the client, you must
have a certificate on the server and the client must have the Trusted Root
Authority updated to trust the server certificate. You can install your own
CA and get certficate from it on the server, and install root CA
certificate on the client.
You may have reviewed the following articles but the steps to enable SSL
from client are verified to work properly.
316898 How to enable SSL encryption for SQL Server 2000 with Microsoft
http://support.microsoft.com/?id=316898
316779 PRB: Clients with Force Protocol Encryption Set On May Fail to
Connect
http://support.microsoft.com/?id=316779
276553 How to enable SSL encryption for SQL Server 2000 with Certificate
Server
http://support.microsoft.com/?id=276553
Also, to make sure the certificate installed on the SQL server is correct,
we suggest that you enable "Force Protocol Encryption" temporarily and
disable "Force Protocol Encryption" on client to test the situation. If it
works under this situation, the server certificate itself has no issues.
Note: EVEN IF YOU ARE ENABLING FORCE PROTOCOL ENCRYPTION ON THE CLIENT SIDE
ONLY, YOU STILL NEED TO RESTART SQL SERVER FOR THE CERTIFICATE TO BECOME
EFFECTIVE AND USED BY SQL SERVER.
If "Force Protocol Encryption" on server does not work, please check the
certificate property to make sure it is for FQDN for the SQL server.
839617 BUG: You cannot connect to an instance of SQL Server on a server
http://support.microsoft.com/?id=839617
You may want to check if the issue occurs on different client computers to
isolate the issue.
Best Regards,
Peter Yang
MCSE2000/2003, MCSA, MCDBA
Microsoft Online Partner Support
When responding to posts, please "Reply to Group" via your newsreader so
that others may learn and benefit from your issue.
================================================== ===
This posting is provided "AS IS" with no warranties, and confers no rights.
| From: "Aubrey McAuley" <winaix@.nospam.nospam>
| Subject: client-requested SSL encryption errors
| Date: Wed, 27 Jul 2005 16:10:49 -0500
| Lines: 65
| X-Priority: 3
| X-MSMail-Priority: Normal
| X-Newsreader: Microsoft Outlook Express 6.00.2900.2527
| X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2527
| X-RFC2646: Format=Flowed; Original
| Message-ID: <#Gi#t#ukFHA.2852@.TK2MSFTNGP15.phx.gbl>
| Newsgroups: microsoft.public.sqlserver.server
| NNTP-Posting-Host: rrcs-67-79-5-147.sw.biz.rr.com 67.79.5.147
| Path: TK2MSFTNGXA01.phx.gbl!TK2MSFTNGP08.phx.gbl!TK2MSFT NGP15.phx.gbl
| Xref: TK2MSFTNGXA01.phx.gbl microsoft.public.sqlserver.server:64999
| X-Tomcat-NG: microsoft.public.sqlserver.server
|
| I did not get any useful response the last time I posted this, so now I'm
| posting a more detailed version of the question.
|
| We are having difficulty getting client-requested SSL encryption to work
| with SQL Server 2000 Enterprise SP4.
|
| Using "Force All Clients to Use SSL" is not an option for us. We need to
be
| able to have certain clients (extranet)use encryption without forcing
other
| clients (intranet) to also use encryption. Hence, we need to know how to
| make "Force Protocol Encryption" work from the Client Network Utility
with
| SQL Query Analyzer.
|
| Ultimately, our goal is to enable encryption in certain connection
requests
| from custom client applications we are writing. However, we will be happy
| for now if we can at least get it working from a standard MS tool as
| described in the SQL Server documentation and KB articles.
|
| Has anyone else managed to make client-requested encryption work without
| using a commercial CA? For that matter, has anyone suceeded in making it
| work *with* a commercial CA?
|
| When I connect using SQL Query Analyzer without Force Protocol Encryption
in
| the Client Network Utility, everything works fine. When I select Force
| Protocol Encryption, then I get the following error:
|
| ====
| unable to connect to server
| server: msg 18, level 16, state 1
| [microsoft][ODBC SQL Server Driver][DBNETLIB]SSL Security error
|
| ====
|
| The server is running Windows Server 2003 Enterprise SP1. As mentioned
| earlier, MSSQLSERVER version is SQL Server 2000 Enterprise SP4.
|
| The Server Authentication certificate is installed correctly on the SQL
| Server 2000 machine. It was generated by Microsoft Certificate Services
| configured as a stand-alone root CA. The certificate chain is OK
according
| to MMC snap-in and works fine with no warnings for HTTPS connections to
IIS,
| so I don't see how the certificate could be malformed. There definitely
is
| only one certificate installed on the server (at least according to the
MMC
| snap-in for Certificates). The Root CA chain is installed on the client
and
| is OK according to MMC. This seems to be validated by the fact that IE
| doesn't give any warnings when making an HTTPS connection to the server
| (i.e., it recognizes the certificate chain as a trusted source).
|
| I've read every KB article I can find on the subject, followed all the
| instructions with meticulous care, and reinstalled everything from
scratch
| twice already (including the CA, thus generating a new root certificate
and
| new server authentication certificate). The client still fails to connect
| whenever I force client encryption (it's not feasible for us to set force
| encryption on the server).
|
| I've even tried creating various aliases for the server in the Client
| Network Utility, as suggested in one KB article, but that doesn't seem to
| help either.
|
| Perhaps I'm overlooking something really obvious, but I'm seriously
| beginning to doubt whether SQL Server really supports client-initiated
SSL
| connections at all. Has anyone else gotten this to work? If so, what was
the
| trick to making it work?
|
| Any suggestions would be greatly appreciated.
|
|
|

client-requested SSL encryption errors

I did not get any useful response the last time I posted this, so now I'm
posting a more detailed version of the question.
We are having difficulty getting client-requested SSL encryption to work
with SQL Server 2000 Enterprise SP4.
Using "Force All Clients to Use SSL" is not an option for us. We need to be
able to have certain clients (extranet)use encryption without forcing other
clients (intranet) to also use encryption. Hence, we need to know how to
make "Force Protocol Encryption" work from the Client Network Utility with
SQL Query Analyzer.
Ultimately, our goal is to enable encryption in certain connection requests
from custom client applications we are writing. However, we will be happy
for now if we can at least get it working from a standard MS tool as
described in the SQL Server documentation and KB articles.
Has anyone else managed to make client-requested encryption work without
using a commercial CA? For that matter, has anyone suceeded in making it
work *with* a commercial CA?
When I connect using SQL Query Analyzer without Force Protocol Encryption in
the Client Network Utility, everything works fine. When I select Force
Protocol Encryption, then I get the following error:
==== unable to connect to server
server: msg 18, level 16, state 1
[microsoft][ODBC SQL Server Driver][DBNETLIB]SSL Security error
====
The server is running Windows Server 2003 Enterprise SP1. As mentioned
earlier, MSSQLSERVER version is SQL Server 2000 Enterprise SP4.
The Server Authentication certificate is installed correctly on the SQL
Server 2000 machine. It was generated by Microsoft Certificate Services
configured as a stand-alone root CA. The certificate chain is OK according
to MMC snap-in and works fine with no warnings for HTTPS connections to IIS,
so I don't see how the certificate could be malformed. There definitely is
only one certificate installed on the server (at least according to the MMC
snap-in for Certificates). The Root CA chain is installed on the client and
is OK according to MMC. This seems to be validated by the fact that IE
doesn't give any warnings when making an HTTPS connection to the server
(i.e., it recognizes the certificate chain as a trusted source).
I've read every KB article I can find on the subject, followed all the
instructions with meticulous care, and reinstalled everything from scratch
twice already (including the CA, thus generating a new root certificate and
new server authentication certificate). The client still fails to connect
whenever I force client encryption (it's not feasible for us to set force
encryption on the server).
I've even tried creating various aliases for the server in the Client
Network Utility, as suggested in one KB article, but that doesn't seem to
help either.
Perhaps I'm overlooking something really obvious, but I'm seriously
beginning to doubt whether SQL Server really supports client-initiated SSL
connections at all. Has anyone else gotten this to work? If so, what was the
trick to making it work?
Any suggestions would be greatly appreciated.Hello Aubrey,
I don't think you need a commercial certfiicate to do this.
If you want to enable Force Protocol Encryption on the client, you must
have a certificate on the server and the client must have the Trusted Root
Authority updated to trust the server certificate. You can install your own
CA and get certficate from it on the server, and install root CA
certificate on the client.
You may have reviewed the following articles but the steps to enable SSL
from client are verified to work properly.
316898 How to enable SSL encryption for SQL Server 2000 with Microsoft
http://support.microsoft.com/?id=316898
316779 PRB: Clients with Force Protocol Encryption Set On May Fail to
Connect
http://support.microsoft.com/?id=316779
276553 How to enable SSL encryption for SQL Server 2000 with Certificate
Server
http://support.microsoft.com/?id=276553
Also, to make sure the certificate installed on the SQL server is correct,
we suggest that you enable "Force Protocol Encryption" temporarily and
disable "Force Protocol Encryption" on client to test the situation. If it
works under this situation, the server certificate itself has no issues.
Note: EVEN IF YOU ARE ENABLING FORCE PROTOCOL ENCRYPTION ON THE CLIENT SIDE
ONLY, YOU STILL NEED TO RESTART SQL SERVER FOR THE CERTIFICATE TO BECOME
EFFECTIVE AND USED BY SQL SERVER.
If "Force Protocol Encryption" on server does not work, please check the
certificate property to make sure it is for FQDN for the SQL server.
839617 BUG: You cannot connect to an instance of SQL Server on a server
http://support.microsoft.com/?id=839617
You may want to check if the issue occurs on different client computers to
isolate the issue.
Best Regards,
Peter Yang
MCSE2000/2003, MCSA, MCDBA
Microsoft Online Partner Support
When responding to posts, please "Reply to Group" via your newsreader so
that others may learn and benefit from your issue.
=====================================================
This posting is provided "AS IS" with no warranties, and confers no rights.
| From: "Aubrey McAuley" <winaix@.nospam.nospam>
| Subject: client-requested SSL encryption errors
| Date: Wed, 27 Jul 2005 16:10:49 -0500
| Lines: 65
| X-Priority: 3
| X-MSMail-Priority: Normal
| X-Newsreader: Microsoft Outlook Express 6.00.2900.2527
| X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2527
| X-RFC2646: Format=Flowed; Original
| Message-ID: <#Gi#t#ukFHA.2852@.TK2MSFTNGP15.phx.gbl>
| Newsgroups: microsoft.public.sqlserver.server
| NNTP-Posting-Host: rrcs-67-79-5-147.sw.biz.rr.com 67.79.5.147
| Path: TK2MSFTNGXA01.phx.gbl!TK2MSFTNGP08.phx.gbl!TK2MSFTNGP15.phx.gbl
| Xref: TK2MSFTNGXA01.phx.gbl microsoft.public.sqlserver.server:64999
| X-Tomcat-NG: microsoft.public.sqlserver.server
|
| I did not get any useful response the last time I posted this, so now I'm
| posting a more detailed version of the question.
|
| We are having difficulty getting client-requested SSL encryption to work
| with SQL Server 2000 Enterprise SP4.
|
| Using "Force All Clients to Use SSL" is not an option for us. We need to
be
| able to have certain clients (extranet)use encryption without forcing
other
| clients (intranet) to also use encryption. Hence, we need to know how to
| make "Force Protocol Encryption" work from the Client Network Utility
with
| SQL Query Analyzer.
|
| Ultimately, our goal is to enable encryption in certain connection
requests
| from custom client applications we are writing. However, we will be happy
| for now if we can at least get it working from a standard MS tool as
| described in the SQL Server documentation and KB articles.
|
| Has anyone else managed to make client-requested encryption work without
| using a commercial CA? For that matter, has anyone suceeded in making it
| work *with* a commercial CA?
|
| When I connect using SQL Query Analyzer without Force Protocol Encryption
in
| the Client Network Utility, everything works fine. When I select Force
| Protocol Encryption, then I get the following error:
|
| ====| unable to connect to server
| server: msg 18, level 16, state 1
| [microsoft][ODBC SQL Server Driver][DBNETLIB]SSL Security error
|
| ====|
| The server is running Windows Server 2003 Enterprise SP1. As mentioned
| earlier, MSSQLSERVER version is SQL Server 2000 Enterprise SP4.
|
| The Server Authentication certificate is installed correctly on the SQL
| Server 2000 machine. It was generated by Microsoft Certificate Services
| configured as a stand-alone root CA. The certificate chain is OK
according
| to MMC snap-in and works fine with no warnings for HTTPS connections to
IIS,
| so I don't see how the certificate could be malformed. There definitely
is
| only one certificate installed on the server (at least according to the
MMC
| snap-in for Certificates). The Root CA chain is installed on the client
and
| is OK according to MMC. This seems to be validated by the fact that IE
| doesn't give any warnings when making an HTTPS connection to the server
| (i.e., it recognizes the certificate chain as a trusted source).
|
| I've read every KB article I can find on the subject, followed all the
| instructions with meticulous care, and reinstalled everything from
scratch
| twice already (including the CA, thus generating a new root certificate
and
| new server authentication certificate). The client still fails to connect
| whenever I force client encryption (it's not feasible for us to set force
| encryption on the server).
|
| I've even tried creating various aliases for the server in the Client
| Network Utility, as suggested in one KB article, but that doesn't seem to
| help either.
|
| Perhaps I'm overlooking something really obvious, but I'm seriously
| beginning to doubt whether SQL Server really supports client-initiated
SSL
| connections at all. Has anyone else gotten this to work? If so, what was
the
| trick to making it work?
|
| Any suggestions would be greatly appreciated.
|
|
|

client-requested SSL encryption errors

I did not get any useful response the last time I posted this, so now I'm
posting a more detailed version of the question.
We are having difficulty getting client-requested SSL encryption to work
with SQL Server 2000 Enterprise SP4.
Using "Force All Clients to Use SSL" is not an option for us. We need to be
able to have certain clients (extranet)use encryption without forcing other
clients (intranet) to also use encryption. Hence, we need to know how to
make "Force Protocol Encryption" work from the Client Network Utility with
SQL Query Analyzer.
Ultimately, our goal is to enable encryption in certain connection requests
from custom client applications we are writing. However, we will be happy
for now if we can at least get it working from a standard MS tool as
described in the SQL Server documentation and KB articles.
Has anyone else managed to make client-requested encryption work without
using a commercial CA? For that matter, has anyone suceeded in making it
work *with* a commercial CA?
When I connect using SQL Query Analyzer without Force Protocol Encryption in
the Client Network Utility, everything works fine. When I select Force
Protocol Encryption, then I get the following error:
====
unable to connect to server
server: msg 18, level 16, state 1
[microsoft][ODBC SQL Server Driver][DBNETLIB]SSL Security error
====
The server is running Windows Server 2003 Enterprise SP1. As mentioned
earlier, MSSQLSERVER version is SQL Server 2000 Enterprise SP4.
The Server Authentication certificate is installed correctly on the SQL
Server 2000 machine. It was generated by Microsoft Certificate Services
configured as a stand-alone root CA. The certificate chain is OK according
to MMC snap-in and works fine with no warnings for HTTPS connections to IIS,
so I don't see how the certificate could be malformed. There definitely is
only one certificate installed on the server (at least according to the MMC
snap-in for Certificates). The Root CA chain is installed on the client and
is OK according to MMC. This seems to be validated by the fact that IE
doesn't give any warnings when making an HTTPS connection to the server
(i.e., it recognizes the certificate chain as a trusted source).
I've read every KB article I can find on the subject, followed all the
instructions with meticulous care, and reinstalled everything from scratch
twice already (including the CA, thus generating a new root certificate and
new server authentication certificate). The client still fails to connect
whenever I force client encryption (it's not feasible for us to set force
encryption on the server).
I've even tried creating various aliases for the server in the Client
Network Utility, as suggested in one KB article, but that doesn't seem to
help either.
Perhaps I'm overlooking something really obvious, but I'm seriously
beginning to doubt whether SQL Server really supports client-initiated SSL
connections at all. Has anyone else gotten this to work? If so, what was the
trick to making it work?
Any suggestions would be greatly appreciated.Hello Aubrey,
I don't think you need a commercial certfiicate to do this.
If you want to enable Force Protocol Encryption on the client, you must
have a certificate on the server and the client must have the Trusted Root
Authority updated to trust the server certificate. You can install your own
CA and get certficate from it on the server, and install root CA
certificate on the client.
You may have reviewed the following articles but the steps to enable SSL
from client are verified to work properly.
316898 How to enable SSL encryption for SQL Server 2000 with Microsoft
http://support.microsoft.com/?id=316898
316779 PRB: Clients with Force Protocol Encryption Set On May Fail to
Connect
http://support.microsoft.com/?id=316779
276553 How to enable SSL encryption for SQL Server 2000 with Certificate
Server
http://support.microsoft.com/?id=276553
Also, to make sure the certificate installed on the SQL server is correct,
we suggest that you enable "Force Protocol Encryption" temporarily and
disable "Force Protocol Encryption" on client to test the situation. If it
works under this situation, the server certificate itself has no issues.
Note: EVEN IF YOU ARE ENABLING FORCE PROTOCOL ENCRYPTION ON THE CLIENT SIDE
ONLY, YOU STILL NEED TO RESTART SQL SERVER FOR THE CERTIFICATE TO BECOME
EFFECTIVE AND USED BY SQL SERVER.
If "Force Protocol Encryption" on server does not work, please check the
certificate property to make sure it is for FQDN for the SQL server.
839617 BUG: You cannot connect to an instance of SQL Server on a server
http://support.microsoft.com/?id=839617
You may want to check if the issue occurs on different client computers to
isolate the issue.
Best Regards,
Peter Yang
MCSE2000/2003, MCSA, MCDBA
Microsoft Online Partner Support
When responding to posts, please "Reply to Group" via your newsreader so
that others may learn and benefit from your issue.
========================================
=============
This posting is provided "AS IS" with no warranties, and confers no rights.
| From: "Aubrey McAuley" <winaix@.nospam.nospam>
| Subject: client-requested SSL encryption errors
| Date: Wed, 27 Jul 2005 16:10:49 -0500
| Lines: 65
| X-Priority: 3
| X-MSMail-Priority: Normal
| X-Newsreader: Microsoft Outlook Express 6.00.2900.2527
| X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2527
| X-RFC2646: Format=Flowed; Original
| Message-ID: <#Gi#t#ukFHA.2852@.TK2MSFTNGP15.phx.gbl>
| Newsgroups: microsoft.public.sqlserver.server
| NNTP-Posting-Host: rrcs-67-79-5-147.sw.biz.rr.com 67.79.5.147
| Path: TK2MSFTNGXA01.phx.gbl!TK2MSFTNGP08.phx.gbl!TK2MSFTNGP15.phx.gbl
| Xref: TK2MSFTNGXA01.phx.gbl microsoft.public.sqlserver.server:64999
| X-Tomcat-NG: microsoft.public.sqlserver.server
|
| I did not get any useful response the last time I posted this, so now I'm
| posting a more detailed version of the question.
|
| We are having difficulty getting client-requested SSL encryption to work
| with SQL Server 2000 Enterprise SP4.
|
| Using "Force All Clients to Use SSL" is not an option for us. We need to
be
| able to have certain clients (extranet)use encryption without forcing
other
| clients (intranet) to also use encryption. Hence, we need to know how to
| make "Force Protocol Encryption" work from the Client Network Utility
with
| SQL Query Analyzer.
|
| Ultimately, our goal is to enable encryption in certain connection
requests
| from custom client applications we are writing. However, we will be happy
| for now if we can at least get it working from a standard MS tool as
| described in the SQL Server documentation and KB articles.
|
| Has anyone else managed to make client-requested encryption work without
| using a commercial CA? For that matter, has anyone suceeded in making it
| work *with* a commercial CA?
|
| When I connect using SQL Query Analyzer without Force Protocol Encryption
in
| the Client Network Utility, everything works fine. When I select Force
| Protocol Encryption, then I get the following error:
|
| ====
| unable to connect to server
| server: msg 18, level 16, state 1
| [microsoft][ODBC SQL Server Driver][DBNETLIB]SSL Security erro
r
|
| ====
|
| The server is running Windows Server 2003 Enterprise SP1. As mentioned
| earlier, MSSQLSERVER version is SQL Server 2000 Enterprise SP4.
|
| The Server Authentication certificate is installed correctly on the SQL
| Server 2000 machine. It was generated by Microsoft Certificate Services
| configured as a stand-alone root CA. The certificate chain is OK
according
| to MMC snap-in and works fine with no warnings for HTTPS connections to
IIS,
| so I don't see how the certificate could be malformed. There definitely
is
| only one certificate installed on the server (at least according to the
MMC
| snap-in for Certificates). The Root CA chain is installed on the client
and
| is OK according to MMC. This seems to be validated by the fact that IE
| doesn't give any warnings when making an HTTPS connection to the server
| (i.e., it recognizes the certificate chain as a trusted source).
|
| I've read every KB article I can find on the subject, followed all the
| instructions with meticulous care, and reinstalled everything from
scratch
| twice already (including the CA, thus generating a new root certificate
and
| new server authentication certificate). The client still fails to connect
| whenever I force client encryption (it's not feasible for us to set force
| encryption on the server).
|
| I've even tried creating various aliases for the server in the Client
| Network Utility, as suggested in one KB article, but that doesn't seem to
| help either.
|
| Perhaps I'm overlooking something really obvious, but I'm seriously
| beginning to doubt whether SQL Server really supports client-initiated
SSL
| connections at all. Has anyone else gotten this to work? If so, what was
the
| trick to making it work?
|
| Any suggestions would be greatly appreciated.
|
|
|

Client tools licensing question

Hello,
If we have a full version of SQL2K and want to install MSDE on about 30
mobile laptops can we install the client utilities from the SQL2K cd onto
each laptop? If not is there any other options? What would be the cost per
laptop to install the client software? Thanks.
Jake
Hi Jake,
No, you can't. We have a utility that's free for personal use and licensing
for things like you describe. Details are at our site. For other options,
look at: www.microsoft.com/sql/msde/partners/default.asp
HTH,
Greg Low [MVP]
MSDE Manager SQL Tools
www.whitebearconsulting.com
"Jake" <rondican@.hotmail.com> wrote in message
news:O5In$G%23rEHA.3848@.TK2MSFTNGP14.phx.gbl...
> Hello,
> If we have a full version of SQL2K and want to install MSDE on about 30
> mobile laptops can we install the client utilities from the SQL2K cd onto
> each laptop? If not is there any other options? What would be the cost per
> laptop to install the client software? Thanks.
> Jake
>
|||Greg,
Is there one that would be good for setting up and managing replication.
We are planning on using merge replication.
Jake
"Greg Low [MVP]" <greglow@.lowell.com.au> wrote in message
news:eKmUUt%23rEHA.2948@.TK2MSFTNGP11.phx.gbl...
> Hi Jake,
> No, you can't. We have a utility that's free for personal use and
> licensing for things like you describe. Details are at our site. For other
> options, look at: www.microsoft.com/sql/msde/partners/default.asp
> HTH,
> --
> Greg Low [MVP]
> MSDE Manager SQL Tools
> www.whitebearconsulting.com
> "Jake" <rondican@.hotmail.com> wrote in message
> news:O5In$G%23rEHA.3848@.TK2MSFTNGP14.phx.gbl...
>
|||Hi Jake,
That's on the way in our next version but it's not here yet. I've tried many
of the others but haven't come across one yet that does.
Regards,
Greg Low [MVP]
MSDE Manager SQL Tools
www.whitebearconsulting.com
"Jake" <rondican@.hotmail.com> wrote in message
news:OepQcx%23rEHA.868@.TK2MSFTNGP10.phx.gbl...
> Greg,
> Is there one that would be good for setting up and managing
> replication. We are planning on using merge replication.
> Jake
>
> "Greg Low [MVP]" <greglow@.lowell.com.au> wrote in message
> news:eKmUUt%23rEHA.2948@.TK2MSFTNGP11.phx.gbl...
>
|||Greg,
Any idea on a release date? Will it work with SQLExpress?
Jake
"Greg Low [MVP]" <greglow@.lowell.com.au> wrote in message
news:u%234Y7IEsEHA.376@.TK2MSFTNGP14.phx.gbl...
> Hi Jake,
> That's on the way in our next version but it's not here yet. I've tried
> many of the others but haven't come across one yet that does.
> Regards,
> --
> Greg Low [MVP]
> MSDE Manager SQL Tools
> www.whitebearconsulting.com
> "Jake" <rondican@.hotmail.com> wrote in message
> news:OepQcx%23rEHA.868@.TK2MSFTNGP10.phx.gbl...
>
|||Hi Jake,
Still about 6 weeks. Separate product coming for SQL Express. It's a little
more challenging because SQL Agent isn't included.
HTH,
Greg Low [MVP]
MSDE Manager SQL Tools
www.whitebearconsulting.com
"Jake" <rondican@.hotmail.com> wrote in message
news:ORLaiyFsEHA.2136@.TK2MSFTNGP14.phx.gbl...
> Greg,
> Any idea on a release date? Will it work with SQLExpress?
> Jake
> "Greg Low [MVP]" <greglow@.lowell.com.au> wrote in message
> news:u%234Y7IEsEHA.376@.TK2MSFTNGP14.phx.gbl...
>
|||Pop me an email offline with what you need it to do so I can make sure it's
getting covered.
Regards,
Greg Low [MVP]
MSDE Manager SQL Tools
www.whitebearconsulting.com
"Jake" <rondican@.hotmail.com> wrote in message
news:ORLaiyFsEHA.2136@.TK2MSFTNGP14.phx.gbl...
> Greg,
> Any idea on a release date? Will it work with SQLExpress?
> Jake
> "Greg Low [MVP]" <greglow@.lowell.com.au> wrote in message
> news:u%234Y7IEsEHA.376@.TK2MSFTNGP14.phx.gbl...
>
|||"Jake" <rondican@.hotmail.com> wrote in message news:O5In$G%
| If we have a full version of SQL2K and want to install MSDE on about 30
| mobile laptops can we install the client utilities from the SQL2K cd onto
| each laptop? If not is there any other options? What would be the cost per
| laptop to install the client software? Thanks.
|
For 30 servers, wouldn't you want to script it anyway? Seems odd to want to
install a GUI for such a task. I don't like using EM to make changes on even 1
production box.
Also, if you are going to use EM, I would want either the same person or 'team'
of dba's doing the configs. What you can do is put the msde box on the LAN and
connect to it from the dba's copy of EM that is probably installed on their
desktop.
Carl Karsten
|||if you go to the MS site and search for SQL 2000 eval version, it states
that the enterprise t tools can be used indefinitely. confirmed with MS.
Use the EVAL version to intstall just the Enterprise Mgr. everything works
properly with MSDE2000 except the scheduled backups.
steve
"Jake" <rondican@.hotmail.com> wrote in message
news:O5In$G%23rEHA.3848@.TK2MSFTNGP14.phx.gbl...
> Hello,
> If we have a full version of SQL2K and want to install MSDE on about
30
> mobile laptops can we install the client utilities from the SQL2K cd onto
> each laptop? If not is there any other options? What would be the cost per
> laptop to install the client software? Thanks.
> Jake
>
|||hi Steve,
"bozo" <bozo@.bozosplace.com> ha scritto nel messaggio
news:10nc2v5ff2iambe@.corp.supernews.com
> if you go to the MS site and search for SQL 2000 eval version, it
> states that the enterprise t tools can be used indefinitely.
> confirmed with MS. Use the EVAL version to intstall just the
> Enterprise Mgr. everything works properly with MSDE2000 except the
> scheduled backups.
I'm really not certain you are allowed to use the Eval tools on production
servers, or, anyway, after the evaluation time is finished...
they do work after the evaluation expires, but I'm confident you are not
allowed at all to use them...
Andrea Montanari (Microsoft MVP - SQL Server)
http://www.asql.biz/DbaMgr.shtmhttp://italy.mvps.org
DbaMgr2k ver 0.9.1 - DbaMgr ver 0.55.1
(my vb6+sql-dmo little try to provide MS MSDE 1.0 and MSDE 2000 a visual
interface)
-- remove DMO to reply

Tuesday, February 14, 2012

Client Licensing

We are just about to upgrade our trial version of SQL 2005 to SQL 2005 std.
I underatand I need a license for the server and each client.
My query is I have 3 users which can also work from home as and when
required, will they be covered under the licences we use in the office or do
i need to purchase 3 more, these users will be using different machines at
home
thanksHello Leonard!
SQL Server is available under three licensing options:
â?¢ Per Processor Licensing Model. A Processor license is required for each
physical or virtual processor that is accessed by an operating system
environment running SQL Server. This license does not require any device or
user client access licenses (CALs).
â?¢ Server plus Device CALs Licensing Model. A Server license is required for
each operating system environment running an instance of SQL Server, as well
as a CAL for each client device that accesses a system running SQL Server.
â?¢ Server plus User CALs Licensing Model. A Server license is required for
each operating system environment running an instance of SQL Server, as well
as a CAL for each user who accesses a system running SQL Server.
So, If you buy User CALs for those 3 users then you do not need to buy extra
licenses for them.
However, I encourage you to contact to a local authorized license vendor to
get the most correct answer about this stuff.
You may have more info about licensing from the following link:
http://www.microsoft.com/sql/howtobuy/default.mspx
Ekrem Ã?nsoy
"Leonard" <Leonard@.discussions.microsoft.com> wrote in message
news:01B44CCE-9F73-4880-B9CC-697C463DBBB0@.microsoft.com...
> We are just about to upgrade our trial version of SQL 2005 to SQL 2005
> std.
> I underatand I need a license for the server and each client.
> My query is I have 3 users which can also work from home as and when
> required, will they be covered under the licences we use in the office or
> do
> i need to purchase 3 more, these users will be using different machines at
> home
> thanks

Client installation of sql server

Hi,
I have both client and server of 2000 version sql server installed on my xp
machine. However, I need to install 2005 sql server client software on the
same machine. After I install this, I cannot see the program. Do I have to
unstall 2000 client software to work on 2005 client software. I would
appreciate any help on this matter.
Thanks in advanceThanks for your help Sailesh. I appreciate it.
"Shailesh Khanal" wrote:
> No, you can use both clients side by side. Check the log file in setup
> bootstarp folder to see if the installation was successful.
> "Jack" wrote:
> > Hi,
> > I have both client and server of 2000 version sql server installed on my xp
> > machine. However, I need to install 2005 sql server client software on the
> > same machine. After I install this, I cannot see the program. Do I have to
> > unstall 2000 client software to work on 2005 client software. I would
> > appreciate any help on this matter.
> > Thanks in advance|||> I have both client and server of 2000 version sql server installed on my xp
> machine. However, I need to install 2005 sql server client software on the
> same machine. After I install this, I cannot see the program.
What "program" is it that you don't see? SQL Server management studio? If so, perhaps you didn't
select to install the workstation components when you installed 2005?
--
Tibor Karaszi, SQL Server MVP
http://www.karaszi.com/sqlserver/default.asp
http://sqlblog.com/blogs/tibor_karaszi
"Jack" <Jack@.discussions.microsoft.com> wrote in message
news:5A0F5715-35F7-437B-8E5B-3C920DB09FA1@.microsoft.com...
> Hi,
> I have both client and server of 2000 version sql server installed on my xp
> machine. However, I need to install 2005 sql server client software on the
> same machine. After I install this, I cannot see the program. Do I have to
> unstall 2000 client software to work on 2005 client software. I would
> appreciate any help on this matter.
> Thanks in advance|||No, you can use both clients side by side. Check the log file in setup
bootstarp folder to see if the installation was successful.
"Jack" wrote:
> Hi,
> I have both client and server of 2000 version sql server installed on my xp
> machine. However, I need to install 2005 sql server client software on the
> same machine. After I install this, I cannot see the program. Do I have to
> unstall 2000 client software to work on 2005 client software. I would
> appreciate any help on this matter.
> Thanks in advance

Friday, February 10, 2012

Clearer version of my earlier question re sp_grantlogin and sp_grantdbaccess

I have amended this post from the one I posted a few hours ago - to make it
clearer (and friendlier!).
I have developed an app for my customer and it assigns different privilege
levels to users based on which domain network group they belong to.
However the only way I have found to be able to grant them access to the sql
server and
database is to connect with a trusted connection having logged in as Domain
Admin. Is that correct?
(I have to go to another site in order to be allowed to do this which is
somewhat inconvenient).
What I would like to able to do but cannot is log into MSDE as sa and run
the following:
use AppDB
exec sp_grantlogin 'TheirDomain\AppManagers'
exec sp_grantdbaccess 'TheirDomain\AppManagers'
exec sp_grantlogin 'TheirDomain\AppReadWrite'
exec sp_grantdbaccess 'TheirDomain\AppReadWrite'
etc.
Can someone let me know if I could achieve the above with a trusted
connection to MSDE as
something less than Domain Admin? If so what network rights would I need?
Many thanks in advance, for your time and expertise!
Clive Elsworth (London UK)
www.EndorphinSoftware.co.uk
Outgoing mail is certified Virus Free.
Checked by AVG anti-virus system (http://www.grisoft.com).
Version: 6.0.631 / Virus Database: 404 - Release Date: 17/03/2004
First question is whether the SQL Server install is a default install or if you can add some login first.
If it is a default install, the only logins which exists are the Windows Administrators group and "sa" (which
requires mixed mode - not recommended). However, in order to install SQL Server, you need to be Administrator
anyhow, so why not just run the script which creates the users after install? Am I missing something?
Tibor Karaszi, SQL Server MVP
http://www.karaszi.com/sqlserver/default.asp
"Clive Elsworth" <clive@.takethisbitout.elsworth.dircon.co.uk> wrote in message
news:OrihgJpEEHA.3864@.TK2MSFTNGP12.phx.gbl...
> I have amended this post from the one I posted a few hours ago - to make it
> clearer (and friendlier!).
> I have developed an app for my customer and it assigns different privilege
> levels to users based on which domain network group they belong to.
> However the only way I have found to be able to grant them access to the sql
> server and
> database is to connect with a trusted connection having logged in as Domain
> Admin. Is that correct?
> (I have to go to another site in order to be allowed to do this which is
> somewhat inconvenient).
> What I would like to able to do but cannot is log into MSDE as sa and run
> the following:
> use AppDB
> exec sp_grantlogin 'TheirDomain\AppManagers'
> exec sp_grantdbaccess 'TheirDomain\AppManagers'
> exec sp_grantlogin 'TheirDomain\AppReadWrite'
> exec sp_grantdbaccess 'TheirDomain\AppReadWrite'
> etc.
> Can someone let me know if I could achieve the above with a trusted
> connection to MSDE as
> something less than Domain Admin? If so what network rights would I need?
> Many thanks in advance, for your time and expertise!
> Clive Elsworth (London UK)
>
> --
> www.EndorphinSoftware.co.uk
>
> --
> Outgoing mail is certified Virus Free.
> Checked by AVG anti-virus system (http://www.grisoft.com).
> Version: 6.0.631 / Virus Database: 404 - Release Date: 17/03/2004
>
|||Tibor
Hello again - you and I were in contact about 4 years ago or so - I don't
think I've been to Sweden since then unfortunately. It may have been my SQL
Beautifier that we were discussing then, which after giving away a fair bit
I have not developed since. In any case you were a great help with a trick
to restart SQL Agent when SQL Server restarts (using sp_procoption) which I
have since given away to countless students in classes I have taught.
Anyhow..
I did the install about a month ago as Domain Admin (default install - mixed
mode - not recommended I know, but I really need it) and ran the
sp_grantlogin and sp_grantdbaccess fine, because I was then at the 'Admin'
site where they let me login as Domain Admin. Since then, they wanted a
minor enhancement which meant altering a number of Tables, SPs and Views.
What I usually like to do in this situation is:
1. - Backup the customer's DB and restore it to my laptop
2. - Transfer the customer's data to the newly enhanced DB on my laptop,
which I have tested with the app back in my office
3. - Transfer and Restore that DB to the customer server PC
4. - Grant rights to network groups to the DB now on the customer server PC
In the end I had to do it the other way which was to:
1. - Backup the customer's DB and restore it to my laptop
2. - Apply all the changes to their DB and hope I hadn't missed anything.
3. - Restore it back to their server - the domain groups still existed as DB
users and so no further action was necessary.
Maybe I'll just have to invest in one of those utilities that tells you all
the differences between two DBs - so I can be sure I never miss anything -
but I'd rather not if possible.
It doesn't seem right that sa - that should have total control over a SQL
Server, doesn't have the right to grant DB access to Domain Groups. What do
you think?
Best Regards
Clive
"Tibor Karaszi" <tibor_please.no.email_karaszi@.hotmail.nomail.com> wrote in
message news:exVYrQpEEHA.1032@.TK2MSFTNGP09.phx.gbl...
> First question is whether the SQL Server install is a default install or
if you can add some login first.
> If it is a default install, the only logins which exists are the Windows
Administrators group and "sa" (which
> requires mixed mode - not recommended). However, in order to install SQL
Server, you need to be Administrator
> anyhow, so why not just run the script which creates the users after
install? Am I missing something?
> --
> Tibor Karaszi, SQL Server MVP
> http://www.karaszi.com/sqlserver/default.asp
>
> "Clive Elsworth" <clive@.takethisbitout.elsworth.dircon.co.uk> wrote in
message
> news:OrihgJpEEHA.3864@.TK2MSFTNGP12.phx.gbl...
it
privilege
sql
Domain
run
need?
>
Outgoing mail is certified Virus Free.
Checked by AVG anti-virus system (http://www.grisoft.com).
Version: 6.0.631 / Virus Database: 404 - Release Date: 18/03/2004
|||> Hello again - you and I were in contact about 4 years ago or so <snip>
Ahh, yes. Thanks for reminding me, Clive. :-)

> Maybe I'll just have to invest in one of those utilities that tells you all
> the differences between two DBs - so I can be sure I never miss anything -
> but I'd rather not if possible.
I take it that you have already determined that it is too labor intensive to continuously add onto a script
file while you do changes, so the script file in the end contains the necessary ALTER TABLE commands etc? This
is perfectly doable, but only you can determine whether you consider this hinders your development too much to
be worth it.

> It doesn't seem right that sa - that should have total control over a SQL
> Server, doesn't have the right to grant DB access to Domain Groups. What do
> you think?
Seems I missed this in the beginning of the thread. I thought that your problem is that you don't are
connected as sysadmin. I realize now that you are connected as sa. I didn't know that an SQL Server login as
sa doesn't give you the ability to add Windows Logins from a domain as database users to a database, and if
you read the documentation for sp_grantdbaccess, it only say that you need to be sysadmin (etc). If this is
what you are seeing, then you might want to post a bug report (or rather open a case which might end up in a
bug report being filed).
Tibor Karaszi, SQL Server MVP
http://www.karaszi.com/sqlserver/default.asp
"Clive Elsworth" <clive@.takethisbitout.elsworth.dircon.co.uk> wrote in message
news:%23Zd5q5vEEHA.1376@.TK2MSFTNGP10.phx.gbl...
> Tibor
> Hello again - you and I were in contact about 4 years ago or so - I don't
> think I've been to Sweden since then unfortunately. It may have been my SQL
> Beautifier that we were discussing then, which after giving away a fair bit
> I have not developed since. In any case you were a great help with a trick
> to restart SQL Agent when SQL Server restarts (using sp_procoption) which I
> have since given away to countless students in classes I have taught.
> Anyhow..
> I did the install about a month ago as Domain Admin (default install - mixed
> mode - not recommended I know, but I really need it) and ran the
> sp_grantlogin and sp_grantdbaccess fine, because I was then at the 'Admin'
> site where they let me login as Domain Admin. Since then, they wanted a
> minor enhancement which meant altering a number of Tables, SPs and Views.
> What I usually like to do in this situation is:
> 1. - Backup the customer's DB and restore it to my laptop
> 2. - Transfer the customer's data to the newly enhanced DB on my laptop,
> which I have tested with the app back in my office
> 3. - Transfer and Restore that DB to the customer server PC
> 4. - Grant rights to network groups to the DB now on the customer server PC
> In the end I had to do it the other way which was to:
> 1. - Backup the customer's DB and restore it to my laptop
> 2. - Apply all the changes to their DB and hope I hadn't missed anything.
> 3. - Restore it back to their server - the domain groups still existed as DB
> users and so no further action was necessary.
> Maybe I'll just have to invest in one of those utilities that tells you all
> the differences between two DBs - so I can be sure I never miss anything -
> but I'd rather not if possible.
> It doesn't seem right that sa - that should have total control over a SQL
> Server, doesn't have the right to grant DB access to Domain Groups. What do
> you think?
> Best Regards
> Clive
>
> "Tibor Karaszi" <tibor_please.no.email_karaszi@.hotmail.nomail.com> wrote in
> message news:exVYrQpEEHA.1032@.TK2MSFTNGP09.phx.gbl...
> if you can add some login first.
> Administrators group and "sa" (which
> Server, you need to be Administrator
> install? Am I missing something?
> message
> it
> privilege
> sql
> Domain
> run
> need?
>
> --
> Outgoing mail is certified Virus Free.
> Checked by AVG anti-virus system (http://www.grisoft.com).
> Version: 6.0.631 / Virus Database: 404 - Release Date: 18/03/2004
>
|||Tibor
Please see my reply to Greg Low about the sp_grantlogin problem. It's
basically still unresolved - I have more tests to do.

> I take it that you have already determined that it is too labor intensive
to continuously add onto a script
> file while you do changes, so the script file in the end contains the
necessary ALTER TABLE commands etc? This
> is perfectly doable, but only you can determine whether you consider this
hinders your development too much to
> be worth it.
Up to now I have got away without needing to do that because I've been
transferring the client's data into my own 'upgraded and fully tested' db,
before restoring it to their computers.
I was shocked the other day to learn that that was no longer going to be
possible in all cases, although luckily in that case I had kept a note of
all the changes I had made - and so made them all again manually to their
version of the db (briefly restored onto my laptop), which had security all
set up, and so could be restored back to their network without the need for
any additional sp_grantlogins.
Thanks for your help. Hope business is good for you.
Regards
Clive
"Tibor Karaszi" <tibor_please.no.email_karaszi@.hotmail.nomail.com> wrote in
message news:eFRGgzZFEHA.2408@.TK2MSFTNGP10.phx.gbl...
> Ahh, yes. Thanks for reminding me, Clive. :-)
>
all
anything -
> I take it that you have already determined that it is too labor intensive
to continuously add onto a script
> file while you do changes, so the script file in the end contains the
necessary ALTER TABLE commands etc? This
> is perfectly doable, but only you can determine whether you consider this
hinders your development too much to
> be worth it.
>
SQL
What do
> Seems I missed this in the beginning of the thread. I thought that your
problem is that you don't are
> connected as sysadmin. I realize now that you are connected as sa. I
didn't know that an SQL Server login as
> sa doesn't give you the ability to add Windows Logins from a domain as
database users to a database, and if
> you read the documentation for sp_grantdbaccess, it only say that you need
to be sysadmin (etc). If this is
> what you are seeing, then you might want to post a bug report (or rather
open a case which might end up in a
> bug report being filed).
> --
> Tibor Karaszi, SQL Server MVP
> http://www.karaszi.com/sqlserver/default.asp
>
> "Clive Elsworth" <clive@.takethisbitout.elsworth.dircon.co.uk> wrote in
message
> news:%23Zd5q5vEEHA.1376@.TK2MSFTNGP10.phx.gbl...
don't
SQL
bit
trick
which I
mixed
'Admin'
Views.
PC
anything.
as DB
all
anything -
SQL
What do
in
or
Windows
SQL
make
the
which is
and
>
Outgoing mail is certified Virus Free.
Checked by AVG anti-virus system (http://www.grisoft.com).
Version: 6.0.648 / Virus Database: 415 - Release Date: 31/03/2004