| Author | Messages | |
Servernet
Posts:34
 | | 06/24/2009 1:30 PM |
|
I'm interested in the experience of others with migrating member servers from one domain to another and specifically the impact on installed applications.
At a basic level, moving users, groups and computers from one domain to another appears to be a straightforward task that can be accomplished with ADMT or the likes of Quest's DMW or QMM (depending on whether your source domain is NT 4.0 or Active Directory). After migrating users and groups, any member servers left in the source domain will have their security descriptors updated by the ADMT/Quest tools to include an ACE for the migrated users and groups, in order to maintain access to resources (SID History should be enough, but Quest claim that it often isn't). When the member server is moved to the target domain, the security descriptors are updated again to remove ACEs relating to users and groups from the source domain. Access to files, folders and shares etc is retained by the migrated users and everyone is happy. But what about applications?
Older versions of Sharepoint needed to be updated with details of users' migrated logon credentials (KB896593 and KB896161) which is something that the ADMT and Quest tools do not handle. The Quest toolset does provides a utility to update SQL Server security, but what if I had Oracle, or MySQL or any number of applications hosted on a member server that needed to be moved to a new domain? Is it really a case of examining every application on a case-by-case basis and determining whether application security needs updating, or are examples such as older versions of Sharepoint just corner cases and most of the time, applications will continue to run without issue after migration?
There are other issues to address such as the dreaded in-house written apps with hardcoded domain or server names.
What are your experiences? Was migrating a bunch of application servers a pain, or was it straightforward. Which apps caused the most pain?
Steve G
_________________________________________________________________
Get the best of MSN on your mobile
http://clk.atdmt.com/UKM/go/147991039/direct/01/
| | | |
| LeslieTyson
Posts:13
| | 06/29/2009 4:24 AM |
| This is an area where we've found no 3rd party solutions were acceptable.
>> Is it really a case of examining every application on a case-by-case basis and determining whether application security needs updating...?
Yes. (Unfortunately...) This is an incredible time sink, but we've found it must be done that way. Typically we've written scripts (in-house) to deal with the changes. The worst applications are any that maintain an internal user list, and do not sync against AD. Apps with hard-coded credentials are problematic for different reasons - again, you'll have to test once you make changes. For apps that maintain relationships between AD accounts and data, those relationships need to be updated to reflect the new accounts. Once you've figured out how to change one though, you can typically script it to update the rest.
In the dozens of domain migrations that we've done, application testing has always been the biggest area of concern. You can't underestimate the amount of time it can take to identify and resolve the issues.
Cheers,
Tyson.
From: activedir-owner@mail.activedir.org [mailto:activedir-owner@mail.activedir.org] On Behalf Of Steven Griffiths
Sent: June-24-09 8:29 PM
To: ActiveDir.Org
Subject: [ActiveDir] OT: Member Server Migration
I'm interested in the experience of others with migrating member servers from one domain to another and specifically the impact on installed applications.
At a basic level, moving users, groups and computers from one domain to another appears to be a straightforward task that can be accomplished with ADMT or the likes of Quest's DMW or QMM (depending on whether your source domain is NT 4.0 or Active Directory). After migrating users and groups, any member servers left in the source domain will have their security descriptors updated by the ADMT/Quest tools to include an ACE for the migrated users and groups, in order to maintain access to resources (SID History should be enough, but Quest claim that it often isn't). When the member server is moved to the target domain, the security descriptors are updated again to remove ACEs relating to users and groups from the source domain. Access to files, folders and shares etc is retained by the migrated users and everyone is happy. But what about applications?
Older versions of Sharepoint needed to be updated with details of users' migrated logon credentials (KB896593 and KB896161) which is something that the ADMT and Quest tools do not handle. The Quest toolset does provides a utility to update SQL Server security, but what if I had Oracle, or MySQL or any number of applications hosted on a member server that needed to be moved to a new domain? Is it really a case of examining every application on a case-by-case basis and determining whether application security needs updating, or are examples such as older versions of Sharepoint just corner cases and most of the time, applications will continue to run without issue after migration?
There are other issues to address such as the dreaded in-house written apps with hardcoded domain or server names.
What are your experiences? Was migrating a bunch of application servers a pain, or was it straightforward. Which apps caused the most pain?
Steve G
________________________________
Beyond Hotmail - see what else you can do with Windows Live. Find out more.<http://clk.atdmt.com/UKM/go/134665375/direct/01/>
*** WORLEYPARSONS GROUP NOTICE ***
"This email is confidential. If you are not the intended recipient, you must not disclose or use the information contained in it.
If you have received this email in error, please notify us immediately by return email and delete the email and any attachments.
Any personal views or opinions expressed by the writer may not
necessarily reflect the views or opinions of any company in the WorleyParsons Group of Companies."
| | | |
| sbradcpa
Posts:496
| | 06/29/2009 5:37 AM |
| <!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
<meta content="text/html;charset=ISO-8859-1" http-equiv="Content-Type">
</head>
<body bgcolor="#ffffff" text="#000000">
Have you compared what the cost/time is to deploy new versus
migration?
I know on some of our databases that I'm in charge of, they are so
crusty from various upgrades that sometimes installing clean and
moving what data we need over in the long run is better. Granted I'm
sure my migrations pale in comparison, but whenever we've done LOB
migrations, weird stuff travels with the apps that you just never get
rid of.
Leslie, Tyson (Calgary) wrote:
<blockquote
cite="mid:6C38A6056196DC4FA435B51EE91A8F7A05885CCD96@CACDCWPE7M01V.WorleyParsons.com"
type="cite">
<meta http-equiv="Content-Type" content="text/html; ">
<meta name="Generator" content="Microsoft Word 12 (filtered medium)">
<!--[if !mso]>
<style>
v\:* {behavior:url(#default#VML);}
o\:* {behavior:url(#default#VML);}
w\:* {behavior:url(#default#VML);}
..shape {behavior:url(#default#VML);}
</style>
<![endif]-->
<style>
<!--
/* Font Definitions */
@font-face
{font-family:"Cambria Math";
panose-1:2 4 5 3 5 4 6 3 2 4;}
@font-face
{font-family:Calibri;
panose-1:2 15 5 2 2 2 4 3 2 4;}
@font-face
{font-family:Tahoma;
panose-1:2 11 6 4 3 5 4 4 2 4;}
@font-face
{font-family:Verdana;
panose-1:2 11 6 4 3 5 4 4 2 4;}
/* Style Definitions */
p.MsoNormal, li.MsoNormal, div.MsoNormal
{margin:0in;
margin-bottom:.0001pt;
font-size:12.0pt;
font-family:"Times New Roman","serif";}
a:link, span.MsoHyperlink
{mso-style-priority:99;
color:blue;
text-decoration:underline;}
a:visited, span.MsoHyperlinkFollowed
{mso-style-priority:99;
color:purple;
text-decoration:underline;}
p
{mso-style-priority:99;
mso-margin-top-alt:auto;
margin-right:0in;
mso-margin-bottom-alt:auto;
margin-left:0in;
font-size:12.0pt;
font-family:"Times New Roman","serif";}
span.EmailStyle18
{mso-style-type:personal-reply;
font-family:"Calibri","sans-serif";
color:#1F497D;}
..MsoChpDefault
{mso-style-type:export-only;
font-size:10.0pt;}
@page Section1
{size:8.5in 11.0in;
margin:1.0in 1.0in 1.0in 1.0in;}
div.Section1
{page:Section1;}
-->
</style><!--[if gte mso 9]><xml>
<o:shapedefaults v:ext="edit" spidmax="1026" />
</xml><![endif]--><!--[if gte mso 9]><xml>
<o:shapelayout v:ext="edit">
<o:idmap v:ext="edit" data="1" />
</o:shapelayout></xml><![endif]-->
<div class="Section1">
<p class="MsoNormal"><span
style="font-size: 11pt; font-family: "Calibri","sans-serif"; color: rgb(31, 73, 125);">This
is an area where we’ve found no 3<sup>rd</sup> party
solutions were acceptable.<o:p></o:p></span></p>
<p class="MsoNormal"><span
style="font-size: 11pt; font-family: "Calibri","sans-serif"; color: rgb(31, 73, 125);"><o:p> </o:p></span></p>
<p class="MsoNormal"><span
style="font-size: 11pt; font-family: "Calibri","sans-serif"; color: rgb(31, 73, 125);">>>
</span><span
style="font-size: 10pt; font-family: "Verdana","sans-serif";">Is
it really a case of examining every application on a case-by-case basis
and
determining whether application security needs updating…?</span><span
style="font-size: 11pt; font-family: "Calibri","sans-serif"; color: rgb(31, 73, 125);"><o:p></o:p></span></p>
<p class="MsoNormal"><span
style="font-size: 11pt; font-family: "Calibri","sans-serif"; color: rgb(31, 73, 125);"><o:p> </o:p></span></p>
<p class="MsoNormal"><span
style="font-size: 11pt; font-family: "Calibri","sans-serif"; color: rgb(31, 73, 125);">Yes.
(Unfortunately…) This is an incredible
time sink, but we’ve found it must be done that way. Typically we’ve
written scripts (in-house) to deal with the changes. The worst
applications
are any that maintain an internal user list, and do not sync against
AD. Apps
with hard-coded credentials are problematic for different reasons –
again,
you’ll have to test once you make changes. For apps that maintain
relationships between AD accounts and data, those relationships need to
be updated
to reflect the new accounts. Once you’ve figured out how to change
one though, you can typically script it to update the rest. <o:p></o:p></span></p>
<p class="MsoNormal"><span
style="font-size: 11pt; font-family: "Calibri","sans-serif"; color: rgb(31, 73, 125);"><o:p> </o:p></span></p>
<p class="MsoNormal"><span
style="font-size: 11pt; font-family: "Calibri","sans-serif"; color: rgb(31, 73, 125);">In
the dozens of domain migrations that we’ve done,
application testing has always been the biggest area of concern. You
can’t
underestimate the amount of time it can take to identify and resolve
the issues.<o:p></o:p></span></p>
<p class="MsoNormal"><span
style="font-size: 11pt; font-family: "Calibri","sans-serif"; color: rgb(31, 73, 125);"><o:p> </o:p></span></p>
<p class="MsoNormal"><span
style="font-size: 11pt; font-family: "Calibri","sans-serif"; color: rgb(31, 73, 125);">Cheers,<o:p></o:p></span></p>
<p class="MsoNormal"><span
style="font-size: 11pt; font-family: "Calibri","sans-serif"; color: rgb(31, 73, 125);"><o:p> </o:p></span></p>
<p class="MsoNormal"><span
style="font-size: 11pt; font-family: "Calibri","sans-serif"; color: rgb(31, 73, 125);">
Tyson.<o:p></o:p></span></p>
<p class="MsoNormal"><span
style="font-size: 11pt; font-family: "Calibri","sans-serif"; color: rgb(31, 73, 125);"><o:p> </o:p></span></p>
<div>
<div
style="border-style: solid none none; border-color: rgb(181, 196, 223) -moz-use-text-color -moz-use-text-color; border-width: 1pt medium medium; padding: 3pt 0in 0in;">
<p class="MsoNormal"><b><span
style="font-size: 10pt; font-family: "Tahoma","sans-serif";">From:</span></b><span
style="font-size: 10pt; font-family: "Tahoma","sans-serif";">
<a class="moz-txt-link-abbreviated" href="javascript:window.location.replace('ma'+'ilto:'+'activedir-owner'+'@'+'mail'+'.activedir')".org">activedir-owner@mail.activedir.org</a>
[<a class="moz-txt-link-freetext" href="javascript:window.location.replace('ma'+'ilto:'+'activedir-owner'+'@'+'mail'+'.activedir')".org">mailto:activedir-owner@mail.activedir.org</a>] <b>On
Behalf Of </b>Steven Griffiths
<b>Sent:</b> June-24-09 8:29 PM
<b>To:</b> ActiveDir.Org
<b>Subject:</b> [ActiveDir] OT: Member Server Migration<o:p></o:p></span></p>
</div>
</div>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal" style="margin-bottom: 12pt;"><span
style="font-size: 10pt; font-family: "Verdana","sans-serif";">I'm
interested in the experience of others
with migrating member servers from one domain to another and
specifically the
impact on installed applications.
At a basic level, moving users, groups and computers from one domain to
another appears to be a straightforward task that can be accomplished
with
ADMT or the likes of Quest's DMW or QMM (depending on whether your
source
domain is NT 4.0 or Active Directory). After migrating users and
groups, any
member servers left in the source domain will have their security
descriptors
updated by the ADMT/Quest tools to include an ACE for the migrated
users
and groups, in order to maintain access to resources (SID History
should be
enough, but Quest claim that it often isn't). When the member server is
moved
to the target domain, the security descriptors are updated again to
remove ACEs
relating to users and groups from the source domain. Access to files,
folders
and shares etc is retained by the migrated users and everyone is happy.
But what about applications?
Older versions of Sharepoint needed to be updated with details of
users'
migrated logon credentials (KB896593 and KB896161) which is something
that the
ADMT and Quest tools do not handle. The Quest toolset does provides a
utility
to update SQL Server security, but what if I had Oracle, or MySQL or
any number
of applications hosted on a member server that needed to be moved to a
new
domain? Is it really a case of examining every application on a
case-by-case
basis and determining whether application security needs updating, or
are
examples such as older versions of Sharepoint just corner cases and
most of the
time, applications will continue to run without issue after migration?
There are other issues to address such as the dreaded in-house written
apps
with hardcoded domain or server names.
What are your experiences? Was migrating a bunch of application servers
a
pain, or was it straightforward. Which apps caused the most pain?
Steve G<o:p></o:p></span></p>
<div class="MsoNormal" style="text-align: center;" align="center"><span
style="font-size: 10pt; font-family: "Verdana","sans-serif";">
<hr align="center" size="2" width="100%"></span></div>
<p class="MsoNormal"><span
style="font-size: 10pt; font-family: "Verdana","sans-serif";">Beyond
Hotmail - see what else you can do with Windows Live. <a
moz-do-not-send="true"
href="http://clk.atdmt.com/UKM/go/134665375/direct/01/" target="_new">Find
out
more.</a><o:p></o:p></span></p>
</div>
<pre>*** WORLEYPARSONS GROUP NOTICE ***
"This email is confidential. If you are not the intended recipient, you must not disclose or use the information contained in it.
If you have received this email in error, please notify us immediately by return email and delete the email and any attachments.
Any personal views or opinions expressed by the writer may not
necessarily reflect the views or opinions of any company in the WorleyParsons Group of Companies."
</pre>
</blockquote>
</body>
</html>
| | | |
| LeslieTyson
Posts:13
| | 06/29/2009 6:46 AM |
| It depends on the scope. Most of the migrations have been due to acquisitions, and the priority is to get the newly acquired company 'on net' ASAP. If it makes sense to move them to a process or app that the parent company is already using then we do it, but usually the migration timeframe is too short to transition them to a new system. It happens over time, but as part of another project. (Financial systems are at the top of this list.)
From: activedir-owner@mail.activedir.org [mailto:activedir-owner@mail.activedir.org] On Behalf Of Susan Bradley
Sent: June-29-09 12:35 PM
To: activedir@mail.activedir.org
Subject: Re: [ActiveDir] OT: Member Server Migration
Have you compared what the cost/time is to deploy new versus migration?
I know on some of our databases that I'm in charge of, they are so crusty from various upgrades that sometimes installing clean and moving what data we need over in the long run is better. Granted I'm sure my migrations pale in comparison, but whenever we've done LOB migrations, weird stuff travels with the apps that you just never get rid of.
Leslie, Tyson (Calgary) wrote:
This is an area where we've found no 3rd party solutions were acceptable.
>> Is it really a case of examining every application on a case-by-case basis and determining whether application security needs updating...?
Yes. (Unfortunately...) This is an incredible time sink, but we've found it must be done that way. Typically we've written scripts (in-house) to deal with the changes. The worst applications are any that maintain an internal user list, and do not sync against AD. Apps with hard-coded credentials are problematic for different reasons - again, you'll have to test once you make changes. For apps that maintain relationships between AD accounts and data, those relationships need to be updated to reflect the new accounts. Once you've figured out how to change one though, you can typically script it to update the rest.
In the dozens of domain migrations that we've done, application testing has always been the biggest area of concern. You can't underestimate the amount of time it can take to identify and resolve the issues.
Cheers,
Tyson.
From: activedir-owner@mail.activedir.org<mailto:activedir-owner@mail.activedir.org> [mailto:activedir-owner@mail.activedir.org] On Behalf Of Steven Griffiths
Sent: June-24-09 8:29 PM
To: ActiveDir.Org
Subject: [ActiveDir] OT: Member Server Migration
I'm interested in the experience of others with migrating member servers from one domain to another and specifically the impact on installed applications.
At a basic level, moving users, groups and computers from one domain to another appears to be a straightforward task that can be accomplished with ADMT or the likes of Quest's DMW or QMM (depending on whether your source domain is NT 4.0 or Active Directory). After migrating users and groups, any member servers left in the source domain will have their security descriptors updated by the ADMT/Quest tools to include an ACE for the migrated users and groups, in order to maintain access to resources (SID History should be enough, but Quest claim that it often isn't). When the member server is moved to the target domain, the security descriptors are updated again to remove ACEs relating to users and groups from the source domain. Access to files, folders and shares etc is retained by the migrated users and everyone is happy. But what about applications?
Older versions of Sharepoint needed to be updated with details of users' migrated logon credentials (KB896593 and KB896161) which is something that the ADMT and Quest tools do not handle. The Quest toolset does provides a utility to update SQL Server security, but what if I had Oracle, or MySQL or any number of applications hosted on a member server that needed to be moved to a new domain? Is it really a case of examining every application on a case-by-case basis and determining whether application security needs updating, or are examples such as older versions of Sharepoint just corner cases and most of the time, applications will continue to run without issue after migration?
There are other issues to address such as the dreaded in-house written apps with hardcoded domain or server names.
What are your experiences? Was migrating a bunch of application servers a pain, or was it straightforward. Which apps caused the most pain?
Steve G
________________________________
Beyond Hotmail - see what else you can do with Windows Live. Find out more.<http://clk.atdmt.com/UKM/go/134665375/direct/01/>
*** WORLEYPARSONS GROUP NOTICE ***
"This email is confidential. If you are not the intended recipient, you must not disclose or use the information contained in it.
If you have received this email in error, please notify us immediately by return email and delete the email and any attachments.
Any personal views or opinions expressed by the writer may not
necessarily reflect the views or opinions of any company in the WorleyParsons Group of Companies."
*** WORLEYPARSONS GROUP NOTICE ***
"This email is confidential. If you are not the intended recipient, you must not disclose or use the information contained in it.
If you have received this email in error, please notify us immediately by return email and delete the email and any attachments.
Any personal views or opinions expressed by the writer may not
necessarily reflect the views or opinions of any company in the WorleyParsons Group of Companies."
| | | |
| Servernet
Posts:34
| | 06/29/2009 5:33 PM |
|
Thanks for the input, Tyson
Like you, I've been involved with many migrations over the last few years and just wanted to revisit the whole process as a migration with 1000 member servers looms on the horizon. With this volume of servers, the amount of investigation is going to be very significant...and that's before any remediation and testing are factored in. The economics of consolidating what will be about a dozen forests down to a single one is barely justifiable in my view and it is unlikely to pay for itself before the next round of migration takes place!
What have been your problem applications when migrating?
Steve G
From: Tyson.Leslie@WorleyParsons.com
To: activedir@mail.activedir.org
Date: Sun, 28 Jun 2009 23:45:29 -0600
Subject: RE: [ActiveDir] OT: Member Server Migration
It depends on the scope. Most of the migrations have been due to acquisitions, and the priority is to get the newly acquired company ‘on net’ ASAP. If it makes sense to move them to a process or app that the parent company is already using then we do it, but usually the migration timeframe is too short to transition them to a new system. It happens over time, but as part of another project. (Financial systems are at the top of this list.)
From: activedir-owner@mail.activedir.org [mailto:activedir-owner@mail.activedir.org] On Behalf Of Susan Bradley
Sent: June-29-09 12:35 PM
To: activedir@mail.activedir.org
Subject: Re: [ActiveDir] OT: Member Server Migration
Have you compared what the cost/time is to deploy new versus migration?
I know on some of our databases that I'm in charge of, they are so crusty from various upgrades that sometimes installing clean and moving what data we need over in the long run is better. Granted I'm sure my migrations pale in comparison, but whenever we've done LOB migrations, weird stuff travels with the apps that you just never get rid of.
Leslie, Tyson (Calgary) wrote:
This is an area where we’ve found no 3rd party solutions were acceptable.
>> Is it really a case of examining every application on a case-by-case basis and determining whether application security needs updating…?
Yes. (Unfortunately…) This is an incredible time sink, but we’ve found it must be done that way. Typically we’ve written scripts (in-house) to deal with the changes. The worst applications are any that maintain an internal user list, and do not sync against AD. Apps with hard-coded credentials are problematic for different reasons – again, you’ll have to test once you make changes. For apps that maintain relationships between AD accounts and data, those relationships need to be updated to reflect the new accounts. Once you’ve figured out how to change one though, you can typically script it to update the rest.
In the dozens of domain migrations that we’ve done, application testing has always been the biggest area of concern. You can’t underestimate the amount of time it can take to identify and resolve the issues.
Cheers,
Tyson.
From: activedir-owner@mail.activedir.org [mailto:activedir-owner@mail.activedir.org] On Behalf Of Steven Griffiths
Sent: June-24-09 8:29 PM
To: ActiveDir.Org
Subject: [ActiveDir] OT: Member Server Migration
I'm interested in the experience of others with migrating member servers from one domain to another and specifically the impact on installed applications.
At a basic level, moving users, groups and computers from one domain to another appears to be a straightforward task that can be accomplished with ADMT or the likes of Quest's DMW or QMM (depending on whether your source domain is NT 4.0 or Active Directory). After migrating users and groups, any member servers left in the source domain will have their security descriptors updated by the ADMT/Quest tools to include an ACE for the migrated users and groups, in order to maintain access to resources (SID History should be enough, but Quest claim that it often isn't). When the member server is moved to the target domain, the security descriptors are updated again to remove ACEs relating to users and groups from the source domain. Access to files, folders and shares etc is retained by the migrated users and everyone is happy. But what about applications?
Older versions of Sharepoint needed to be updated with details of users' migrated logon credentials (KB896593 and KB896161) which is something that the ADMT and Quest tools do not handle. The Quest toolset does provides a utility to update SQL Server security, but what if I had Oracle, or MySQL or any number of applications hosted on a member server that needed to be moved to a new domain? Is it really a case of examining every application on a case-by-case basis and determining whether application security needs updating, or are examples such as older versions of Sharepoint just corner cases and most of the time, applications will continue to run without issue after migration?
There are other issues to address such as the dreaded in-house written apps with hardcoded domain or server names.
What are your experiences? Was migrating a bunch of application servers a pain, or was it straightforward. Which apps caused the most pain?
Steve G
Beyond Hotmail - see what else you can do with Windows Live. Find out more.*** WORLEYPARSONS GROUP NOTICE ***"This email is confidential. If you are not the intended recipient, you must not disclose or use the information contained in it.If you have received this email in error, please notify us immediately by return email and delete the email and any attachments. Any personal views or opinions expressed by the writer may not necessarily reflect the views or opinions of any company in the WorleyParsons Group of Companies."
*** WORLEYPARSONS GROUP NOTICE ***
"This email is confidential. If you are not the intended recipient, you must not disclose or use the information contained in it.
If you have received this email in error, please notify us immediately by return email and delete the email and any attachments.
Any personal views or opinions expressed by the writer may not
necessarily reflect the views or opinions of any company in the WorleyParsons Group of Companies."
_________________________________________________________________
Share your photos with Windows Live Photos – Free.
http://clk.atdmt.com/UKM/go/134665338/direct/01/
| | | |
|
|