Tom, While I am sure that Rick has some document in which using LMHosts files are identified as a best practice, I can assure you that it is quite feasible to use WINS to accomplish the name resolution requirement for the task at hand: creating an external trust between two domains with different names explicitly for the purpose of migrating client systems from one domain to another. In fact I might suggest that in many cases this is a better approach. The Quest products will rely on name resolution (as well as the trust) in order to migrate users, groups, workstations, server and other resources between domains. This name resolution will in fact be even more important during the migration process if users in one domain will need to access resources in the other domain. The existing WINS environment is already populated with necessary records, and has all the information required to resolve the names of DCs, resource servers, workstations, etc. in the existing domain. Assuming you have administrative control over the WINS server, you can certainly configure WINS replication between a WINS server in the new environment and one in the existing environment - and no, a trust is not needed to make this work as WINS replication (and resolution) is generally unauthenticated.
If you are planning to migrate your WINS servers to the new environment I might argue that the best approach would be to migrate them first (one by one verifying functionality as you go) to the new environment and continue to point both old *and new systems* to the same WINS servers. Of course this assumes, as stated previously, that you have administrative control over the WINS servers. This implementation should avoid the need to use LMHost files or change primary/secondary WINS assignments on migrated systems. This is an approach I have used many times when migrating between forests and between NT4 domains and AD domains. As for migrating without the availability of the root domain, you should be "mostly" OK as the Quest representatives stated. However without the root being accessible and the _mscds DNS domain being unavailable, I would certainly look to accelerate the migration as you should start having replication even within your child domain(s). Regards, Aric -----Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Rick Kingslan Sent: Tuesday, August 09, 2005 9:35 AM To: ActiveDir@mail.activedir.org Subject: RE: [ActiveDir] AD migration Tom, The solution that I gave you is the only one that I know of. If you are able to get DNS to work (doubtful) or are able to get WINS to replicate across a trust that at the present time doesn't exist, more power to you. However, given the trials and tribulations that you have discussed with us over the past couple of weeks - *I* would be looking for the easiest, accepted, maintainable "best practice" method for getting your job done. A piece of personal advice - and you can choose to ignore it or use it - it's free. In your new position, they are looking for results - not the most trick way of doing something. I am sure that the company that has retained your services is being billed for the time that you work to migrate their user base and Exchange to something that they can control. Finding a DNS or a WINS solution when the LMHosts solution is 'best practice' is simply not a good idea. Rick -----Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Tom Kern Sent: Tuesday, August 09, 2005 11:14 AM To: ActiveDir@mail.activedir.org Subject: Re: [ActiveDir] AD migration why can't you just use stub zones or conditional forwarding for this to work? or if NetBT is involved, can you just configure your wins servers to replicate? I thought wins replication had nothing to do with NT security. you just enter the ip of the partner servers... Thanks On 8/9/05, Rick Kingslan <[EMAIL PROTECTED]> wrote: > Really, it uses neither. The NetBT is involved, but because we are on (at > present) untrusted domains and forests, WINS isn't going to work. > > Typically, this is done with an LMHosts file in the \Drivers\ETC directory. > The records are going to be very specific, as they will define the domain of > the target domain, as well as (typically) the PDC for the target. A > 'mirror' LMHosts will be set up on the other trusting side. > > As noted, the format of the records is specific, and can be found here: > > http://support.microsoft.com/kb/180094/ > > And take SPECIAL NOTE that the DOMAIN-NAME records must be EXACTLY as > defined, otherwise they will not work. > > Good luck - it's not daunting, but can be tedious to get working the first > time. > > Rick > > -----Original Message----- > From: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED] On Behalf Of Tom Kern > Sent: Tuesday, August 09, 2005 5:58 AM > To: ActiveDir@mail.activedir.org > Subject: Re: [ActiveDir] AD migration > > Sorry to keep harping- but if you have a trust between a child win2k > domain in one forest with a root or child domain in another forest, > does this use wins or dns. > i know this is not a "real" forest trust and more like an external > trust in that its not transitive and uses ntlm and NOT kerberos, but > does it also relie on wins/netbios like an old NT-style trust? > > thanks > > On 8/8/05, Tom Kern <[EMAIL PROTECTED]> wrote: > > I just started today so what I got was- > > they have connectivity to the child dns server but they cut off > > connectivity to anything in the root domain. > > the firewall is blocking all root traffic. > > this has been like this for a week. > > nothing is replicating to the root and there is no access to the _msdc > > forest zone. > > > > The forest is win2k native with an empty root and 1 child domain in a > > seperate tree. > > they have DA access in the child domain but no DA/EA access in the root. > > all the exchange servers(about 10) are in the child domain. > > the only recipent policy in the root is the default one and the enterprise > RUS. > > > > > > They want to migrate the child domain and all the resources to a new > > forest where we have full control of everything. > > i assume we do not need connectivity to the _msdc forest dns zone to > > create a trust with the old child domain to migrate everything over(or > > anything in the root dns zone). > > > > I'm not 2nd guessing the Quest guys, this is only for my own education. > > > > Thanks a lot > > > > > > On 8/8/05, Medeiros, Jose <[EMAIL PROTECTED]> wrote: > > > I am sure Quest's consultant's knows what they are doing. Didn't you > have them put a quote and migration plan together prior to the actual > migration? Or are you asking these questions because you are second guessing > them? Or is this just for your own knowledge? > > > > > > My understanding is that both domain names have to be different when > using ADMT to migrate from a Source Domain to a Target Domain, unless Quest > has a tool that over comes this that I am not aware of. Are you trying to > keep the same domain name as the source? Microsoft also has a free tool that > will allow you to rename the traget 2003 AD domain as after you have > completed your migration and decommissioned old DC's. > > > > > > Jose > > > > > > -----Original Message----- > > > From: [EMAIL PROTECTED] > > > [mailto:[EMAIL PROTECTED] Behalf Of Almeida Pinto, > > > Jorge de > > > Sent: Monday, August 08, 2005 2:46 PM > > > To: ActiveDir@mail.activedir.org; activedirectory > > > Subject: RE: [ActiveDir] AD migration > > > > > > > > > What do you mean with "In fact, they are cut off from the root domain > pyhsically. "? Do you mean as in there is not replication between the two > domains? If yes... dare I ask for how long? > > > > > > As I know of you can migrate the child domain without the root being > available because you will be having a trust between the new domain and the > child domain > > > > > > I still don't understand what you mean... They are cut off from the root > and the DNS is avlable in the root. I must be missing something. Can you > explain a bit more? > > > > > > Jorge > > > > > > ________________________________ > > > > > > From: [EMAIL PROTECTED] on behalf of Tom Kern > > > Sent: Mon 8/8/2005 11:08 PM > > > To: activedirectory > > > Subject: [ActiveDir] AD migration > > > > > > > > > > > > I just started working for a company. they used to outsource their > > > AD/Exchange but now they're trying to get it back. > > > > > > Its a 2 tree, 2 domain forest. the root domain is empty. > > > this company only has DA access on the child domain. No EA access. In > > > fact, they are cut off from the root domain pyhsically. > > > > > > What they want to do is create a new forest and migrate all > > > users,exchange,computers,etc to the new forest and be done with the > > > old. > > > They are going to use Quest sw and a consultant from Quest for this. > > > > > > My question is- can this be done without any connectivity to the root? > > > both dns zones are in the root so they really don't have any dns > > > locally as well(needless to say, you cam imagine what the rep logs > > > look like). I'm sure this complicates matters. > > > however, the Quest people seem to think this can still work. > > > can it? > > > > > > also, can the new forest have the same domain names as the old one? > > > > > > Thanks(I'm the guy who posted about his new job jitters about a week > > > or 2 ago, and here i am. Their AD is more messed up than I thought :) > > > ) > > > List info : http://www.activedir.org/List.aspx > > > List FAQ : http://www.activedir.org/ListFAQ.aspx > > > List archive: > http://www.mail-archive.com/activedir%40mail.activedir.org/ > > > > > > > > > > > > This e-mail and any attachment is for authorised use by the intended > recipient(s) only. It may contain proprietary material, confidential > information and/or be subject to legal privilege. It should not be copied, > disclosed to, retained or used by, any other party. If you are not an > intended recipient then please promptly delete this e-mail and any > attachment and all copies and inform the sender. Thank you. > > > List info : http://www.activedir.org/List.aspx > > > List FAQ : http://www.activedir.org/ListFAQ.aspx > > > List archive: > http://www.mail-archive.com/activedir%40mail.activedir.org/ > > > > > > List info : http://www.activedir.org/List.aspx > > > List FAQ : http://www.activedir.org/ListFAQ.aspx > > > List archive: > http://www.mail-archive.com/activedir%40mail.activedir.org/ > > > > > > List info : http://www.activedir.org/List.aspx > List FAQ : http://www.activedir.org/ListFAQ.aspx > List archive: http://www.mail-archive.com/activedir%40mail.activedir.org/ > > List info : http://www.activedir.org/List.aspx > List FAQ : http://www.activedir.org/ListFAQ.aspx > List archive: http://www.mail-archive.com/activedir%40mail.activedir.org/ > List info : http://www.activedir.org/List.aspx List FAQ : http://www.activedir.org/ListFAQ.aspx List archive: http://www.mail-archive.com/activedir%40mail.activedir.org/ List info : http://www.activedir.org/List.aspx List FAQ : http://www.activedir.org/ListFAQ.aspx List archive: http://www.mail-archive.com/activedir%40mail.activedir.org/ List info : http://www.activedir.org/List.aspx List FAQ : http://www.activedir.org/ListFAQ.aspx List archive: http://www.mail-archive.com/activedir%40mail.activedir.org/
