SFN 5.03 File Migration Utility Reports Forest Unavailable

[Guest 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

[Guest Ryan Hanisco]

RE: SFN 5.03 File Migration Utility Reports Forest Unavailable

 

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

>

[Guest Peter]

RE: SFN 5.03 File Migration Utility Reports Forest Unavailable

 

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

[Guest Keith L. Schneider]

Re: SFN 5.03 File Migration Utility Reports Forest Unavailable

 

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

>>