Ryan Hanisco wrote:
> Peter,
>
> The FMU is one of my favorite tools... though it can be a bit screwy. If
> you've made it this far, you've already made it through the schema
> extensions and all that jazz.
>
> Here are some hints that should help you through your issue here (and some
> other to hopefully make this less painful):
> 1. While the FMU will run on a workstation, it will not find all the
> resources. You must run it from a DC. This means you have the NW client
> on the DC, which seems annoying when you are trying to get rid of NW, but
> hey,
> you've got no other choice. Just don't do it on your only DC. It can
> screw
> up the TCP/IP stack or worse on uninstall. I usually install a temp DC to
> be destroyed rather than have a tainted DC in the mix.
>
> 2. Make sure you can find the source and target through both DNS, Netbios
> and SLP. This shouldn't be a big deal, but make sure you can contact your
> SLPDA as well as having the right DNS records. For the Windows file
> server, make sure that DC can find it -- if it is off segment, that means
> WINS or lmhosts.
>
> 3. It may sound stupid, but make sure you have permissions to the source
> and
> destination locations. This also means setting the share permissions not
> just the file permissions.
>
> 4. Make sure you have stopped backup jobs and antivirus that will slow
> the copy.
>
> 5. Make sure you have the NIC speeds set to the fastest they can reliably
> go. If you have them connected to the same switch make sure they are at
> least 8 ports apart so they'll use different ASICs. (OK, there are two
> models of server-class blades for the 6500 chassis that don't have this
> issue, but they are expensive and most people don't have these.)
>
> 6. Make sure you have the capacity to handle the potential decompression
> of the NW volume.
>
> 7. The FMU has some limitations... it cannot handle paths including the
> file name longer than 256 characters and will ignore them. It also can
> fail
> on files larger than 2GB. Look for these files before the migration... or
> you'll have to start over. The tool can also die if you are copying from
> multiple source volumes, but this is dependent on source speed.
>
> 8. Remember that if your server is older the copy process can be slow. I
> had a 73GB volume take 19 hours once. Plan for this.
>
> 9. Remember there are no real do-overs. You can't do a differential
> later.
> You'll have to move the whole thing again and you don't want there to be
> an
> issue where you have no idea where it stopped and overwrite new content.
>
> 10. In case there are manually mapped drives out there, unmount the volume
> once it is moved so that people can't get to it. Otherwise you'll be
> sorting
> through file changes and versions for weeks. (Remember dropping the
> sysvol has other impacts...)
>
> I hope this helps. There really isn't much out there for people wanting
> to
> use the FMU and Microsoft tools. (I even wrote tools to build the 1.txt
> files without doing the migration with MSDSS.) If you continue to run
> into
> problems, please let me know. I'll watch this post.
Ryan,
Thanks very much for responding and for providing such a detailed post. Your
instructions accurately detailed steps that I have already taken or had
planned to take when I reach that point. Much of your instructions address
performance however, my issue is specifically with the File Migration
Utility(FMU) listing the forest/domain as "unavailable". It does not
display any machines in the target selection window.
My setup is using a DC with a global catalog and Novell Client for Windows
4.91 SP3 that was purpose built for this migration. This DC will be demoted
and removed after the migration is complete. Its sole purpose is MSDSS and
the FMU.
The target shares were shared and then published with Computer Manager. The
permissions on both the shares and NTFS have been set to allow full
control. The shares were also published in AD using Active Directory for
Users & Computers, which does not display the shares published by Computer
Manager. An oddity that I had not noticed before. All shares, regardless of
how they are published can be viewed and accessed when searching Active
Directory with Explorer on the migration server.
The network is using DNS and WINS and they are properly configured. Name
resolution has been tested from the migration DC and from the target server
using ping by name, ping by domainname and ipconfig /displaydns for DNS
testing, as well as nbtstat -a name and nbtstat -c for NetBIOS/WINS
testing. There does not seem to be any issues with name resolution.
SLP has also been tested and found to be configured and working correctly.
Although, the issue is not with Novell but with listing the forest/domain
on the target side of the migration.
Microsoft kb316094 indicates that my issue, or one exactly like it, was
resolved with the release of Services For Netware(SFN) 5.02 SP2. However, I
am using the latest/newer version available from Microsoft, 5.03 SP2. I am
unable to find the older 5.02 SP2 version and remain unable to resolve this
issue.
The problem remains. On the target selection screen of the FMU the
Forest/Domain is listed as "unavailable" and I am unable to continue.
Thanks for your help.
Peter