We have a small site where we want to rename the domain and bring it into
our domain.
current names are as
domainx.local -holds SQL server cluster
domainx.net -main domain
we want to bring domainx.local into the domainx.net AD.
will will rename and migrate. Are there any tools for SQL2005?
we were planning on using the microsoft domain rename tool and ADMT3.
Any other issues with SQL?
Regards
CC
SQL itself doesn't really care what domain it is in, as long as all of the
resources and servers it has to access are still accessible the way they
were before. The only thing you will have to update is the windows service
accounts if any of them are from AD and not the local machine. Will it be
renamed or are you moving to a new domain while the old domain remains up
for a short period of time? If the latter I would recommend setting up a
trust and switching the accounts, or understanding that you might have blips
in uptime/availability.
"Ned" <Cal@.obded.org> wrote in message
news:%231UNGh2ZIHA.2000@.TK2MSFTNGP05.phx.gbl...
> We have a small site where we want to rename the domain and bring it into
> our domain.
> current names are as
> domainx.local -holds SQL server cluster
> domainx.net -main domain
> we want to bring domainx.local into the domainx.net AD.
> will will rename and migrate. Are there any tools for SQL2005?
> we were planning on using the microsoft domain rename tool and ADMT3.
> Any other issues with SQL?
> Regards
> CC
>
|||Hi
I assume that the machine names for the SQL Servers are not changing?
If you have granted logins to domain accounts or groups then you may need to
change them see http://support.microsoft.com/kb/298897/
John
"Ned" wrote:
> We have a small site where we want to rename the domain and bring it into
> our domain.
> current names are as
> domainx.local -holds SQL server cluster
> domainx.net -main domain
> we want to bring domainx.local into the domainx.net AD.
> will will rename and migrate. Are there any tools for SQL2005?
> we were planning on using the microsoft domain rename tool and ADMT3.
> Any other issues with SQL?
> Regards
> CC
>
>
Showing posts with label domain. Show all posts
Showing posts with label domain. Show all posts
Friday, March 30, 2012
renaming domain
We have a small site where we want to rename the domain and bring it into
our domain.
current names are as
domainx.local -holds SQL server cluster
domainx.net -main domain
we want to bring domainx.local into the domainx.net AD.
will will rename and migrate. Are there any tools for SQL2005?
we were planning on using the microsoft domain rename tool and ADMT3.
Any other issues with SQL?
Regards
CCSQL itself doesn't really care what domain it is in, as long as all of the
resources and servers it has to access are still accessible the way they
were before. The only thing you will have to update is the windows service
accounts if any of them are from AD and not the local machine. Will it be
renamed or are you moving to a new domain while the old domain remains up
for a short period of time? If the latter I would recommend setting up a
trust and switching the accounts, or understanding that you might have blips
in uptime/availability.
"Ned" <Cal@.obded.org> wrote in message
news:%231UNGh2ZIHA.2000@.TK2MSFTNGP05.phx.gbl...
> We have a small site where we want to rename the domain and bring it into
> our domain.
> current names are as
> domainx.local -holds SQL server cluster
> domainx.net -main domain
> we want to bring domainx.local into the domainx.net AD.
> will will rename and migrate. Are there any tools for SQL2005?
> we were planning on using the microsoft domain rename tool and ADMT3.
> Any other issues with SQL?
> Regards
> CC
>|||Hi
I assume that the machine names for the SQL Servers are not changing?
If you have granted logins to domain accounts or groups then you may need to
change them see http://support.microsoft.com/kb/298897/
John
"Ned" wrote:
> We have a small site where we want to rename the domain and bring it into
> our domain.
> current names are as
> domainx.local -holds SQL server cluster
> domainx.net -main domain
> we want to bring domainx.local into the domainx.net AD.
> will will rename and migrate. Are there any tools for SQL2005?
> we were planning on using the microsoft domain rename tool and ADMT3.
> Any other issues with SQL?
> Regards
> CC
>
>
our domain.
current names are as
domainx.local -holds SQL server cluster
domainx.net -main domain
we want to bring domainx.local into the domainx.net AD.
will will rename and migrate. Are there any tools for SQL2005?
we were planning on using the microsoft domain rename tool and ADMT3.
Any other issues with SQL?
Regards
CCSQL itself doesn't really care what domain it is in, as long as all of the
resources and servers it has to access are still accessible the way they
were before. The only thing you will have to update is the windows service
accounts if any of them are from AD and not the local machine. Will it be
renamed or are you moving to a new domain while the old domain remains up
for a short period of time? If the latter I would recommend setting up a
trust and switching the accounts, or understanding that you might have blips
in uptime/availability.
"Ned" <Cal@.obded.org> wrote in message
news:%231UNGh2ZIHA.2000@.TK2MSFTNGP05.phx.gbl...
> We have a small site where we want to rename the domain and bring it into
> our domain.
> current names are as
> domainx.local -holds SQL server cluster
> domainx.net -main domain
> we want to bring domainx.local into the domainx.net AD.
> will will rename and migrate. Are there any tools for SQL2005?
> we were planning on using the microsoft domain rename tool and ADMT3.
> Any other issues with SQL?
> Regards
> CC
>|||Hi
I assume that the machine names for the SQL Servers are not changing?
If you have granted logins to domain accounts or groups then you may need to
change them see http://support.microsoft.com/kb/298897/
John
"Ned" wrote:
> We have a small site where we want to rename the domain and bring it into
> our domain.
> current names are as
> domainx.local -holds SQL server cluster
> domainx.net -main domain
> we want to bring domainx.local into the domainx.net AD.
> will will rename and migrate. Are there any tools for SQL2005?
> we were planning on using the microsoft domain rename tool and ADMT3.
> Any other issues with SQL?
> Regards
> CC
>
>
Saturday, February 25, 2012
Removing Domain Controller status from a SQL server
Aloha -
I have a sick server (HOKU) which doubles as a domain controller and a SQL
server. The plan is to move SQL to a new server (SQL1), demote HOKU to a
member server, remove it from the domain then do away with it.
The plan is to demote it this weekend. Then in a couple weeks move the SQL
once testing is done. Is there danger in "de-domain controlering" a SQL
server that is used to being on a DC? At this point I know enough to know
that we're making a fairly major change, but I don't know enough to know
exactly what I am nervous about.
Hi
From a SQL Server point of view, I don't see any problems in demoting a SQL
server. SQL server don't use anything from the Domain Controller as such, so
as long as you have your domain fully functional there shouldn't be any
problems.
Depending on how your users connect to the databases, there might be some
fiddling around when you move the SQL server, since you most likely will
change the server name and/or IP adress.
Regards
Steen
Kahonu wrote:
> Aloha -
> I have a sick server (HOKU) which doubles as a domain controller and
> a SQL server. The plan is to move SQL to a new server (SQL1), demote
> HOKU to a member server, remove it from the domain then do away with
> it.
> The plan is to demote it this weekend. Then in a couple weeks move
> the SQL once testing is done. Is there danger in "de-domain
> controlering" a SQL server that is used to being on a DC? At this
> point I know enough to know that we're making a fairly major change,
> but I don't know enough to know exactly what I am nervous about.
|||Kahonu wrote on Wed, 1 Jun 2005 19:03:18 -0700:
> Aloha -
> I have a sick server (HOKU) which doubles as a domain controller and a SQL
> server. The plan is to move SQL to a new server (SQL1), demote HOKU to a
> member server, remove it from the domain then do away with it.
> The plan is to demote it this weekend. Then in a couple weeks move the SQL
> once testing is done. Is there danger in "de-domain controlering" a SQL
> server that is used to being on a DC? At this point I know enough to know
> that we're making a fairly major change, but I don't know enough to know
> exactly what I am nervous about.
I demoted a W2K Server to a member server with SQL Server 2000 just 2 weeks
ago, no ill effects as yet. I needed to rename the server prior to running
in production, and I'd be running it as a domain controller while migrating
from NT4 to 2K. The demotion was painless, it was the renaming that was the
fun part :\
Dan
|||I have also demoted as you are doing, and like the others had no problems...
In fact, it is a bad practice to put SQL on a domain controller anyway - so
you are doing a good thing and improving security by your actions as well.
Wayne Snyder MCDBA, SQL Server MVP
Mariner, Charlotte, NC
(Please respond only to the newsgroup.)
I support the Professional Association for SQL Server ( PASS) and it's
community of SQL Professionals.
"Kahonu" <Kahonu@.discussions.microsoft.com> wrote in message
news:FE165EC2-B09B-4D40-9782-D8C54CB036C7@.microsoft.com...
> Aloha -
> I have a sick server (HOKU) which doubles as a domain controller and a SQL
> server. The plan is to move SQL to a new server (SQL1), demote HOKU to a
> member server, remove it from the domain then do away with it.
> The plan is to demote it this weekend. Then in a couple weeks move the SQL
> once testing is done. Is there danger in "de-domain controlering" a SQL
> server that is used to being on a DC? At this point I know enough to know
> that we're making a fairly major change, but I don't know enough to know
> exactly what I am nervous about.
>
I have a sick server (HOKU) which doubles as a domain controller and a SQL
server. The plan is to move SQL to a new server (SQL1), demote HOKU to a
member server, remove it from the domain then do away with it.
The plan is to demote it this weekend. Then in a couple weeks move the SQL
once testing is done. Is there danger in "de-domain controlering" a SQL
server that is used to being on a DC? At this point I know enough to know
that we're making a fairly major change, but I don't know enough to know
exactly what I am nervous about.
Hi
From a SQL Server point of view, I don't see any problems in demoting a SQL
server. SQL server don't use anything from the Domain Controller as such, so
as long as you have your domain fully functional there shouldn't be any
problems.
Depending on how your users connect to the databases, there might be some
fiddling around when you move the SQL server, since you most likely will
change the server name and/or IP adress.
Regards
Steen
Kahonu wrote:
> Aloha -
> I have a sick server (HOKU) which doubles as a domain controller and
> a SQL server. The plan is to move SQL to a new server (SQL1), demote
> HOKU to a member server, remove it from the domain then do away with
> it.
> The plan is to demote it this weekend. Then in a couple weeks move
> the SQL once testing is done. Is there danger in "de-domain
> controlering" a SQL server that is used to being on a DC? At this
> point I know enough to know that we're making a fairly major change,
> but I don't know enough to know exactly what I am nervous about.
|||Kahonu wrote on Wed, 1 Jun 2005 19:03:18 -0700:
> Aloha -
> I have a sick server (HOKU) which doubles as a domain controller and a SQL
> server. The plan is to move SQL to a new server (SQL1), demote HOKU to a
> member server, remove it from the domain then do away with it.
> The plan is to demote it this weekend. Then in a couple weeks move the SQL
> once testing is done. Is there danger in "de-domain controlering" a SQL
> server that is used to being on a DC? At this point I know enough to know
> that we're making a fairly major change, but I don't know enough to know
> exactly what I am nervous about.
I demoted a W2K Server to a member server with SQL Server 2000 just 2 weeks
ago, no ill effects as yet. I needed to rename the server prior to running
in production, and I'd be running it as a domain controller while migrating
from NT4 to 2K. The demotion was painless, it was the renaming that was the
fun part :\
Dan
|||I have also demoted as you are doing, and like the others had no problems...
In fact, it is a bad practice to put SQL on a domain controller anyway - so
you are doing a good thing and improving security by your actions as well.
Wayne Snyder MCDBA, SQL Server MVP
Mariner, Charlotte, NC
(Please respond only to the newsgroup.)
I support the Professional Association for SQL Server ( PASS) and it's
community of SQL Professionals.
"Kahonu" <Kahonu@.discussions.microsoft.com> wrote in message
news:FE165EC2-B09B-4D40-9782-D8C54CB036C7@.microsoft.com...
> Aloha -
> I have a sick server (HOKU) which doubles as a domain controller and a SQL
> server. The plan is to move SQL to a new server (SQL1), demote HOKU to a
> member server, remove it from the domain then do away with it.
> The plan is to demote it this weekend. Then in a couple weeks move the SQL
> once testing is done. Is there danger in "de-domain controlering" a SQL
> server that is used to being on a DC? At this point I know enough to know
> that we're making a fairly major change, but I don't know enough to know
> exactly what I am nervous about.
>
Removing Domain Controller status from a SQL server
Aloha -
I have a sick server (HOKU) which doubles as a domain controller and a SQL
server. The plan is to move SQL to a new server (SQL1), demote HOKU to a
member server, remove it from the domain then do away with it.
The plan is to demote it this weekend. Then in a couple weeks move the SQL
once testing is done. Is there danger in "de-domain controlering" a SQL
server that is used to being on a DC? At this point I know enough to know
that we're making a fairly major change, but I don't know enough to know
exactly what I am nervous about.Hi
From a SQL Server point of view, I don't see any problems in demoting a SQL
server. SQL server don't use anything from the Domain Controller as such, so
as long as you have your domain fully functional there shouldn't be any
problems.
Depending on how your users connect to the databases, there might be some
fiddling around when you move the SQL server, since you most likely will
change the server name and/or IP adress.
Regards
Steen
Kahonu wrote:
> Aloha -
> I have a sick server (HOKU) which doubles as a domain controller and
> a SQL server. The plan is to move SQL to a new server (SQL1), demote
> HOKU to a member server, remove it from the domain then do away with
> it.
> The plan is to demote it this weekend. Then in a couple weeks move
> the SQL once testing is done. Is there danger in "de-domain
> controlering" a SQL server that is used to being on a DC? At this
> point I know enough to know that we're making a fairly major change,
> but I don't know enough to know exactly what I am nervous about.|||Kahonu wrote on Wed, 1 Jun 2005 19:03:18 -0700:
> Aloha -
> I have a sick server (HOKU) which doubles as a domain controller and a SQL
> server. The plan is to move SQL to a new server (SQL1), demote HOKU to a
> member server, remove it from the domain then do away with it.
> The plan is to demote it this weekend. Then in a couple weeks move the SQL
> once testing is done. Is there danger in "de-domain controlering" a SQL
> server that is used to being on a DC? At this point I know enough to know
> that we're making a fairly major change, but I don't know enough to know
> exactly what I am nervous about.
I demoted a W2K Server to a member server with SQL Server 2000 just 2 weeks
ago, no ill effects as yet. I needed to rename the server prior to running
in production, and I'd be running it as a domain controller while migrating
from NT4 to 2K. The demotion was painless, it was the renaming that was the
fun part :\
Dan|||I have also demoted as you are doing, and like the others had no problems...
In fact, it is a bad practice to put SQL on a domain controller anyway - so
you are doing a good thing and improving security by your actions as well.
--
Wayne Snyder MCDBA, SQL Server MVP
Mariner, Charlotte, NC
(Please respond only to the newsgroup.)
I support the Professional Association for SQL Server ( PASS) and it's
community of SQL Professionals.
"Kahonu" <Kahonu@.discussions.microsoft.com> wrote in message
news:FE165EC2-B09B-4D40-9782-D8C54CB036C7@.microsoft.com...
> Aloha -
> I have a sick server (HOKU) which doubles as a domain controller and a SQL
> server. The plan is to move SQL to a new server (SQL1), demote HOKU to a
> member server, remove it from the domain then do away with it.
> The plan is to demote it this weekend. Then in a couple weeks move the SQL
> once testing is done. Is there danger in "de-domain controlering" a SQL
> server that is used to being on a DC? At this point I know enough to know
> that we're making a fairly major change, but I don't know enough to know
> exactly what I am nervous about.
>
I have a sick server (HOKU) which doubles as a domain controller and a SQL
server. The plan is to move SQL to a new server (SQL1), demote HOKU to a
member server, remove it from the domain then do away with it.
The plan is to demote it this weekend. Then in a couple weeks move the SQL
once testing is done. Is there danger in "de-domain controlering" a SQL
server that is used to being on a DC? At this point I know enough to know
that we're making a fairly major change, but I don't know enough to know
exactly what I am nervous about.Hi
From a SQL Server point of view, I don't see any problems in demoting a SQL
server. SQL server don't use anything from the Domain Controller as such, so
as long as you have your domain fully functional there shouldn't be any
problems.
Depending on how your users connect to the databases, there might be some
fiddling around when you move the SQL server, since you most likely will
change the server name and/or IP adress.
Regards
Steen
Kahonu wrote:
> Aloha -
> I have a sick server (HOKU) which doubles as a domain controller and
> a SQL server. The plan is to move SQL to a new server (SQL1), demote
> HOKU to a member server, remove it from the domain then do away with
> it.
> The plan is to demote it this weekend. Then in a couple weeks move
> the SQL once testing is done. Is there danger in "de-domain
> controlering" a SQL server that is used to being on a DC? At this
> point I know enough to know that we're making a fairly major change,
> but I don't know enough to know exactly what I am nervous about.|||Kahonu wrote on Wed, 1 Jun 2005 19:03:18 -0700:
> Aloha -
> I have a sick server (HOKU) which doubles as a domain controller and a SQL
> server. The plan is to move SQL to a new server (SQL1), demote HOKU to a
> member server, remove it from the domain then do away with it.
> The plan is to demote it this weekend. Then in a couple weeks move the SQL
> once testing is done. Is there danger in "de-domain controlering" a SQL
> server that is used to being on a DC? At this point I know enough to know
> that we're making a fairly major change, but I don't know enough to know
> exactly what I am nervous about.
I demoted a W2K Server to a member server with SQL Server 2000 just 2 weeks
ago, no ill effects as yet. I needed to rename the server prior to running
in production, and I'd be running it as a domain controller while migrating
from NT4 to 2K. The demotion was painless, it was the renaming that was the
fun part :\
Dan|||I have also demoted as you are doing, and like the others had no problems...
In fact, it is a bad practice to put SQL on a domain controller anyway - so
you are doing a good thing and improving security by your actions as well.
--
Wayne Snyder MCDBA, SQL Server MVP
Mariner, Charlotte, NC
(Please respond only to the newsgroup.)
I support the Professional Association for SQL Server ( PASS) and it's
community of SQL Professionals.
"Kahonu" <Kahonu@.discussions.microsoft.com> wrote in message
news:FE165EC2-B09B-4D40-9782-D8C54CB036C7@.microsoft.com...
> Aloha -
> I have a sick server (HOKU) which doubles as a domain controller and a SQL
> server. The plan is to move SQL to a new server (SQL1), demote HOKU to a
> member server, remove it from the domain then do away with it.
> The plan is to demote it this weekend. Then in a couple weeks move the SQL
> once testing is done. Is there danger in "de-domain controlering" a SQL
> server that is used to being on a DC? At this point I know enough to know
> that we're making a fairly major change, but I don't know enough to know
> exactly what I am nervous about.
>
Removing Domain Controller status from a SQL server
Aloha -
I have a sick server (HOKU) which doubles as a domain controller and a SQL
server. The plan is to move SQL to a new server (SQL1), demote HOKU to a
member server, remove it from the domain then do away with it.
The plan is to demote it this weekend. Then in a couple weeks move the SQL
once testing is done. Is there danger in "de-domain controlering" a SQL
server that is used to being on a DC? At this point I know enough to know
that we're making a fairly major change, but I don't know enough to know
exactly what I am nervous about.Hi
From a SQL Server point of view, I don't see any problems in demoting a SQL
server. SQL server don't use anything from the Domain Controller as such, so
as long as you have your domain fully functional there shouldn't be any
problems.
Depending on how your users connect to the databases, there might be some
fiddling around when you move the SQL server, since you most likely will
change the server name and/or IP adress.
Regards
Steen
Kahonu wrote:
> Aloha -
> I have a sick server (HOKU) which doubles as a domain controller and
> a SQL server. The plan is to move SQL to a new server (SQL1), demote
> HOKU to a member server, remove it from the domain then do away with
> it.
> The plan is to demote it this weekend. Then in a couple weeks move
> the SQL once testing is done. Is there danger in "de-domain
> controlering" a SQL server that is used to being on a DC? At this
> point I know enough to know that we're making a fairly major change,
> but I don't know enough to know exactly what I am nervous about.|||Kahonu wrote on Wed, 1 Jun 2005 19:03:18 -0700:
> Aloha -
> I have a sick server (HOKU) which doubles as a domain controller and a SQL
> server. The plan is to move SQL to a new server (SQL1), demote HOKU to a
> member server, remove it from the domain then do away with it.
> The plan is to demote it this weekend. Then in a couple weeks move the SQL
> once testing is done. Is there danger in "de-domain controlering" a SQL
> server that is used to being on a DC? At this point I know enough to know
> that we're making a fairly major change, but I don't know enough to know
> exactly what I am nervous about.
I demoted a W2K Server to a member server with SQL Server 2000 just 2 weeks
ago, no ill effects as yet. I needed to rename the server prior to running
in production, and I'd be running it as a domain controller while migrating
from NT4 to 2K. The demotion was painless, it was the renaming that was the
fun part :\
Dan|||I have also demoted as you are doing, and like the others had no problems...
In fact, it is a bad practice to put SQL on a domain controller anyway - so
you are doing a good thing and improving security by your actions as well.
Wayne Snyder MCDBA, SQL Server MVP
Mariner, Charlotte, NC
(Please respond only to the newsgroup.)
I support the Professional Association for SQL Server ( PASS) and it's
community of SQL Professionals.
"Kahonu" <Kahonu@.discussions.microsoft.com> wrote in message
news:FE165EC2-B09B-4D40-9782-D8C54CB036C7@.microsoft.com...
> Aloha -
> I have a sick server (HOKU) which doubles as a domain controller and a SQL
> server. The plan is to move SQL to a new server (SQL1), demote HOKU to a
> member server, remove it from the domain then do away with it.
> The plan is to demote it this weekend. Then in a couple weeks move the SQL
> once testing is done. Is there danger in "de-domain controlering" a SQL
> server that is used to being on a DC? At this point I know enough to know
> that we're making a fairly major change, but I don't know enough to know
> exactly what I am nervous about.
>
I have a sick server (HOKU) which doubles as a domain controller and a SQL
server. The plan is to move SQL to a new server (SQL1), demote HOKU to a
member server, remove it from the domain then do away with it.
The plan is to demote it this weekend. Then in a couple weeks move the SQL
once testing is done. Is there danger in "de-domain controlering" a SQL
server that is used to being on a DC? At this point I know enough to know
that we're making a fairly major change, but I don't know enough to know
exactly what I am nervous about.Hi
From a SQL Server point of view, I don't see any problems in demoting a SQL
server. SQL server don't use anything from the Domain Controller as such, so
as long as you have your domain fully functional there shouldn't be any
problems.
Depending on how your users connect to the databases, there might be some
fiddling around when you move the SQL server, since you most likely will
change the server name and/or IP adress.
Regards
Steen
Kahonu wrote:
> Aloha -
> I have a sick server (HOKU) which doubles as a domain controller and
> a SQL server. The plan is to move SQL to a new server (SQL1), demote
> HOKU to a member server, remove it from the domain then do away with
> it.
> The plan is to demote it this weekend. Then in a couple weeks move
> the SQL once testing is done. Is there danger in "de-domain
> controlering" a SQL server that is used to being on a DC? At this
> point I know enough to know that we're making a fairly major change,
> but I don't know enough to know exactly what I am nervous about.|||Kahonu wrote on Wed, 1 Jun 2005 19:03:18 -0700:
> Aloha -
> I have a sick server (HOKU) which doubles as a domain controller and a SQL
> server. The plan is to move SQL to a new server (SQL1), demote HOKU to a
> member server, remove it from the domain then do away with it.
> The plan is to demote it this weekend. Then in a couple weeks move the SQL
> once testing is done. Is there danger in "de-domain controlering" a SQL
> server that is used to being on a DC? At this point I know enough to know
> that we're making a fairly major change, but I don't know enough to know
> exactly what I am nervous about.
I demoted a W2K Server to a member server with SQL Server 2000 just 2 weeks
ago, no ill effects as yet. I needed to rename the server prior to running
in production, and I'd be running it as a domain controller while migrating
from NT4 to 2K. The demotion was painless, it was the renaming that was the
fun part :\
Dan|||I have also demoted as you are doing, and like the others had no problems...
In fact, it is a bad practice to put SQL on a domain controller anyway - so
you are doing a good thing and improving security by your actions as well.
Wayne Snyder MCDBA, SQL Server MVP
Mariner, Charlotte, NC
(Please respond only to the newsgroup.)
I support the Professional Association for SQL Server ( PASS) and it's
community of SQL Professionals.
"Kahonu" <Kahonu@.discussions.microsoft.com> wrote in message
news:FE165EC2-B09B-4D40-9782-D8C54CB036C7@.microsoft.com...
> Aloha -
> I have a sick server (HOKU) which doubles as a domain controller and a SQL
> server. The plan is to move SQL to a new server (SQL1), demote HOKU to a
> member server, remove it from the domain then do away with it.
> The plan is to demote it this weekend. Then in a couple weeks move the SQL
> once testing is done. Is there danger in "de-domain controlering" a SQL
> server that is used to being on a DC? At this point I know enough to know
> that we're making a fairly major change, but I don't know enough to know
> exactly what I am nervous about.
>
Monday, February 20, 2012
Removing AD from server with SQL on it
I've got a situation where I need to move a server (server A) from the
domain (Domain A) that it is in (it is the only server in this domain)
into a different domain (Domain B). The curve ball is that SQL 2005
is set up on this server.
My question is: How 'broken' will SQL become if I uninstall AD/remove
it from the domain that it is in? I've done some VMWare testing and
forcing the demotion on the SQL box and bringing it into the other
domain isn't that big of a deal. The SQL data that resides on the
server A is just test data but is close to being a production server.
A carbon copy of all the users in Domain B have been recreated on
Server/Domain A.
Comments/suggestions?
Thanks in advance...
I don't think, it matters much as long as the server name is the same. The
SQL instances running on the server should be able to function without major
issues.
You have to make sure the service logins, if using domain accounts, should
be changed to match the accounts in the new domain. Any windows logins that
are mapped to any database users should be modified as well. If you have
special processes like backups to shared drives or log shipping, you'll have
to make sure the folder are shared with appropriate permissions for the new
accounts.
Anith
domain (Domain A) that it is in (it is the only server in this domain)
into a different domain (Domain B). The curve ball is that SQL 2005
is set up on this server.
My question is: How 'broken' will SQL become if I uninstall AD/remove
it from the domain that it is in? I've done some VMWare testing and
forcing the demotion on the SQL box and bringing it into the other
domain isn't that big of a deal. The SQL data that resides on the
server A is just test data but is close to being a production server.
A carbon copy of all the users in Domain B have been recreated on
Server/Domain A.
Comments/suggestions?
Thanks in advance...
I don't think, it matters much as long as the server name is the same. The
SQL instances running on the server should be able to function without major
issues.
You have to make sure the service logins, if using domain accounts, should
be changed to match the accounts in the new domain. Any windows logins that
are mapped to any database users should be modified as well. If you have
special processes like backups to shared drives or log shipping, you'll have
to make sure the folder are shared with appropriate permissions for the new
accounts.
Anith
Removing AD from server with SQL on it
I've got a situation where I need to move a server (server A) from the
domain (Domain A) that it is in (it is the only server in this domain)
into a different domain (Domain B). The curve ball is that SQL 2005
is set up on this server.
My question is: How 'broken' will SQL become if I uninstall AD/remove
it from the domain that it is in? I've done some VMWare testing and
forcing the demotion on the SQL box and bringing it into the other
domain isn't that big of a deal. The SQL data that resides on the
server A is just test data but is close to being a production server.
A carbon copy of all the users in Domain B have been recreated on
Server/Domain A.
Comments/suggestions?
Thanks in advance...I don't think, it matters much as long as the server name is the same. The
SQL instances running on the server should be able to function without major
issues.
You have to make sure the service logins, if using domain accounts, should
be changed to match the accounts in the new domain. Any windows logins that
are mapped to any database users should be modified as well. If you have
special processes like backups to shared drives or log shipping, you'll have
to make sure the folder are shared with appropriate permissions for the new
accounts.
--
Anith
domain (Domain A) that it is in (it is the only server in this domain)
into a different domain (Domain B). The curve ball is that SQL 2005
is set up on this server.
My question is: How 'broken' will SQL become if I uninstall AD/remove
it from the domain that it is in? I've done some VMWare testing and
forcing the demotion on the SQL box and bringing it into the other
domain isn't that big of a deal. The SQL data that resides on the
server A is just test data but is close to being a production server.
A carbon copy of all the users in Domain B have been recreated on
Server/Domain A.
Comments/suggestions?
Thanks in advance...I don't think, it matters much as long as the server name is the same. The
SQL instances running on the server should be able to function without major
issues.
You have to make sure the service logins, if using domain accounts, should
be changed to match the accounts in the new domain. Any windows logins that
are mapped to any database users should be modified as well. If you have
special processes like backups to shared drives or log shipping, you'll have
to make sure the folder are shared with appropriate permissions for the new
accounts.
--
Anith
Subscribe to:
Posts (Atom)