Novell to Windows Server 2008 Migration

[Myke 0]

We're starting to plan a migration from Novell NetWare 6.5 to Windows Server 2008. While we currently use the NDS in NetWare, we have no need to migrate it over to AD, as we have a separate server using AD; we've had a 2 system authentication for many years. All we plan to do is to migrate the file server role to a new server, complete with rights and hierarchial structure.

 

From what I can tell, there isn't any real way to migrate from NetWare to Windows Server 2008. Instead, I have to migrate to Server 2003, then migrate from 2003 to 2008.

 

The problem we're running in to is that there doesn't seem to be any documentation on simply migrating only the file server role, as mentioned above. Everything deals with migrating NDS to AD, then migrating files with permission and the likes.

 

Does anyone have any experience, suggestions, or hints to throw my way in hopes to ease the process? My mind is going numb from pouring over pages of technical documentation which doesn't seem to fully apply to our scenario. Any help would be greatly appreciated. As always, thanks in advance.

[sunroi77 0]

We're in a similar situation, switching from Novell to Server 2008. Our setup is very basic; all we will be using under 2008 is file services (and of course AD and all that entails).

 

As of now I haven't found anything that will let me migrate the file server role directly from NDS to 2008. If I don't find any such tool, I will probably just use robocopy to copy all the file server data to the 2008 file server ... and then use robocopy daily to do "incremental" copies leading up to the day of the actual cut-over. All while creating global groups etc manually on the 2008 AD.

 

More info on Robocopy here:

http://technet.microsoft.com/en-us/magazine/2006.11.utilityspotlight.aspx

 

We do have the advantage of having relatively few users and groups, otherwise this manual approach wouldn't really be feasible.

[Myke 0]

Will Robocopy work within the Novell environment? I considered just performing a restore job with a file redirection to the new server, but the folder/file attributes associated with the backup would be tied to the NDS and not our current AD structure.

 

That being said, we're considering just copying all the files to the new file server (via GB connection on a weekend when we know for certain that all files will be closed) and then manually setting permissions based on groups. Afterwards, I'll spend the next month or so having users hit me up to grant them access when needed.

 

Another thing to note in our environment is that when connecting to a drive that is mapped to a Novell directory, the connection is instantaneous. Contrary, connecting to a drive that is mapped to a Windows directory on a different server always seems to have a delay, which is just going to have users complaining on a daily basis. We're toying with the File Server Role on the Windows Server 2008 to see if we can't speed up that initial connection. Anyone have any hints/tips on how to enhance this?

[sunroi77 0]

Originally Posted By: Myke

Will Robocopy work within the Novell environment?

My approach is to log on to a Windows XP workstation which has the Novell client installed. Authenticate to Novell & map a drive to the appropriate Novell directory; then map a drive to the 2008 server share. Then run robocopy on the workstation to copy from the one mapped drive to the other. The advantage of this method is that once you work out the correct robocopy switches, you can put them in a batch file and schedule it to run daily.

[Myke 0]

Rock on. Thanks. I'll look into that method. Much appreciated, man.

[rosebwl1 0]

Originally Posted By: sunroi

Originally Posted By: Myke

Will Robocopy work within the Novell environment?

My approach is to log on to a Windows XP workstation which has the Novell client installed. Authenticate to Novell & map a drive to the appropriate Novell directory; then map a drive to the 2008 server share. Then run robocopy on the workstation to copy from the one mapped drive to the other. The advantage of this method is that once you work out the correct robocopy switches, you can put them in a batch file and schedule it to run daily.

Hello:
We're trying to go through this migration using MSDSS, but, with our environment, may not work due to needing IPX, and Router not allowing that anymore.
I haven't ventured into Robocopy and was wondering what switches worked for you?
Did you manually create similar workgroups from NDS into AD, and manually match up the permissions? That's a lot of work.

Thanks.

[Myke 0]

Does anyone have good experience using Microsoft Directory Synchronization Services (through Windows Services for NetWare 5.x)? We're hoping that we could use MSDSS to map our current NDS and AD together, which would make migration so much easier. Again, most of the documentation I've come across involves creating a brand new AD from the existing NDS.

 

The problems we're running in to right now is rights management. NTFS permissions are too restrictive and don't function as smooth as NDS permissions. For instance, if a user needs access to a particular folder (\\novell_server\folder1\folder2\folder3), giving the proper NDS permissions to folder3 allows the user to see folder1 (with only folder2 being displayed), folder2 (with only folder3 being displayed), and folder3 (with all contents of folder3 being displayed). NTFS permissions do not allow this, or at least we cannot figure out how to allow this.

 

It is our hopes that by mapping our current NDS to our current AD that we can transfer all data from the Novell server with proper rights over to a Windows Server 2003 x64 file server, then upgrade that server to Windows Server 2008 x64; either that or just then transfer files from 2003 to 2008. As said before, it does not appear that there are any tools for migrating from Novell to Windows 2008.

[Myke 0]

Finally figured this whole mess out. After calling Novell (who directed me to Microsoft) and Microsoft (who said that a tool did not exist which would allow me to do what I wanted), I took a completely separate approach to the problem: I used RichCopy to transfer all the files from Novell to Windows Server 2008; from there, I had to manually setup the NTFS permissions, but with one key component here: Access-Based Enumeration (ABE). Without enabling ABE on the Share itself, you won't get anywhere.

 

I ran into a huge problem here. As I said in my last post, I was trying to allow a user/group access to a particular subfolder, but was having massive problems displaying the paths for the user to get to without showing every single folder/file leading to it.

 

What I did was granted Everyone full-control rights to the root share. From here, I removed the permissions from every folder in that root, granting access only to SYSTEM and admins. I then granted permissions to specified groups for their appropriate folders. That was the easy part.

 

The hard part was diving down about 4 subfolders deep to a particular folder that a user/group needed access to, and only that folder. Here's what I had to do:

 

1. For the target folder, open up the properties, go to the Security tab, open up the advanced security settings, add the user, give them proper permissions, and apply it to the folder/subfolders/files.

 

2. Go to the target folder's parent folder, enter the advanced security settings, add the same user/group from Step 1, give them the following settings while only applying it to "This folder only:"

- List folder / read data

- Read attributes

- Read extended attributes

- Read permissions

 

3. You have to repeat step 2 until you get all the way up to the main folder under the share root.

 

When you test it out, the user/group can now see the main folder under the root. When they open that folder, they can only see the next folder, and the next, and next, all the way until they reach the folder they have been granted access to.

 

This is much more annoying than Novell, but through the process, I can see that being this restrictive can definitely have its benefits in the long run. The initial setup is going to be amazingly tedious work, however.

 

Hopefully this is helpful to someone out there besides just me. Thanks to anyone that threw tips out in my direction.