Guest Peter Posted July 9, 2007 Posted July 9, 2007 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 Posted July 10, 2007 Posted July 10, 2007 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 Posted July 10, 2007 Posted July 10, 2007 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 Posted July 10, 2007 Posted July 10, 2007 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 >>
Recommended Posts