In this Chapter
For many organizations with Novell Networks in their environments there seems to be one of two pretty common scenarios. The organization is looking to integrate Windows Active Directory more tightly with Novell eDirectory and NDS, or the organization is looking to eliminate Novell in place of a full Windows environment. This chapter will highlight the tips, tricks, and best practices to accomplish both a better integrated Microsoft/Novell environment, as well as ways to replace Novell networking with a Microsoft-centric environment.
Services for NetWare (SFNW) is a US$150 add-on available from Microsoft that provides a series of tools that help organizations integrate and migrate Novell and Microsoft networks. Surprisingly, very few organizations are even aware that the product exists; however, when working in a co-existence environment, or even considering migrating from NetWare to Windows, the SFNW can greatly assist an organization with the task.
SFNW provides organizations with the tools to integrate or migrate Novell users and resources to Windows environments. SFNW provides the following tools:
SFNW
To run SFNW on a Windows Server 2003 system, you must run version 3.5 or higher. SFNW v3.0 will only run on a Windows 2000 Server system
Integration of a Windows environment with Novell network operating systems is simplified through the use of Gateway Services for NetWare (GSNW). Gateway Services for NetWare is an integration product that allows Windows Server 2003 systems to provide a bridge to Novell NetWare server resources. GSNW provides for the following functional elements:
Windows client access to file and print services on NetWare servers
NetWare client service access to Windows file and print servers
Specific scenarios for GSNW include the following:
A Windows Server 2003 or Exchange server requires direct access to NetWare File or Print Services.
One circumstance in which this service would be required is the extraction of NetWare accounts from a server or the source extraction of accounts from a NetWare-hosted messaging system such as GroupWise.
A company is migrating desktop clients from a Novell-based network to a Microsoft Windows Server 2003 network.
The Microsoft-based clients that have been migrated over and no longer belong to the Novell network but require access to NetWare resources can access the NetWare resources through GSNW.
File and Print Services for NetWare is a back-end service that allows a Windows server to emulate a NetWare 3.12–compatible File and Print Server. NetWare clients can connect to the file and printer shares as if they were connecting to a Novell server. Novell clients use the same user interface to access file and printer resources running on an FPNW server. Essentially, FPNW allows an FPNW server to spoof an existing NetWare server after it has been retired, allowing you the time to gradually migrate desktops over to the Windows environment.
Specific scenarios for FPNW would include the following:
A company needs to retire an aging Novell 3.12 server without having to make any network configuration changes to the NetWare desktop clients. The Windows Server 2003 running FPNW would be configured with the same File and Print Services as the Novell 3.12 server.
A company is migrating from a Novell-based network to a Microsoft Windows Server 2003 network. During the migration, Novell-based clients that have not yet been migrated over to the Windows Server 2003 network can access the File and Print Services that have already been migrated over to Windows Server 2003 through FPNW.
Microsoft Directory Synchronization Services (MSDSS) is a tool used for synchronization of directory information stored in the Active Directory and Novell Directory Services (NDS). MSDSS synchronizes directory information stored in Active Directory with all versions of NetWare; MSDSS supports a two-way synchronization with NDS and a one-way synchronization with Novell 3.x bindery services.
Because Active Directory does not support a container comparable to an NDS root organization and because Active Directory security differs from Novell, MSDSS, in migration mode only, creates a corresponding domain local security group in Active Directory for each NDS organizational unit (OU) and organization. MSDSS then maps each Novell OU or organization to the corresponding Active Directory domain local security group.
MSDSS provides a single point of administration; with a one-way synchronization, changes made to Active Directory will be propagated over to NDS during synchronization. Synchronization from Active Directory to NDS allows changes to object attributes, such as a user’s middle name or address, to be propagated. In two-way synchronization mode, changes from NDS to Active Directory require a full synchronization of the object (all attributes of the user object).
One of the key benefits to MSDSS is password synchronization. Passwords can be administered in Active Directory and the changes propagated over to NDS during synchronization. Password synchronization allows users access to Windows Server 2003 and Novell NDS resources with the same logon credentials.
The MSDSS architecture is made up of the following three components. These components manage, map, read, and write changes that occur in Active Directory, NDS, and NetWare bindery services:
The configuration of the synchronization parameters is handled by the session manager.
An object mapper relates the objects to each other (class and attributes), namespace, rights, and permissions between the source and target directories.
Changes to each directory are handled by a DirSync (read/write) provider. Lightweight Directory Access Protocol (LDAP) is used for Active Directory calls and NetWare NCP calls for NDS and NetWare binderies.
In addition to the core components of MSDSS, the session configuration settings (session database) are securely stored in Active Directory.
Specific scenarios for MSDSS would include the following:
A company is migrating directly from Novell to a Windows Server 2003 network. All network services such as DNS, DHCP, and IIS services are running on a single server. MSDSS can be used to migrate all users and files over to Windows Server 2003 after all services have been migrated.
A company is gradually migrating from Novell to a Windows Server 2003 network. The network services such as DNS, DHCP, and IIS are installed on multiple servers and sites. MSDSS can be used to migrate and synchronize AD and NDS directories during the migration.
The File Migration Utility is used to manage the migration of files from NetWare File and Print Servers to Windows Server 2003 systems automatically.
Integrated with MSDSS, FMU copies files while preserving the permissions and access control lists (ACLs) associated with each file. FMU copies the file permissions using a user-mapping file that matches an NDS user account with an Active Directory account. Through this mapping file created with MSDSS, files and the rights inherited or assigned in NetWare are calculated and maintained in the Windows network, preserving security and minimizing the time-consuming process of reassigning file rights and permissions. Without the mapping file, FMU will assign file permissions on all migrated files to the administrator.
Besides using a tool like SFNW, organizations have found other methods of bridging the gap between a Novell and Microsoft environment. The best solutions for choosing to integrate or cross support Novell and Windows environments is to determine what applications are desired to be shared.
If there is an equal split between applications that have to run on Windows and applications that have to run on Novell, then an organization has to create a tightly integrated multi-platform environment. However many organizations remain in a tightly integrated dual operating system environment when there are other options to address specific application access across platforms.
The most common method of multi-platform access and integration is to have both the Novell client and the Windows client installed on each client system. This dual client approach provides users the capability to access Novell servers and resources as well as Windows servers and resources. The simplicity for many organizations is that their client systems already support the dual client configuration, so there is no additional work to set up or configure the mixed environment.
To set up a dual client approach, an organization would typically download and install the Novell client from the Novell Web site. There are different versions of the Novell client, and while it typically makes no difference from a Microsoft network perspective which version of the Novell client is used, various Novell applications will not work without the correct version of the client software. Therefore it is best practice to use the latest version of the client to ensure compatibility with the latest Novell administration, management, and operational tools.
Full Compatibility with Novell Directory Services
Microsoft provides a client for NetWare, however the Microsoft client is limited in its ability to access multiple Novell directory trees as well as limits the user the ability to run many of the Novell administrative tools. Therefore, most organizations use the Novell client to get full compatibility with Novell directory services, application services, and application compatibility.
For many organizations that have effectively eliminated most of their Novell network infrastructure but are limited to a handful of legacy applications that are still running on Novell servers, there’s a need for cross compatibility, but possibly not as important to continue to support a dual-client configuration. In these cases, one option an organization can consider is implementing Windows Terminal Services with the Novell client installed on the Terminal Server system. With a Terminal Server system, a single system running the Novell client can host dozens if not a couple hundred client application sessions without having any Novell client software on the client desktop and laptop systems.
A Remote Client Does Not Need to Have the Novell Client Installed
By leveraging the application launch capabilities of Terminal Server, an organization can place an icon on a user’s desktop that effectively launches a Terminal Server session to run a remote client session. A remote client does not need to have the Novell client installed; it just needs to have a Terminal Server client icon linked with the execution of the Novell-based application.
When configuring a client for access to NetWare as well as to Microsoft Windows, the Novell client software provides the ability to log on to a Novell Bindery network, a NetWare eDirectory or NDS tree, a Windows NT domain, and a Windows Active Directory forest simultaneously. The default server, directories, and trees can be configured in the Properties window on the Network Properties page as shown in Figure 17.1.
By preconfiguring the property page options on the client configuration, default settings can be made relative to the network configuration desired. Many times the name services are different between the Novell and Microsoft environment, so a priority order needs to be created to access either the Novell or the Windows look-up tables. Additionally, logon scripts or drive mappings need to be resolved if multiple networks are accessed with similar default drive mappings or printer mappings across the different networks. In areas where configurations and access across multiple networks conflict, the properties option can be set to choose the settings desired.
Another option to provide access to multiple platforms is to identify whether applications that are being used are Web services–enabled applications. Rather than trying to provide a 32-bit client access to applications, many times an application has a universal Web front-end that can be accessed with just a browser.
As an example, an organization that is heavily committed to Novell but needs to access possibly a corporate-hosted Exchange messaging environment might choose to use the Outlook Web Access for e-mail access rather than supporting and accessing Windows logon and network authentication. In a reverse scenario, if an organization has predominantly Microsoft-based applications yet needs to have support for a legacy Btrieve application, or a legacy NLM-based application, rather than supporting the dual-client approach, the organization could potentially use a browser version of the software that runs on Novell.
Web services and Web-enabled applications have become relatively common and greatly simplify the ability for an organization to implement multi-platform integrated configurations. Instead, of supporting a dual-client configuration, an application that might be on a cross-platform environment could be accessed using a more strategic view of application operation and configuration.
To take advantage of the Microsoft Services for NetWare tool, the network administrators need to install Services for NetWare on a Windows 2000 or Windows 2003 server system. There are various versions of the Services for NetWare product. Services for NetWare 5.0 can be purchased for less than US$150; however, version 5.0 is not compatible with Windows 2003. With Services for NetWare Service Pack 2, there was support for Windows 2003 directory synchronization and server operation access.
Services for NetWare provides tools for gateway services, directory synchronization services, and file migration services. Each of the various tools has different system requirements as the tools affect different components in a Windows and NetWare environment. The basic configuration requirements for Services for NetWare are as follows:
Pentium 133Mhz or faster
256MB Ram
130MB of available disk space
CD-ROM, Network Adapter, and VGA Video
The actual system demands of the server system or systems supporting Services for NetWare depends on which of the modules will be used. As an example of varied system configuration:
File Migrator—. The file migrator tool in Services for NetWare does not necessarily need to run on a Windows 2000 or Windows 2003 server. It can actually run on a Windows XP workstation to transfer files from one server to another. The biggest area of performance for File Migrator is the performance of network speed because information is read and written across a network configuration.
File and Print Services—. The file and print services along with the gateway services utilities can greatly benefit from having a faster server (Pentium III 500Mhz or faster) with 512MB or RAM for a workstation class system, or 1GB of memory for a server class system to cache the reads and writes of the tool.
Microsoft Directory Synchronization Service—. MSDSS is probably the most processor and system performance–demanding tool in Services for NetWare. MSDSS requires the product run on a Windows Active Directory domain controller because it is doing direct synchronization between directories. Also because directory synchronization is frequently a real-time proce7ss, the faster the processing capability of the system, the faster it will process the directory requests. A fast system (potentially Pentium III 1Ghz or faster) with 1GB of RAM would be appropriate for an organization trying to synchronize hundreds if not thousands of objects.
Because Services for NetWare is a series of tools, all the utilities do not need to be installed. Only those tools that will be used should be installed. On the first CD are the File and Print Services for NetWare (FPNW) tools as well as the Microsoft Directory Synchronization Service (MSDSS) tools for Windows 2000 and Windows 2003 networks. The second CD contains the tools and utilities for Windows NT 4.0 and Windows NT 3.51. This book only focuses on the first CD for Windows 2003.
From the first Services for NetWare CD, the installation process for File and Print Services for NetWare is as follows:
On the computer where the FPNW will be installed, insert the CD into the CD-ROM drive.
Add the network service by selecting Start, Settings, Network Connections and explore the Network Connections folder.
Right-click and choose Properties on the primary network adapter on the server where the FPNW will be installed.
Click on the Install button and choose Service, and then click on Add.
Click on Have Disk and choose the FPNW directory on the CD-ROM (such as D:FPNW). File and Print Services for NetWare will appear on the Network Service option screen shown in Figure 17.2. Choose OK.
When prompted to enter installation options, this is where you enter information about this system and how it will appear in a Novell network environment. For Directory for the SYS Volume, type in the physical path where normal Novell SYS utilities should be stored (such as E:SYS).
For Server Name, this is the name that this server will publish when a Novell client tries to look for this server. This can be different than the Windows server name, so pick any name that is appropriate for this server in the Novell arena.
Enter the password for this server. Again, the information entered could be different than the Windows administrative password. This is the password that will be used as the Novell server “supervisor”.
Choose one of the three tuning options for server performance. If uncertain, choose maximum performance. This can be changed later.
Click OK to select the settings and proceed with the installation. After the installation is complete, you will be prompted to restart the server. Restart the server to have the new Service for NetWare tools applied.
After File and Print Services for NetWare have been installed, Service Pack 2 or later of the Services for NetWare (v5.02 or later) needs to be applied for full Windows 2003 compatibility. To install the Service Pack for Services for NetWare, do the following:
Download the Service Pack from the Microsoft (http://www.microsoft.com) using the keyword search
services for netwareand in the downloads section, look for the latest service pack for Services for NetWare.After the Service Pack has downloaded, run the Service Pack executable that will install the update on the Windows 2003 server.
Reboot the system as prompted to have Services for NetWare updated.
Separate from the installation of the File and Print Services for NetWare (FPNW) is the installation of the Microsoft Directory Synchronization Service (MSDSS). This tool is not installed with the rest of the File and Print Services for NetWare tools because an organization might install FPNW on one server, whereas MSDSS will likely be installed only on a single server. Effectively, MSDSS does the synchronization between Active Directory and Novell NDS and eDirectory. MSDSS needs to be installed on a Windows domain controller to properly synchronize directory information between the two different network environments.
Installing MSDSS
Installing MSDSS initiates an extension of the schema of the Active Directory forest. As with any schema update, the Active Directory should be backed up before performing a schema update. Also with a schema update, because the update will replicate directory changes to all Global Catalogs throughout the organization, the replication should be done at a time when a Global Catalog synchronization can take place without affecting the normal production environment.
To install MSDSS, follow these steps on a Windows 2003 domain controller:
On the domain controller computer where the MSDSS will be installed, insert the CD into the CD-ROM drive.
Go into the MSDSS directory on the CD-ROM (such as D:msdss) and run the msdss.msi script package. This will launch the Installation Wizard.
Choose to install the Microsoft Directory Synchronization Service.
When logging in to multiple networks, one of the first things that is requested is the ability for a user to type in a logon name and password, and not have to be prompted to enter a logon and password for each additional network being accessed. The request is to have a single logon name and password that can be entered so that the user can access both Microsoft and Novell resources with an initial logon and password entry.
There are several ways that a single sign-on can be accomplished. The key to having an effective single sign-on process is to synchronize logon names and passwords between the multiple environments. When the logon names and passwords are identical, it’s just a matter of having the logon process connect to each of the different systems.
One way that organizations try to accomplish a single sign-on process is to load both the Microsoft and Novell client software programs on the same system. With the same logon name and password, users think they have a fully integrated single sign-on process because they can access both a Microsoft and Novell network with a single logon.
Unfortunately a dual-client configuration does not provide manageability between the multiple logons. Effectively the single sign-on works until the user changes his or her password. Because the system was working on a dual-client architecture, changing the password on one operating system does not synchronize the password on the other network operating system. Each system will require a separate password change sequence.
So although the logon process with dual clients only requires a single logon and password entry when the logon names and passwords are identical, there is no manageability between the platforms. The user has to make password changes on each of the operating environments.
To effectively create a fully managed single sign-on environment, the logon names and passwords on the network systems need to be synchronized. There are many ways to try to accomplish this; however, the Microsoft Services for NetWare includes the Microsoft Directory Synchronization Service (MSDSS) tool that not only maintains a link between user accounts in Active Directory and NetWare, but also synchronizes user’s passwords.
MSDSS enables users to change their passwords on the NetWare system and have the password automatically replicate to the Windows system. And the user can also change the password on the Windows systems and have the password updated on the NetWare system. This automated synchronization of user accounts and passwords across Windows and NetWare provides an easy way for an organization to maintain common logon and password information throughout a migration process.
For organizations that have both a Windows Active Directory and a Novell eDirectory, or Novell Directory Service (NDS) environment, there are two primary methods of performing directory synchronization between the two directories. One method is using the Novell dirXML product, and the other method is using the Microsoft Directory Synchronization Service utility. With regard to synchronization of user accounts and passwords, both tools do the same job, and for the purpose of this book, the Microsoft solution will be the focus of this section. To configure and run the MSDSS utility, do the following:
Use the Bindery Option
Use the NDS option if Novell NetWare v4.x or later running NDS or eDirectory is used. Use the Bindery option if Novell NetWare v3.2 or lower bindery mode is running on the Novell network.
Launch the MSDSS utility by choosing Start, Programs, Administrative Tools, Directory Synchronization.
Right-click on the MSDSS tool option and select New Session.
Click Next at the New Session Welcome screen.
At the Synchronization and Migration Tasks screen, choose either Novell Directory Service (NDS) or Bindery for the type of service.
Dependent on the synchronization option, choose either a one way (from Active Directory to NDS/Bindery), a two-way (AD to NDS/Bindery and back), or a migration from NDS/Bindery to Active Directory. Click Next.
For the Active Directory container and domain controller, choose the AD container where objects will be synchronized to as well as the name of the domain controller that will be used to extract and synchronize information similar to the settings shown in Figure 17.3. Click Next.
For the NDS Container and Password, select the NDS container where AD information will be synchronized from and/or to the Novell directory. Enter in a logon name and password for a supervisor account on Novell to access the Novell directory. Click Next.
On the initial reverse synchronization screen, select the password option to either define passwords to be blank, same as the username, set to a random value (that can be viewed in the log file), or set to an organizational default. Click OK after making the password option, and then click Next to continue.
Click Finish to begin the synchronization/migration process.
MSDSS runs on a Windows 2000 or Windows 2003 domain controller and replicates user account and password information between the Active Directory environment and a Novell eDirectory or NDS environment. MSDSS is a Windows service that synchronizes user account information between Active Directory and NetWare. The following are best practices determined in the implementation of MSDSS in an enterprise environment:
Ensure the Microsoft MSDSS server that is running on a Windows Active Directory domain controller and the Novell directory server are on the same network segment or have limited hops between each other.
Because directory synchronization reads and writes information directly to the network directory, test the replication process between mirrored domain and directory services in a test lab environment before implementing MSDSS for the first time in a production environment.
Monitor directory and password synchronization processing times to confirm the transactions are occurring fast enough for users to access network resources. If users get an authentication error, consider upgrading the MSDSS server to a faster system.
Password characteristic policies (requiring upper/lowercase letters, numbers, or extended characters in the password, and password change times) should be similar on both the Microsoft and Novell environments to minimize inconsistencies in authorization and update processes.
While directory synchronization can provide common logon names and passwords, MSDSS does not provide dual client support or any application-level linkage between multiple platform configurations. This means that if a Novell server is running IPX as a communication protocol and Windows is running TCP/IP, the MSDSS does not do protocol conversion. Likewise, if an application is running on a Novell server requiring the Service Advertising Protocol (SAP), because Windows servers commonly use NetBIOS for device advertising, a dual client protocol stack must be enabled to provide common communications.
MSDSS merely links the logon names and passwords between multiple environments. The following are areas that need to be considered separate of the logon and password synchronization process:
Protocols like TCP/IP and IPX/SPX need to be supported by servers and clients.
Applications that require communication standards for logon authentication might require a client component to be installed on the workstations or servers in the mixed environment.
Applications that were written for Novell servers, such as Network Loadable Modules (NLMs) or Btrieve databases, need to be converted to support Windows.
Login scripts, drive mappings, or other access systems compatible with one networking environment might not work across multiple environments, so those components will need to be tested for full compatibility.
Backup utilities, antivirus applications, network management components, or system monitoring tools that work on one system will need to be purchased or re-licensed to support another network operating configuration.
MSDSS configuration, tables, and system configurations are critical to the operations of the MSDSS synchronization tool. Microsoft provides a backup and restore utility that allows for the storage and recovery of MSDSS information. To back up MSDSS, do the following:
Select Start, Programs, Administrative Tools, MSDSS Backup & Restore Utility. You should see a screen similar to the one shown in Figure 17.4.
Either click on Backup Now to back up the MSDSS session directory, or change the default time when the MSDSS information should be backed up.
If you choose to back up the session directory information you will be notified that the MSDSS service will need to be stopped. Choose Yes to continue.
Upon completion of the backup, you will be prompted that the MSDSS service will need to be restarted. Choose Yes to restart the MSDSS service.
At any time, if the MSDSS session directory information gets corrupt or behaves erratically, the MSDSS information can be restored. To restore MSDSS, do the following:
Select Start, Programs, Administrative Tools, MSDSS Backup & Restore Utility.
Click on Restore Now to restore the MSDSS session directory.
When notified that the MSDSS service will need to be stopped. Choose Yes to continue.
Upon completion of the restoration, you will be prompted that the MSDSS service will need to be restarted. Choose Yes to restart the MSDSS service.
A common process in a migration or partial migration from Novell NetWare to a Windows network environment involves the replacement of servers. Sometimes the server replacement is performed in entirety; sometimes the server replacement process is performed over an extended period of time. Regardless of the strategy chosen, the Services for NetWare tools provide options for the integration and migration process. The options are as follows:
One method of replacing a Novell server with a Windows server is to physically replace the Novell server with a Microsoft Windows system. The problem is usually the situation where users who are mapped to the Novell server need to have their mappings changed to the new Windows server. This creates a chicken and egg scenario where the server cannot be replaced because each client system needs to be touched, but each client system cannot be reconfigured until the server data is migrated.
By using the File and Print Services for NetWare server replacement functionality, a Microsoft Windows server can take on the exact same server name, IP address, and drive and resource mapping as the old Novell server. Effectively, the Microsoft server responds not only as a Windows server, but also can respond to Novell MAP commands for sharing files, printers, and other network devices. One day, the server was running on Novell NetWare, and the next day a Windows server running Windows 2000 or Windows 2003 responds to the exact same Novell access commands.
Login scripts, drive mappings, configuration access files, file permissions, and all other information is migrated from the old to new server. The process in which this is done is as follows:
Install Windows 2000 or Windows 2003 on a new server. Give the server a new Windows server name.
Install File and Print Services for NetWare on the server as described in the “Installation of the File and Print Services for NetWare” section earlier in this chapter.
When choosing the Novell name, temporarily select a new NetWare server name for this system (this will be changed later to be the exact same name as the old Novell server, however it cannot be changed now because the names will conflict in the directory).
Use the file migration tool to migrate all volume information from the old Novell server to the new Windows server as described in the “Using the File Migration Wizard to Migrate Files” section later in this chapter.
After all files have been migrated, unplug the old Novell server from the network. Do not shut the server off, delete the server from the directory, or make any changes to the network. Simply unplug the network cable to remove the system (that way if you have any problems with the new Windows server, you can simply plug the old server back in without making any network changes).
Change the IP address of the new Windows server to be the same IP address as the old Novell server.
Change the File and Print Services for NetWare server name to be identical to the name of the old Novell server.
Reboot the Windows server to reconnect to the network that will then respond as if it were the old NetWare server.
Another method of gaining access to Novell information during a migration to Windows is to set up the Gateway Services for NetWare (GSNW), which is part of the File and Print Services for NetWare installation tool. What GSNW does is allow a workstation that no longer has the Novell client installed to access a Novell NetWare shared resource by connecting through a Windows server. Instead of connecting directly from the client to the Novell server for file and print access, all file and printer components are redirected through a Windows server.
The Windows Server Becomes a Bottleneck
Because all traffic to a Novell server has to first go through a Windows server, the Windows server becomes a bottleneck if an extensive amount of traffic must be routed through the server. GSNW works fine for organizations with less than 25–50 connections, or for organizations that are using GSNW for a temporary cross-over server in a migration process. When more than 100 users have to access resources through a GSNW server for an extensive period of time, the performance might be degraded and should be tested before using GSNW for an extensive server reroute of information.
This minimizes the need for the client systems to have the Novell client installed, and a quick and easy way to share old legacy Novell file shares or printers without having to configure Novell workstation configurations. GSNW is installed on a Windows server and the Windows server has the Client for Novell installed and accesses the Novell resource, and then redistributes the shared access to Windows clients.
To install GSNW, perform the following steps:
After File and Print Services for NetWare has been installed on a Windows 2000 or Windows 2003 server, click on Start, Settings, Control Panel, and then double-click on GSNW.
Click on Settings, and then click on Enable Gateway.
Type in a username that will be the default access path from the Windows server to the Novell server. If the user account is in eDirectory or NDS, enter the username as .username.organizationalunit.organization format.
Enter in the password for the selected user account, again enter the same password into the Confirm Password box, and then click OK.
Type the Windows share name as you want this Novell network share to appear in Windows, click OK.
If you want to apply new permissions for Windows users to this share, click on Permissions and choose the Type of Access and the Access Through the Share information. Click OK to select the settings.
A Security Limitation for GSNW
Because all users route through the GSNW server using the same logon and password, usually a supervisor type password is used. However, this becomes a security limitation for GSNW because all users routing through GSNW will have the same access name and password to the Novell system, so permissions should be applied in step 6.
A utility that is installed with the MSDSS tool is the File Migration Utility. The File Migration Utility migrates files from one server to another, particularly from Novell servers to Windows servers while preserving filenames, file paths, access control lists (ACLs), and user and directory permission information. The File Migration Wizard simplifies the process of moving information from one server to another in an ability to migrate information without having to manually track file permissions or to rebuild configuration settings.
Build a Brand New Microsoft Windows Server
A common practice for organizations replacing Novell servers with Microsoft Windows servers is to build a brand new Microsoft Windows server and then run the File Migration Wizard to extract information from a Novell server and replace the information onto a Windows server. Upon completion of the file migration, a drive mapping is changed in the network logon script remapping the user drive from a Novell volume to a Microsoft Windows share.
To run the File Migration Wizard, do the following:
Launch the File Migration Wizard by selecting Start, Programs, Administrative Tools, File Migration Utility.
For Step 1 – Mappings, enter the name of a log file that will be used to record the server, drive, and configuration mappings. This is extremely helpful in creating a prototype test migration in a lab environment that can then be replicated in a production environment using the exact same settings. Choose Next to continue.
For Step 2 – Security Accounts, if not already logged on to Novell, click on the Log On to Novell button and enter in a valid account (typically the supervisor account) that has full access to the Novell server information. Click Next.
For Step 3 – Source and Target, choose the Novell server volume that is the source of information to be migrated, and select the Microsoft Windows share that is the target of the migrated information as shown in Figure 17.5. Choose Next to continue.
For Step 4 – Log Settings, choose to log the migration process. During a test migration during the prototype phase, select high log detail to view all migration change information. If after a test migration all processes are validated in the test, you can choose to log at a low or medium level to save disk space on the migration process. Click Next to continue.
Step 5 – Scan performs a test to validate whether there will be any failures during the migration process. The scan tests for available disk space, read and write permissions, matching account information, and proper configuration settings between the source and target servers. Click Next to continue.
Step 6 – Migrate performs the migration. If there were any errors in the test migration process, the errors will be reported and a warning will be displayed onscreen to prevent a migration process from occurring with undesired results. If the migration test phases are successful, the migration will proceed with a progress displayed similar to the one shown in Figure 17.6.
Integrating and migrating Novell networks and Windows networks might seem to be a challenging task; however, the Services for NetWare is a great resource for Windows to NetWare inter-connectivity. An organization can choose to simply migrate files, including file permissions, from a Novell server to a Windows server all the way through, completely replacing the Novell server with a Windows server system.
For an organization that wants to create a single sign-on type environment, the Microsoft Directory Synchronization Service, or MSDSS, does the synchronization between Novell and Windows networks. MSDSS also includes the File Migration Wizard that migrates files, file properties, and file permissions from a Novell server to a Windows server.
The combination of all the tools included in Services for NetWare simplifies the task and the process of migrating or integrating Novell and Windows networks together.