How to integrate a network; share resources

Question

An engineering department has been running its own network for years with a NovellNetware server using IPX/SPX protocol.All 25 client computers are running windows XP Professional.This network is running a hub-based Eternet 10 base T implementation that is physically seperated from the campus network.How do i bring this department into the main campus Network with as little disruption as possible to its current operation.The campus network was windows 2003 server domain configuration and windows XP professional client computers using TCP/IP Microsoft.how do i develop a plan that allows client from the engineering department network to access resources on the main campus network.

Answer 1

Your users are going to get disrupted, there is no way around that. They're far enough behind the curve when it comes to accepted practice with respect to fileservers that their internal user practices are going to have to accommodate change. That is never an easy thing to tell groups of users, especially quasi-independent ones that can cause political trouble; this is likely the very reason they've stayed that out of date.

Some things you can use to help them accept this change is needed:

• NetWare support ended a couple of years ago.
• WinXP support ended a couple of years ago.
• Novell itself deprecated IPX support over a decade ago, and didn't bother porting it to Linux when they created Open Enterprise Server.
• IPX support is still baked into switches, but probably won't survive the jump to software defined networking.

Given all of that, if they ever need more resources for something (more disk-space for instance) they're going to have an increasingly hard time integrating it in. They may need such a "migration event" to get over the hump.

---

That said, I've been on campus networks before. You said 'engineering' and that made me twitch. One of the science departments I used to work with paid for a Very Expensive Thing with grant money back in 1998, and it only spoke IPX. Said VET resisted all of our efforts to get it to talk IP. When the Networking group wanted to turn off IPX support in the core, they worked with this science department to create a bastion host that was connected to the campus network and an island network the VET and a stand-alone NetWare server were inhabiting.

That system is still running that way. The instrument is still scientifically useful, but how it talks to network isn't and there isn't an upgrade. So we had to make accommodations. Be sure you're not running into a VET yourself before dragging that department into the future.

If you do have an IPX-only VET on your hands, what we did to deal with it was this:

• Create a stand-alone NetWare server for it to drop its data onto.
• Create a dual-homed WinXP box, with one NIC on the IP-based campus network and another NIC on the IPX VET-net.
• Put the dual-homed WinXP box behind a hardware firewall to minimize it's exposure to evil.
• Build user processes for accessing the data by the WinXP box and transferring it to the Windows fileservers for chewing

Or if the firewall approach won't pass security, the USB-stick tango can work almost as well.

---

If there isn't a Very Expensive Thing keeping them in the past, then it's just inertia and political will keeping them back there. Overcoming both of those is going to be a political task, and I realize it will be made easier if you can offer a solution that is just, "exactly what you're doing right now, but running on Windows."

I'm afraid that is not going to be possible. NetWare and Windows are completely different in their approach to file access-controls and anyone used to how NetWare does it will have to be retrained in the Windows way, there is no getting around it. You will not be able to offer an, "exactly the same but with different icons" solution.

You're going to have to figure out a way to get them to accept some change. That kind of thing is beyond the scope of ServerFault (though may be topical over on workplace).

---

Moving from NetWare to Windows is something that has been going on since the NT4.0 days, and Microsoft keeps making it easier. Windows 2008R2 is probably the most NetWare-like Windows release, so if you can move to that, great. There are a lot of migration guides around for making this transition.

The biggest pain-point is going to be in file and directory access controls.

• MS-style doesn't have the concept of pass-through rights, where a read-right assignment three deep in a directory structure makes the two parent directories visible and allows that three-deep directory to be browseable from root.
• MS-style doesn't have the concept of the Inherited Rights Filter
• MS-style rights don't map one-to-one with NW-style rights.

The first point there caused us a huge amount of change when we made the switch. Like most NetWare people we granted zero rights to the root of the volume and only granted read or read/write rights to sub-directories. This followed Novell best-practice as we granted only the rights users needed, where they needed them, and the system just did it.

\\server\volume\department\division\directory

We'd grant rights on that terminal 'directory' which would make 'department' visible at the top of the volume and have a sub-directory named 'division'. Microsoft doesn't work that way. It can be made to work, but it's a lot of extra work on the admin staff doing unconventional NTFS things that are easy to screw up. We ended up coming up with a different way to lay out the directories completely, which really messed with our end-user's internal procedures.

The Inherited Rights Filter thing was used by us in a bunch of areas. We dealt with it by specifying such IRF points in the directory tree to be MS-style 'don't inherit from parent' points, which doesn't behave the same way but is as close as you're going to get in MS-land. Identify IRF usage in your volumes so you don't get surprised.

Rights-mapping... I had a translation-guide written up for that old job, but I'm afraid it's lost to time right now. We even had a script that took TRUSTEE.NLM dumped permissions to build the equivalent xcacls calls (no, I don't have that script anymore, don't ask). Microsoft does things in simplified, Read + Read/Write + FullControl ways, but Novell allowed more flexibility. Identify places in your directories where people got flexible so you won't be surprised, and work on ways to make the intent of the rights work within NTFS.

---

The final technical point, ensure you turn on Access Based Enumeration on your Windows shares. It presents users with a NetWare-like directory structure where directories only show up if a user has explicit rights to view or do anything with it. By default, Windows shows ALL directories; our users sure as heck weren't used to seeing a "Faculty-Shared" volume with 200 directories in it 196 of which they get an access-denied error if they click into.