SFN 5.03 File Migration Utility Reports Forest Unavailable

[Peter]

I am attempting to perform a migration from a Novell Netware 6 environment
to Windows Server 2003 R2 using Microsoft Services For Netware(SFN) 5.03
SP2. The Windows servers have the latest patches and SFN is running on a
domain controller with Novell Client for Windows 4.91 SP3.

The Microsoft Directory Synchronization Service(MSDSS) installed properly,
migrated Netware accounts to Active Directory(AD) OUs and continues one-way
synchronization without issue.

When attempting to use the File Migration Utility(FMU) to transfer files and
permissions from Netware to a Windows 2003 server, the FMU indicates that
the forest is "unavailable" in the Active Directory target selection window
of Step 3.

The FMU is being run on a Windows 2003 Domain Controller(DC) that is not
having any issues what-so-ever. The share is published in Active Directory
and Explorer searches for AD shares from the FMU server return all of the
published shares.

I have searched extensively for a solution and, although I have found other
reports of this issue, I have yet to find any solution. Has anyone else
seen this behavior and is there a resolution?


Thanks in advance,

Peter

 

[Ryan Hanisco]

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 Hanisco
MCSE, MCTS: SQL 2005, Project+
Chicago, IL

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


"Peter" wrote:

> I am attempting to perform a migration from a Novell Netware 6 environment
> to Windows Server 2003 R2 using Microsoft Services For Netware(SFN) 5.03
> SP2. The Windows servers have the latest patches and SFN is running on a
> domain controller with Novell Client for Windows 4.91 SP3.
>
> The Microsoft Directory Synchronization Service(MSDSS) installed properly,
> migrated Netware accounts to Active Directory(AD) OUs and continues one-way
> synchronization without issue.
>
> When attempting to use the File Migration Utility(FMU) to transfer files and
> permissions from Netware to a Windows 2003 server, the FMU indicates that
> the forest is "unavailable" in the Active Directory target selection window
> of Step 3.
>
> The FMU is being run on a Windows 2003 Domain Controller(DC) that is not
> having any issues what-so-ever. The share is published in Active Directory
> and Explorer searches for AD shares from the FMU server return all of the
> published shares.
>
> I have searched extensively for a solution and, although I have found other
> reports of this issue, I have yet to find any solution. Has anyone else
> seen this behavior and is there a resolution?
>
>
> Thanks in advance,
>
> Peter
>

 

[Peter]

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

 

[Keith L. Schneider]

Ryan, I would be greatly interested in your "tools" to build the 1.txt files
without MSDSS as I'm working on a migration in an environment that AD and
eDirectory are already synced with DirXML.

-Keith

nospam_kschneider@coleman.com

"Ryan Hanisco" <RyanHanisco@discussions.microsoft.com> wrote in message
news:A1109CC8-BD07-4C10-8789-2DBDE3C431C9@microsoft.com...
> 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 Hanisco
> MCSE, MCTS: SQL 2005, Project+
> Chicago, IL
>
> Remember: Marking helpful answers helps everyone find the info they need
> quickly.
>
>
> "Peter" wrote:
>
>> I am attempting to perform a migration from a Novell Netware 6
>> environment
>> to Windows Server 2003 R2 using Microsoft Services For Netware(SFN) 5.03
>> SP2. The Windows servers have the latest patches and SFN is running on a
>> domain controller with Novell Client for Windows 4.91 SP3.
>>
>> The Microsoft Directory Synchronization Service(MSDSS) installed
>> properly,
>> migrated Netware accounts to Active Directory(AD) OUs and continues
>> one-way
>> synchronization without issue.
>>
>> When attempting to use the File Migration Utility(FMU) to transfer files
>> and
>> permissions from Netware to a Windows 2003 server, the FMU indicates that
>> the forest is "unavailable" in the Active Directory target selection
>> window
>> of Step 3.
>>
>> The FMU is being run on a Windows 2003 Domain Controller(DC) that is not
>> having any issues what-so-ever. The share is published in Active
>> Directory
>> and Explorer searches for AD shares from the FMU server return all of the
>> published shares.
>>
>> I have searched extensively for a solution and, although I have found
>> other
>> reports of this issue, I have yet to find any solution. Has anyone else
>> seen this behavior and is there a resolution?
>>
>>
>> Thanks in advance,
>>
>> Peter
>>