9.1 Troubleshooting the Server Consolidation Utility
Explanation:
In general, when troubleshooting errors in the Server Consolidation
Utility, first ensure that the latest smdr.nlm and tsafs.nlm modules
are loaded on the source and destination NetWare servers.
The log files contain detailed information about what was
successfully copied (success log) and what was not copied and why
(error log). The log files are written to the project folder, which
is located by default in My Documents.
Utility Hangs when
Selecting Source and Destination Trees
Problem:
When running the Server Consolidation Utility on a Windows
2000 workstation, the application hangs when selecting the source
and destination trees for the consolidation project.
Action:
Install Windows 2000 SP 2 or later on the workstation to correct
this issue.
Contents of the eDirectory
Container Can’t Be Listed
Possible Cause:
Your workstation is not running the latest support pack update
of the Novell® Client™ for Windows 2000/XP
version 4.91.
Volume Contents Do
Not Display
Problem:
No data appears in the Volume object after dropping a container
into a volume that has not been opened.
Action:
Map a drive to the volume from the workstation.
“SMDR Not
Communicating” or “Error Opening Connection to
SMDR” Errors
Possible Cause:
The Storage Management Data Requester (SMDR) and Target Service
Agent (TSA) are not loaded on either the source or the destination
server, or the sys:etc/hosts file
does not contain the server IP addresses, or Service Location Protocol
(SLP) is not properly configured.
Action:
Check to see if smdr.nlm is running on a NetWare® server
by entering m smdr at the server console.
To check if the SMDR module is running on an OES Linux server,
enter pgrep smdr at the shell prompt.
If SMDR is not loaded on the source or destination server,
manually load it. On a NetWare server, enter load smdr.
On an OES Linux server, enter /etc/init.d/novell-smdrd
start.
Action:
Check to see if tsafs.nlm is running on a NetWare server by
entering m tsa* at the server console.
To check if the TSAFS module is running on an OES Linux server,
enter /opt/novell sms/bin/smsconfig
-t at the shell prompt.
If TSAFS is not loaded on the source or destination server,
manually load it. On a NetWare server, enter load tsafs.
On an OES Linux server, enter /opt/novell/sms/bin/smsconfig
-l tsafs.
Action:
On a small network with three or fewer servers, you do not
need to configure SLP. Instead, edit the sys:etc/hosts
file on the source server to contain the IP address and DNS name
of the destination server, and vice versa on the destination server.
After editing the sys:etc/hosts files, you might
need to reload smdr.nlm and tsafs.nlm on your
NetWare servers.
Action:
Enter display slp services smdr.novell//(svcname-ws==source_ server_name)
(replace source_server_name with
the name of your source server) at the destination server console.
If it appears there is a problem with SLP, go to Novell’s
Knowledgebase and search for SLP-related configuration information.
“Specified
TSA Does Not Exist” Errors When Copying Data from NetWare
to OES Linux
Possible Cause:
The SMDR daemon needs to be restarted on the OES Linux server.
Action:
Enter rcnovell-smdrd restart at the Linux
server’s shell prompt.
Trustee Rights Restored
to Wrong User in Tree-to-Tree Copy
Problem:
In a tree-to-tree consolidation scenario, it is possible to
have users with the same Common Name (CN) that exist in multiple
contexts in the destination tree (for example, jdoe.users.novell,
jdoe.mktg.novell, and jdoe.sales.novell). If you do not match up
the user in the source tree with the desired user in the destination
tree, SMS automatically copies trustee rights to the first user
match it finds.
Action:
Before running the consolidation, be sure to match up the
users in the source tree with the correct users in the destination
tree.
Server Consolidation
Performance Problems
Explanation:
The performance of a project can be determined by looking
at the success log after a project completes. The success log gives
the amount of time the project took to complete and the amount of
data copied.
There are several factors that determine the performance of
the file copy. It is also important that each server be updated
to the latest Support Pack to ensure you have the latest performance
enhancements for SMS™.
Possible Cause:
Heavy traffic on the network.
Action:
Speeds can be increased by connecting servers and the workstation
to a dedicated switch.
Possible Cause:
A mismatch in duplexing among servers, switches, and the workstation.
Action:
Make sure all hardware is set to either full duplex or half
duplex. Setting all hardware to half duplex might result in greater
performance than full duplexing.
Possible Cause:
Virus scan software running on the source or destination servers.
Action:
Turn off any virus scanning software on the source or destination
servers to increase the speed of the consolidation. Turn the virus
scanning software back on after the consolidation completes.
Possible Cause:
An incorrect version of smdr.nlm is loaded
on a NetWare server.
Action:
At the NetWare server, unload smdr.nlm,
then load the version of the smdr.nlm file
that comes with the newest Support Pack.
Possible Cause:
Small file sizes.
In general, the larger the file sizes, the better the performance.
Copying a single 500 MB file will be significantly faster than copying
five thousand 100 KB files.
Possible Cause:
Hardware configuration.
The performance of the Server Consolidation Utility varies
according to the environment. Using a 100 MB LAN, tests have measured
speeds ranging from 3 to 15 GB per hour, with the most common speed
being between 5 and 8 GB per hour. You should check the performance
of your LAN before copying very large amounts of data.
The Server Consolidation Utility copies data at a faster rate
than a Windows file copy.
Server Consolidation
Utility Copies Incomplete Data Files
Problem:
Files copied to the destination server have any of the following
characteristics:
-
Destination is a 0-byte file.
-
Creation time and date are incorrect when compared
to the source server.
-
Modification time and date are incorrect when compared
to the source server.
-
File was not completely copied. (This would be indicated
by the destination file being smaller in size than the source file.)
Action:
Use the latest SMDR and TSAFS modules on the source NetWare
server.
Path Size Limitations
for Data Copy
Problem:
Because the Server Consolidation Utility is a Windows-based
program, it is subject to the path size limitation of Windows, which
is 255 characters. If you have data where the path name is longer
than 255 characters, the Server Consolidation Utility cannot copy
data that exceeds this maximum.
Action:
One workaround is to reorganize the data on your source server
so that the path size does not exceed 255 characters.
Action:
Another possibility is to use the server-based processing
feature to copy the data. Since the workstation does not monitor
the file copy process, it is not subject to the path size limitations
of the workstation. However, the server-based processing copy is
limited by the supported path size of the server operating system.
For example, if the server allows path sizes up to 1024 characters,
then data is copied up to the 1024-character path limit.
“Trustee
Not Restored” Errors When Copying Double-Byte Character
Data Tree-to-Tree
Explanation:
In a tree-to-tree consolidation, the Server Consolidation
Utility stores the full distinguished names of trustees in a file
that is stored on the destination server. This file is stored using
the local code page of the destination server. Object names containing
double-byte characters (Japanese and other oriental languages) may
not match if the local code page versions on the source and destination
servers do not match exactly.
Problem:
When the object names do not match between the source and
destination server, you might see messages such as “Trustee name was
not restored for path, because the trustee
IDs are different.”
Action:
Because of known limitations with code pages, this issue cannot
be resolved in the current version of the Server Consolidation Utility.
Novell plans to address this in a future release of the Server Consolidation
and Migration Toolkit.
Copying Double-Byte
Character Data from NetWare 5.1 to OES Linux
Problem:
In NetWare 5.1, SMS uses the double-byte or multi-byte character
set (MBCS) format to back up Japanese data. NSS and Linux use Unicode.
In order for MBCS data to be copied to an NSS volume on an OES Linux
server, conversion must take place from MBCS to Unicode* and
certain Japanese characters might not come through intact.
Errors When Migrating
a Cluster Volume
Problem:
When using the Server Consolidation Utility and migrating
data from or to a cluster volume, an error (0xFFFDAE) might occur
if your cluster server nodes are spread throughout different eDirectory
contexts. If the server (from the SCU project) that holds the mounted
cluster volumes does not have rights to the cluster Virtual Server
object and the cluster-enabled Volume object, and does not have
a Read/Write replica of the partition these objects reside
in, then a failure fffdae is displayed on the verification screen
of the Server Consolidation Utility.
Action:
To resolve this, add the server as a trustee of the context
that contains the Virtual Server and Cluster Volume objects. The
default rights assigned when adding the trustee are sufficient.
Problem:
When migrating data to or from a NetWare 5.1 cluster volume,
the copy fails with a critical error: “Error opening connection
to SMDR.”
Unloading NUWAGENT.NLM
on an Nterprise Branch Office Appliance
Problem:
When running the Server Consolidation Utility in conjunction
with an Nterprise Branch Office appliance, if an error state occurs
and you are asked to unload nuwagent.nlm, the
system might not allow you to unload the module.
Action:
Perform a reboot of the Nterprise Branch Office appliance.
Errors When Connecting
to a NetWare 4 Server
Problem:
When attempting to connect to a NetWare 4 server, any of the
following types of errors are returned:
-
An error occurred opening the file. filename was
invalid.
-
Error opening connection to SMDR.
-
The name spaces couldn’t be checked.
-
8998 error. NWGetVolumeNumber.
Action:
There are several actions to take if errors are returned when
trying to connect to a NetWare 4 server, including the following:
-
If your source server is NetWare 4,
make sure that you have IPX™ on your client. For information
on verifying IPX on your client, see Section 6.11.3, Verifying IPX Is Bound on the Client.
-
Add a mapped drive to the source server.
-
Ensure that SLP is configured properly on the servers
involved in the consolidation project.
Problem:
NetWare 6.5 won't communicate with NetWare 4 during a consolidation.
IPX was not installed during the NetWare 6.5 installation.
Action:
Add IPX to the NetWare 6.5 server after the NetWare 6.5 installation
is complete.
-
Enter edit
sys:system/autoexec.ncf at the NetWare 6.5 server console.
-
Add the server ID of the source server
and save the autoexec.ncf file.
Problem:
IPX connection is not communicating.
Action:
Ensure that there is an IPX connection to the server.
To verify that the source and destination servers can see
each other via IPX:
-
On the server
console of the destination server, enter serverid xxxxx,
where xxxxx is the unique server ID number
for the server.
-
Enter load ipxping.
-
Enter the internal IPX number of the
source server.
-
Repeat this process on the source server,
replacing the internal IPX number of the source server with the
destination server's internal IPX number in Step 3.
Action:
Bind IPX on the destination server.
-
At the destination
server console, enter inetcfg.
-
Select Boards and press Enter.
-
Press the Insert key.
-
Select the appropriate network interface
and press Enter.
-
Enter a board name and slot number, then
press the Esc key.
-
Select Yes to save changes and press
Enter.
-
Press the Esc key to return to the main
Internetworking Configuration screen.
-
Select Protocols and press Enter.
-
Select IPX and press Enter.
-
Enable and configure IPX and exit the
inetcfg utility.
HINT:If you prefer, IPX can also be enabled on the server by adding
the appropriate Load and Bind commands to the server’s
autoexec.ncf file.
Action:
Verify that IPX is bound on the client running the Server
Consolidation Utility:
-
Right-click
the red N in the system tray on your workstation.
-
Select .
-
Select the Protocol Preferences tab.
If the Protocol window displays both IP and IPX, the client
has IPX bound.
If the Protocol window displays only IP, then IPX needs to
be bound on the workstation.
Action:
Bind IPX on the client running the Server Consolidation Utility:
-
Obtain the
latest Novell Client software and run the installation program.
-
Select the appropriate language and click .
-
Select and
click .
-
Click the radio button next to one of
the following two choices:
-
Click > > .
Action:
Ensure that the correct smdr.nlm and tsa.nlm are loaded on
the server.
-
On the server
console, enter unload smdr.
-
Enter smdr new.
-
Enter N when asked
if you want to disable NDS.
-
Enter N when asked
if you want to disable SLP.
-
Enter N when asked
if you want to disable SAP.
-
Enter N when asked
if you want to disable name resolution through sys:\etc\hosts file.
-
Enter load smdr on
the server console.
-
Enter load tsafs on
the server console.
NUWAGENT Won’t
Load (NetWare 4.2 Only)
Possible Cause:
Clibaux.nlm is not loaded.
Action:
Go to the server specified in the error message and at the
server console, enter load clibaux.nlm.
NDPS Printer Agents
Don't Migrate
Possible Cause:
If after a migration, it appears NDPS® Printer Agents
have not migrated, it is possible that eDirectory™ has
not had time to properly synchronize.
Action:
Wait for a few minutes, then check again to see if eDirectory
has been updated to reflect the Printer Agent migration.
Action:
If the Printer Agents have still not migrated after allowing
eDirectory to synchronize, ensure the Novell Distributed Print Services™ Manager (ndpsm.nlm)
is loaded on either the source or destination server.