What are the pros of having SQL Server instance added to Active Directory ?
I was looking at the server properties and saw the Active Directory tab and
had an option to add it.
What may be the cons ? Right now none of our SQL Servers are added. Do most
of you add the server to AD ? What am I missing by not doing so ? Thanks
Well, are you using AD for anything now? If not, it is unlikely that the
mere adding of SQL Server to AD will produce any tangible benefits.
What you get by adding SQL Server to AD are things like Service Publication,
which is just a fancy form of an alias or DNS, IMHO. For example, if SQL
Server is on myServer01, it can be published through AD, then you can move
the server and clients do not need to know that the server has moved...
Since, instead of using a hard-coded IP address or server name, you are
going through AD, and it is redirecting you based solely on the name of the
database you want to connect to. This means you will have to change your
applications (and expect to need this flexibility) before you will see this
benefit.
A few of the problems I see with the above approach:
(a) obviously with AD there are more security considerations, so it won't be
like SQL Server authentication anymore. Apps have to be rewritten and
protecting the directory might take a significant amount of work.
(b) in our environment we have several locations with the same database -
e.g. Dev, QA, Production. If I want to connect to the Sales database, I now
have to think about this differently. Instead of "just connect to the Sales
database on the QA server," I now have to give each one a distinct
publication name, such as QA-SalesDB. This isn't a difficult change, and in
fact in some lights it is better, but it is a change, and we know how some
people are resistant to even the smallest delta in mindset or approach.
(c) using SQL through ADSI versus directly through the OLEDB provider can
cause some problems with existing code (and habits that will lend to
continuing to write code this way). There is no longer the ability to use
SELECT * ... You must name your columns.
As in a previous thread, I strongly suggest you spend some time reading on
the subject. You'll be much better informed to make a decision than just
listening to opinions (which are not based at all on anything specific in
YOUR environment).
ADSI and using SQL Server through AD are documented in MSDN Online, as well
as several 3rd party web sites.
On 3/20/05 2:51 PM, in article #NqyHZYLFHA.732@.TK2MSFTNGP12.phx.gbl,
"Hassan" <fatima_ja@.hotmail.com> wrote:
> What are the pros of having SQL Server instance added to Active Directory ?
> I was looking at the server properties and saw the Active Directory tab and
> had an option to add it.
> What may be the cons ? Right now none of our SQL Servers are added. Do most
> of you add the server to AD ? What am I missing by not doing so ? Thanks
>
Showing posts with label active. Show all posts
Showing posts with label active. Show all posts
Friday, March 30, 2012
Pros of having SQL server added to AD
What are the pros of having SQL Server instance added to Active Directory ?
I was looking at the server properties and saw the Active Directory tab and
had an option to add it.
What may be the cons ? Right now none of our SQL Servers are added. Do most
of you add the server to AD ? What am I missing by not doing so ? ThanksWell, are you using AD for anything now? If not, it is unlikely that the
mere adding of SQL Server to AD will produce any tangible benefits.
What you get by adding SQL Server to AD are things like Service Publication,
which is just a fancy form of an alias or DNS, IMHO. For example, if SQL
Server is on myServer01, it can be published through AD, then you can move
the server and clients do not need to know that the server has moved...
Since, instead of using a hard-coded IP address or server name, you are
going through AD, and it is redirecting you based solely on the name of the
database you want to connect to. This means you will have to change your
applications (and expect to need this flexibility) before you will see this
benefit.
A few of the problems I see with the above approach:
(a) obviously with AD there are more security considerations, so it won't be
like SQL Server authentication anymore. Apps have to be rewritten and
protecting the directory might take a significant amount of work.
(b) in our environment we have several locations with the same database -
e.g. Dev, QA, Production. If I want to connect to the Sales database, I now
have to think about this differently. Instead of "just connect to the Sales
database on the QA server," I now have to give each one a distinct
publication name, such as QA-SalesDB. This isn't a difficult change, and in
fact in some lights it is better, but it is a change, and we know how some
people are resistant to even the smallest delta in mindset or approach.
(c) using SQL through ADSI versus directly through the OLEDB provider can
cause some problems with existing code (and habits that will lend to
continuing to write code this way). There is no longer the ability to use
SELECT * ... You must name your columns.
As in a previous thread, I strongly suggest you spend some time reading on
the subject. You'll be much better informed to make a decision than just
listening to opinions (which are not based at all on anything specific in
YOUR environment).
ADSI and using SQL Server through AD are documented in MSDN Online, as well
as several 3rd party web sites.
On 3/20/05 2:51 PM, in article #NqyHZYLFHA.732@.TK2MSFTNGP12.phx.gbl,
"Hassan" <fatima_ja@.hotmail.com> wrote:
> What are the pros of having SQL Server instance added to Active Directory ?
> I was looking at the server properties and saw the Active Directory tab and
> had an option to add it.
> What may be the cons ? Right now none of our SQL Servers are added. Do most
> of you add the server to AD ? What am I missing by not doing so ? Thanks
>sql
I was looking at the server properties and saw the Active Directory tab and
had an option to add it.
What may be the cons ? Right now none of our SQL Servers are added. Do most
of you add the server to AD ? What am I missing by not doing so ? ThanksWell, are you using AD for anything now? If not, it is unlikely that the
mere adding of SQL Server to AD will produce any tangible benefits.
What you get by adding SQL Server to AD are things like Service Publication,
which is just a fancy form of an alias or DNS, IMHO. For example, if SQL
Server is on myServer01, it can be published through AD, then you can move
the server and clients do not need to know that the server has moved...
Since, instead of using a hard-coded IP address or server name, you are
going through AD, and it is redirecting you based solely on the name of the
database you want to connect to. This means you will have to change your
applications (and expect to need this flexibility) before you will see this
benefit.
A few of the problems I see with the above approach:
(a) obviously with AD there are more security considerations, so it won't be
like SQL Server authentication anymore. Apps have to be rewritten and
protecting the directory might take a significant amount of work.
(b) in our environment we have several locations with the same database -
e.g. Dev, QA, Production. If I want to connect to the Sales database, I now
have to think about this differently. Instead of "just connect to the Sales
database on the QA server," I now have to give each one a distinct
publication name, such as QA-SalesDB. This isn't a difficult change, and in
fact in some lights it is better, but it is a change, and we know how some
people are resistant to even the smallest delta in mindset or approach.
(c) using SQL through ADSI versus directly through the OLEDB provider can
cause some problems with existing code (and habits that will lend to
continuing to write code this way). There is no longer the ability to use
SELECT * ... You must name your columns.
As in a previous thread, I strongly suggest you spend some time reading on
the subject. You'll be much better informed to make a decision than just
listening to opinions (which are not based at all on anything specific in
YOUR environment).
ADSI and using SQL Server through AD are documented in MSDN Online, as well
as several 3rd party web sites.
On 3/20/05 2:51 PM, in article #NqyHZYLFHA.732@.TK2MSFTNGP12.phx.gbl,
"Hassan" <fatima_ja@.hotmail.com> wrote:
> What are the pros of having SQL Server instance added to Active Directory ?
> I was looking at the server properties and saw the Active Directory tab and
> had an option to add it.
> What may be the cons ? Right now none of our SQL Servers are added. Do most
> of you add the server to AD ? What am I missing by not doing so ? Thanks
>sql
Pros of having SQL server added to AD
What are the pros of having SQL Server instance added to Active Directory ?
I was looking at the server properties and saw the Active Directory tab and
had an option to add it.
What may be the cons ? Right now none of our SQL Servers are added. Do most
of you add the server to AD ? What am I missing by not doing so ? ThanksWell, are you using AD for anything now? If not, it is unlikely that the
mere adding of SQL Server to AD will produce any tangible benefits.
What you get by adding SQL Server to AD are things like Service Publication,
which is just a fancy form of an alias or DNS, IMHO. For example, if SQL
Server is on myServer01, it can be published through AD, then you can move
the server and clients do not need to know that the server has moved...
Since, instead of using a hard-coded IP address or server name, you are
going through AD, and it is redirecting you based solely on the name of the
database you want to connect to. This means you will have to change your
applications (and expect to need this flexibility) before you will see this
benefit.
A few of the problems I see with the above approach:
(a) obviously with AD there are more security considerations, so it won't be
like SQL Server authentication anymore. Apps have to be rewritten and
protecting the directory might take a significant amount of work.
(b) in our environment we have several locations with the same database -
e.g. Dev, QA, Production. If I want to connect to the Sales database, I now
have to think about this differently. Instead of "just connect to the Sales
database on the QA server," I now have to give each one a distinct
publication name, such as QA-SalesDB. This isn't a difficult change, and in
fact in some lights it is better, but it is a change, and we know how some
people are resistant to even the smallest delta in mindset or approach.
(c) using SQL through ADSI versus directly through the OLEDB provider can
cause some problems with existing code (and habits that will lend to
continuing to write code this way). There is no longer the ability to use
SELECT * ... You must name your columns.
As in a previous thread, I strongly suggest you spend some time reading on
the subject. You'll be much better informed to make a decision than just
listening to opinions (which are not based at all on anything specific in
YOUR environment).
ADSI and using SQL Server through AD are documented in MSDN Online, as well
as several 3rd party web sites.
On 3/20/05 2:51 PM, in article #NqyHZYLFHA.732@.TK2MSFTNGP12.phx.gbl,
"Hassan" <fatima_ja@.hotmail.com> wrote:
> What are the pros of having SQL Server instance added to Active Directory
?
> I was looking at the server properties and saw the Active Directory tab an
d
> had an option to add it.
> What may be the cons ? Right now none of our SQL Servers are added. Do mos
t
> of you add the server to AD ? What am I missing by not doing so ? Thanks
>
I was looking at the server properties and saw the Active Directory tab and
had an option to add it.
What may be the cons ? Right now none of our SQL Servers are added. Do most
of you add the server to AD ? What am I missing by not doing so ? ThanksWell, are you using AD for anything now? If not, it is unlikely that the
mere adding of SQL Server to AD will produce any tangible benefits.
What you get by adding SQL Server to AD are things like Service Publication,
which is just a fancy form of an alias or DNS, IMHO. For example, if SQL
Server is on myServer01, it can be published through AD, then you can move
the server and clients do not need to know that the server has moved...
Since, instead of using a hard-coded IP address or server name, you are
going through AD, and it is redirecting you based solely on the name of the
database you want to connect to. This means you will have to change your
applications (and expect to need this flexibility) before you will see this
benefit.
A few of the problems I see with the above approach:
(a) obviously with AD there are more security considerations, so it won't be
like SQL Server authentication anymore. Apps have to be rewritten and
protecting the directory might take a significant amount of work.
(b) in our environment we have several locations with the same database -
e.g. Dev, QA, Production. If I want to connect to the Sales database, I now
have to think about this differently. Instead of "just connect to the Sales
database on the QA server," I now have to give each one a distinct
publication name, such as QA-SalesDB. This isn't a difficult change, and in
fact in some lights it is better, but it is a change, and we know how some
people are resistant to even the smallest delta in mindset or approach.
(c) using SQL through ADSI versus directly through the OLEDB provider can
cause some problems with existing code (and habits that will lend to
continuing to write code this way). There is no longer the ability to use
SELECT * ... You must name your columns.
As in a previous thread, I strongly suggest you spend some time reading on
the subject. You'll be much better informed to make a decision than just
listening to opinions (which are not based at all on anything specific in
YOUR environment).
ADSI and using SQL Server through AD are documented in MSDN Online, as well
as several 3rd party web sites.
On 3/20/05 2:51 PM, in article #NqyHZYLFHA.732@.TK2MSFTNGP12.phx.gbl,
"Hassan" <fatima_ja@.hotmail.com> wrote:
> What are the pros of having SQL Server instance added to Active Directory
?
> I was looking at the server properties and saw the Active Directory tab an
d
> had an option to add it.
> What may be the cons ? Right now none of our SQL Servers are added. Do mos
t
> of you add the server to AD ? What am I missing by not doing so ? Thanks
>
Monday, March 26, 2012
proper shutdown order for MSCS SQL cluster?
Hi,
We're having a SAN outage & I've noticed some **flakiness with regard to a
'clean' shutdown of our SQL 2000(active/active) & 2005(active/passive)
clusters.
**In the past when we've disconnected storage and had to cold boot all the
cluster nodes, we've had trouble starting the cluster back up. ( network
name not found in the cluster resource group and/or cluster services
wouldn't start)
Is there a recommended order to shut down & restart cluster resource groups
(including SQL+DTC) when system maintenanence need to occur?
Thanks,
Mike Bonvie
Shutdown:
Take the SQL resources offline and set the startup type to DISABLED on all
nodes
Stop the Cluster Service on all nodes and set the startup type to disabled.
Perform hardwarework as necessary.
Only boot one node at a time. If all nodes are down, us a staggered startup
sequence.
Enable and start cluster services on each node. Test moving the cluster
group.
Set SQL Service startup type to MANUAL.
Using the cluster admin tool, bring the diskm IP address, and network name
resources online. Test moving them across nodes.
Bring the SQL Services online using the cluster tool. Test moving groups.
Geoff N. Hiten
Senior Database Administrator
Microsoft SQL Server MVP
"Mike Bonvie" <m@.d.net> wrote in message
news:e7WcCzMYHHA.1388@.TK2MSFTNGP05.phx.gbl...
> Hi,
> We're having a SAN outage & I've noticed some **flakiness with regard to a
> 'clean' shutdown of our SQL 2000(active/active) & 2005(active/passive)
> clusters.
> **In the past when we've disconnected storage and had to cold boot all the
> cluster nodes, we've had trouble starting the cluster back up. ( network
> name not found in the cluster resource group and/or cluster services
> wouldn't start)
> Is there a recommended order to shut down & restart cluster resource
> groups (including SQL+DTC) when system maintenanence need to occur?
> Thanks,
> Mike Bonvie
|||Thank You Geoff,
Great information. Is this based on Microsoft documentation, or a combo of
experience/documentation?
If there's a KB or other resource, where can I get it?
Thanks again,
Mike Bonvie
"Geoff N. Hiten" <SQLCraftsman@.gmail.com> wrote in message
news:u$vRT9MYHHA.4440@.TK2MSFTNGP03.phx.gbl...
> Shutdown:
> Take the SQL resources offline and set the startup type to DISABLED on all
> nodes
> Stop the Cluster Service on all nodes and set the startup type to
> disabled.
> Perform hardwarework as necessary.
> Only boot one node at a time. If all nodes are down, us a staggered
> startup sequence.
> Enable and start cluster services on each node. Test moving the cluster
> group.
> Set SQL Service startup type to MANUAL.
> Using the cluster admin tool, bring the diskm IP address, and network name
> resources online. Test moving them across nodes.
> Bring the SQL Services online using the cluster tool. Test moving groups.
>
> --
> Geoff N. Hiten
> Senior Database Administrator
> Microsoft SQL Server MVP
>
>
> "Mike Bonvie" <m@.d.net> wrote in message
> news:e7WcCzMYHHA.1388@.TK2MSFTNGP05.phx.gbl...
>
|||This is a mix of best practices guidelines and experience. The staggered
startup is documented somewhere, but the other steps are stuff I have worked
out over the years. The DISABLED service ettings just makes sure the
resource won't attempt to come online accidentally.
Geoff N. Hiten
Senior Database Administrator
Microsoft SQL Server MVP
"Mike Bonvie" <m@.d.net> wrote in message
news:Oqu9AHNYHHA.4552@.TK2MSFTNGP05.phx.gbl...
> Thank You Geoff,
> Great information. Is this based on Microsoft documentation, or a combo of
> experience/documentation?
> If there's a KB or other resource, where can I get it?
> Thanks again,
> Mike Bonvie
>
> "Geoff N. Hiten" <SQLCraftsman@.gmail.com> wrote in message
> news:u$vRT9MYHHA.4440@.TK2MSFTNGP03.phx.gbl...
>
sql
We're having a SAN outage & I've noticed some **flakiness with regard to a
'clean' shutdown of our SQL 2000(active/active) & 2005(active/passive)
clusters.
**In the past when we've disconnected storage and had to cold boot all the
cluster nodes, we've had trouble starting the cluster back up. ( network
name not found in the cluster resource group and/or cluster services
wouldn't start)
Is there a recommended order to shut down & restart cluster resource groups
(including SQL+DTC) when system maintenanence need to occur?
Thanks,
Mike Bonvie
Shutdown:
Take the SQL resources offline and set the startup type to DISABLED on all
nodes
Stop the Cluster Service on all nodes and set the startup type to disabled.
Perform hardwarework as necessary.
Only boot one node at a time. If all nodes are down, us a staggered startup
sequence.
Enable and start cluster services on each node. Test moving the cluster
group.
Set SQL Service startup type to MANUAL.
Using the cluster admin tool, bring the diskm IP address, and network name
resources online. Test moving them across nodes.
Bring the SQL Services online using the cluster tool. Test moving groups.
Geoff N. Hiten
Senior Database Administrator
Microsoft SQL Server MVP
"Mike Bonvie" <m@.d.net> wrote in message
news:e7WcCzMYHHA.1388@.TK2MSFTNGP05.phx.gbl...
> Hi,
> We're having a SAN outage & I've noticed some **flakiness with regard to a
> 'clean' shutdown of our SQL 2000(active/active) & 2005(active/passive)
> clusters.
> **In the past when we've disconnected storage and had to cold boot all the
> cluster nodes, we've had trouble starting the cluster back up. ( network
> name not found in the cluster resource group and/or cluster services
> wouldn't start)
> Is there a recommended order to shut down & restart cluster resource
> groups (including SQL+DTC) when system maintenanence need to occur?
> Thanks,
> Mike Bonvie
|||Thank You Geoff,
Great information. Is this based on Microsoft documentation, or a combo of
experience/documentation?
If there's a KB or other resource, where can I get it?
Thanks again,
Mike Bonvie
"Geoff N. Hiten" <SQLCraftsman@.gmail.com> wrote in message
news:u$vRT9MYHHA.4440@.TK2MSFTNGP03.phx.gbl...
> Shutdown:
> Take the SQL resources offline and set the startup type to DISABLED on all
> nodes
> Stop the Cluster Service on all nodes and set the startup type to
> disabled.
> Perform hardwarework as necessary.
> Only boot one node at a time. If all nodes are down, us a staggered
> startup sequence.
> Enable and start cluster services on each node. Test moving the cluster
> group.
> Set SQL Service startup type to MANUAL.
> Using the cluster admin tool, bring the diskm IP address, and network name
> resources online. Test moving them across nodes.
> Bring the SQL Services online using the cluster tool. Test moving groups.
>
> --
> Geoff N. Hiten
> Senior Database Administrator
> Microsoft SQL Server MVP
>
>
> "Mike Bonvie" <m@.d.net> wrote in message
> news:e7WcCzMYHHA.1388@.TK2MSFTNGP05.phx.gbl...
>
|||This is a mix of best practices guidelines and experience. The staggered
startup is documented somewhere, but the other steps are stuff I have worked
out over the years. The DISABLED service ettings just makes sure the
resource won't attempt to come online accidentally.
Geoff N. Hiten
Senior Database Administrator
Microsoft SQL Server MVP
"Mike Bonvie" <m@.d.net> wrote in message
news:Oqu9AHNYHHA.4552@.TK2MSFTNGP05.phx.gbl...
> Thank You Geoff,
> Great information. Is this based on Microsoft documentation, or a combo of
> experience/documentation?
> If there's a KB or other resource, where can I get it?
> Thanks again,
> Mike Bonvie
>
> "Geoff N. Hiten" <SQLCraftsman@.gmail.com> wrote in message
> news:u$vRT9MYHHA.4440@.TK2MSFTNGP03.phx.gbl...
>
sql
Subscribe to:
Posts (Atom)