RE: ADMT (file permissions, log files, and clustering)

Tech Tip: Click here to run a free scan for Windows Errors and optimize PC performance

Patrick,

I cna understand being bitter about that, but AD migrations always run into
those kinds of issues.

With the data migrations, it goes a lot like the workstation migrations.
You will want to rank and prioritize your servers though. There are some
that you can just let the wizard move and do the security translation. On
mission critical ones, you will want to do those one at a time. The last
thing you need if for something stupid to happen and then you have to worry
about MANY mission critical systems screwed up at once..

With the clusters, this isn't as hard as it might seem with a File server
cluster. (Printers are easy too -- you use the printmig utility to back them
up and you can move them from there.) You jsut get to play the shuffle game
with the file servers. Remember though that they are pointing to the same
file space on the SAN so you'll not have to do the security translation.
You'll just want to migrate it one node at a time, with the others down.
Usually the cluster node have no problem finding one another once they are
back online, but you may have to restart the cluster service or reconnect to
the quorem resource.

Hope this helps.
--
Ryan Hanisco
MCSE, MCTS: SQL 2005, Project+
Chicago, IL

Remember: Marking helpful answers helps everyone find the info they need
quickly.


"Patrick F." wrote:

Thanks for the info Ryan! I appreciate it. I have a couple of clarification
points as requested.

Regarding the general process for migration. The users, groups and
workstations have already been moved using the ADMT and the process went very
well [except of course for those user who a) work in a locked office and b)
did not leave their workstation up and running as we requested in numerous
emails before we did the work! Bitter? me? nah! :^]. This last step is
just the data.

Regarding the cluster, luckily it only contains files and file shares - no
printers or SQL servers. But my question still stands - I know that during
the workstation migration, if there was a hangup on a single workstation the
process did not stop. I wanted to be sure that the same was true for the
server migration. Specifically the process of moving the data permissions
from one domain to the other. Or am I misreading the ADMT process itself?

Thanks again!

"Ryan Hanisco" wrote:

Patrick,

I'll answer your questions by number (paint by number??) so this doesn't get
all jumbled. This is a fairly involved process. You'll want to test things
thoroughly and make sure you have resolved all domain problems before you
start.

1. When doing a large migration like this, you don't want to do it all in
one shot. Remember that an intra-forest migration is a move, not a copy so
there is no net to fall back on. When I do these, I like to move the users
and groups, then the workstations, and finally the resources. If you have a
lot of each, then break them up into groups.

You will also want to identify a pilot group for each of the three types of
resources -- maybe even ones that you created just for the test to make sure
you have the process down. You DO NOT want to do this in a single hit over
night or over a weekend unless you are very comfortablewith the process, have
done several test groups, and have little other choice. By default, the
process will continue to run for the whole set that you specified and will
migrate the objects that it can and leave the others.

2. I have never had a problem with FSMigrate, but usually I can get
everything I need done with careful planning and the ADMT tools.

3. The issues involved in migrating the clusters will depend on what is
running on the cluster. I am sure you can understand that a SQL cluster will
be different from an Exchange cluster which is different from a MOSS
cluster... I can help you with everything except Exchange; I have never had
to move an exchange cluster before.

Hope this helps. Post back with more cluster info and I'm sure there will
be robust discussion. <smirk>
--
Ryan Hanisco
MCSE, MCTS: SQL 2005, Project+
Chicago, IL

Remember: Marking helpful answers helps everyone find the info they need
quickly.
.

Relevant Pages

  • RE: ADMT (file permissions, log files, and clustering)
    ... Remember that an intra-forest migration is a move, ... I am sure you can understand that a SQL cluster will ... be different from an Exchange cluster which is different from a MOSS ... The NOS running on all servers and the DCs is Win2003 ...
    (microsoft.public.windows.server.active_directory)
  • Re: Migrating from old cluster to a new one
    ... Interesting timing - I will be leaving for work in about an hour to begin our migration to a brand new cluster. ... For me, the simplest option is a straight backup/restore, since our new servers are also on a new SAN. ... Run the application install for the current version of the application (builds default databases and CLR components) ...
    (microsoft.public.sqlserver.clustering)
  • RE: ADMT and Clustered Servers
    ... Thanks once again for the information Bob. ... You can migrate the cluster server after you ... > sure at this point what we will do in terms of our migration project. ... >> other servers, computers and users to get the job done, and if so, ...
    (microsoft.public.windows.server.migration)
  • Re: Migrating File Storage Cluster
    ... File Server Migration Wizard will treat the source cluster as ... share' from the shares created by 'Share Subdirectories' option on clusters. ...
    (microsoft.public.windows.server.migration)
  • Re: Netware is no VMS
    ... >>What new features do you believe are needed above what's already in the ... not something like process migration ... >>between cluster nodes), and valuable. ... OS noticing that there was such a major problem it's only solution was to crash ...
    (comp.os.vms)