OES 2018: Migration Tool Administration Guide

Open Enterprise Server 2018
Migration Tool Administration Guide
November 2017
Legal Notices
For information about legal notices, trademarks, disclaimers, warranties, export and other use restrictions, U.S. Government
rights, patent policy, and FIPS compliance, see https://www.microfocus.com/about/legal/.
Copyright © 2017 Micro Focus. All Rights Reserved.
Contents
About This Guide
11
Part I Overview
13
1 Overview of the Migration Tools
15
Migration Tool Enhancements. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
Different Migration Tools . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
Migration Scenarios . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16
Migrate . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16
Transfer ID . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18
Support Matrix for NetWare and OES Services . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18
2 Overview of the Migration GUI
21
Project Pane . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21
Create Project . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22
Schedule Service . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23
Email Notification . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24
View Logs. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26
Project Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28
Help . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28
Quit. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28
Whiteboard . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28
Migration Pane . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29
Authenticate Source Server and Target Server . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29
Type of Migration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31
Services to Migrate Pane . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31
Options . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31
Migration Status . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33
Status . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33
Service Information . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33
3 What’s New or Changed in the Migration Tool
37
What’s New (OES 2018) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37
Part II Getting Started
39
4 Planning for Migration
41
Prerequisites . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41
Source Server Requirements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41
Target Server Requirements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42
Unsupported Target Platforms . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42
Preparing the Source Server for Migration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42
Preparing the Target Server for Migration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42
Installing and Accessing the Migration Tool . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43
What’s Next. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43
Contents
3
5 Using the Migration Tool GUI
45
Getting Started . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45
Launch the Migration Tool Utility . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45
Migration Process . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45
6 Troubleshooting Issues
49
Source Server Authentication Fails in an Cluster Environment. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 49
Clear User Name Entries Populated in the Source or Target Authentication Screen . . . . . . . . . . . . . . . . . . 49
Unable to Authenticate to Source or Target Server Using Non-SSL Option . . . . . . . . . . . . . . . . . . . . . . . . . 49
Target Server Authentication Fails or Unable to Browse the eDirectory Tree in the Migration GUI . . . . . . . 50
The Authentication Dialog Box is Blank . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 50
Part III Server Consolidations
51
7 Preparing for Server Migration
53
Prerequisites . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 53
Migration Support Matrix . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 53
8 Using the Migration GUI Tool
55
Launch the Migration Tool Utility . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 55
Create the Project File . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 56
Select the Source Server, Target Server, and Migration Type . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 57
Configure the Services . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 58
Run the Migration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 58
Part IV Transfer ID Migration
59
9 Preparing for Transfer ID
61
Prerequisites . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 61
Preparing the Source Server for Migration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 62
Preparing the Target Server for Migration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 62
Preparing Source and Target Server in an Active Directory Environment. . . . . . . . . . . . . . . . . . . . . . . . . . . 63
Source Server and Target Server are Configured With NSS AD . . . . . . . . . . . . . . . . . . . . . . . . . . . . 64
Source Server is Configured with NSS AD and Target Server is not in an AD environment . . . . . . . 64
Source Server is not in an AD environment and Target Server is Configured with NSS AD . . . . . . . 64
10 Using the Migration GUI Tool for Transfer ID
67
Understanding Transfer ID GUI . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 67
Left Pane . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 67
Right Pane . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 68
Launch the Migration Tool Utility . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 68
Create the Project File . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 69
Select the Source and Target Server and the Migration Type. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 69
Configure the Services and Run Migration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 69
Run Transfer ID. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 70
4
Contents
11 Using Migration Commands for Transfer ID
75
Backup eDirectory Database and NICI Keys . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 83
12 Running Transfer ID Remotely
85
Using Two Network Interface Cards . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 85
Using VNC . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 85
Using SSH . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 86
13 Post Transfer ID Migration
87
Joining Target Server to an Active Directory Domain . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 87
Cleanup Objects . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 87
AFP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 87
CIFS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 88
eDirectory . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 88
NSS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 88
iPrint . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 88
DHCP, FTP and NTP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 88
DFS Junctions are Not Restored . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 89
14 Troubleshooting Issues
91
Copying NICI Keys Fails When Performing Transfer ID . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 91
LUM Repair Fails When Performing Transfer ID . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 91
On Completing Transfer ID migration, iManager or OES Remote Manager is Not Accessible via a
Web browser on the Target Server . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 91
System Might Hang on Terminating the IP Address Change Step when Performing the Transfer ID
Scenario . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 92
System Might Hang on Terminating the Hostname Change Step when Performing the Transfer ID
Scenario . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 92
On Failure of Migration and Restoring eDirectory to the Source Server, LDAP Does Not Bind . . . . . . . . . . 93
eDirectory Error 626 on Performing Transfer ID Migration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 93
Transfer ID fails when NetStorage is Configured on the Source Server . . . . . . . . . . . . . . . . . . . . . . . . . . . 94
Part V Security Considerations
95
15 Security Considerations for Data Migration
97
Root-Level Access Is Required . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 97
Securing User Credentials . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 97
How User Credentials Are Stored During a Migration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 98
How Credentials Are Passed from the Migration GUI Utilities to the Migration Commands . . . . . . . 98
Mounting Remote File Systems . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 98
Transmitting Data Across the Network . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 99
Managing Passwords for Migrated Users . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 99
Part VI Data Migration
101
16 Migrating File Systems to OES 2018
103
Preparing for File System Migration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 103
Source Server Requirements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 103
Target Server Requirements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 104
Contents
5
Migration Scenarios . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 105
Consolidating Data to a Server in the Same Tree . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 105
Consolidating Data to a Server in a Different Tree. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 105
Migrating Compressed Files . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 105
Data Migration for Clustered Volumes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 106
Data Migration for DST Volumes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 106
Data and Trustee Migration in Active Directory Environment . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 108
Transfer ID . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 108
Migration Procedure . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 109
Moving Devices for Migrating the Data from NetWare to OES 2015 or Later. . . . . . . . . . . . . . . . . . . . . . . 109
Migrating File System Using GUI . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 109
Synchronizing File System Using Migration GUI . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 115
Same Tree . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 115
Different Tree . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 116
Migrating File System Using Command Line Utilities . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 116
Migrating Data to a Server in the Same Tree . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 117
Migrating Data to a Server in a Different Tree . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 118
Migrating Data to a POSIX File System . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 123
File System Migration Commands . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 125
Additional Migration Options . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 137
Troubleshooting . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 139
Same Tree Scenario . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 139
Different Tree Scenario . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 140
General Issues . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 141
Part VII Service Migration
145
17 Migrating eDirectory to OES 2018
147
Planning Your Migration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 147
System Requirements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 147
Prerequisites . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 147
Supported Platforms . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 148
Considerations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 148
Troubleshooting . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 148
Migration Tools . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 148
Migration Procedure . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 149
After the Migration. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 150
18 Migrating AFP to OES 2018
151
Migrating AFP from Netware to OES 2018 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 151
Requirements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 151
Migration Scenarios . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 151
Migration Procedure . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 152
Verifying the Migration Process . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 153
Cross-Platform Issues . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 153
Migrating AFP to OES 2018 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 153
What is Migrated . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 154
Prerequisites . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 154
Modifying Thread Range . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 154
Migration Procedure . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 154
Verifying Migration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 155
19 Migrating CIFS to OES 2018
157
Migrating CIFS from Netware to OES 2018 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 157
6
Contents
Migration Prerequisites . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 157
Migration Scenarios . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 157
Migration Procedure . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 158
Post-Migration Procedure . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 162
Verifying the Migration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 162
Man Page for Migration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 163
Migrating CIFS to OES 2018 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 166
What is Migrated . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 166
Prerequisites . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 166
Migration Procedure . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 166
Post Transfer ID Migration Procedure . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 167
Verifying Migration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 168
20 Migrating DHCP to OES 2018
169
Migrating DHCP from Netware to OES 2018 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 169
Migration Requirements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 169
Migrating DHCP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 170
Migration Scenarios . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 177
Migrating a Cluster . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 178
Post-Migration Procedures. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 178
Verifying the Migration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 179
Migrating DHCP to OES 2018. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 179
Planning Your Migration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 180
Migration Scenarios . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 180
Post-Migration Procedure . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 182
Verifying the Migration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 182
21 Migrating DNS to OES 2018
183
Migrating DNS from Netware to OES 2018. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 183
Planning Your Migration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 183
Migration Scenarios . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 184
Migration Procedure . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 184
Post-Migration Procedure . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 185
Migrating DNS to OES 2018 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 185
Planning Your Migration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 185
Migration Scenarios . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 186
Post-Migration Procedure . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 187
22 Migrating DSfW to OES 2018
189
Planning Your Migration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 189
Prerequisites . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 189
What is Migrated . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 189
Migration Procedure . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 190
Post-Migration Procedure . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 191
23 Migrating LUM to OES 2018
193
Planning the Migration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 193
Prerequisite . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 193
Migration Scenarios . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 193
24 Migrating FTP to OES 2018
195
Migrating FTP from Netware to OES 2018 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 195
Planning the Migration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 195
Contents
7
Migration Scenarios . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 195
Migrating FTP. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 196
Post-Migration Procedure . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 197
Migrating FTP to OES 2018 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 198
Prerequisites . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 198
What is Migrated . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 198
Migration Procedure . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 198
25 Migrating iPrint to OES 2018
201
Prerequisites . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 201
Platform Specifications. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 201
General Prerequisites . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 202
Supported Migration Scenarios. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 202
What is Migrated . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 202
Migration Procedure . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 203
Pre-Migration iPrint Configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 203
iPrint Consolidate Migration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 204
Verifying the Result of the iPrint Migration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 211
Transfer ID . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 211
Migrating an iPrint Cluster Resource . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 211
Migrating ZENworks iPrint Policies . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 212
Policy Migration in ZENworks 10 Configuration Management . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 213
Policy Migration in ZENworks 7 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 214
Verifying Migration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 215
Using iManager . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 215
Using the Command Line . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 215
Cleaning Up Stale Objects . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 215
Troubleshooting iPrint Migration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 216
iPrintmig Man Page. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 222
iprintmig . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 223
26 Migrating NetStorage to OES 2018
229
Migrating NetStorage to OES 2018 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 229
Prerequisites . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 229
Migration Procedure . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 229
27 Migrating NTP to OES 2018
233
Planning the Migration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 233
Migration Scenarios . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 233
Migration Procedure . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 233
Using the Migration Tool to Migrate Servers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 234
Using the Command Line to Migrate Servers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 234
Post-Migration Procedure . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 234
28 Migrating NCP to OES 2018
235
Prerequisites . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 235
What is Migrated . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 235
Migration Procedure . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 235
29 Migrating OpenSLP to OES 2018
237
What is Migrated . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 237
8
Contents
Prerequisites . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 237
Migration Procedure . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 237
Verification . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 238
30 Migrating Proxy users to OES 2018
239
What is Migrated . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 239
Transfer ID Migration Procedure. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 239
Using Migration GUI for Proxy Migration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 239
Using the Migration Commands for Proxy Migration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 240
Troubleshooting . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 241
Enabling SSH . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 242
Contents
9
10
About This Guide
This guide describes the functionality and usage of the Open Enterprise Server 2018 (OES 2018)
migration tool. This guide covers the following topics:
 Chapter 1, “Overview of the Migration Tools,” on page 15
 Chapter 2, “Overview of the Migration GUI,” on page 21
 Chapter 3, “What’s New or Changed in the Migration Tool,” on page 37
 Chapter 4, “Planning for Migration,” on page 41
 Chapter 5, “Using the Migration Tool GUI,” on page 45
 Chapter 6, “Troubleshooting Issues,” on page 49
 Chapter 7, “Preparing for Server Migration,” on page 53
 Chapter 8, “Using the Migration GUI Tool,” on page 55
 Chapter 9, “Preparing for Transfer ID,” on page 61
 Chapter 10, “Using the Migration GUI Tool for Transfer ID,” on page 67
 Chapter 11, “Using Migration Commands for Transfer ID,” on page 75
 Chapter 12, “Running Transfer ID Remotely,” on page 85
 Chapter 13, “Post Transfer ID Migration,” on page 87
 Chapter 14, “Troubleshooting Issues,” on page 91
 Chapter 15, “Security Considerations for Data Migration,” on page 97
 Chapter 16, “Migrating File Systems to OES 2018,” on page 103
 Chapter 17, “Migrating eDirectory to OES 2018,” on page 147
 Chapter 18, “Migrating AFP to OES 2018,” on page 151
 Chapter 19, “Migrating CIFS to OES 2018,” on page 157
 Chapter 20, “Migrating DHCP to OES 2018,” on page 169
 Chapter 21, “Migrating DNS to OES 2018,” on page 183
 Chapter 22, “Migrating DSfW to OES 2018,” on page 189
 Chapter 23, “Migrating LUM to OES 2018,” on page 193
 Chapter 24, “Migrating FTP to OES 2018,” on page 195
 Chapter 25, “Migrating iPrint to OES 2018,” on page 201
 Chapter 26, “Migrating NetStorage to OES 2018,” on page 229
 Chapter 27, “Migrating NTP to OES 2018,” on page 233
 Chapter 28, “Migrating NCP to OES 2018,” on page 235
 Chapter 29, “Migrating OpenSLP to OES 2018,” on page 237
 Chapter 30, “Migrating Proxy users to OES 2018,” on page 239
Audience
This guide is intended for network administrators, installers, and consultants who are involved in
migrating data and services to OES 2018.
About This Guide
11
Feedback
We want to hear your comments and suggestions about this manual and the other documentation
included with this product. Please use the User Comments feature at the bottom of each page of the
online documentation.
Documentation Updates
For the most recent version of the Migration Tool Administration Guide, visit the OES 2018 Web site
(https://www.novell.com/documentation/open-enterprise-server-2018/).
12
About This Guide
I
Overview
I
 Chapter 1, “Overview of the Migration Tools,” on page 15
 Chapter 2, “Overview of the Migration GUI,” on page 21
 Chapter 3, “What’s New or Changed in the Migration Tool,” on page 37
Overview
13
14
Overview
1
Overview of the Migration Tools
1
Migration is the process of migrating services, file system data, and eDirectory information from an
existing NetWare 6.5 or OES servers to an OES 2018 server. The Migration tool now supports
migration of Active Directory trustees. The Migration Toolkit is designed to meet all your migration
needs.
In this document, the supported NetWare and OES servers are referred to as the source server, and
the OES 2018 server is referred to as the target server.
The following topics are discussed in this section:
 “Migration Tool Enhancements” on page 15
 “Different Migration Tools” on page 15
 “Migration Scenarios” on page 16
 “Support Matrix for NetWare and OES Services” on page 18
Migration Tool Enhancements
The Migration Tool has an enhanced graphical user interface (GUI), which enables you to migrate all
the services from the source server to the target server. The Migration Tool uses a plug-in
architecture and is made up of Linux command line utilities with a GUI wrapper.
Features
 Supports migration of AD trustees
 Transfer ID GUI now supports proxy migration from source OES Linux server to target OES 2018
server.
 In Transfer ID, you can perform unattended full repair of eDirectory (existing option in earlier
OES releases) and local eDirectory database and network repair
 Use a Transfer ID scenario to migrate the server identity.
 Create a migration project to migrate multiple services.
 Schedule and run the migration at your convenience.
 Receive an e-mail message indicating the success or failure of the migration process.
 Display the status of the migrating service and display service-specific logs.
 Display the overall progress of migration and display the logs.
 View a summary of the options configured for each service and for the entire migration project.
Different Migration Tools
The following table lists the tool to use for migrating services, depending on the source platform and
target platform.
Overview of the Migration Tools
15
Table 1-1 Migration Tools Matrix
Source Platforms
Target Platforms
Migration Tool
For Information
From any of these physical
servers:
To this physical or
virtualized server:
Migration Tool
Chapter 2, “Overview of
the Migration GUI,” on
page 21
 OES 2018
 OES 2018
 OES 2015 SP1
 OES 2015
 OES 11 SP3
 OES 11 SP2
 OES 2 SP3 Linux on SLES
10 SP4
 NetWare 6.5 SP8
From any of these physical
servers:
 NetWare 5.1 SP8
To this physical or
virtualized server:
 NetWare 6.5 SP8
Server
Server Consolidation and
Consolidation
Migration Toolkit
Migration Toolkit 1.2 Administration Guide
Migration Scenarios
The Migration Tool supports the following scenarios:
 “Migrate” on page 16
 “Transfer ID” on page 18
Migrate
The Migrate scenario helps you reorganize your network by copying the service configuration and
data from any number of source servers to the target server. By consolidating data on new, more
powerful servers, you can simplify your network administration processes and lower your IT costs.
This section describes example scenarios of how to consolidate your data.
 “Sample Scenarios” on page 16
 “Cross-Platform Data Consolidations” on page 18
Sample Scenarios
The benefits of the Migration Tool can be better understood through examining some sample
scenarios.
 “Basic Server Consolidation: Many-to-One” on page 17
 “Consolidating Data from Multiple Servers onto a Two-Node Cluster” on page 17
16
Overview of the Migration Tools
Basic Server Consolidation: Many-to-One
In this scenario (see Figure 1-1), you have three existing OES servers. You recently purchased a
multiprocessor server and installed OES 2018 on it. You want to copy the data from each of the three
servers to the single OES 2018 server. Instead of manually moving all the data or backing up the data
on each of the three servers and then restoring it on the OES 2018 server, you can use the Migration
Tool to automate the process.
Figure 1-1 Many-to-One Server Consolidation
eDirectory Tree
Server 1 Server 2 Server 3
MP Server
Data
Volumes
Migration
Although Figure 1-1 shows a consolidation scenario in which all servers are in the same eDirectory
tree, you can also perform tree-to-tree consolidations.
Consolidating Data from Multiple Servers onto a Two-Node Cluster
In this scenario (see Figure 1-2), you have five existing OES servers. You recently purchased two
multiprocessor servers and the necessary hardware to create a two-node cluster complete with an
attached Storage Area Network (SAN). You decide to install OES 2018 on the two-node cluster and to
copy the data from each of the five servers to the SAN on the two-node cluster. Instead of manually
moving all the data and Printer Agents or backing up the data and restoring it to the SAN, you can use
the Migration Tool, which automates the data migration process.
Overview of the Migration Tools
17
Figure 1-2 Cluster Server Consolidation
Cross-Platform Data Consolidations
The Migration Tool supports cross-platform data consolidations from supported NetWare or OES
servers to an OES 2018 server.
Transfer ID
Transfer ID is a migration scenario for transferring the server identity of the source server to the target
server. The identity of the server is made up of its IP address, hostname, eDirectory identity, NICI
keys, and the certificates from the source server. This scenario is only supported in same tree
migration.
On successful completion of the Transfer ID migration, the target server functions with the identity of
the source server and the source server goes offline.
Support Matrix for NetWare and OES Services
The Table 1-2 lists the support for the source platforms for OES 2018 services.
The legends used in the following table are:
Supported source platform
Unsupported source platform
18
NA
Service is not available on that platform
*
iFolder 2
Overview of the Migration Tools
Table 1-2 Source Platform Support for OES 2018 Services
Services
NW 6.5
OES 2
SP8
SP3 (SLES
10 SP4)
OES 11 SP2 OES 11
SP3
OES 2015
OES 2015 OES 2018
SP1
AFP
CIFS
DHCP
DNS
DSfW
FTP
iFolder
*
NA
iPrint
NetStorage
NCP
NA
NSS
NTP
NA
NA
NA
NA
NA
NA
NetWare
Traditional
NA
NA
NA
NA
NA
NA
OpenSLP
NOTE: If the source platforms are NW 5.1, NW 6.0 SP5, OES 1, OES 2 SP2, or OES 11, you must
upgrade to the supported source platform listed in the above table.
Detailed information on configuring and migrating the above services is documented in Part VII,
“Service Migration,” on page 145.
Overview of the Migration Tools
19
20
Overview of the Migration Tools
2
Overview of the Migration GUI
2
This section describes the different panes in the Migration Tool GUI.
 “Project Pane” on page 21
 “Migration Pane” on page 29
 “Services to Migrate Pane” on page 31
 “Migration Status” on page 33
Figure 2-1 Migration Tool GUI
Project Pane
This is the left pane. You use it to access common project options:
 “Create Project” on page 22
 “Schedule Service” on page 23
 “Email Notification” on page 24
Overview of the Migration GUI
21
 “View Logs” on page 26
 “Project Summary” on page 28
 “Help” on page 28
 “Quit” on page 28
 “Whiteboard” on page 28
Figure 2-2 Project Pane
Create Project
When you start Migration Tool GUI, a default project opens. You can save that project, create a new
project or open an existing migration project.
 “New Project” on page 22
 “Load Project” on page 23
 “Save Project” on page 23
New Project
To create a new project, click New Project. Specify the location to create the new project.
Figure 2-3 New Project
22
Overview of the Migration GUI
Load Project
To open an existing migration project, click Open Project. Select the project, then click Open.
Save Project
To save a migration project, click Save Project, then click Yes. Click No to save the project to a
different location.
For example, /var/opt/novell/migration/NewProj1.xml. The migration project file
NewProj1.xml is saved to the default location.
Schedule Service
You can schedule the migration project to run at your convenience.
Figure 2-4 Scheduler
Use the scheduler to perform the following tasks:
 “Configure” on page 23
 “View” on page 24
Configure
You can schedule the migration project to run on multiple days.
1 Select the date in the calendar.
2 Specify the Start Time to run the project.
3 Specify the Duration to run the project.
Overview of the Migration GUI
23
4 Click OK to save the schedule.
5 In the main migration window, click Migrate to migrate the service, or click Sync, to synchronize
the data at the specified time.
The migration project runs on the scheduled date and time.
View
Use this tab to see the week view of the scheduled project.
Email Notification
You can set email notifications for receiving the status of the migration.
Figure 2-5 Notification
 “Email” on page 24
 “Configure” on page 25
Email
1 In the To field, type the e-mail address of an individual or group to receive notifications. You can
include multiple e-mail addresses separated by a comma.
2 In the From field, type the e-mail address that the notification e-mail messages will be sent from.
3 Under Mail Notification On, select the option to generate mail.
If you select all the options, you receive notification through mail, depending on the state of
migration. For example, when migration fails, you receive an e-mail message notifying you that
migration has failed.
4 Click OK to save the settings.
24
Overview of the Migration GUI
Configure
1 In the Server field, specify the hostname or IP address of the recipient's inbound mail queue.
2 Specify the port for the recipient's mail server. In non-secure mode the default port is 25.
3 To send an e-mail message through a secure SMTP connection, select StartTLS.
For example, to send an e-mail to a gmail account, the IP address is gmail-smtp-in.l.google.com
and the port is 26.
4 Specify the mail interval (in minutes) to send e-mail messages for errors encountered. The
default time is 15 minutes, but you can increase or decrease the interval as necessary. The email messages are sent only if error notification in the Email tab is set and if errors are
encountered.
NOTE: To set default mail settings for multiple projects, update the details in the
migconf.properties file.
The e-mail settings can be set by using the /opt/novell/migration/plugin/conf/
migconf.properties file. Update the values for the following parameters according to your
requirements:
 mail_server_ip
 mail_server_port
 mail_to
 mail_from
 populate_values_from_httpstkd
However, if you want default e-mail settings specified in /etc/opt/novell/httpstkd.conf file,
then set the populate_values_from_httpstkd parameter to yes in the migconf.properties file.
5 Click OK to save the settings.
Overview of the Migration GUI
25
View Logs
In the main Migration GUI, click View Logs. This displays Migration Logs window with logs for overall
migration and service-specific migration. You can select Migration or a service and use the search
functionality to filter logs for specific type of error messages or keywords, the results are displayed in
a new search window. By default, only the last log file is filtered and results are displayed. You must
select the Include All Files option to search all log files for a service.
Figure 2-6 Migration Logs
The overall progress of migration, sync, and errors are recorded in the common migration file migration.log and service-specific logs in the servicename.log file. A log directory is created in
the same path as the migration project. The associated output and log files for the project are stored
in this directory. For example, /var/opt/novell/migration/NewProj123/log/migration.log.
For example, if Migration is selected in the left pane, logs from the migration.log file is displayed in
the right pane.
During migration, if a fatal error is encountered, migration is stopped and details are logged in the log
files.
Search For: Select Migration or a service in the left pane. Specify string in the Search For text box
or select keywords for logs from the drop-down list, then click Search, a new window is displayed with
the search results. To search all the log files for a project, select the Include All Files option.
The keywords are: INFO, DEBUG, WARN, ERROR, and FATAL.
26
Overview of the Migration GUI
NOTE: The input string for search is case-sensitive to search for keywords.
Include All Files: By default, only the last log file is filtered as per the search string and results are
displayed. You must select the Include All Files option to search all the log files for a service.
Configuring Log Files
The log files are overwritten after it reaches the maximum limit. You can increase the log file size or
number of log files as per your log requirement. The changes can be done to the values of the
MaxFileSize and maxBackupIndex parameters in the configuration file at /etc/opt/novell/
migration/Log.xml.
Customize the following parameters for each log file you want to modify:
Parameter
Description
MaxFileSize
Specifies the size of the service.log file (default: 10
MB) and migration.log and filesystem.log (default: 10
MB).
maxBackupIndex
Specifies the maximum number of files created before
the first log file is overwritten.
Default value: 10
For example, you can increase the file size of filesystem.log to 10 MB by editing the MaxFileSize
value in the Log.xml file.
Overview of the Migration GUI
27
Project Summary
This displays a tree view of the options configured for all the services selected for migration.
Figure 2-7 Project Summary
Help
This displays the help for the Migration Tool.
Quit
This closes the migration window and stops the migration process. If the migration project is not
saved, you are prompted to save the project.
Whiteboard
This display instructions and tips to perform a successful migration.
28
Overview of the Migration GUI
Migration Pane
This is the top pane of the Migration Tool GUI.
Figure 2-8 Top Pane
Use this pane to perform the following tasks:
 Authenticate the source server and target server credentials.
 Select the type of migration as Migrate or Transfer ID. The Migrate option is enabled only after
configuring a service for migration. By default, only the Transfer ID option is enabled.
Authenticate Source Server and Target Server
Specify the credentials to authenticate the source server and target server.
Figure 2-9 Source Server Authentication Screen
1 In the Server field, specify the IP address or hostname of the source server.
Overview of the Migration GUI
29
The server IP, user name and port information is cached by the Migration GUI. When entering
values in the Server or User Name field, Migration GUI auto-fills this information. To clear the
cache entries, delete the entries from the /opt/novell/migration/plugin/conf/
migration.history file.
(Optional) Is Cluster Resource: To migrate cluster volumes, specify cluster resource IP in the
Server field and select the Is Cluster Resource option. If you select this option, only the file
system and iPrint services are migrated. This option supports only Migrate scenario and does
not support Transfer ID.
For example, use the NSS Cluster Pool IP to migrate NSS cluster volumes and use the iPrint
cluster IP to migrate iPrint.
Use the node IP address for migrating other services.
2 In the User Name field, specify the FDN of the admin user of the source server. Use the LDAP
(comma-delimited) format. For example, cn=admin,o=novell
3 In the Password field, specify the password for the admin user who is performing the migration.
4 If the source server is OES, specify the password for authentication in the Root Password field.
5 In the Port field, specify the port number to use for the SSL connection on the source server. By
default, port 636 is used for the SSL connection and port 389 for the non-SSL connection.
6 (Optional) To use a secure connection for LDAP authentication, select Use SSL.
7 Click OK to authenticate the credentials on the source server.
In the Target Server Authentication dialog box there is no field available to specify the IP address or
the hostname because the Migration Tool is launched from the target server.
If the source and target servers are in the same tree, the credentials on the target server are
automatically populated when the credentials on the source server are authenticated.
Figure 2-10 Target Server Authentication Screen
1 Specify the credentials of the administrator of the target server.
2 Specify the root password.
3 (Optional) To use a secure connection for LDAP authentication, select Use SSL.
4 Click OK.
30
Overview of the Migration GUI
Type of Migration
On successful authentication of the source server and target server, the IP address or the DNS name
of the servers are displayed below the server icons.
1 Depending on your requirements, select the migration type:
 Migrate: Select this option, if you want to consolidate the services from the source server
into an already running instance of the service on the target server. The source server and
the target server can be in the same eDirectory tree or a different eDirectory tree. This
option is enabled only after configuring a service for migration.
 Transfer ID: Select this option to transfer the server identity of the source server to the
target server. The source server and the target server must be in the same eDirectory tree.
2 To configure the services for migration, see “Services to Migrate Pane” on page 31
Services to Migrate Pane
This is the central pane. Use this pane to select the services that you plan to migrate, and configure
the options. When multiple services are configured for migration, the order represents the sequence
for migration of the services.
IMPORTANT: You must install all the services on the target server that you plan to migrate from the
source server.
For a list of service migration chapters and their corresponding documentation, see the Part VII,
“Service Migration,” on page 145.
You use this pane to perform the following tasks:
 Select and configure services for migration.
 Synchronize the migrated service with the service on the source server.
 View the configuration summary of the service.
Figure 2-11 Services to Migrate
Options
 Add: The Add Services dialog box displays a list of services to be migrated to the target server.
Services that are not installed on the target server prior to the migration are not listed.
Overview of the Migration GUI
31
NOTE: If the Source server is OES, the Add Services dialog box displays only File System and
iPrint service. Only these two services can be migrated using GUI.
Figure 2-12 List of Services to Migrate from NetWare Source Server
 Remove: In the Services to Migrate pane, select the service you do not want to migrate and
click Remove.
 Order: The number indicates the order in which each service migrates. The order is displayed
by the migration tool and cannot be edited.
 Service: Lists the name of service to be migrated.
 Status: Displays the status of the service and last executed date and time of migration or
synchronization of a service.
The services can be in different states during migration:
State
Description
Not Configured
The service is not configured.
Password Required
Configuration of a service is not complete.
Ready
The service is configured and ready to migrate.
Migrating
The service is in the process of migration.
Migrated
The service is migrated to the target server.
Synced
The service on the target server is updated with the changes on the source
server.
 Dependencies: Lists the dependent services to be migrated. The migration process progresses
independently of whether the dependency is completed.
 Configure: Select the service to prepare for migration, then click Configure.
 Sync: This option is enabled when you are synchronizing the file system or CIFS services. The
service details on the target server are compared with the source server and only the changed
information is migrated to the target server. Select the service, then click Sync.
 Summary: A tree view that displays migration options configured for a selected service.
32
Overview of the Migration GUI
To select the services to migrate:
1 Click Add to display the list of services available for migration.
2 In the Add Services window, select the services to migrate, then click OK.
In the Status column, the status of the unconfigured services is listed as Not Configured.
3 Select the service, then click Configure to configure the migration options.
Details to configure and migrate the services are documented as an Appendix in this guide.
NOTE: The services are listed depending on the source operating system, support for different types
of migration scenarios (Migrate and Transfer ID) and the services installed on the target server.
Migration Status
Displays the service status and logs.
 “Status” on page 33
 “Service Information” on page 33
Status
Displays the status of the selected service. If a service is in a migrating state, the progress of the
migration is displayed.
State
Description
Ready
The service is configured and ready to migrate.
Precheck
The prerequisites and migration options configured for each service are
validated.
Migrate
The service is in the process of migration.
Sync
The migrated service is being synchronized with the service on the source
server.
Service Start Time: The date and the time when migration started for a specific service.
Service Elapsed Time: The execution time of service migration.
Remaining Time: The time remaining to complete migration of a service.
Project Start Time: The date and the time when migration started for a specific complete project.
Project Elapsed Time: The execution time of project migration.
Progress bar: The progress of migration for a service.
Service Information
The tree view displays the progress of migration and sync for each service.
Overview of the Migration GUI
33
Migrate - Tree View for All Services
Service State: The current state of migration for a service whether it is Ready, Precheck, Migrate or
Sync.
Progress Status: The progress of migration for a service. For example, Successfully Completed
Migration Status: The status of migration for a service. For example, Complete
Migrate - Tree View for File System
Number of files/folders to migrate: The total number of files and folders on the source server that
are to be migrated to the target server.
Number of files/folders migrated: The total number of files and folders successfully migrated to the
target server.
Data to be migrated: The amount of data on the source server that is to be migrated to the target
server.
Migrated data: The amount of data successfully migrated to the target server.
Trustee errors: The number of errors encountered when performing trustee migration. The error
details are recorded in the filesystem.log file.
Total errors: The total number of errors encountered when performing migration. Click the link to
display the service-specific log file.
Migration Start Time: The date and time when migration starts for a project.
Migration End Time: The date and time when migration is completed.
Sync - Tree View for All Services
Service State: The state of sync for a service.
Progress State: The progress of sync for a service.
Sync Status: The status of sync for a service.
Sync - Tree View for File System
Number of files/folders to sync: The total number of files and folders on the source server that are
modified and need to be synced to the target server.
Number of files/folders synced: The total number of files and folders successfully synced to the
target server.
Data to be synced: The amount of data on the source server that is to be synced to the target
server.
Synced data: The amount of data successfully synced to the target server.
Trustee errors: The number of errors encountered when syncing trustees. The error details are
recorded in the filesystem.log file.
Total errors: The total number of errors encountered when performing sync. Click the link to display
the service-specific log file.
34
Overview of the Migration GUI
Number of files/folders deleted on target: The total number of files and folders that are deleted
from the target server because those files and folders were deleted from the source server.
Sync Start Time: The date and time when synchronization of service starts for a project.
Sync End Time: The date and time when synchronization of services is completed.
Overview of the Migration GUI
35
36
Overview of the Migration GUI
3
What’s New or Changed in the Migration
Tool
3
This section describes enhancements and changes in the Migration Tool, beginning with the initial
release Open Enterprise Server (OES) 2018.
What’s New (OES 2018)
Migration Tool in OES 2018 has been modified for bug fixes. There are no new features or
enhancements in OES 2018.
What’s New or Changed in the Migration Tool
37
38
What’s New or Changed in the Migration Tool
II
Getting Started
I
 Chapter 4, “Planning for Migration,” on page 41
 Chapter 5, “Using the Migration Tool GUI,” on page 45
 Chapter 6, “Troubleshooting Issues,” on page 49
Getting Started
39
40
Getting Started
4
Planning for Migration
4
The following topics are discussed in this section:
 “Prerequisites” on page 41
 “Preparing the Source Server for Migration” on page 42
 “Preparing the Target Server for Migration” on page 42
 “Installing and Accessing the Migration Tool” on page 43
 “What’s Next” on page 43
Prerequisites
 “Source Server Requirements” on page 41
 “Target Server Requirements” on page 42
 “Unsupported Target Platforms” on page 42
The Migration Tool is installed as part of the Open Enterprise Server (OES) 2018 installation. The
source server and the target server must meet the requirements outlined in this section.
 Platform Support for the Source Server:
 OES 2018
 OES 2015 SP1
 OES 2015
 OES 11 SP3
 OES 11 SP2
 OES 2 SP3 Linux on SLES 10 SP4
 NetWare 6.5 SP8 and eDirectory 8.7.3.x or later
 Platform Support for the Target Server:
 OES 2018
 Time Synchronization: The source and target servers must be using the same time
synchronization method. For more information on time synchronization, see “Time Services” in
the OES 2018: Planning and Implementation Guide.
Source Server Requirements
The source server contains the files, volumes, and eDirectory objects that are to be copied to the
target server.
 The source server must be running supported versions of NetWare or OES and eDirectory.
 Update the source server with the latest NetWare and OES Support Pack.
 Ensure that the user performing the migration has read/write/access rights on the source server.
Planning for Migration
41
Target Server Requirements
 Ensure that the user performing the migration has read/write/access rights on the target server.
Unsupported Target Platforms
Novell does not support the following as Migration Tool target server:
 Novell Open Workgroup Suite - Small Business Edition
Preparing the Source Server for Migration
1 Shut down any applications, products, or services (virus scan software, backup software, etc.)
running on the server to be migrated.
2 Verify the health of eDirectory by loading DSRepair with the following three options:
 Unattended Full Repair
 Time Synchronization
 Report Synchronization Status
If errors are reported, resolve them before attempting migration.
3 (Recommended) Back up eDirectory data and trustees on the source server, even though the
source data is not modified during migration.
For information on creating a backup of eDirectory, see Backing Up and Restoring eDirectory in
the NetIQ eDirectory Administration Guide.
4 Remove any unnecessary applications, then delete and purge unused files and folders.
5 Ensure that all the latest patches are installed.
Preparing the Target Server for Migration
1. Back up the eDirectory information on the target server.
For information on creating a backup of eDirectory, see “Backing Up and Restoring NetIQ
eDirectory” in the NetIQ eDirectory Administration Guide.
2. Make sure that you have installed and configured the services that you are migrating from the
source server.
IMPORTANT: If a service is not available on the target server, it is not listed in the Migration Tool
GUI.
42
Planning for Migration
Installing and Accessing the Migration Tool
The Migration Tool is automatically installed with the OES 2018 (target server) server in the /opt/
novell/migration/sbin folder. We recommend you to set the screen resolution to 1024X768
before launching the Migration Tool GUI.
Log in as the root user and use one of the following methods to access the Migration Tool on your
target server:
 Desktop: Click Applications > Other > Novell Migration Tools.
 Console: At the terminal prompt, enter:
miggui
What’s Next
To get started with the Migration Tool GUI, see “Using the Migration Tool GUI” on page 45.
Planning for Migration
43
44
Planning for Migration
5
Using the Migration Tool GUI
5
This section describes how to migrate data from supported source server version to an OES 2018
server.
After you have completed the prerequisite procedures in Chapter 4, “Planning for Migration,” on
page 41, you are ready to perform migration. To do this, complete the following tasks in the order they
are listed:
 “Getting Started” on page 45
 “Launch the Migration Tool Utility” on page 45
 “Migration Process” on page 45
Getting Started
The Migration Tool is automatically installed with OES 2018 in the /opt/novell/migration/sbin
folder.
IMPORTANT: To perform migration, you must be a root user and an eDirectory administrator.
Launch the Migration Tool Utility
We recommend you to set the screen resolution to 1024X768 before launching the Migration Tool
GUI.
Log in as the root user and use one of the following methods to access the Migration Tool on your
target server:
Desktop: Click Applications > Other > Novell Migration Tools.
Console: At the terminal prompt, enter:
miggui
Migration Process
1 Launch the Migration Tool.
2 Do one of the following to create, open, or save the migration project:
 To create a new migration project, click New Project, specify the name of the project, then
click OK.
 To open an existing project, click Open Project, then select the project and click Open.
When a confirmation message to open the project is displayed, click Yes.
 To save a project, click Save Project > Yes.
3 Specify the credentials of the source server, then click OK.
Using the Migration Tool GUI
45
4 Specify the credentials of the target server, then click OK.
5 Depending on your requirements, select the migration type:
 Migrate: To perform migration, see Chapter 7, “Preparing for Server Migration,” on page 53
 Transfer ID: To perform a Transfer ID, see Part IV, “Transfer ID Migration,” on page 59.
6 In the Services to Migrate pane, select the services to migrate from the source server to the
target server.
Only the services installed on the target server are listed for migration.
6a To display the list of services for migration, click Add.
6b In the Add Services window, select the services to migrate, then click OK.
7 Select the service for which you want to configure the migration options, then click Configure.
8 Click Migrate to proceed with migration. The status of the service changes to Migrating.
46
Using the Migration Tool GUI
In Status > Service Status, you can view the progress of migration. When the migration is
complete, the status of the service changes to Migrated.
In Status > Service Information, the tree view displays the progress of migration for each
service. The Trustee errors and Total errors, displays the number of error encountered on
performing migration. Click Total errors to view the service-specific log file.
Using the Migration Tool GUI
47
48
Using the Migration Tool GUI
6
Troubleshooting Issues
6
 “Source Server Authentication Fails in an Cluster Environment” on page 49
 “Clear User Name Entries Populated in the Source or Target Authentication Screen” on page 49
 “Unable to Authenticate to Source or Target Server Using Non-SSL Option” on page 49
 “Target Server Authentication Fails or Unable to Browse the eDirectory Tree in the Migration
GUI” on page 50
 “The Authentication Dialog Box is Blank” on page 50
Source Server Authentication Fails in an Cluster
Environment
If NCS is configured after OES configuration, then SMS is not registered with NCS. This causes
authentication failure of the source server if the IS Cluster Resource option is selected.
To resolve this issue, restart SMDR or unload and load TSA components of SMS, then autheticate to
the source server.
Clear User Name Entries Populated in the Source or
Target Authentication Screen
The server IP, user name and port details provided in the Source Server Authentication screen and
the Target Server Authentication screen is cached by the Migration GUI. When entering a user name
the values are auto-filled by the Migration GUI; to clear these cache entries, delete the
MIGFW_SOURCE_USERNAME and MIGFW_TARGET_USERNAME entry from the /opt/novell/
migration/plugin/conf/migration.history file.
Unable to Authenticate to Source or Target Server
Using Non-SSL Option
In the Source Server Authentication screen or the Target Server Authentication screen, if the Use SSL
option is not selected, then authentication to the server fails.
 If you do not want to use a secure connection, deselect the Use SSL option.
When this option is not selected, you must ensure that TLS is disabled for LDAP on the source
server. Using iManager > LDAP > LDAP Options > LDAP Group-server_name > Authentication
Options and deselect Require TLS for Simple Binds with Password.
 To use a secure connection, select the Use SSL option (default setting).
When this option is selected, you must ensure that TLS is enabled for LDAP on the source
server. Using iManager > LDAP > LDAP Options > LDAP Group-server_name > Authentication
Options and select Require TLS for Simple Binds with Password (it is selected by default).
Troubleshooting Issues
49
Target Server Authentication Fails or Unable to
Browse the eDirectory Tree in the Migration GUI
Description: If you execute the Migration GUI on a new OES 2018 server, the target server
authentication fails or the Services panel is unable to display eDirectory objects on browsing the tree
or LDAP secure bind fails displaying an empty eDirectory tree.
The Migration Tool creates a private Java certificate store on first-time authentication to the target
server. This store is used by Java Security Provider for all the SSL communications. When you
launch the Migration Tool for the first time, the keystore does not exist, the LDAP bind fails during
authentication or when performing an eDirectory search.
Action: The error is resolved on performing the following steps:
1 Save the migration project.
2 Close the Migration Tool GUI.
3 Start the Migration Tool GUI.
4 Start the migration project saved in Step 1.
5 Configure the service.
eDirectory objects are now available in the service GUI.
The Authentication Dialog Box is Blank
Description: When you switch from a desktop or any window to the Source Server Authentication or
the Target Server Authentication dialog box, the Migration Tool displays a blank authentication dialog
box.
This is an issue that occurs randomly. The authentication details are not lost, but you see a blank
dialog box.
Action: Close the dialog box and open it again. All the details in the authentication dialog box are
retained.
50
Troubleshooting Issues
III
Server Consolidations
I
 Chapter 7, “Preparing for Server Migration,” on page 53
 Chapter 8, “Using the Migration GUI Tool,” on page 55
Server Consolidations
51
52
Server Consolidations
7
Preparing for Server Migration
7
To prepare your source server and target server for migration, complete the tasks in the following
sections:
 “Prerequisites” on page 53
 “Migration Support Matrix” on page 53
Prerequisites
 Ensure that the source server and target server are running with the supported versions of the
NetWare, or Linux server software. For more information, see “Support Matrix for NetWare and
OES Services” on page 18.
 The target must be running Open Enterprise Server (OES) 2018 with the following components
enabled:
 NetIQ eDirectory
 NCP Server for Linux
 Storage Management Services (SMS)
For more information on installing and configuring OES, see the OES 2018: Installation Guide.
Migration Support Matrix
To migrate a service, you must select the Migrate scenario. Depending on the service, the Migrate
scenario either migrates or consolidates the service.
The Table 7-1 explains the behavior of the service on selecting the Migrate scenario.
 Overwrites the existing configuration: The service configuration on the target server is
overwritten with the service configuration from the source server.
 Append to existing configuration: The service configuration on the target server is appended
with the service configuration from the source server.
Table 7-1 Support Matrix
Services
Migrate
Details
Overwrites the
existing
configuration
Append to the existing
configuration
AFP
No
Yes
CIFS
CIFS configuration
 Shares
 Context
“Migration Scenarios” on
page 151
“Migrate - Same Tree” on
page 158
Preparing for Server Migration
53
Services
54
Migrate
Details
DHCP
No
Yes
“Consolidation” on page 178
FTP
Yes
No
“Migration Scenarios” on
page 195
iPrint
No
Yes
“Supported Migration Scenarios”
on page 202
NTP
No
Yes
“Migration Scenarios” on
page 233
Preparing for Server Migration
8
Using the Migration GUI Tool
8
After you have completed the general prerequisites in Chapter 4, “Planning for Migration,” on page 41
and prerequisite procedures in Chapter 7, “Preparing for Server Migration,” on page 53, you are
ready to migrate the source server. To do this, complete the following tasks in the order they are
listed:
 “Launch the Migration Tool Utility” on page 55
 “Create the Project File” on page 56
 “Select the Source Server, Target Server, and Migration Type” on page 57
 “Configure the Services” on page 58
 “Run the Migration” on page 58
Launch the Migration Tool Utility
Log in as the root user and use one of the following methods to access the Migration Tool on your
target server:
Desktop: Click Applications > Other > Novell Migration Tools.
Console: At a terminal prompt, enter
miggui
Using the Migration GUI Tool
55
Figure 8-1 Migration Tool GUI
Create the Project File
1 To create a new migration project, click New Project. Type the path to the project in the Location
field or browse to the location and click Save.
The filename can include any character except \ *? < > | " /. The project name also serves as the
project's folder name, so you might want to keep it short. The project folder stores the log files
and other files associated with the project.
or
To open an existing migration project, click Open Project. Browse to the project and click Open.
For example, /home/Carla/migration/mig.xml
2 (Conditional) If you want to store the project file in a location other than the default location
provided, click Browse and navigate to the desired location, then click OK.
3 Continue with “Select the Source Server, Target Server, and Migration Type” on page 57.
56
Using the Migration GUI Tool
Select the Source Server, Target Server, and
Migration Type
Specify the credentials to authenticate the source server and target server.
1 Specify the source credentials and click OK.
2 Specify the target server credentials and click OK.
On successful authentication, both the servers change to green.
3 You must configure a service to enable the Migrate button. Continue with “Configure the
Services” on page 58.
4 Click Migrate.
Using the Migration GUI Tool
57
Configure the Services
1 In the Services to Migrate panel, click Add and select the services to migrate to target server.
The Status of the services is Not Configured.
2 Select the service to configure for migration, then click Configure.
On successful configuration, the Status of the service changes to Ready.
IMPORTANT: Before you proceed with migration, ensure that you have met all the prerequisites
and configured the migration options for all the services that are to be migrated to the target
server.
For a list of service migration chapters and their corresponding documentation, see Part VII,
“Service Migration,” on page 145.
3 Continue with “Run the Migration” on page 58.
Run the Migration
1 Click Migrate to proceed with migration.
You can view the service-specific status of the migration or the status of the overall migration:
 In the Status > Service Status tab, you can view the progress of migration. On completion of
migration, the Status of a service changes to Migrated.
 In the Status pane > Service Information tab, you can view the tree view of services
migrating to the target system. A message Migration completed for all Services is
displayed on completion of the migration.
NOTE: If you encounter any errors during migration, click View Logs in the left pane. After
resolving the errors, execute the migration procedure again.
58
Using the Migration GUI Tool
IV
Transfer ID Migration
IV
 Chapter 9, “Preparing for Transfer ID,” on page 61
 Chapter 10, “Using the Migration GUI Tool for Transfer ID,” on page 67
 Chapter 11, “Using Migration Commands for Transfer ID,” on page 75
 Chapter 12, “Running Transfer ID Remotely,” on page 85
 Chapter 13, “Post Transfer ID Migration,” on page 87
 Chapter 14, “Troubleshooting Issues,” on page 91
Transfer ID Migration
59
60
Transfer ID Migration
9
Preparing for Transfer ID
9
To prepare your source server and target server for a Transfer ID project, complete the tasks in the
following sections:
 “Prerequisites” on page 61
 “Preparing the Source Server for Migration” on page 62
 “Preparing the Target Server for Migration” on page 62
 “Preparing Source and Target Server in an Active Directory Environment” on page 63
Prerequisites
 Ensure that the source server and target server are running supported versions of NetWare or
Linux server software. For more information, see “Support Matrix for NetWare and OES
Services” on page 18.
 To perform transfer id using container admin, the container admin must have supervisory rights
on the container he/she exists.
 The source server and the target server must be in the same eDirectory tree.
 The source and target server must be in the same subnet and gateway.
 The source server can either be a replica or a non-replica server in the eDirectory tree.
 The target server must be a non-replica server in the eDirectory tree.
To make the target server as a non-replica server, select the Novell Pre-migration Server option
while installing OES 2018 on the target server.
 Verify the health of eDirectory by executing the ndsrepair command on Open Enterprise Server
with the following three options:
 Unattended Full Repair, execute the command: ndsrepair -U
 Time Synchronization, execute the command: ndsrepair -T
The target server must be time synchronized with the source server. Time across all the
servers in the replica ring should be synchronized.
For more information on time synchronization, see “Time Services” in the OES 2018:
Planning and Implementation Guide.
NOTE: The ndsrepair command locks the eDirectory database, and this results in failure
of the Transfer ID migration. You must ensure that all the eDirectory operations are
complete before performing a Transfer ID migration.
 Report Synchronization Status, execute the command: ndsrepair -E
All the eDirectory replicas are synchronized.
For more information about DSRepair command, see DSRepair Options in the NetIQ eDirectory
Administration Guide
If any errors are reported, resolve them before attempting migration.
 Ensure that the names and properties of the NSS pools and volumes on the target server are the
same as on the source server.
Preparing for Transfer ID
61
 Ensure that all the eDirectory replicas are up and working in the current partition; otherwise,
eDirectory migration cannot be completed successfully.
 Ensure that the hostname and IP address of source server and target server are mapped
correctly. The /etc/hosts file on the source server must contain correct entries for resolving
source server's DNS hostname to IP address.
Preparing the Source Server for Migration
 Shut down any applications, products, or services (virus scan software, backup software, etc.)
running on the server to be migrated.
 (Recommended) Back up all the data of the source server, even though the source server data is
not modified during migration.
For information on creating a backup of eDirectory, see Backing Up and Restoring eDirectory in
the NetIQ eDirectory Administration Guide.
You must back up the data and trustee of the source servers,
 Remove any unnecessary applications, then delete and purge unused files and folders. Files
that are deleted from the source server prior to migration are not migrated to the target server.
 Ensure the NetWare server has a valid license. If Transfer ID is performed on the NetWare
server with evaluation license, then it might fail due to insufficient user connections.
 If the source server is supported OES platform, enable the SSH service. Ensure you have copied
the SSH keys to avoid multiple password prompts on execution of the DIB Copy step. For more
information, see Step 1a on page 70.
 If the source server is NetWare, ensure to comment the line, “LOAD DSMETER” in the
SYS:\SYSTEM\autoexec.ncf file and restart the NetWare server before performing Transfer ID.
 Ensure that the /root/.ssh/known_hosts file contains the entries of both the hostname and its
corresponding IP address.
On successful Transfer ID, the identity of the source server is transferred to the target server
container.
Preparing the Target Server for Migration
 Make sure that the Novell Pre-migration Server option is selected for the target server.
When you install OES 2018 on the target server for a Transfer ID migration and you reach the
Software Selection window, you must select the Novell Pre-migration Server option. This
prepares eDirectory for the Transfer ID migration that you will perform later.
62
Preparing for Transfer ID
Figure 9-1 Novell Pre-migration Server
IMPORTANT: Select the Novell Pre-migration Server option at the start of OES 2018
installation; otherwise, an eDirectory replica is installed on the server and it cannot be the target
server for Transfer ID migration. If the target server already has OES 2018 installed, without the
Novell Pre-migration Server option selected, then selecting this option later does not prepare
the target server for Transfer ID migration until you reinstall OES 2018 and select this option.
 Install the services that you need to migrate from the source server.
If a service is not installed on the target server, it is not listed in the Migration Tool GUI screen for
migration. This is a mandatory requirement.
 Back up the eDirectory information on the target server. For information on creating a backup of
eDirectory, see Backing Up and Restoring eDirectory in the NetIQ eDirectory Administration
Guide.
 If the source server is a VLDB replica, then the target server also must be a VLDB replica.
NOTE: Each DFS management context allows maximum of two VLDB replicas. If your setup has
a source server and a non-target server as a VLDB replica, then you must ensure to remove the
non-target server as VLDB replica and make the target server as a new VLDB replica.
Preparing Source and Target Server in an Active
Directory Environment
In addition to the Transfer ID prerequisites, ensure to meet these specific prerequisites in an Active
Directory environment.
Table 9-1 Transfer ID Support Matrix in Active Directory Scenario
Source Server
Target Server
Source Platform Target Platform Migration Support
Support
Support
NSS AD configured
NSS AD
configured
OES 2015 or later OES 2018
Supported
Preparing for Transfer ID
63
Source Server
Target Server
Source Platform Target Platform Migration Support
Support
Support
NSS AD configured
Only eDirectory OES 2015 or later OES 2018
Not Supported
You can leave the AD
domain and perform
Transfer ID. Post-Transfer
ID rejoin the domain.
Only eDirectory
NSS AD
configured
Supported OES
platform
OES 2018
Not Supported
You can leave the AD
domain and perform
Transfer ID. Post-Transfer
ID rejoin the domain.
Source Server and Target Server are Configured With NSS
AD
 The source server must be configured with OES 2015 or later.
 The target server must be configured with OES 2018.
 The source server and target server must join to the same Active Directory domain. For more
information on joining to an Active Directory domain, see Installing and Configuring NSS AD
Support in the OES 2018: NSS AD Administration Guide.
During the eDirectory Precheck step, the source server’s files /etc/krb5.conf, /etc/krb5.keytab,
/etc/resolv.conf, and /etc/opt/novell/nit/nitd.conf are copied to the target server. In the
Repair step, the target server’s krb5.conf, krb5.keytab, resolv.conf files are replaced with the
backed up source server files. The target server’s nitd.conf file is merged with the backed up
source server’s nitd.conf file.
On successful Transfer ID, the target server will leave the Active Directory domain and the source
server computer domain object will be used.
Source Server is Configured with NSS AD and Target Server
is not in an AD environment
 The source server must be configured with OES 2015 or later.
 The source server must leave the AD domain. For more information, see --leave-domain in the
OES 2018: NSS AD Administration Guide.
Post-Transfer ID, you must join the target server to the AD domain. For more information, see
Installing and Configuring NSS Active Directory Support in the OES 2018: Installation Guide or --join
in the OES 2018: NSS AD Administration Guide.
Source Server is not in an AD environment and Target
Server is Configured with NSS AD
 The target server must be configured with OES 2018.
 The target server must leave the AD domain. For more information, see --leave-domain in the
OES 2018: NSS AD Administration Guide.
64
Preparing for Transfer ID
Post-Transfer ID, you must join the target server to the AD domain. For more information, see
Installing and Configuring NSS Active Directory Support in the OES 2018: Installation Guide or --join
in the OES 2018: NSS AD Administration Guide.
Preparing for Transfer ID
65
66
Preparing for Transfer ID
10
Using the Migration GUI Tool for
Transfer ID
10
After you have completed the prerequisite procedures in Chapter 9, “Preparing for Transfer ID,” on
page 61, you are ready to migrate the source server. To do this, complete the following tasks in the
order they are listed:
 “Understanding Transfer ID GUI” on page 67
 “Launch the Migration Tool Utility” on page 68
 “Create the Project File” on page 69
 “Select the Source and Target Server and the Migration Type” on page 69
 “Configure the Services and Run Migration” on page 69
 “Run Transfer ID” on page 70
Understanding Transfer ID GUI
The Transfer ID GUI runs a series of tasks for transferring the server identity of the source server to
the target server. The identity of the server is made up of its IP address, hostname and the eDirectory
DIB information from the source server.
On successful completion of the Transfer ID migration, the target server functions with the identity of
the source server and source server goes offline
The interface is divided into a left pane and right pane, and each task is associated with an icon that
represents the status of the task.
 “Left Pane” on page 67
 “Right Pane” on page 68
Left Pane
The left pane lists a series of tasks to be completed for successful completion of Transfer ID. Each
task is associated with an icon.
Using the Migration GUI Tool for Transfer ID
67
Table 10-1 Status Icons
Icon
Description
The task is not yet started.
The task is in progress.
The task is complete.
Errors must be resolved before proceeding with the next step. An error is displayed in the
Errors text box.
You can choose to skip this task in the GUI and perform it manually.
Right Pane
 Task Description: A description of the task in progress. The Command Executed field displays
the command executed to perform the task.
 Errors: A description of the error or warnings and a possible resolution. If no resolution is
provided, you can find more information in the Novell Error Code online documentation (http://
www.novell.com/documentation/lg/nwec/index.html).
 Log Messages: Log messages for each executed tasks and the overall Transfer ID.
 Send E-mail Notification: Select this option to receive an e-mail for a main task. An e-mail is
sent only if you have already configured the Email Notification tab in the main Migration GUI
screen. E-mail is not sent for suggests.
 Ignore: Ignores a task and proceeds with the next task.
 Back: Click Back to re-execute a task.
IMPORTANT: When the current task is executed, the changes are committed, using Back on a
completed task does not roll back the changes.
 Next: Click Next to complete the current task and move to the next task.
 Cancel: Click Cancel to close the Transfer ID Wizard and quit the task.
IMPORTANT: The Transfer ID process is canceled, but changes or steps executed earlier are
not rolled back.
Launch the Migration Tool Utility
Log in as the root user and use one of the following methods to access the Migration Tool on your
target server:
Desktop: Click Applications > Other > Novell Migration Tools.
Console: At a terminal prompt, enter
miggui
68
Using the Migration GUI Tool for Transfer ID
Create the Project File
1 To create a new migration project, click New Project. Type the path to the project in the Location
field or browse to the location, then click Save.
The filename can include any characters except \* ? < > | " /. The project name also serves as
the project's folder name, so you might want to keep it short. The project folder stores the log
files and other files associated with the project.
or
To open an existing migration project, click Open Project. Browse to the project and click Open.
For example, /home/Carla/migration/mig.xml
2 (Conditional) If you want to store the project file in a location other than the default location
provided, click Browse and navigate to the desired location, and then click OK.
Select the Source and Target Server and the Migration
Type
Specify the credentials to authenticate the source server and target server.
1 Specify the source credentials, then click OK.
If the Is Cluster Resource option is selected, Transfer ID scenario is not available.
2 Specify the target server credentials, then click OK.
On successful authentication, both the servers change to green.
3 You can either migrate all the services to the target server and then transfer the NetWare or OES
server’s identity, or only transfer NetWare or OES server’s identity to the target server.
3a To migrate services, continue with “Configure the Services and Run Migration” on page 69.
3b To transfer the NetWare or OES server’s identity, click the Transfer ID button.
3b1 Click Yes to perform identity transfer without migrating the services.
3b2 Click No to configure and migrate services, refer to “Configure the Services and Run
Migration” on page 69.
Configure the Services and Run Migration
1 In the Services to Migrate panel, click Add and select the services to migrate to target server.
The Status of the services is Not Configured.
2 To configure a service for migration, click Configure.
On successful configuration the Status of the service changes to Ready.
NOTE: Before you proceed with migration, ensure that you have met all the prerequisites and
configured the migration options for all the services that are to be migrated to the target server.
For a list of service migration chapters and their corresponding documentation, see the Part VII,
“Service Migration,” on page 145.
3 Click Migrate to proceed with migration.
The Status pane displays service-specific migration progress. On completion of migration, the
Status of a service changes to Migrated.
Using the Migration GUI Tool for Transfer ID
69
If you encounter any errors during migration, click View Logs in the left pane. After resolving the
errors, execute the migration procedure again.
In the Status pane, Service Information, you can view the progress of overall migration. A
message Migration completed for all Services is displayed on completion of migration.
4 (Optional) We recommend you to complete synchronization of the services before proceeding
for Transfer ID.
5 (Optional) Back up the eDirectory database and NICI keys. For more information, see “Backup
eDirectory Database and NICI Keys” on page 83.
6 Check the status of the migration. If migration is successful, then perform Transfer ID either by
using GUI or CLI.
 To launch the Transfer ID GUI, click Transfer ID. For more information on performing the
steps in the GUI, see “Run Transfer ID” on page 70.
 To use the command line, see Chapter 11, “Using Migration Commands for Transfer ID,” on
page 75.
Run Transfer ID
Ensure that you have completed the following:
 All the services you need to migrate must be configured on the target server.
 Ensure that all eDirectory processes (such as eDirectory repair) are completed before
performing the Transfer ID scenario. The Transfer ID process locks the DIB (eDirectory
database) on the source server and no operations can be performed.
 Back up the eDirectory database. For more information, see “Backup eDirectory Database and
NICI Keys” on page 83.
IMPORTANT: Some of the steps for Transfer ID need to be performed manually. The GUI displays
messages to ensure that you have completed the manual step. When the manual steps are
completed, click OK to proceed to the next step. If you skip the manual steps, errors are encountered
in the subsequent steps.
The Transfer ID GUI displays tasks you perform to complete the identity transfer.
1 eDirectory Precheck: Click Next.
The eDirectory Precheck step can be executed multiple times to verify the health of the
eDirectory tree. Executing this step does not modify the source server and target server.
On successful completion of this step, the icon adjacent eDirectory Precheck changes to a green
check mark.
1a (Conditional) If the source server is supported version of OES, ensure that you have copied
the SSH keys to avoid multiple password prompts on execution of this step.
1a1 Enable SSH on the source server and the target server.
1a2 Enter the # ssh-keygen -t rsa command on the target server.
1a3 When you are prompted to enter the file in which to save the key (/root/.ssh/
id_rsa), press Enter.
The ssh keys are stored in the default location.
1a4 When you are prompted to enter the passphrase (empty for no passphrase), press
Enter.
We recommend that you do not include the passphrase.
70
Using the Migration GUI Tool for Transfer ID
1a5 Copy the key value (the output of the # ssh-keygen -t rsa command) to the source
server.
# scp ~/.ssh/id_rsa.pub root@<source-server>:/root/
where <source-server> is the IP address or the hostname of the source server.
1a6 Log on to source server by using ssh. If the .ssh directory is not available, create the
directory, then append the key value to the list of authenticated keys.
cat id_rsa.pub >> /root/.ssh/authorized_keys
2 Preparation: Click Next.
The Preparation step removes eDirectory from the target server. The LUM association with the
groups and users is no longer available because the Unix Workstation object is also removed.
This step fails to execute if the prerequisites are not met.
Source Server and Target server in Active Directory environment: If the source server and
target server are in Active Directory environment, additional Domain Authentication screen is
displayed. You must specify the credentials to authenticate to the Active Directory server.
 Domain Name: Specify the Active Directory domain name that the OES server is joined to.
 Administrator Name: Specify the user name that can be used for the domain join
operation. This user should have the following privileges: rights to reset password, create
computer objects, delete computer objects, and read and write the msDssupportedEncryptionTypes attribute.
 Password: Specify the password of the user who is used for the domain join operation.
 Port: Specify the port number for the SSL connection on the Active Directory server. By
default, port 636 is used for the SSL connection and port 389 for the non-SSL connection.
 Use SSL: Select this option to perform Transfer ID by using the SSL connection.
3 DIB Copy: Click Next.
The DIB Copy creates a eDirectory DIB (Directory Information Base) copy of the source server
on to the target server.
On completion of this step, the source server's DIB is locked and further operations are not
permitted on the source server. The eDirectory database and the NICI files are copied to the
target server.
IMPORTANT: This command fails to execute if the replica ring is not in sync, or the time is not
synchronized among all the servers in the replica ring.
The eDirectory database on the source server is locked. The eDirectory database and the NICI
files are copied to the target server.
4 Shutdown Source: Click Next to manually shut down the source server and disconnect it from
the network.
4a You are prompted to confirm that the source server is shut down. Click OK and proceed with
the next step, or click Cancel and shutdown the source server.
5 DIB Restore: Click Next to restore the eDirectory database that was backed up from the source
server in Step 3 on page 71 on the target server. This includes the NICI keys and the eDirectory
related information.
WARNING: If the backup in Step 3 on page 71 was not successful, the DIB Restore step fails. A
failure at this point might cause the target eDirectory server to be unusable.
6 IP Change: Click Next to change the IP address of the services and their configuration files on
the target server to the source server IP address.
Using the Migration GUI Tool for Transfer ID
71
IMPORTANT: Failure of the script to change the IP address, or terminating the operation
manually, might cause the system to hang. For more details, refer to Chapter 14,
“Troubleshooting Issues,” on page 91.
If you are executing the Migration GUI by using a remote session, the Transfer ID wizard hangs
and fails to proceed. For more information, refer Chapter 12, “Running Transfer ID Remotely,” on
page 85.
 System: The target server IP address is overwritten with the source server IP address.
 Services: The configuration files of the migrated services are assigned with the new IP
address of the target server.
 Others: The IP address change scripts located in the nonplugin folder is executed.
Executes the IP address change scripts for the services that are not included in the plug-ins
of the Migration Tool GUI. The IP address change scripts are located in the /opt/novell/
migration/sbin/serveridswap/scripts/ipchange/nonplugin/ folder. If you need to
change the IP address of any additional services, you must add the scripts to the
nonplugin folder.
No e-mail is sent in this step, even if you have selected the settings to receive an e-mail.
7 Hostname Change: Click Next to change the hostname of the system, services and their
configuration files to the source server hostname.
IMPORTANT: Failure of the script to change the hostname or terminating the operation
manually, may cause the system to hang. For more details, refer to Chapter 14, “Troubleshooting
Issues,” on page 91.
 System: The target server hostname is overwritten with the source server hostname.
 Services: The configuration files of the migrated services are assigned with the new
hostname of the target server.
 Others: Executes the hostname change scripts for the services that are not included in the
plug-ins of the Migration Tool GUI. The hostname change scripts are located in the /opt/
novell/migration/sbin/serveridswap/scripts/hostchange/nonplugin/ folder. If you
need to change the hostname of any additional services, you need to add the scripts in the
nonplugin folder.
In this step, the Transfer ID wizard runs the hostname change scripts located in the
nonplugin folder.
NOTE: No e-mail is sent in this step, even if you have selected the settings to receive an email.
8 Reinitialize Server: Click Next to reinitialize the target server with the IP address and hostname
of the source server. eDirectory is also restarted.
9 Repair: Click Next displays an option to perform either of the following eDirectory repair:
 Unattended full repair of eDirectory (existing option in earlier OES releases)
 Local eDirectory database and network repair
The ndsrepair command is used to perform eDirectory repair. Service-specific repairs only run
for services that were migrated using the current project.
 eDirectory: Checks if eDirectory is up and running on the target server. It also runs a repair
on the eDirectory tree.
 Certificates: Repairs the target server certificate and the trusted root certificate.
72
Using the Migration GUI Tool for Transfer ID
 LUM: The following steps are performed during LUM repair:
 Creates a Unix Workstation object.
 Regenerates the certificate for LUM on the target server.
 Associates LUM groups and users to the target servers’s Unix Workstation object.
 Refreshes the LUM cache.
 Services: Repairs the services that are migrated to the target server. If no services are
configured for migration, then the Migration Tool skips this step and icon adjacent to
Services changes to a green check mark.
 Others: Executes the repair scripts for the services that are not included in the plug-ins of
the Migration Tool GUI. The scripts are located in the /opt/novell/migration/sbin/
serveridswap/scripts/repair/nonplugin/ folder. If you need to repair any additional
services, you must add the scripts to the nonplugin folder.
In this step, Transfer ID wizard runs the scripts located in nonplugin folder.
 CleanUp: Lists all the stale objects available on the temporary server. You can select the
stale objects that needs to be deleted from the target server. Click OK to delete the selected
objects.
10 Restart Server: Manually restart your target server for completion of Transfer ID.
The target server now runs with the source server identity.
Continue with Section 13, “Post Transfer ID Migration,” on page 87.
Using the Migration GUI Tool for Transfer ID
73
74
Using the Migration GUI Tool for Transfer ID
11
Using Migration Commands for Transfer
ID
1
Before running Transfer ID, ensure you have met all the prerequisites and prepared your servers as
described in “Preparing the Source Server for Migration” on page 42 and “Preparing the Target
Server for Migration” on page 42.
Before you begin, remember the following considerations:
 All the services you need must be migrated to the target server.
 When you start the Transfer ID process, you cannot perform any operations on the source server
because the process locks the DIB (eDirectory database) on the source server.
Run all the commands on the target server, to perform Transfer ID:
1 eDirectory Precheck: Executes prerequisites that need to be done for Transfer ID scenario.
1a Use the following command to do an eDirectory precheck:
migedir -s <sourceipaddress> -u -A <projectpath> -i -t
For example, /opt/novell/migration/sbin/migedir -s 172.16.100.101 -u -A /
var/opt/novell/migration/NewProj0 -i -t
When prompted, enter the username and password of the source server.
This step can be executed multiple times to verify the health of the eDirectory tree.
Execution of this step does not modify the source server and target server.
1b Check the availability of the hostname and IP address on the source server. The hostname
or IP address can be resolved using the DNS server or using the /etc/hosts file on the
source server (OES Linux) or SYS:etc\hosts file on the NetWare server.
1c The nam.conf file on the target server includes LUM settings that will be required later while
performing the repair steps for migration. Create a backup of /etc/nam.conf file on the
target server by executing the command: cp /etc/nam.conf <Project_path>/
nam.conf.target.
For example: cp /etc/nam.conf /var/opt/novell/migration/NewProj0/
nam.conf.target
1d If the source server is OES, create a backup of the /etc/nam.conf file of the source server.
1e (Conditional) In an Active Directory environment, copy the following files from the source
server to the migration project location on the target server. For example, /var/opt/
novell/migration/NewProj0/.
 /etc/krb5.conf
 /etc/krb5.keytab
 /etc/resolv.conf
 /etc/opt/novell/nit/nitd.conf
1f Retrieve and store the list of LUM enabled groups:
(Conditional) If the source server is NetWare, enter
Using Migration Commands for Transfer ID
75
ruby /opt/novell/migration/sbin/serveridswap/scripts/repair/nam-grpmod.rb
-H <target server short hostname> -a <admindn> -S <ldap-server-ip> --ldapport <port number> -p <password> -l
The above commands displays the list of groups that are LUM-enabled on the target server.
These same groups must be LUM-enabled on completion of Transfer ID.
1g If the source server is OES, ensure that ssh keys to avoid multiple prompts for password on
execution of this step.
To copy the ssh keys:
1. Enable ssh on the source server and target server.
2. Enter the command on the target server, # ssh-keygen -t rsa
On executing the above command, you are prompted for the following:
a. “Enter file in which to save the key (/root/.ssh/id_rsa)”, press Enter.
The ssh keys are stored in the default location.
b. “Enter passphrase (empty for no passphrase)”, press Enter.
We recommend you not to include passphrase.
3. Copy the key value i.e. the output of the above command to the source server
# scp ~/.ssh/id_rsa.pub root@<source-server>:/tmp
4. Log to source server using ssh and add the key value to the list of authenticated keys.
cat /tmp/id_rsa.pub >> /root/.ssh/authorized_keys
1h If the source server is OES, ensure to copy the .nss.dat file to the target server. This file
stores the nss user context information of the source server and is required when we repair
the NSS admin object.
Enter the command on the target server,
scp <Source-IP>:/var/opt/novell/nss/.nss.dat /tmp/
2 Preparation: Removes the eDirectory from the target server. The LUM association with the
groups and users is no longer available because the Unix Workstation object is also removed. In
an AD environment the source server leaves the AD domain.
2a (Conditional) In an Active Directory environment, execute the following command:
2a1 /opt/novell/xad/bin/kinit Administrator@<ad domain name>
This command prompts for the administrator password.
IMPORTANT: Executing kinit is necessary to obtain and cache Kerberos ticketgranting ticket. It is mandatory to obtain the ticket before performing any AD domain
related operations.
2a2 The target server must leave the AD domain, execute the following command:
/opt/novell/bin/novell-ad-util --leave-domain
For more information, see --leave-domain in the OES 2018: NSS AD Administration
Guide.
2b To remove the Unix Workstation object on the target server, enter
/usr/bin/namconfig rm -a <admindn>
In the above command for SSL connection, you must use -l option and specify default port
number as 636.
2c To remove eDirectory from the target server, enter
76
Using Migration Commands for Transfer ID
/opt/novell/eDirectory/bin/ndsconfig rm -c -a <admindn.novell> -w
ADM_PASSWD --config-file /etc/opt/novell/eDirectory/conf/nds.conf
Use dot format when passing values for -a option. For example, -a admin.novell
2d To verify the health of the eDirectory and to ensure that both the source server and target
server are time-synchronized, enter
migedir -s <sourceipaddress> -u -A <projectpath> -i -t
For example, /opt/novell/migration/sbin/migedir -s 172.16.100.101 -u -A /
var/opt/novell/migration/NewProj0 -i -t
When prompted, enter the username and password of the source server.
2e To perform common proxy migration, see “Pre-Migration Procedure” on page 240.
3 DIB Copy: Creates a backup of the eDirectory DIB (Directory Information Base) of the source
server on to the target server. This step locks the DIB of the source server and further operations
are not permitted on the source server.
migedir -s <source-server-ip> - u -A <logfile directory> -i -B
For example, /opt/novell/migration/sbin/migedir -s 172.16.100.101 -u -A /var/
opt/novell/migration/NewProj0 -i -B
On running the above command, you are prompted for the username and password of the
source server. Enter the admin credentials when prompted.
IMPORTANT: This command fails to execute if the replica ring is not in sync, or the time is not
synchronized between all the servers in the replica ring.
NOTE: If you need to perform any operations on the source server, you must unlock the DIB. To
unlock the DIB on the NetWare server, reload the DS.nlm file and on the OES server, restart
ndsd daemon.
4 Shutdown Source: You need to shutdown the source server.
5 DIB Restore: Restores the eDirectory database that was backed up from the source server in
Step 3 on the target server. This includes the NICI keys and the DIB identity.
IMPORTANT: Ensure to backup the target eDirectory database and NICI keys, see “Backup
eDirectory Database and NICI Keys” on page 83 for more information.
5a At the command prompt of the target server, enter
migedir -R
For example, /opt/novell/migration/sbin/migedir -R
On running the above command, you will be prompted for the administrator credentials for
the source server.
WARNING: If the backup in Step 3 on page 77 was not successful, the DIB Restore step
fails. A failure at this point may cause the eDirectory service on the target server to be
unusable.
6 IP Address Change: The IP address of the target server and its services is changed to the
source server IP address.
Using Migration Commands for Transfer ID
77
The scripts to be executed in this step are located in the /opt/novell/migration/sbin/
serveridswap/scripts/ipchange and /opt/novell/migration/sbin/serveridswap/
scripts/ipchange/nonplugin folders.
 To change the IP address of the server in the /opt/novell/migration/sbin/
serveridswap/scripts/ipchange folder, enter
ruby server-yast-ipchange.rb --old-ip <target_server IP> --ip
<source_serverIP>
For example, ruby server-yast-ipchange.rb --old-ip 172.16.200.201 --ip
172.16.100.101
 The ipchange folder contains a list of scripts that need to be executed for changing the IP
address. An example to change the IP address of the services on the target server by using
the iprintipchange.sh script in the /opt/novell/migration/sbin/serveridswap/
scripts/ipchange/nonplugin folder, enter
<server-script> <target_server IP> <source_server IP> <source_server IP>
<source_server IP>
For example, iprintipchange.sh 172.16.200.201 172.16.100.101 172.16.100.101
172.16.100.101
You also need to run the remaining scripts for other services in the same manner.
WARNING: Failure of the script to change the IP address or terminating the operation
manually, may cause the system to hang. If a service-specific IP address script fails to
change the IP address, replace the <service>.conf file with <service>.orig file.
For example, if eDirectory authentication fails on completion of IP Change step, do the
following:
cp /etc/opt/novell/eDirectory/conf/nds.conf.orig /etc/opt/novell/
eDirectory/conf/nds.conf
 To change the IP address for the configuration files of each service on the target server
enter the following in the /opt/novell/migration/sbin/serveridswap/scripts/
ipchange/nonplugin folder:
ipchange.sh <oldip> <newip> <oldremoteip> <newremoteip> yes
Here, oldip is the IP address of the existing server and newip is the new IP address
assigned to the server. The oldremoteip is the remote IP address that you used when
installing the existing server into the eDirectory tree. If the remote IP address is not changed
then, oldremoteip and newremoteip can be same.
Example 11-1 For example, ipchange.sh 172.16.200.201 172.16.100.101 172.16.200.200
172.16.200.200 yes
If you want to execute any additional scripts copy them to the /ipchange/nonplugin folder
in the same pattern as the existing scripts.
7 Host Name Change: Hostname of the services is changed to source server hostname.
7a To change the hostname of the server and the services go to /opt/novell/migration/
sbin/serveridswap/scripts/hostchange folder, enter
<hostname-script> <targethostname> <sourcehostname>
For example, server-hostname-change.sh aus-market201.marketing.com ausmarket101.marketing.com
7b On the console, enter
hostname <sourceserver_name>
78
Using Migration Commands for Transfer ID
The above command changes the hostname of the server, when you relogin.
If you want to execute any additional scripts copy them to the nonplugin folder in the same
pattern as the existing scripts.
For example, ./iprinthostchange.sh oldhostname newhostname oldmasterhostname
newmasterhostname
where oldhostname is the old server host name and newhostname is the new server host
name. The master hostname is the hostname of the master server in the eDirectory tree.
The oldmasterhostname and newmasterhostname can be the same if the master hostname
is not changed on performing Transfer ID migration.
WARNING: Failure of the script to change the hostname or terminating the operation
manually, may cause the system to hang. If a service specific hostname script fails to
change the hostname, replace the <service>.conf with <service>.orig file.
For example, if iPrint authentication fails on completion of Hostname Change step, do the
following:
cp /etc/opt/novell/iprint/httpd/conf/iprint_ssl.orig /etc/opt/novell/
iprint/httpd/conf/iprint_ssl.conf
8 Reinitialize Server: Reinitialize the target server with the IP address and hostname of the
source server. In this step, eDirectory is also restarted.
 To re initialize the server, enter
systemctl restart network
 To restart eDirectory, enter
systemctl restart ndsd.service
Next, you need to repair eDirectory, certificates for the server, LUM, and other OES services on
the target server.
9 Repair: Performs repair of eDirectory, certificates, LUM, and services on the target server. The
ndsrepair command is used to perform eDirectory repair. The service-specific repairs run only
for services that were migrated using the current project.
9a eDirectory: You can either perform “Unattended full repair of eDirectory” or “Local
eDirectory database and network repair”
9a1 To perform unattended full repair of eDirectory, enter
/opt/novell/eDirectory/bin/ndsrepair -U
or
9a2 To perform local eDirectory database and network repair
/opt/novell/eDirectory/bin/ndsrepair -N
/opt/novell/eDirectory/bin/ndsrepair -R
9a3 To restart eDirectory, enter
systemctl restart ndsd.service
Ensure to fix all errors before proceeding with the next step.
9b Repair Certificates: To create the SAS object, enter
/opt/novell/eDirectory/bin/ndsconfig add -m sas -a <admin dn> --config-file
/etc/opt/novell/eDirectory/conf/nds.conf
9b1 To regenerate the certificate on the target server, enter
/opt/novell/oes-install/util/getSSCert -a <new_ip_address> -t
<treename> -u <admindn dot format> - x <password>
Using Migration Commands for Transfer ID
79
For example, /opt/novell/oes-install/util/getSSCert -a 172.16.100.101 -t
TESTTREE -u cn=admin.o=novell -x novell
The regenerated SSCert.der certificate is stored at /etc/opt/novell/certs location.
9b2 To convert the certificate to the pem format, enter
openssl x509 -inform der -in /etc/opt/novell/certs/SSCert.der -outform
pem -out /etc/opt/novell/certs/SSCert.pem
9b3 To verify the health of eDirectory, enter
ndscheck -h <new_ip_address> -a <admindn dot format> -w <adminpass> -F
<Project_path>
For example, ndscheck -h 172.16.100.101 -a cn=admin.o=novell -w novell F /var/opt/novell/migration/Newproject1/ndscheck.log
You must resolve all errors before proceeding to the next step. It is recommended to
backup the nam.conf file before proceeding with the next step.
9b4 (Conditional) To remove the existing nam.conf, enter
rm /etc/nam.conf
9c LUM: Create or modify the existing Unix Workstation object:
 If the source server is NetWare, a new Unix Workstation object is created. Enter the
following command:
ruby /opt/novell/migration/sbin/serveridswap/scripts/repair/namreconf.rb -a <admindn comma format> -p <admin password> -S <ldapserver-ip> --ldap-port <port number> -u <Unix_config_object-dn>
where Unix_config_object-dn is the value of the base-name parameter in the nam.conf
file. A backup of the file was created in Step 1c.
ldap-server-ip is the value of the preferred-server parameter in the nam.conf.target
file.
NOTE: If the value of the preferred-server parameter is the same as the IP address of
the target server, then the value of the ldap-server-ip must be the same as the IP
address of either the source server or the appropriate LDAP server.
 If the source server is OES, the Unix workstation object is retained. To modify the Unix
workstation object, enter the following command:
ruby /opt/novell/migration/sbin/serveridswap/scripts/repair/namreconf.rb -a <admindn comma format> -p <admin password> -S <ldapserver-ip> --ldap-port <port number> -u <Unix_config_object-dn>
where Unix_config_object-dn is the value of the base-name parameter in the nam.conf
file. A backup of the file was created in Step 1d.
ldap-server-ip is the value of the preferred-server parameter in the nam.conf.target
file.
For example, ruby /opt/novell/migration/sbin/serveridswap/scripts/
repair/nam-reconf.rb -a cn=admin,o=novell -p novell -S 172.16.200.201 -ldap-port 636 -u "o=novell"
9c1 To copy the certificate for LUM operations, enter
cp /etc/opt/novell/certs/SSCert.der /var/lib/novell-lum/
.<new_ip_address>.der
For example, cp /etc/opt/novell/certs/SSCert.der /var/lib/novell-lum/
.172.16.100.101.der
80
Using Migration Commands for Transfer ID
9c2 (Conditional) If the source server is NetWare, run the command to modify the users
and groups listed in Step 1f on page 75:
ruby /opt/novell/migration/sbin/serveridswap/scripts/repair/namgrpmod.rb -H <source short hostname> -a <admin dn> -S <ldap-server-ip>
--ldap-port <port number> -p <password> --grp <group FDN> -l <LUM enabled
user and groups> [--check]
ldap-server-ip is the value of the preferred-server parameter in the nam.conf.target
file.
Parameters
Description
-H
Specify the hostname of the source server
-a
Specify the administrator’s name in LDAP format
-S
Specify the IP address of the preferred LDAP eDirectory server.
--ldap-port
Specify the port for LDAP server to listen on.
-p
Specify the administrator’s password.
--grp
Specify the group to be modified.
-l
Specify the list of LUM enabled user and groups in fully distinguished format.
--check
Verify LUM enabled users and groups
When prompted, enter the password for the administrator.
9c3 (Conditional) If the source server is OES, modify the users and groups by entering the
following command:
ruby /opt/novell/migration/sbin/serveridswap/scripts/repair/nam-fix.rb
-H <new_server short hostname> -a <admindn_comma_format> -p <password>
-S <ldap-server-ip> --ldap-port <port number>
For example, ruby /opt/novell/migration/sbin/serveridswap/scripts/repair/nam-fix.rb -H
mark-nov101 -a cn=admin,o=novell -p novell -S 172.16.100.101 --ldap-port 636
9c4 Refresh LUM Cache, run /usr/bin/namconfig cache_refresh to rebuild LUM
cache.
9c5 (Conditional) If the source server is OES linux server, enter
chown -R wwwrun:www /var/opt/novell/nici/30
You must change the ownership, so that you can login to iManager post-Transfer ID.
9d To repair pool and volume objects, enter
/opt/novell/migration/sbin/serveridswap/scripts/repair/volrepair.rb -a
<admindn_comma_format> -p <password> -f <project_path>/fs
For example, /opt/novell/migration/sbin/serveridswap/scripts/repair/volrepair.rb -a
cn=admin,o=novell -p novell -f /var/opt/novell/migration/NewProj1/fs
9e Services: The scripts are executed for the services that are migrated before performing
Tansfer ID.
 To repair iPrint service, enter
/opt/novell/migration/sbin/serveridswap/scripts/repair/iprintrepair.sh
-s <new IP> -u <admindn comma format> -T <source type {-L|-N}> -p <ssl
port> -S
Using Migration Commands for Transfer ID
81
For example, /opt/novell...iprintrepair.sh -s 172.16.100.101 - u cn=admin,o=novell -T -L
-p 636 -S
Specify -S option only when LDAP server is configured for SSL. And do specify SSL
port only if its configured.
 To repair CIFS service, enter
sh /opt/novell/migration/sbin/migcifs.sh -s <new IP> -p <ssl port> -a
<admindn_ldap_format> {-f 1 <if ssl> | -f 0 <non-ssl>} -t <tree name> d <target server IP> -q <port> -b <admin name> {-g 1 <if ssl> | -g 0
<non-ssl>} -m <project_path>/cifs/cifsSourceShares.tmp -S 3 -r
9f Others: Execute the repair scripts for the services that are not included in the plug-ins of
the Migration Tool.
 NSS Admin Object: To repair the NSS admin object, execute the following on the
target server depending on the source server (NetWare or OES):
/opt/novell/migration/sbin/serveridswap/scripts/repair/nssadminrepair.sh -a <admindn dot format> -p <admin password> -s <source
server [OES/NW]> -o <nssadmin object name with server context>
where -a, -p, -s are mandatory parameters. If the source server is NetWare (NW), the o option is required to create a new NSS admin object.
For example: nss-adminrepair.sh -a admin.sales.novell -p test -s NW -o
nssAdminUser.sales.novell
 Common Proxy:
 If the source is Netware, to repair common proxy on the target OES 2018 server,
execute the following:
/opt/novell/proxymgmt/bin/mignwproxy.sh -d <LDAP Admin FDN> -w
<LDAP Admin Password> -i <LDAP-Server-IP-Address> -p <LDAP Secure
Port>
 If the source is Linux, to perform common proxy migration on the target OES
2018 server, see “Post-Migration Procedure” on page 241.
 Active Directory:
1. Overwrite the target server’s files /etc/krb5.conf, /etc/krb5.keytab, and /
etc/resolv.conf with source server files copied in Step 1e.
2. Merge the contents of the target server’s file /etc/opt/novell/nit/nitd.conf
with the source server file nitd.conf copied in Step 1e.
3. Execute the following command:
rcnovell-nit restart
4. Execute the following command:
/opt/novell/xad/bin/kinit -E Administrator@<ad domain name>
 NetStorage: To repair NetStorage, enter the following commands:
/opt/novell/xtier/bin/xsrvcfg -D
/opt/novell/xtier/bin/xsrvcfg -d <ipaddress> -c <context>
where context is the value of the attribute CONFIG_XTIER_USERS_CONTEXT in /
etc/sysconfig/novell/netstore11 file.
/usr/sbin/rcnovell-xregd restart
/usr/sbin/rcapache2 restart
82
Using Migration Commands for Transfer ID
10 Restart Server: Restart the target server for the changes to take effect.
On successful completion of the Transfer ID migration, the target server functions with the
source server’s eDirectory identity.
Backup eDirectory Database and NICI Keys
Before performing Transfer ID, we recommend that you to back up your eDirectory database and
NICI keys on both the source server and target server. If the Transfer ID fails or you quit the scenario,
you cannot perform any actions on the source server without restoring the server’s DIB from the
backup.
For more information on backing up and restoring eDirectory, refer to the NetIQ eDirectory
Administration Guide.
For more information on backing up and restoring NICI keys, refer to the NetIQ eDirectory
Administration Guide.
Using Migration Commands for Transfer ID
83
84
Using Migration Commands for Transfer ID
12
Running Transfer ID Remotely
12
NOTE: It is recommended to perform Transfer ID from the target OES machine instead of performing
it remotely.
If you need to perform Transfer ID remotely, you need to complete the prerequisite procedures in
Chapter 9, “Preparing for Transfer ID,” on page 61. When you perform Transfer ID remotely, after the
IP address of the target server is changed with the IP address of the source server, the remote
machine hangs. This happens because the IP address of the target server no longer exists. To
perform Transfer ID remotely, perform any of the following methods:
 “Using Two Network Interface Cards” on page 85
 “Using VNC” on page 85
 “Using SSH” on page 86
Using Two Network Interface Cards
To perform Transfer ID remotely, you can connect to the secondary IP address of the target machine
using SSH client or VNC client and follow Step 1 on page 70 to Step 10 on page 73. The connection
will never be terminated because only the primary IP address of the target server changes during
Transfer ID.
Using VNC
To perform Transfer ID by using the VNC client (TightVNC), perform the following steps:
1 Connect to the remote VNC client(TightVNC) running on target server from your server or
desktop by providing the IP address of the target server.
2 On the command prompt enter, miggui to launch the application.
3 Authenticate both source and target servers.
4 Select the migration type as Transfer ID.
You can either migrate all the services to an OES server, then transfer the NetWare or OES
server’s identity, or only transfer NetWare or OES server’s identity to an OES server.
5 Perform Step 1 on page 70 (eDirectory Precheck) to Step 6 on page 71 (IP Change) provided in
the “Run Transfer ID” on page 70.
After changing the IP address, the TightVNC console will hang.
6 Close VNC client and then relaunch it.
7 Connect to the VNC server by providing the new IP address from Step 5.
8 To complete Transfer ID, perform Step 7 on page 72 (Hostname Change) to Step 10 on page 73
(Restart Server) provided in the “Run Transfer ID” on page 70.
Running Transfer ID Remotely
85
Using SSH
You can migrate the services (Step 1 to Step 5) using either the Migration GUI or using CLI. From
Step 6, you must proceed only with CLI because after IP change you cannot SSH to the target server.
To perform Transfer ID by using the SSH console, perform the following steps:
1 Connect to target server using SSH.
2 On the command prompt enter, miggui to launch the application.
3 Authenticate both source and target servers.
4 Select the migration type as Transfer ID.
You can either migrate all the services to an OES server, then transfer the NetWare or OES
server’s identity, or only transfer NetWare or OES server’s identity to an OES server.
5 Save the project and close the Migration Tool GUI.
6 Run the scripts mentioned in Step 1 on page 75 (eDirectory Precheck) to Step 5 on page 77 (DIB
Restore) provided in the Chapter 11, “Using Migration Commands for Transfer ID,” on page 75.
7 On the SSH terminal console, run the script mentioned in Step 6 on page 77 (IP Change)
provided in the Chapter 11, “Using Migration Commands for Transfer ID,” on page 75.
After running these scripts the remote machine hangs.
8 Reconnect to the target server with the new IP address provided in Step 7.
9 On the SSH terminal console, run the scripts mentioned in Step 7 on page 78 (Host Name
change) to Step 8 on page 79 (Reinitialize Server) provided in the Chapter 11, “Using Migration
Commands for Transfer ID,” on page 75.
10 To complete Transfer ID, run the scripts mentioned in Step 9 on page 79 (Repair) to Step 10 on
page 83 (Restart Server).
86
Running Transfer ID Remotely
13
Post Transfer ID Migration
13
 “Joining Target Server to an Active Directory Domain” on page 87
 “Cleanup Objects” on page 87
 “DFS Junctions are Not Restored” on page 89
Joining Target Server to an Active Directory Domain
If the source server or the target server is not joined to AD, then on completion of Transfer ID, you
must join the target server to an Active Directory domain either by using Yast or the command line
options.
 For more information on performing the steps by using YaST, see Installing and Configuring NSS
Active Directory Support in the OES 2018: Installation Guide.
 To use the command line, see Domain Join Tool to Join the OES 2015 Servers to an Active
Directory Domain.
Cleanup Objects
On completion of Transfer ID, some of the objects in eDirectory retain the temporary Linux server
hostname. You can either clean up the objects from the GUI or manually from the target server. Even
if the objects are not cleaned, they do not impact the working of the target server.
 “AFP” on page 87
 “CIFS” on page 88
 “eDirectory” on page 88
 “NSS” on page 88
 “iPrint” on page 88
 “DHCP, FTP and NTP” on page 88
AFP
If you decide to delete the proxy username having the old hostname, you must recreate new proxy
user using YaST.
1 Using iManager delete the proxy user. The format of the proxy user is cn=afpProxyUser-
<new_hostname>.<context_of_server>
2 Using YaST, recreate the proxy user.
yast2 novell-afp
Post Transfer ID Migration
87
CIFS
If you decide to delete the proxy username having the old hostname, you must recreate new proxy
user using YaST.
1 Using iManager delete the proxy user. The format of the proxy user is cn=cifsProxyUser-
<new_hostname>.<context_of_server>
2 Using YaST, recreate the proxy user.
yast2 novell-cifs
eDirectory
Delete the following objects that are present with temporary Linux hostname:
 SAS Service-<temporaryLinuxhostname>
 DNS AG <temporaryLinuxhostname>
 IP AG <temporary IP address-temporaryLinuxhostname>
 SSL CertificateDNS-<temporaryLinuxhostname>
 SSL CertificateIP-<temporaryLinuxhostname>
NSS
 “Pools and Volumes” on page 88
Pools and Volumes
The pools and volumes created on the Linux server before performing Transfer ID are associated
with the old hostname, perform the following post Transfer ID:
1 Using iManager, delete the pool and volume object containing the temporary Linux hostname
name.
2 (Conditional) If the target server contains pools or volumes which are not available on the source
server, recreate these objects using Update NDS option from NSSMU.
iPrint
1 To delete NDPSPrinter object, run /opt/novell/iprint/bin/iprintcleanup.pl script.
For information on how to run the script, see “Cleaning Up Stale Objects” on page 215.
DHCP, FTP and NTP
These services require no additional steps after Transfer ID.
88
Post Transfer ID Migration
DFS Junctions are Not Restored
If a volume on the source server is a DFS junction target, the junctions are not restored on the target
server after Transfer ID migration.
After performing Transfer ID, delete the ~DFSINFO.8-P file from the migrated volumes on the target
server, then run VLDB repair to update the file from eDirectory. For more information about VLDB
repair, see “Repairing the VLDB” in the OES 2018: Distributed File Services Administration Guide for
Linux.
Post Transfer ID Migration
89
90
Post Transfer ID Migration
14
Troubleshooting Issues
14
 “Copying NICI Keys Fails When Performing Transfer ID” on page 91
 “LUM Repair Fails When Performing Transfer ID” on page 91
 “On Completing Transfer ID migration, iManager or OES Remote Manager is Not Accessible via
a Web browser on the Target Server” on page 91
 “System Might Hang on Terminating the IP Address Change Step when Performing the Transfer
ID Scenario” on page 92
 “System Might Hang on Terminating the Hostname Change Step when Performing the Transfer
ID Scenario” on page 92
 “On Failure of Migration and Restoring eDirectory to the Source Server, LDAP Does Not Bind”
on page 93
 “eDirectory Error 626 on Performing Transfer ID Migration” on page 93
 “Transfer ID fails when NetStorage is Configured on the Source Server” on page 94
Copying NICI Keys Fails When Performing Transfer ID
Description: If the source server is NetWare copying NICI files fails due to DSMETER.NLM.
Action: To resolve this issue, you must comment the line, “LOAD DSMETER” in the autoexec.ncf
file and restart the NetWare server before performing Transfer ID.
LUM Repair Fails When Performing Transfer ID
Description: The container admin performing Transfer ID is not part of the admingroup object or
does not have supervisory permissions on all the users or groups in the admingroup object.
Action: To resolve this issue, either Transfer ID should be performed using a treeadmin or if a
container admin is used, ensure the admin has supervisory permissions on all the users or groups in
the admingroup object.
On Completing Transfer ID migration, iManager or
OES Remote Manager is Not Accessible via a Web
browser on the Target Server
Description: In the Transfer ID migration, certificates were not repaired properly in the Repair step.
Action:
1 Relaunch the project created for the Transfer ID migration, then authenticate to the target server.
On successful authentication of the target server, the Transfer ID GUI is launched. The Finish
and the Back buttons are highlighted.
Troubleshooting Issues
91
2 Click Back to reach the Repair step, then run the Repair step again.
3 Restart the target server for changes to be effective.
System Might Hang on Terminating the IP Address
Change Step when Performing the Transfer ID
Scenario
Description: Failure of the script to change the IP address or terminating the IP Change step
manually might cause the system to hang. You must restart the target server and replace the servicespecific configuration file with the backup file for the service.
Action: To restore the original IP address of the target server, replace the <service>.conf
configuration file with the <service>.orig backup file for the service.
For example, if eDirectory authentication fails on completion of the IP Change step, use the following
command:
cp etc/opt/novell/eDirectory/conf/nds.conf.orig etc/opt/novell/eDirectory/conf/
nds.conf
where nds.conf.orig is the backup service file on the target server and nds.conf is the
configuration file created during execution of the IP Change step.
System Might Hang on Terminating the Hostname
Change Step when Performing the Transfer ID
Scenario
Description: Failure of the script to change the hostname or terminating the Hostname Change step
manually might cause the system to hang. You must restart the target server and replace the servicespecific configuration file with the backup file for the service.
Action: To restore the original hostname of the target server, replace the <service>.conf
configuration file with the <service>.orig backed up file of the service.
For example, if iPrint authentication fails on completion of the Hostname Change step, use the
following command:
cp /etc/opt/novell/iprint/httpd/conf/iprint_ssl.orig /etc/opt/novell/iprint/httpd/
conf/iprint_ssl.conf
where iprint_ssl.orig is the backup service file on the target server and iprint_ssl.conf is the
configuration file created during execution of the Hostname Change step.
92
Troubleshooting Issues
On Failure of Migration and Restoring eDirectory to
the Source Server, LDAP Does Not Bind
To bind LDAP you must modify the values of the LDAP configuration version of the LDAP server and
LDAP group objects of the source server:
If the LDAP server displays a message, “Config version 10 is greater than 8 in attribute” or any such
similar message, you must change the Version attribute value of the LDAP group and server objects
of the source server to 8. You can change the attribute values using iManager. Perform the following
steps:
1 Access iManager, then log in to the eDirectory tree where the source server you want to manage
resides.
2 In Roles and Tasks, select Directory Administration > Modify Object.
3 Browse and select the LDAP server object of the source server, then click OK.
4 In General > Other tab, in Valued Attributes column, select ldapConfigVersion and click Edit.
5 Change the LDAP Configuration Version value as defined in the error, then click OK.
For example, if the LDAP server displays a message, “Config version 10 is greater that 8 in
attribute” or any such similar message, you must change the LDAP Configuration Version
attribute value of the LDAP server to 8.
6 Click OK.
7 Repeat Step 2 to Step 6 for LDAP group objects of the source server.
8 Restart LDAP module on the source server:
On NetWare:
unload nldap.nlm
load nldap.nlm
On OES
nldap -u
nldap -l
On performing the preceding steps the server returns to the status before it is removed from the
eDirectory tree.
eDirectory Error 626 on Performing Transfer ID
Migration
1 Check the status of SLP by entering
rcslpd status
If SLP is not running, start SLP by entering
rcslpd start
For information on using SLP, see “Using SLP with eDirectory” in the NetIQ eDirectory
Installation Guide.
2 (Conditional) If SLP is not used, create /etc/opt/novell/eDirectory/conf/hosts.nds file on
the non-replica server that points to the master server and the container in which the user object
is present. For more information, refer to the manpage hosts.nds.
Troubleshooting Issues
93
Transfer ID fails when NetStorage is Configured on
the Source Server
During Transfer ID process, miggui tries to retrieve the proxy credentials for each of the services
configured on the source server. If NetStorage is configured, its script returns the proxy user name in
dot separated format instead of comma separated format. Due to this, miggui displays the following
warning: "The source server is configured with both service proxy and common proxy. This is not a
supported scenario and will cause failure of proxy user migration. Do you want to continue?" In this
scenario, the OES services fail to launch after the transfer ID is complete.
To resolve this issue, before starting the transfer ID process, update the source OES 2015 or later
server, and reconfigure NetStorage using YaST > OES Install and Configuration, or by executing
yast2 netstorage command. Complete the reconfiguration steps without altering any of the existing
settings.
94
Troubleshooting Issues
V
Security Considerations
V
 Chapter 15, “Security Considerations for Data Migration,” on page 97
Security Considerations
95
96
Security Considerations
15
Security Considerations for Data
Migration
15
This section describes how the Micro Focus Open Enterprise Server (OES) file system Migration Tool
can be used in a secure environment. It provides information to help you ensure that authentication
credentials and other sensitive data are not compromised through the use of the Migration tool.
For additional security implementation information, see “Security” in the OES 2018: Planning and
Implementation Guide.
 “Root-Level Access Is Required” on page 97
 “Securing User Credentials” on page 97
 “Mounting Remote File Systems” on page 98
 “Transmitting Data Across the Network” on page 99
 “Managing Passwords for Migrated Users” on page 99
Root-Level Access Is Required
To use the OES migration tool, you must be logged in to the target OES 2018 server as root or a
root-equivalent user.
Securing User Credentials
You can take precautions to ensure that authentication credentials (usernames and passwords) are
securely stored and retrieved when using the migration tool.
 “How User Credentials Are Stored During a Migration” on page 98
 “How Credentials Are Passed from the Migration GUI Utilities to the Migration Commands” on
page 98
Security Considerations for Data Migration
97
How User Credentials Are Stored During a Migration
By default, neither the migration GUI utilities (File System Migration Utility) nor the command line
tools (mls, migfiles, etc.) store the usernames and passwords entered by the user running the
migration.
 “Migration GUI Utilities” on page 98
Migration GUI Utilities
The migration GUI utilities do not use OES Credential Store (OCS), nor do they store user credentials
in any file format. Rather, the utilities accept the user credentials entered for the source server and
target server and, after validating them (via secure or non-secure LDAP authentication), the utilities
store this information in a proprietary cache. These credentials are used by the applications to
execute various migration-related operations. For example:
 To retrieve NetWare source volumes, the File System Migration Utility issues an nwmap
command.
 To carry out migrations, the GUI utilities execute the required migration commands (mls,
migfiles, maprights, maptrustees, etc.).
The migration utility cache is flushed when the applications are closed.
In a saved migration project, only the IP addresses of the source and target servers, the volume
names, and any other migration options, are stored in the .xml configuration file. When you open and
rerun a saved project, you are prompted to reenter the credentials.
How Credentials Are Passed from the Migration GUI Utilities
to the Migration Commands
The GUI utilities execute migration commands within their process context and pass the user
credentials whenever required or prompted through their process APIs, which can be hidden from the
user. The GUI applications neither set the credentials in environment variables nor use the OES
Credential Store (OCS), even though the migration commands provide the option.
To pass credentials to the migration commands, the GUI utilities open a terminal connected to the
standard input and feed in the password to the command line prompt.
Mounting Remote File Systems
The migration tool must mount the remote file systems of the source servers in order to obtain
information about the source volumes and to copy the specified data to the target server.
For NetWare and OES migrations, the mls and migfiles uses nwmap command to map to the remote
volumes and read data from the _admin volume to validate the source path. The mls and migfiles
commands unmounts the file system upon termination. If a process is killed forcibly (kill -9), the
mount point remains mounted and must be unmounted by the administrator.
The mls command uses nbackup tool to build the list of trustees.
98
Security Considerations for Data Migration
Transmitting Data Across the Network
The OES migration tool use Storage Management Services (SMS) to copy data from OES servers.
Data is not encrypted when it is transmitted across the network.
Managing Passwords for Migrated Users
When performing a tree-to-tree migration, you have the option to migrate users into the target
server’s eDirectory tree. If you are migrating users, you have two choices for passwords:
 Generate random passwords for the migrated users (by using the -r option of the migtrustees
command).When using this option, you must always pass the --newusers-password-file option
so that the randomly generated passwords and usernames are stored in the file.
or
 Assign a specific password for all migrated users (by using the -s option of the migtrustees
command)
If neither -r nor -s is used, users are created without a password and the user accounts are locked
until they are manually assigned a password by the administrator, using iManager or other eDirectory
management tools. Null passwords (-s "") are not allowed.
The new passwords generated by -r option are stored in a new file. To avoid password theft, dispose
of this file in a secure manner after you have communicated the new passwords to their respective
users.
Security Considerations for Data Migration
99
100
Security Considerations for Data Migration
VI
Data Migration
VI
 Chapter 16, “Migrating File Systems to OES 2018,” on page 103
Data Migration
101
102
Data Migration
16
Migrating File Systems to OES 2018
16
This section provides information on how to migrate the file system from supported source servers to
an OES 2018 server.
 “Preparing for File System Migration” on page 103
 “Migration Scenarios” on page 105
 “Moving Devices for Migrating the Data from NetWare to OES 2015 or Later” on page 109
 “Migrating File System Using GUI” on page 109
 “Synchronizing File System Using Migration GUI” on page 115
 “Migrating File System Using Command Line Utilities” on page 116
 “Troubleshooting” on page 139
The following sections provide more details on the migration procedure for the file system.
Preparing for File System Migration
To prepare your network for file system migration, complete the tasks in the following sections:
 “Source Server Requirements” on page 103
 “Target Server Requirements” on page 104
Source Server Requirements
 “NetWare Server” on page 103
 “OES Server” on page 103
NetWare Server
 Shut down any applications, products, or services (virus scan software, backup software, etc.)
running on the server to be migrated.
 Ensure that the latest version of Storage Management Services (SMS) is running on the source
NetWare server.
SMS updates can be downloaded from the Novell Downloads Web site (http://
download.novell.com/patch/finder/#familyId=122).
 When migrating data from a Traditional NetWare volume, ensure that the NPM files for NFS and
the NFS name space is loaded on the Traditional NetWare Volumes.
 Although data on the source server is not deleted as part of the migration, we recommend that
you back up your data.
OES Server
 Shut down any applications, products, or services (virus scan software, backup software, etc.)
running on the server to be migrated.
Migrating File Systems to OES 2018
103
 Ensure that the server is running supported OES versions with all the available patches in the
channel.
 Ensure that Storage Management Services (SMS) and NetWare Core Protocol (NCP) is running
on the server.
 Ensure that source volumes on OES servers are NSS volumes, NCP volumes, or POSIX
volumes.
NOTE: The Migration Tool GUI does not support POSIX file system migration. Create an NCP
volume with the POSIX path that you want to migrate, then migrate the NCP volume.
 To migrate data from NCP volumes on OES server, ensure that you have done the following:
 Install the Novell Client for Linux
 Restart SMS by running the following command:
rcnovell-smdrd restart
 Ensure that the user performing migration has read/write/access rights to back up the files
on the NCP volume.
 To perform migration, the user must have read/write/access permissions to the source server
Target Server Requirements
 Ensure that the server is running OES 2018.
 Services to be migrated must be installed and configured on the target server.
The following additional prerequisites must be met for NSS and NCP target volumes:
 “For NSS Target Volumes” on page 104
 “For NCP Target Volumes” on page 104
For NSS Target Volumes
 Using Migration GUI, if you have configured file system and for some reason the mount point of
NSS volumes change, then you must reconfigure the paths for file system.
 Create the NSS volumes to which you will migrate the data. Ensure that you allocate sufficient
space for the volume to hold all of the source data.
 Ensure that the target volumes have similar properties to the source volumes. For example, if
compression is turned on for the source volume, turn on compression for the target volume as
well. The same applies to user quotas and other NSS features.
For NCP Target Volumes
 Create NCP volumes to which you will migrate the data.
 Ensure that the user performing the migration has read/write/access rights to the POSIX path
that corresponds to the NCP volume.
 Although data is successfully migrated to the clustered NCP target volumes, trustee migration is
not supported.
104
Migrating File Systems to OES 2018
Migration Scenarios
The procedures for migrating file system data from the NSS volumes or Traditional volumes on
NetWare or from the NSS volumes on OES vary depending on whether the source server and target
server are in the same eDirectory tree or in different eDirectory trees. This section covers the
following scenarios:
 “Consolidating Data to a Server in the Same Tree” on page 105
 “Consolidating Data to a Server in a Different Tree” on page 105
 “Migrating Compressed Files” on page 105
 “Data Migration for Clustered Volumes” on page 106
 “Data Migration for DST Volumes” on page 106
 “Data and Trustee Migration in Active Directory Environment” on page 108
 “Transfer ID” on page 108
 “Migration Procedure” on page 109
NOTE: For more information about migration scenarios, see Chapter 1, “Overview of the Migration
Tools,” on page 15.
Consolidating Data to a Server in the Same Tree
The source file system volumes are migrated to the target file system volumes within the same
eDirectory tree.
The following are migrated from the source server to target server:
 Volumes, folders and files
 Trustee rights for files
Consolidating Data to a Server in a Different Tree
The source file system volumes are migrated to the target file system volumes in a different
eDirectory tree.
The following are migrated from the source server to target server:
 Volumes, folders and files
 Trustee rights for files
 Create users in the target’s file system volumes.
 An option to set a default global password for the new users created on the target server.
Migrating Compressed Files
In any of the following scenarios compressed files are seamlessly migrated from source server to
target server:
 Source server volumes and target server volumes both are compression enabled.
Migrating File Systems to OES 2018
105
 Source server volume is compression enabled and target volume is not enabled for
compression. Migration gui uncompresses the migrated files on the target server volume.
 Source server volume is not enabled for compression and target volume is compression
enabled. Migration gui compresses the migrated files on the target server volume.
The compress and uncompress commands run as a backend process in the migration gui.
Data Migration for Clustered Volumes
You can perform data migration by upgrading only the cluster nodes or both the cluster nodes and
storage:
 “Upgrading NetWare Cluster Nodes” on page 106
 “Upgrading NetWare Cluster and Shared Storage” on page 106
Upgrading NetWare Cluster Nodes
One or more NetWare nodes are replaced with OES 2015 or later nodes. Novell Cluster Services
supports rolling server upgrade, using which one or more NetWare nodes can be replaced with OES
2015 or later nodes. For performing upgrade, refer to the “Converting NetWare Cluster Nodes to OES
(Rolling Cluster Conversion)” in the OES 2015 SP1: Novell Cluster Services NetWare to Linux
Conversion Guide.
Upgrading NetWare Cluster and Shared Storage
All nodes and shared storage is replaced with new cluster with OES 2015 or later configured on a
new shared storage. Migrating cluster NSS volumes from NetWare cluster to a new Linux cluster can
be achieved using Migration Tool.
The Migration Tool provides two options Is Cluster Resource and Follow Cluster Resource to
perform cluster migration.
If you select Follow Cluster Resource option, migration continues uninterruptedly during cluster
resource migrations to different cluster nodes. This option is valid only on the source server clusters.
On migrating data to cluster NSS volume on the target server, migration stops when the resource
migrates to a different node. To continue migration you must make the resource active on the target
server.
If this option is not selected, migration stops when the resource migrates to a different node on source
server. Once the resource comes up on the different node, re-start migration to continue the migration
from where it failed. The Migration Tool supports only source NSS volumes for migration.
Data Migration for DST Volumes
On performing migration for DST volumes, the data is migrated for only the primary volume and does
not include the secondary volume. To perform migration for all the volumes, remove the shadow
volume relationship of the DST server.
When performing migration, consider the following:
Source Server as DST
 The target server can be a DST or non-DST server.
 Stop the DST policies before performing the migration.
106
Migrating File Systems to OES 2018
For more information on stopping the policies, see “Stopping a Running Policy” in the OES 2018:
Dynamic Storage Technology Administration Guide.
 Only the data that is stored on the primary volume of the source server is migrated to the target
server.
 To migrate the data from all the volumes of the source server, remove the shadow volume
relationship on the source server.
For more information on removing the shadow volume relationship, see“Removing the Shadow
Relationship for a Clustered DST Volume Pair” or “Removing the Shadow Relationship for a
Non-Clustered DST Shadow Volume” in the OES 2018: Dynamic Storage Technology
Administration Guide.
 Configure the file system GUI to perform migration. For more information, go to “Migrating File
System Using GUI” on page 109.
Target server as DST
 The source server can be a DST or non-DST server
 Stop the DST policies before performing migration.
For more information on stopping the policies, see “Stopping a Running Policy” in the OES 2018:
Dynamic Storage Technology Administration Guide.
 The data is migrated from the source server to only the primary volume of the target server.
 To migrate the data from the source server to all the volumes on the target server, remove the
shadow volume relationship on the target server.
For more information on removing the shadow volume relationship, see “Removing the Shadow
Relationship for a Clustered DST Volume Pair” or “Removing the Shadow Relationship for a
Non-Clustered DST Shadow Volume” in the OES 2018: Dynamic Storage Technology
Administration Guide.
 Configure the file system GUI to perform migration. For more information go to “Migrating File
System Using GUI” on page 109.
Example 16-1 For Example:
Consider a scenario, where you are migrating data from a source non-DST server to a target DST
server. The source server has volumes Vol1, Vol2, Vol3 of 3 GB each. The target server contains the
primary volume Vol4 with 1 GB space and secondary volume Vol5 with 10 GB space. In this scenario
you can migrate the data by using any of the following:
 “Migrating without the Shadow Volume Relationship:” on page 107
 “Migrating with the Shadow Volume Relationship:” on page 108
Migrating without the Shadow Volume Relationship: When the shadow volume relationship is
removed from the target server, it acts as a non-DST server and the migration can be performed
normally.
Perform the following to migrate the data:
1 Remove the shadow volume relationship. For more information, see “Removing the Shadow
Relationship for a Clustered DST Volume Pair” or “Removing the Shadow Relationship for a
Non-Clustered DST Shadow Volume” in the OES 2018: Dynamic Storage Technology
Administration Guide.
2 Configure the file system GUI to perform migration. For more information go to “Migrating File
System Using GUI” on page 109.
Migrating File Systems to OES 2018
107
Migrating with the Shadow Volume Relationship: Only 1 GB of data from the source server can
be migrated to the primary volume Vol4 of the target server. If you need the data on all the volumes of
source server to be migrated to the target server, perform the following:
NOTE: You require to stop the DST policies temporarily before performing migration.
1 Stop the existing DST policies.
2 Create a project to migrate the data less than or equal to 1 GB from the source server to the
target server.
3 Perform the migration.
4 (Conditional) If some files or folders were open on the source server and did not get migrated to
the target server, perform synchronization.
Synchronization must be performed before performing the next step.
5 Configure a DST policy on the target server to move the migrated data from the primary volume
to the secondary volume.
As a result, there is space available on the primary volume of the target server to migrate
additional data from the source server.
6 Stop the DST policy after the required data is moved from the primary volume Vol4 to the
secondary volume Vol5.
7 Repeat Step 2 to Step 6 until the entire data is migrated.
Data and Trustee Migration in Active Directory Environment
When performing data or trustee migration in Active Directory environment, you must ensure that on
the source server and target server the pool containing NSS volumes is media-upgraded, the NSS
volumes are AD-enabled, and trustee rights are assigned on the specific folders or files.
Table 16-1 Support Matrix in Active Directory Environment
Source Volume
Target Volume
Data Migration
Trustee Rights
eDirectory
Active Directory
AD-enabled
AD-enabled
Success
Success
Success
AD-enabled
Non AD-enabled
Success
Success
Not supported
Non AD-enabled
AD-enabled
Success
Success
Not applicable
Non AD-enabled
Non AD-enabled
Success
Success
Not applicable
Transfer ID
In the Transfer ID scenario a series of tasks are executed for transferring the server identity of the
source server to the target server. In the Migration Tool GUI, the file system is configured, then
migrated. On successful migration of all of the services, click Transfer ID. For more information, see
Part IV, “Transfer ID Migration,” on page 59.
108
Migrating File Systems to OES 2018
Migration Procedure
Use either of the following methods to perform a file system migration:
 “Migrating File System Using GUI” on page 109
 “Migrating File System Using Command Line Utilities” on page 116
Moving Devices for Migrating the Data from NetWare
to OES 2015 or Later
You can move devices containing NSS volumes from NetWare to OES server by decommissioning
the volumes on the device in the eDirectory, then recommissioning the volumes on the new server.
For more information, see the “Moving Non-Clustered Devices From NetWare 6.5 SP8 Servers to
OES 2018” in the OES 2018: NSS File System Administration Guide for Linux.
For shared NSS pools and volumes, Novell Cluster Services provides this service automatically
during a rolling cluster conversion from NetWare to OES. For information about converting shared
pool cluster resources and service resources, see the OES 2015 SP1: Novell Cluster Services
NetWare to Linux Conversion Guide.
Migrating File System Using GUI
After you have completed the prerequisites procedures in “Preparing for File System Migration” on
page 103, you are ready to migrate the source server.
1 Launch the Migration Tool from the target server, using either of the following methods:
Desktop: Click Applications > Other > Novell Migration Tools to launch the Migration GUI.
Terminal Prompt: Log in as the root user and at a terminal prompt, enter miggui
2 Enter authentication credentials for the source server.
(Optional) Is Cluster Resource: This option supports only Migrate scenario and does not
support Transfer ID. If you want to migrate data in a cluster environment, you can perform either
of the following:
 Migrating Cluster Volumes: In the Source Server Authentication screen, specify the
cluster resource IP and select the Is Cluster Resource option. On configuring file system
the Volume Information tab displays all cluster volumes from the cluster resource as part of
the source volume.
 Migrating Non Cluster Volumes from a Cluster Node: In the Source Server
Authentication screen, specify the cluster node IP and do not select the Is Cluster
Resource option. On configuring file system the Volume Information tab displays all non
cluster volumes present on the source server.
3 Enter your authentication credentials for the target server
4 Depending on the type of migration to perform, select the migration type as Migrate or Transfer
ID.
5 In the Services panel, click Add and select File System.
The Status of the file system service is Not Configured.
IMPORTANT: File system is listed in the Service panel list only if it installed and configured on
the target server.
Migrating File Systems to OES 2018
109
6 To configure migration parameters for the file system, select File System, then click Configure.
Tabs
Purpose
Volume Information
Identify the volumes or folders that you want to move from the selected source
server to a selected target server. By default, all of the data in the volumes or
folders that you select for migration in the source server tree is migrated to the
target server.
File Options
Customize the files and quotas that are migrating to the target server. You can also
specify the home directory location and set options to synchronize the file system.
Trustee Options
You can migrate the trustee rights of the users and groups from the source server
to target server. You can also specify the global password for the new users
created on the target server.
This tab is enabled only in a Different Tree scenario.
Match User Options
You can specify which users to migrate and how to handle the migration if the user
already exists on the target server.
This tab is enabled when you select the Custom User mapping option in the
Trustee Options page.
7 In the Volume Information tab, in the Source Server tree, select volumes or folders that you want
to migrate, then drag and drop it in the Target Server tree. The names of the source cluster
volumes can only include “_” as a special character to be listed in the Source Server tree.
IMPORTANT: You cannot migrate a DFS junction. A DFS junction is displayed under the source
tree as a folder because this junction appears in the file structure as a directory. Under Volume
Information, the DFS junction can be dragged to the target server tree, but actually, the junction
and the data are not migrated to the target server and migration fails.
On migrating a directory to an existing file system (NSS, NCP volume, or Linux POSIX volume),
there are access rights set on the target location that can be inherited by the folder and its
contents after migration (either the trustees and trustee rights in the case of NSS and NCP, or
the ACLs (access control lists) for Linux POSIX). You must modify the settings as needed to
ensure that the files are available only to authorized users before you allow users to access the
data in the new location.
In the Source Server tree, you cannot expand volumes or folders that are copied to the Target
Server tree.
For explanation on different tasks that can be performed in the Volume Information tab, refer to
the table below, else proceed with default settings to Step 8.
110
Migrating File Systems to OES 2018
Task
Description
Target Location
After you have selected volumes and folders for migration, you might want
to identify the path of the folder or volume moved to the target server.
In the Source Server tree, right-click the volume or folder that is selected
for migration, then click Target Location from the drop-down menu. The
tree in the Target Server view expands to display the volume or folder that
was copied from the source server.
Source Location
After you have selected volumes and folders for migration, you might want
to identify the path of the folder or volume moved from the source Server.
In the Target Server tree, right-click the volume or folder that is highlighted
for migration, then click Source Location from the drop-down menu. The
tree in the Source Server view expands to display the volume or folder that
was copied to the Target Server.
Volumes or Folders selected The volumes or folders that are selected for migration are highlighted in
for migration
blue in the Source Server tree and the Target Server tree.
Removing Volumes or
Folders from the Target
Server
In the target server tree, right-click the volume or folder that you have
decided not to migrate, then select Undo. The folder no longer appears
under the target server tree and is no longer a candidate for migration.
Follow Cluster Resource
Select this option to perform uninterrupted migration when cluster
resources migrate to different cluster nodes. This option is valid only on the
source server clusters.
For example, when a failure occurs on one node of the cluster, the
resources are relocated to another node in the cluster. The migration tool
connects to the cluster instead of individual server and performs
uninterrupted migration during this failure.
If this option is not selected, migration stops when the resource migrates to
a different node. When the resource comes up on a different node, run the
migration project again, the migration tool ensures that the migration
process resumes from the state where it had stopped.
On migrating data to cluster volume on the target server, migration stops
when the resource migrates to a different node. To continue migration you
must make the resource active on the target server.
8 Click the File Options tab, then click OK to accept the defaults.
or
Use the options to customize the files and quotas to migrate to the target server, then click OK to
save the settings.
Migrating File Systems to OES 2018
111
For explanation of the different tasks that can be performed in the File Options page, refer to the
Table below.
Task
Description
Duplicate File
Resolution
Determines what action to take when a file copied from the source server has the
same filename as an existing file on the target server. Specify one of the following
resolutions:
 Always Copy Source File (default): The migrated file always overwrites the
existing file.
 Never Overwrite Existing File: The file from the source server is not migrated,
if a file of the same name exists on the target server.
 Copy if Newer: The migrated file overwrites the existing file on the target
server, only if its last modified date is newer than the existing file’s date. This
option is applicable only for data migration.
Quotas
This option is applicable only for data migration.
NOTE: If you are migrating to a different file system (NSS to NCP volumes or from
NSS to Linux POSIX volumes) on the target server, user quotas and directory quotas
are not valid.
 Exclude User Quotas on Source: The user quotas from the source server are
not copied to the target server.
 Exclude Directory Quotas on Source: The directory quotas from the source
server are not copied to the target server.
 Disable Quota Checks on Target: The user and directory quotas set on the
target server are ignored by the migration tool on performing data copy.
File Filters
Determines which files to include for migration. If no filters are set, all files are
migrated. You can specify the files that you want to migrate by specifying the date
range or you can exclude the files from migrating by specifying the filenames or file
extensions.
 Last Accessed/ Last Modified: The date range to include files for migration.
 Exclude File(s): The filenames or file extensions to exclude from migration.
Wildcards (*) are permitted. For example: *.mp3, *.mov, *.tmp,
samplefile.txt, “my sample file.txt.”
Specifying *.mp3 excludes all files with an extension of .mp3 from being
migrated. Specifying samplefile.txt excludes all samplefile.txt from being
migrated.
Home Directory
Options
Specify the target server path for the users whose home directory you are migrating
from the source server.
For example, If the users’s home directory path on the source server is /media/
nss/VOL1/users and the target path where the users will be migrated is /media/
nss/VOL2/users, then specify the path in the Home Directory Options as /media/
nss/VOL2/users. On successful migration, the home directory of the users is
updated with the new target server path.
NOTE: If you are performing migration across multiple volumes, you cannot specify
multiple home directory paths.
112
Migrating File Systems to OES 2018
Task
Description
Sync Options
The Sync option performs synchronization of the target server with the source server.
After completion of file system migration, if the source server is updated with new
information, you can use the Sync option for synchronizing the servers. The Sync
option is available in the main Migration GUI window.
Delete Files Not On Source: During synchronization of the servers, additional files
or folders on the target servers are deleted that are not available on the source
server.
Delete Trustees Not On Source: This option is enabled only for same tree
migration. Set this option to update trustee information on target server when trustees
are deleted on the source volume on completion of migration or synchronization.
Trustee information that is not on the source server is deleted from the target server.
Copy Trustees Only At The Directory Level: Synchronizes trustees only at the
directory level. Trustees for files are not synchronized.
Do Not Copy Trustees: The user rights on the source server folders are not synced
to the target server.
Login Options
This option indicates whether you want users to be logged in during the data
migration.
Disable Login On Source: If you disable user login, the users cannot log in to the
network and modify the open files during the file copy. Users already logged in to the
source server are not logged out, but no new logins are allowed until the migration
completes.
9 Click the Trustee Options tab, then click OK to accept the defaults and migrate the trustee rights
of users and groups on the source server to target server.
or
Use the options to customize the files trustee options to migrate to the target server, then click
OK to save the settings.
For explanation on different tasks that can be performed in the Trustee Options tab, refer to the
table below.
NOTE: In the Same Tree scenario, the Trustee Options tab is disabled.
Migrating File Systems to OES 2018
113
Task
Description
Trustee
Migration
Specify an option to migrate trustee rights of users and groups from the source server to
the target server.
 Do Not Migrate Trustees (default): The user rights to the access folder on the
source server are not migrated to the target server.
 Flatten Trustees: The users on the source server are migrated to a selected
context on the target server, irrespective of whether the users are in a different
context on the source server.
 Target Context to flatten the users: Select the context on the target server
to migrate all the users.
 Custom User Mapping: Users on the source volume are mapped with the users
on the target server. When you select this option, the Match User Options tab is
enabled, which enables you to select the users from the source server or the
target server, and then assign migration options.
 Search Context to map users: Select the context on the target server to
match the users.
Existing User
Options
A username on the source server has a corresponding username on the target server.
You can overwrite the trustee details of the user on the target server, or ignore the user.
 Ignore All: Do not create users on the target server.
 Overwrite All: Overwrite the users on the target server.
New User
Options
Specify the global password for the new users created on the target server.
eDirectory Password: Specify the password for the users to use, when they log in for
the first time on the target server.
IMPORTANT: If password restrictions are set for users on the source tree, you must
specify a default password, else migrating users in a different tree scenario might fail.
10 (Conditional) If the Match User Options tab is enabled, click it, then continue with Step 10a to
specify which users to migrate and how to handle the migration if the user already exists on the
target server.
or
If the Match User Options tab is not enabled, click OK to save your file system migration setup
and return to the main Migration Tool window then continue with Step 12.
10a To view the list of users on the source server and target server, click Map Users, then select
how to handle the users.
NOTE: In a migration project, if you select multiple volumes for migration that are
associated with same users, then on mapping users the source displays duplicate user list.
 Existing or Mapped Users: A username on the source server has a corresponding
username on the target server. If the users are mapped, only the trustee details are
migrated.
 New Users: Users do not exist on the target server. Create new users on the target
server, or ignore the users.
114
Migrating File Systems to OES 2018
10b This is a global setting for all the users. Specify one of the following options to migrate users
or ignore users.
 Ignore All: Do not migrate the new users. Only existing users are migrated to the
target server.
 Create All: Create all users on the target server.
10c (Optional) To specify settings for individuals and groups that override the global handling of
user migration, click the username, then assign one of the migration options from the dropdown menu:
 Create: Create users on the target server and assign the trustee rights.
The users are created on the target server that is using the same FDN as the source
server. The search context is used only to match the source server users to target
server users in that context.
 Ignore: Ignore the user and do not assign the trustee rights of the source user.
 Browse: Assign an equivalent user by browsing the same context or a different
context on the target server and assigning trustee rights.
11 After you have finished configuring the parameters in each tab, click OK to save your file system
migration setup and return to the main Migration window.
12 Click Migrate on the main migration window to begin the migration.
The log files for the file system are located at /var/opt/novell/migration/<project name>/log.
Following log files are created during file system migration:
filesystem.log: This stores the information about the command sequence and errors encountered
during migration.
filesystem.success.log: This stores the list of all successfully migrated files.
filesystem.delete.log: This stores list of files deleted from the target server which are not available
on the source server when performing sync. This log file is updated with list of deleted files, if you
have selected the option Delete Files Not On Source in the File Options tab.
Synchronizing File System Using Migration GUI
On performing synchronization, the service details (data, trustee etc) on the target server is compared
with the source server and the updated information is migrated to the target server. You can perform
synchronization in the following two scenarios:
 “Same Tree” on page 115
 “Different Tree” on page 116
Same Tree
On successful migration, you are ready to perform synchronization for any new or modified files or
trustee rights.
1 Launch the Migration Tool on the target server.
2 Open the migration project that you need to perform synchronization.
The status of the file system is “Migrated on <Date and Time of successful migration>”.
3 Authenticate the source server and target server.
Migrating File Systems to OES 2018
115
4 (Conditional) You can modify only few options for file system. In the Services to Migrate panel,
select File System, then click Configure. In the File system GUI, File Options tab only the
Duplicate File Resolution, Login Options, and Sync Options are enabled and can be modified.
5 In the main Migration Tool GUI, click Sync.
All the new or modified files or trustee rights on the source server are migrated to the target
server.
Different Tree
On successful migration, you are ready to perform synchronization for any new or modified files or
trustee rights.
1 Launch the Migration Tool from the target server.
2 Open the migration project that you need to perform synchronization.
The status of the file system is “Migrated on <Date and Time of successful migration>”.
3 Authenticate the source server and target server.
In the File system GUI, File Options tab only the Duplicate File Resolution, Login Options, and
Sync Options are enabled and can be modified.
3a (Conditional) In the Trustees Options tab, if you have selected the Custom User Mapping
option, you must remap the users on the source volume with the users on the target volume
in the Match User Options tab.
4 In the main Migration Tool GUI, click Sync.
All the new or modified files or trustee rights on the source server are migrated to the target
server.
Migrating File System Using Command Line Utilities
This section provides information on how to use the command line to migrate a file system running on
supported source servers to target server.
NOTE: All the migration commands must be run on the target server.
This section covers the following scenarios:
 “Migrating Data to a Server in the Same Tree” on page 117
 “Migrating Data to a Server in a Different Tree” on page 118
 “Migrating Data to a POSIX File System” on page 123
 “File System Migration Commands” on page 125
 “Additional Migration Options” on page 137
116
Migrating File Systems to OES 2018
Migrating Data to a Server in the Same Tree
This section describes how to migrate file system data from source server to target server in the same
eDirectory tree.
 “Migrating the Data” on page 117
 “Examples” on page 117
 “Limitations” on page 118
Migrating the Data
migfiles is command to migrate files and directories. If you need to modify the home directories of
the migrated users, you also need to use mls, maptrustees, and migtrustees.
1 (Conditional) If you need to modify the home directories of the migrated users, run the following
command:
mls
2 Run the migfiles command to copy the data from the source server to the target server.
3 (Conditional) If you need to modify the home directories of the migrated users, run the following
commands in the order specified:
maptrustees
migtrustees
Examples
The following examples illustrate ways to use the various options available for the migration
commands.
 “Volume-to-Volume Migration” on page 117
 “Directory-to-Directory Migration” on page 117
 “Volume-to-Directory Migration (NSS Volume to NCP Directory)” on page 118
 “Remapping Home Directories” on page 118
Volume-to-Volume Migration
This command migrates all data from the Traditional or NSS volume SRCVOL1 on the source server
with the IP address 192.168.1.3 to the target server’s TGTVOL1 volume with verbose output:
migfiles -s 192.168.1.3 -V SRCVOL1 -v TGTVOL1 -i
Directory-to-Directory Migration
This command migrates data from the Traditional or NSS path DATA:impstuff on the source server
with the IP address 192.168.1.3 to the stuff directory on the NSS volume NSS1 with verbose output:
migfiles -s 192.168.1.3 -V DATA:impstuff -x /media/nss/NSS1/stuff -i
Migrating File Systems to OES 2018
117
Volume-to-Directory Migration (NSS Volume to NCP Directory)
This command migrates data from the Traditional or NSS volume named DATA on the source server
with the IP address 192.168.1.3 to the newdir directory on the NCP volume NCP1 located at path /
data/ncp1 without verbose output:
migfiles -s 192.168.1.3 -V DATA -x /data/ncp1/newdir
Remapping Home Directories
These commands migrate the VOL1 volume on source server 192.168.1.3 to the VOL1 volume on
target server 192.168.1.4. The -H option in the maptrustees command is used to remap the home
directories of the users to the target server.
1 Create a list of files and associated rights on the source volume:
mls -s 192.168.1.3 -V VOL1 > mls.yaml
2 Copy the data from the source volume to the target volume:
migfiles -s 192.168.1.3 -V VOL -x /media/nss/VOL1 -i
3 Map the trustees and home directories from the source server to the target server:
maptrustees -s 192.168.1.3 -H /media/nss/VOL1/users/--map-homedir-only
mls.yaml> maptrustees.yaml
The -H option is a path to the base directory that includes all the home directories.
4 Migrate the information generated in the previous step:
migtrustees -d 192.168.1.4 -m maptrustees.yaml
Limitations
If you have user space restrictions set on a source NSS volume, the restrictions are migrated to target
NSS volumes if you do a full volume migration.
Migrating Data to a Server in a Different Tree
When the source server and target servers are in different eDirectory trees, your file system user and
group trustees must be migrated from the source tree to the target tree, along with their associated
data. The maptrustees and migtrustees commands are used to migrate users and groups
assigned as trustees in the source tree to the target tree. Alternatively, you can use Novell Identity
Manager to migrate the eDirectory users and groups, and then use the migmatchup command to
match the user from the source server to the target server. Use the maprights and migrights
commands only if the user and the group structure has changed during the migration.
 “Migrating the Data” on page 119
 “Examples” on page 119
 “Limitations” on page 122
118
Migrating File Systems to OES 2018
Migrating the Data
The main command to use is migfiles. To map the trustees (users and groups) from the source tree
to the target tree, you need to use mls, maptrustees, and migtrustees. If you are reorganizing the
trustees (migrating to a different context), you also need to use mls, maprights, and migrights to
map the trustee rights.
To migrate the data from a source NetWare server or OES server in one eDirectory tree to the target
Linux server in another tree:
1 You can either migrate the source server trustees to the target server or map the source server
trustees with the target server.
 To migrate the trustees, run the following commands in the order shown:
mls
maptrustees
migtrustees
 To map the trustees, run the following commands in the order shown:
mls
migmatchup
2 Run the migfiles command to copy the data from the source to the target server.
3 (Conditional) If you are migrating users and groups to a different context or matching the user
with different name, run the following commands in the order shown:
maprights
migrights
Examples
 “Tree-to-Tree Migration Using the Migration Tool to Migrate Trustees” on page 119
 “Tree-to-Tree Migration Using the Migration Tool to Migrate Trustees and Flatten the Trustee
Structure” on page 120
 “Tree-to-Tree Migration with Trustees Already Migrated to the New Tree and Reorganized in the
New Tree.” on page 121
Tree-to-Tree Migration Using the Migration Tool to Migrate Trustees
The following example shows how to migrate data from a source NetWare server in one tree to a
target server in another tree. In this example, the target volumes are NSS volumes, and the users are
to be migrated to the same context in the target tree.
1 Create a list of files and trustees on volume V1 on the source server with IP address
192.168.1.3:
mls -s 192.168.1.3 -V V1 > mls.yaml
2 Map the trustees on the source server and output the list to a file:
maptrustees -s 192.168.1.3 -H /media/nss/VOL1/users/ mls.yaml >
maptrustees.yaml
The -H option replaces the home directory of the source server user with the new home directory
specified by -H option. The -H option is a path to the base directory that includes all the home
directories. If the users don’t have home directories, this option doesn’t need to be used.
3 Migrate the trustees to the target server:
migtrustees -d 192.168.1.67 --specific-password novell maptrustees.yaml
Migrating File Systems to OES 2018
119
If you want to assign each user a random password, use --random-password option, it stores
the passwords in a file. To avoid password theft, dispose of the password file in a secure manner
after you have communicated the new passwords to their respective users.
4 (Conditional) When migrating to an NCP Linux volume, if you want to preserve file ownership in
the target tree, you should LUM-enable the migrated users before continuing. For information
about LUM-enabling users, see “LUM Implementation Suggestions” in the OES 2018: Planning
and Implementation Guide.
5 Migrate the data from source volume V1 to target NSS volume VOL1:
migfiles -s 192.168.1.3 -V V1 -x /media/nss/VOL1/ -i
After the users have been migrated (this only needs to be done once), additional data volumes
can be migrated. Repeat Step 1 to Step 5 to migrate other volumes on the source server.
Tree-to-Tree Migration Using the Migration Tool to Migrate Trustees and Flatten
the Trustee Structure
The maptrustees command includes a -k option that allows you to migrate users to a different
context in the target tree. When you do this, the container hierarchy is flattened.
For example, suppose your source eDirectory tree looks like the one shown in Figure 16-1.
Figure 16-1 Source eDirectory Tree Structure
When the users are migrated to ou=test.o=novell, the resulting tree structure is shown in Figure 16-2.
Figure 16-2 Target eDirectory Tree Structure
120
Migrating File Systems to OES 2018
The following example shows how to migrate data from a source server in one tree to a target server
in another tree. In this example, the target volumes are NCP Linux volumes and the new user context
is ou=new-context.o=company.
1 Create a list of files and trustees on volume SRCVOL on the source server with IP address
192.168.1.3:
mls -s 192.168.1.3 -V SRCVOL > mls.yaml
2 Map the trustees on the source server and output the list to a file:
maptrustees -s 192.168.1.3 -H /usr/novell/NCP1/homes/ -k 'ou=newcontext,o=company’ mls.yaml > maptrustees.yaml
The -H option replaces the home directory of the source server user with the new home directory
specified by -H option. The -H option is a path to the base directory that includes all the home
directories. If the users don’t have home directories, this option doesn’t need to be used.
3 Migrate the trustees to the target server:
migtrustees -d 192.168.1.67 --specific-password novell maptrustees.yaml
If you want to assign each user a random password, use --random-password option, it stores
the passwords in a file. To avoid password theft, dispose of the password file in a secure manner
after you have communicated the new passwords to their respective users.
4 (Conditional) When migrating to an NCP Linux volume, if you want to preserve file ownership in
the target tree, you should LUM-enable the migrated users before continuing. For more
information on LUM-enabling users, see “LUM Implementation Suggestions” in the OES 2018:
Planning and Implementation Guide.
5 Migrate the data from source volume SRCVOL to target NCP Linux volume NCP1:
migfiles -s 192.168.1.3 -V SRCVOL -x /usr/novell/NCP1/ -i --no-trustees
After the users have been migrated (this only needs to be done once), various data volumes can
be migrated. Repeat Step 1 to Step 5 to migrate other volumes on the source server.
6 Map the trustee rights on the source server:
maprights -V SRCVOL -k ou=new-context,o=company -x /usr/novell/NCP1/ mls.yaml >
maprights.yaml
7 Migrate the trustee rights to the target server:
migrights -i maprights.yaml
Repeat Step 1, Step 6, and Step 7 to migrate trustee rights for each source volume being
migrated.
Tree-to-Tree Migration with Trustees Already Migrated to the New Tree and
Reorganized in the New Tree.
The following example shows how to migrate data from a source NetWare server in one tree to a
target server in another tree. In this example, the target volume is an NSS volume, and the users
have already been migrated by using tools like Novell Identity Manager so that they now reside in
different contexts in the target tree. In this example, the migration tool is used only to migrate the data
and map the trustees correctly.
1 Create a list of files and trustees on volume V1 on the source server with IP address
192.168.1.3:
mls -s 192.168.1.3 -V V1 > mls.yaml
2 Match the users on the source server to the users on the target server:
Migrating File Systems to OES 2018
121
migmatchup -s 192.168.1.3 -d 192.168.1.67 -k 'ou=re-org,o=company' mls.yaml >
migmatchup.yaml
migmatchup searches for the trustees in their source context. If it doesn't find a matching trustee,
it searches the container specified with the -k option recursively and matches the first trustee
with the same name. If the trustee with the same name is not found, it is not matched.
If the trustee name is changed, then the output of migmatchup can be edited so that each source
trustee is mapped to the corresponding user on the target tree.
3 (Conditional) When you are migrating to a NCP Linux volume, if you want to preserve file
ownership in the target tree, you should LUM-enable the migrated users before continuing. For
more information on LUM-enabling users, see “LUM Implementation Suggestions” in the OES
2018: Planning and Implementation Guide.
4 Migrate the data from source volume SRCVOL to target NSS volume TGTVOL:
migfiles -s 192.168.1.3 -V SRCVOL -x /media/nss/TGTVOL/ -i --no-trustees
After the users have been migrated (this only needs to be done once), various data volumes can
be migrated. Repeat Step 1 to Step 4 migrate other volumes on the source server.
5 Map the trustee rights on the source server:
maprights -V SRCVOL --matchup-file migmatchup.yaml -x /media/nss/TGTVOL/
mls.yaml > maprights.yaml
6 Migrate the trustee rights to the target server:
migrights -i maprights.yaml
Repeat Step 5 and Step 6 to migrate trustee rights for each source volume being migrated.
Limitations
Following are the limitations when performing tree-to-tree migrations:
 If users have home directories on a volume that is migrated, the Home Directory attribute is
changed only for users who are assigned as trustees or belong to the groups that are assigned
as trustees.
 If the maptrustees and migtrustees commands are used to migrate the users then the
following User Object attributes are migrated:
 Common Name (CN)
 Country
 Description (description)
 E-mail Address (mail)
 Fax Number (facsimileTelephoneNumber)
 Full Name (fullName)
 Generational Qualifier (generationQualifier)
 Given Name (givenName)
 Initials (initials)
 Language (Language)
 Locality Name (l)
 Lockout After Detection (lockedByIntruder)
 Login Allowed Time (loginAllowedTimeMap)
 Login Disabled (loginDisabled)
122
Migrating File Systems to OES 2018
 Login Expiration Time (loginExpirationTime)
 Login Grace Limit (loginGraceLimit)
 Login Grace Remaining (loginGraceRemaining)
 Login Intruder Limit (loginIntruderAttempts)
 Login Maximum Simultaneous (loginMaximumSimultaneous)
 Login Script (loginScript)
 Network Address Restriction (networkAddressRestriction)
 Organizational Name (o)
 Organizational Unit Name (ou)
 Password Allow Change (passwordAllowChange)
 Password Expiration Interval (passwordExpirationInterval)
 Password Expiration Time (passwordExpirationTime)
 Password Minimum Length (passwordMinimumLength)
 Password Required (passwordRequired)
 Password Unique Required (passwordUniqueRequired)
 Physical Delivery Office Name (physicalDeliveryOfficeName)
 Post Office Box (postOfficeBox)
 Postal Address (postalAddress)
 Postal Code (postalCode)
 State or Province Name (st)
 Street Address (street)
 Surname (sn)
 Telephone Number (telephoneNumber)
 Title (title)
 When LUM-enabled users are migrated to a new tree, they are no longer LUM-enabled.
Migrating Data to a POSIX File System
This section provides information on migrating data from source NSS volumes to a POSIX file system
such as EXT3 or Reiser on a target server.
 “Mapping Users, Groups, and File Attributes to POSIX” on page 123
 “Example” on page 124
 “Limitations” on page 125
Mapping Users, Groups, and File Attributes to POSIX
In this type of migration, eDirectory users and groups are migrated to POSIX. The useradd and
groupadd commands are used to create the POSIX users and groups corresponding to their
eDirectory equivalents, and the NetWare file attributes are mapped to the POSIX rwx permissions.
Objects in eDirectory with an objectClass of Organization, groupOfNames, or organizationUnit are
mapped to POSIX groups. Those with objectClass organizationalPerson are mapped to POSIX
users.
Migrating File Systems to OES 2018
123
Because POSIX user and group names are more restrictive than eDirectory object names, the
following conventions are used to map the common name (cn) of the objects to POSIX:
 Names with 32 or more characters are truncated to 31 characters in length.
 Characters not belonging to the POSIX portable character class ([A-Za-z_] [A-Za-z0-9_-.] * [AZa-z0-9_-.$]) are replaced by an underscore ( _ ) character.
For more details about POSIX names, see the man page for the useradd command.
NetWare file attributes are mapped as shown in Table 16-2.
Table 16-2 Mapping NetWare Attributes to POSIX Permissions
NetWare Attribute
POSIX Permissions
No attributes set
rw_ ___ ___
Read Only and Hidden
___ ___ ___
Read Only
r__ ___ ___
Hidden
_w_ ___ ___
For directories, the execute bit for the owner is set.
NOTE: These mappings are based on NetWare attributes, not trustee rights. Administrators should
evaluate the post-migration POSIX permissions and make adjustments as necessary to maintain
suitable data security for users.
1 Run the migfiles command to copy the data from the source to the target server.
2 (Conditional) If you need to modify the home directories of the migrated users, run the following
three commands in the order specified:
mls
maptrustees
migtrustees
3 Run the following commands in the order shown:
mls
maprights
migrights
Example
The following example shows how to migrate data to a POSIX file system.
1 Create a list of files and trustees on volume SRCVOL:
mls -s 192.168.1.3 -V SRCVOL > mls.yaml
2 Map the trustees on the source server and output the list to a file:
maptrustees -s 192.168.1.3 -p -H /data/home/ mls.yaml > maptrustees.yaml
The -H option replaces the home directory of the source server user with the new home directory
specified by -H option. The -H option is a path to the base directory that includes all the home
directories. If the users don’t have home directories, this option doesn’t need to be used.
3 Migrate the trustees to the target server:
124
Migrating File Systems to OES 2018
migtrustees -p --specific-password novell maptrustees.yaml
If you want to assign users with random password, use the --random-password option, it stores
the new passwords in an output file. To avoid password theft, dispose of the password file in a
secure manner after you have communicated the new passwords to their respective users.
4 Migrate the data from the volume SRCVOL on the source server with IP address 192.168.1.3 to
the target POSIX path:
migfiles -s 192.168.1.3 -V SRCVOL -x /path/to/copy --no-trustees -pi
Substitute the desired target POSIX path for /path/to/copy.
Users must be migrated before migrating data volumes. Repeat Step 1 to Step 3 for migrating
trustees.
5 Map the trustee rights on the source server:
maprights -p -V SRCVOL1 -x /path/to/copy -m maptrustees.yaml mls.yaml >
maprights.yaml
6 Migrate the trustee rights to the target server:
migrights -p maprights.yaml
Repeat Step 4, Step 5, and Step 6 for each source volume being migrated.
Limitations
Sparse files are copied as normal files when migrated from NSS to POSIX. This is because of a
known limitation from the POSIX perspective. Sparse files are generally supported on restore by
restoring the data areas to sparse locations in the file system. The file system then determines
whether or not to preserve the sparse nature of the file. POSIX file systems do not preserve the
sparse nature of sparse files.
File System Migration Commands
The migration tool include several command line tools for file system migrations. Each tool performs
a subtask of the migration by taking the required input and outputting the converted output or results
to stdout. Table 16-3 lists the commands that are available for file system migrations.
Table 16-3 File System Migration Commands
Command
Description
mls
Lists all files in source NSS path, with associated trustees, rights, and quotas.
migmatchup
Matches users and groups from the source server to the target server.
maptrustees
Maps users and groups from the source server to the target server specifications.
migtrustees
Creates users and groups on the target server based on the output generated by the
maptrustees command.
migfiles
Copies files and folders from a source server to a target server.
maprights
Maps NetWare NSS/Traditional or OES NSS file system rights to OES 2015 or later file
system rights.
migrights
Sets file rights on the target server as defined by the output from the maprights
command.
Migrating File Systems to OES 2018
125
The sections that follow discuss these commands and their options in greater detail. You can also
refer to the respective man page for each command or use the -h (--help) and --usage options.
mls
The mls command lists files and associated trustees, rights, and quotas from source servers. The
output from this command is used as input for both maprights and maptrustees.
To gather the required information for NetWare Traditional or NSS volumes, mls copies tcnvlnx.nlm
to the NetWare server. To gather this information for OES NSS volumes, it uses
the.trustee_database.xml file in the ._NETWARE directory.
Syntax
mls -s -V|-X [--continue-after-failover] [-e] [-c] [--precheck] [--update-ifnewer] [--progress] [--progress-
interval] [--source-unsecure-ldap] [--source-ldap-port] [--debug] [--modified-after] [--modified-before] [-accessed-after] [--accessed-before] [--no-dirquotas] [--no-userquotas]
Options
Option
Long Form
Purpose
-s
--source-server
Specifies the source server’s IP address.
Example: -s 192.168.1.3
-V
--source-path
Specifies the volume or directory path to use on the source server.
Examples: -V NSSVOL
-V VOL1:/apps/data
-X
-e
[-c]
--source-full-path
Indicates the full path of the volume to use on the source server.
--continue-afterfailover
Specifies that mls continues migration after a resource failover.
--exclude
Excludes filter on files to be copied. Use this multiple times for excluding
multiple file types (eg. -e "*.mp3" -e "*.tmp").
--source-unsecureldap
Uses unsecure LDAP connection for all LDAP calls. By default mls uses
secure LDAP.
--source-ldap-port
Uses the specified port for LDAP calls. By default, it uses port number 389 for
unsecure LDAP and 636 for secure LDAP.
--session-file
These options are explained in the Additional Migration Options.
--progress
--progress-interval
--debug
--precheck
126
--modified-after
Scans files which are modified after this date.
--modified-before
Scans files which are modified before this date.
--accessed-after
Scans files which are accessed after this date.
Migrating File Systems to OES 2018
Option
Long Form
Purpose
--accessed-before
Scans files which are accessed before this date.
--no-dirquotas
Directory quota information is not listed.
--no-userquotas
User quota information is not listed.
migmatchup
The migmatchup command uses input from the mls command to produce a mapping of users and
groups from the source server to those on the target server. It uses ldapsearch to retrieve the user
and group data from the source and destination LDAP server.
Objects can be excluded from migration by specifying them in the global /etc/opt/novell/
migration/obj-exclude-list.conf file or a custom exclude file can be specified using the -E
option. The global exclude file has entries to not migrate NetWare specific user like
"cn=admin,ou=Tomcat-Roles,*". If a custom exclude file is specified then the global exclude file is not
read.
Syntax
migmatchup -s -d -k [-E] [-c] [--progress] [--progress-interval] [--debug] [-precheck] [--source-unsecure-ldap] [--source-ldap-port] [--destination-unsecureldap] [--destination-ldap-port] <inputfile>
Options
Option
Long Form
Purpose
-s
--source-server
Specifies the source server's IP address.
-d
--destination-server
Specifies the target server's IP address.
-k
--destination-ldapcontainer
Options to specify LDAP container to be searched for finding matching
users and groups.
-E
--obj-exclude-file
Excludes the objects listed in this file from migration. The entries can
contain pattern with wild cards * and ?. Refer to the object exclude file /
etc/opt/novell/migration/obj-exclude-list.conf for more
details.
-c
--session-file
These options are explained in the Additional Migration Options.
--progress
--progress-interval
--debug
--precheck
--source-unsecure-ldap
Uses unsecure LDAP connection for all LDAP calls. By default migfiles
uses secure LDAP.
--source-ldap-port
Uses the specified port for LDAP calls. By default, it uses port number
389 for unsecure LDAP and 636 for secure LDAP.
--destination-unsecureldap
Uses unsecure LDAP connection for all LDAP calls. By default migfiles
uses secure LDAP.
Migrating File Systems to OES 2018
127
Option
Long Form
Purpose
--destination-ldap-port
Uses the specified port for LDAP calls. By default, it uses port number
389 for unsecure LDAP and 636 for secure LDAP.
inputfile
Indicates the output file produced from the mls command from stdin.
Example
This example illustrates matching users and groups from source server to a target server:
migmatchup -s 192.168.1.3 -d 192.168.1.4 -k o=company mls.yaml
maptrustees
The maptrustees command maps the users and groups from the source server’s tree or domain to
the target server’s specifications. It uses input from mls to produce and map user and group data
from the source server. You must use maptrustees when migrating data to a different tree or when
migrating users and groups to a different context.
By default, maptrustees maps users and groups into a new target tree. The target file server should
be in the same tree as the LDAP target server. You can use the -k option to map users and groups
into a single target container.
The maptrustees command can also be used to map users and groups to POSIX users and groups
in /etc/passwd and /etc/group. It uses ldapsearch to retrieve the user and group data from the
source LDAP server. The source LDAP server should be in the same tree as the source file server
that produced the mls output.
Syntax
maptrustees -s [-H] [--map-homedir-only] [-p] [-k] [--matchup-file] [-g] [-E] [-source-unsecure-ldap] [--source-ldap-port] [--debug] [--precheck] [-c] [-progress] [--progress-interval] <inputfile>
Options
Option Long Name
Purpose
-s
Specifies the source server’s IP address.
--source-server
Example: -s 192.168.1.3
[-H]
--homedir
Specifies the path to the directory for migrating user’s home
directories. This option is used to map users’ home directories to the
new path on the target server.
Example: -H /media/nss/nssvol1/homedir
[-p]
128
[--map-homedir-only]
This option is used when source and destination servers are in same
tree. This option forces maptrustees to generate only home directory
information of users, so that migtrustees can just modify home
directories of users. You must also pass --homedir(-H) option along
with this option.
[--posix]
Maps users and groups to /etc/passwd and /etc/group on the
OES server. Default is LDAP, if no mapping option is specified.
Migrating File Systems to OES 2018
Option Long Name
Purpose
[-k]
Specifies the container where all users and groups are to be
migrated.
[--destination-ldapcontainer]
Example: -k ou=merged,o=company
[-g]
--matchup-file
Specify a user matchup file as generated by migmatchup.
[--primary-group]
Specifies the primary POSIX group for migrated users. If not
specified, the default primary group is “users.”
Example: -g migrated-users
The specified group must be created before you run the
migtrustees command, because migtrustees does not create
the group.
[-E]
--source-unsecure-ldap
Uses unsecure LDAP connection for all LDAP calls. By default
migfiles uses secure LDAP.
--source-ldap-port
Uses the specified port for LDAP calls. By default, it uses port
number 389 for unsecure LDAP and 636 for secure LDAP.
[--obj-exclude-file]
Excludes from migration the objects listed in the specified file.
Example: -E excludefile.txt
If this option is used, the global exclude file is not read. See
“Excluding Objects” on page 130 for more information.
[-c]
--session-file
These options are explained in the Additional Migration Options.
--progress
--progress-interval
--debug
--precheck
inputfile
Indicates the output file produced from the mls command or from
stdin.
Examples
 This first example illustrates mapping users and groups to the same container in the target tree
as in the source tree:
maptrustees -s 192.168.1.3 mls.yaml
The example assumes you have the same tree structure in the target tree as in the source tree.
 This next example illustrates mapping users and groups to a new container in the target tree,
using the output from the mls command:
maptrustees -s 192.168.1.3 -k ou=merged,o=company mls.yaml
A new container named ou=merged,o=company is created in the target tree, and all migrated
users and groups are created within that container.
 This third example illustrates mapping users to /etc/passwd and /etc/group in a POSIX
environment and redirect the output to maptrustess.yaml file:
maptrustees -s 192.168.1.3 -p mls.yaml > maptrustees.yaml
Migrating File Systems to OES 2018
129
Excluding Objects
When generating the list of users and groups to be mapped to the target tree, maptrustees reads the
obj-exclude-list.conf file in the /etc/opt/novell/migration/ directory and excludes the
eDirectory objects listed in that file.
The global exclude file includes entries for NetWare objects, such as cn=admin,ou=Tomcat-Roles.
If you find that objects are being migrated from your source eDirectory tree that you do not want to
appear in the target tree, you can add the objects to the obj-exclude-list.conf file. Use fully
distinguished object names in LDAP (comma-delimited) format. For example:
cn=testuser,ou=users,o=novell
NOTE: NCP Server objects that are assigned as file system trustees are not migrated in a tree-totree migration.
migtrustees
The migtrustees command uses input from maptrustees to create users and groups in the target
tree. It uses ldapadd and ldapmodify to make the changes on the target LDAP server.
If the -p (--posix) option has been specified in maptrustees, migtrustees uses useradd and
groupadd to create users and groups in /etc/passwd and /etc/group.
If the -g (--primary-group) option was specified in maptrustees, the specified group must already
exist or it must be created before running migtrustees.
Syntax
migtrustees -d [-i] [-A] [-m] [-p] [-r] [--destination-unsecure-ldap] [-destination-ldap-port] [--debug] [--precheck] [-c] [--progress] [--progressinterval] [--specific-password] [--newusers-password-file] <inputfile>
Options
Option Long Form
Purpose
-d
Specifies the target server’s IP address (not needed for POSIX
migrations).
--destination-server
Example: -d 192.168.1.5
[-i]
[--verbose]
Prints verbose information regarding the user and group migration
status.
[-A]
[--audit]
Audits the results of the user and group migration.
[-m]
[--modify-existing]
Modifies or updates users or groups if they already exist.
If you do not include the -m option, the migtrustees command
displays user exists errors if a User object being migrated is already
present in the target eDirectory tree. In this case, no modifications are
made to the User object in the target tree.
[-p]
130
[--posix]
Migrating File Systems to OES 2018
Creates POSIX users and groups on destination server. Default is
LDAP.
Option Long Form
[-c]
Purpose
--destination-unsecure-ldap
Uses unsecure LDAP connection for all LDAP calls. By default, migfiles
uses secure LDAP.
--destination-ldap-port
Uses the specified port for LDAP calls. By default, it uses port number
389 for unsecure LDAP and 636 for secure LDAP.
--session-file
These options are explained in the Additional Migration Options.
--progress
--progress-interval
--debug
--precheck
[-s]
--specific-password
Specify the password for newly created users. You must note the
password so that it can be forwarded to individual users.
If the specific password or random password option is not specified,
then the users are created but locked until you assign a password.
[-r]
--random-password
Generate random passwords for new users created on the target
server. When using this option, you must always pass the --newuserspassword-file option so that the randomly generated passwords and
usernames are stored in the file.
--newusers-password-file
The newly created usernames along with passwords are stored in the
file specified with this option. This option must be passed with the -random-password option.
If the specified file exists, migtrustees appends the file else it creates a
new file with read-only permission.
inputfile
Indicates the output file produced from the maptrustees command or
from stdin.
Examples
 To migrate users and groups to a target tree, using an LDAP server with the IP address of
192.168.1.4 in the target tree:
migtrustees -d 192.168.1.4 -s novell maptrustees.yaml
 To audit the outcome of a trustee migration:
migtrustees -d 192.168.1.4 -A -s novell maptrustees.yaml
 To migrate users and groups to POSIX with verbose information:
migtrustees -i -p -s novell maptrustees.yaml
Migrating File Systems to OES 2018
131
migfiles
The migfiles command copies files from NetWare Traditional or NSS volumes to target NSS, NCP,
or POSIX paths. It uses the Storage Management Services (SMS) framework to migrate file data and
metadata.
When the migration is between two servers in the same eDirectory tree, migfiles copies the
trustees and rights information along with the file data. When migrating data to a server in a different
tree, migfiles copies only the file data. You must use other commands such as mls, maptrustees,
migtrustees, maprights, and migrights to migrate the trustees and rights information.
Syntax
migfiles -s [-p] [-i] -v|-x -V|-X [--continue-after-failover] [--disable-login] [P] [-e] [--exclude-path] [-c] [--no-trustees] [--trustees-only] [--deleteexisting-trustees] [--source-unsecure-ldap] [--source-ldap-port] [--debug] [-precheck] [--progress] [--progress-interval] [--demigrate-files] [--neveroverwrite] [--update-ifnewer] [--modified-after] [--modified-before] [--accessedafter] [--accessed-before] [--usecodeset] [--no-dirquotas] [--no-userquotas] [-sync] [--delete] [--delete-file-on-restore-error] [--ignore-quota-checking] [-trustees-dirs-only]
General Options
Option Long Form
Purpose
-s
Specifies the source server’s IP address.
--source-server
Example: -s 192.168.1.3
[-p]
[--posix]
Specifies that the target is a POSIX path. (If not specified, the default
target type is NCP over POSIX.).
[-i]
[--verbose]
Prints verbose file migration status.
-V
--source-path
Specifies the source path, in VOLNAME or VOLNAME:/path format.
Example: -V NSSVOL -V VOL:apps/data -V winshare
@srcpathfile
Specifies the source file that includes multiple source paths and is
prefixed with a symbol (@).
Example: -V @srcpathfile
-v
--destination-path
Specifies the volume on the target server where the files are copied.
This option cannot be used with the -x option.
Example: -v VOL1
-x
--destination-full-path Specifies the target path for copying NSS, NCP, or POSIX data. This
option cannot be used with the -v option.
Example: -x /media/nss/TEST
@destpathfile
Specifies the target file that includes corresponding target paths and is
prefixed with a symbol (@).
Example: -x @destpathfile
132
Migrating File Systems to OES 2018
Option Long Form
Purpose
-X
Specifies the source path for copying NSS, NCP, or POSIX data. This
option cannot be used with the -V option.
--source-full-path
Example: -X /media/nss/TEST
[-e]
--continue-after-failover
Specifies that migfiles continue migration after a resource failover.
--disable-login
New logins to source server are disabled during data migration.
--never-overwrite
Do not overwrite files that already exist on the target server.
[--exclude]
Sets an exclude filter on files to be copied. Use this option multiple
times to exclude multiple file types.
Example: -e "*.mp3" -e "*.tmp"
[-c]
--exclude-path
Excludes the directory with the specified source path from migration.
Use this multiple times for excluding multiple directories or files.
--source-unsecure-ldap
Uses unsecure LDAP connection for all LDAP calls. By default,
migfiles uses secure LDAP.
--source-ldap-port
Uses the specified port for LDAP calls. By default it uses port number
389 for unsecure LDAP and 636 for secure LDAP.
--session-file
These options are explained in the Additional Migration Options.
--progress
--progress-interval
--debug
--precheck
-u
--no-trustees
Do not migrate trustees.
--trustees-only
Migrate only the trustees. New trustees added to the source server are
migrated to the target server.
--delete-existing-trustees
Trustees that do not exist on the source server are deleted from the
target server. You must use this option with --trustees-only option.
--demigrate-files
Migrates the data of HSM migrated files. By default, only stubs are
migrated.
--update-ifnewer
Updates the file on the target server with the new data from the file on
the source server.
--modified-after
Migrates files which are modified after this date.
--modified-before
Migrates files which are modified before this date.
--accessed-after
Migrates files which are accessed after this date.
--accessed-before
Migrates files which are accessed before this date.
--usecodeset
Code page value of the source server. This option is applicable only
for NetWare 5.1 server.
--no-dirquotas
Do not migrate directory quotas.
--no-userquotas
Do not migrate user quotas.
Migrating File Systems to OES 2018
133
Option Long Form
Purpose
[--sync]
Synchronizes source server and target server. Migrates files from the
source server that are not available on the target server or is modified
after the date given.
[--delete]
Synchronizes source server and target server. You must use this
option with --sync option. Files that do not exist on the source server
are deleted from the target server.
[--delete-file-on-restore-error] Deletes partially restored or 0 byte files that are created during
synchronization .
--ignore-quota-checking
Disables quota checking on the target server. When migration is
completed, migfiles enables quota checking.
--trustees-dirs-only
Synchronizes trustees only at the directory level. Trustees for files are
not synchronized. This option must be used only with the --trusteesonly option or with the sync options.
NetWare to Linux Migration Options
The following options can be used only in NetWare-to-Linux migrations.
Option
Long Form
Purpose
[-c]
[--session-file]
Stores the migration’s progress, including the date and time of the
migration, the source and target IP addresses, and the source and
target volume names, in the specified session file.
Example: -c "status.log"
This file can be used to resume a previously halted migration job. If an
absolute or relative path is not specified with the filename, migfiles
searches the current working directory for the file. If the specified file
does not exist, all files are migrated. See “Multi-Session Migration” on
page 135 for more information.
[-u]
[--update]
Migrates files newer than the date specified with this option. See
“Updating Modified Files” on page 135 for more information.
This option supports date/time inputs in the following formats:
"%d-%m-%Y %H:%M:%S"
"%d-%m-%Y %H:%M"
where d, m, Y, H, M, and S are format variables of standard Linux date/
time implementations. The supported formats can be extended by
using the DATEMSK environment variable. The DATEMSK
environment variable must be sent to the file path pointing to the date/
time formats to support. See getdate(1) and strptime(3) for more
information on using DATEMSK.
134
[--no-trustees]
Excludes trustees while migrating file system data.
[--demigrate files]
Migrates the data of HSM-migrated files. By default, only stubs are
migrated.
[--update-ifnewer]
Updates the file if the file on the source server is newer than the file on
the target server. This option is applicable only for data migration.
Migrating File Systems to OES 2018
Multiple Source Path Migration
This command migrates the source paths listed in the source file srcpathfile to corresponding
target paths listed in the target file destpathfile. Pass the srcpathfile with -V and destpathfile
with -x option prefixed with a symbol (@). The sample IP address is 192.168.1.3 of the source server.
Source Paths in srcpathfile
Target Paths in destpathfile
DATA:DEPT/finance
/media/nss/DATA/finance
DATA:DEPT/legal
/media/nss/DATA/legal
migfiles -s 192.168.1.3 -V @srcpathfile -x @destpathfile -i
Progress Indicator
While the migfiles command is running (without the -i option), a pound (#) character is displayed
for every 100 files migrated.
Multi-Session Migration
The -c or --session-file option of the migfiles command allows you to stop the migration
partway through and then continue it later from where it left off. This is especially useful when
migrating large data volumes that might take several working days to copy and that must remain
online during the migration.
For example, the following command stores the migration’s progress and other metadata in a session
file named V1-to-V1 090907:
migfiles -s 192.168.1.3 -v VOL1 -V VOL1 -ni -c "V1-to-V1 090907"
To terminate the migration session at any time, press Ctrl+C. You can resume the session later by
reentering the migfiles command by passing the same session file V1-to-V1 090907
Updating Modified Files
Another useful option for the migfiles command is the -u or --update option. This option lets you
specify a date and time, then migfiles copies only files that have been modified after this date and
time. This option must be used after completing a multi-session migration described above to update
all the files modified by users during the migration. The session file contains the data and time at
which the migration started.
For example, the following command updates all the files on the target volume that have been
modified at the source after 9 September 2008 at 12:30:
migfiles -s 192.168.1.3 -v V1 -V V1 -ni -u "9-09-2007 12:30"
maprights
The maprights command gleans file system rights information from the mls output and maps the
rights to a specified volume or path on the target server. You can specify a mapping to NSS, NCP, or
POSIX rights.
If the target server is in a different tree and users and groups are in new containers, you can use the
-k option to migrate the users and groups into a specified container in the target eDirectory tree.
Migrating File Systems to OES 2018
135
Syntax
maprights -V [-p] -v|-x [-k] [--matchup-file] [-m] [--debug] [--precheck] [-c] [-progress] [--progress-interval] <inputfile>
Options
Option Long Form
Purpose
-V
Specifies the volume or directory path to use on the source server.
--source-path
Examples: -V NSSVOL
-V VOL1:/apps/data
[-p]
[--posix]
Maps user rights to POSIX file system access rights.
-v
--destinationpath
Specifies the volume on the target server where the rights information is
mapped. This option cannot be used with the -x option.
Example: -v NSSVOL
-x
--destinationfull-path
Specifies the volume path on the target server where the rights information is
mapped. You must use -x in maprights if you have used -x in migfiles.
[-k]
[--destinationldap-container]
Specifies an eDirectory container where all users and groups are to be
migrated. You must use -k in maprights, if you have used -k in
maptrustees.
Example: -k ou=users,o=company
[-m]
[--matchup-file]
Specify a user matchup file as generated by migmatchup.
[--maptrusteesfile]
Specifies the name of the maptrustees file associated with this maprights
migration (required for POSIX rights mapping).
Example: -m maptrustees.yaml
inputfile
Indicates the name of the output file produced from the mls command or from
stdin.
--session-file
These options are explained in the Additional Migration Options.
[-c]
--progress
--progress-interval
--debug
--precheck
migrights
The migrights command uses input from maprights to set file rights on the target server. All details
for setting rights are stated in the input file. migrights uses this information to set the rights
appropriately on the target file system.
Syntax
migrights [-i] [-A] [-t] [-p] [--debug] [--precheck] [-c] [--progress] [--progressinterval] <inputfile>
136
Migrating File Systems to OES 2018
Options
Option
Long Form
Purpose
[-i]
[--verbose]
Prints verbose rights migration status.
[-A]
[--audit]
Audits the results of the file rights migration.
[-t]
[--test]
Performs a test run of the rights migration operation.
[-p]
[--posix]
Indicates that the destination path is POSIX.
[-c]
--session-file
These options are explained in the Additional Migration Options.
--progress
--progress-interval
--debug
--precheck
inputfile
Indicates the output file produced by the maprights or from stdin.
[--debug]
Prints debug messages to the migrights log file located at /var/
opt/novell/log/migration/.
Examples
 To set rights on the target file system with verbose output:
migrights -i maprights.yaml
 To audit the outcome after setting rights on the target file system:
migrights -i -A maprights.yaml
 To perform a test run with the output from maprights and see if the files and users exist in the
target tree. The test results are being directed to migrights-t.yaml:
migrights -i maprights.yaml -t > migrights-t.yaml
Additional Migration Options
The Migration Tool provides additional options to be executed with file system migration utilities.
You can execute these commands with file system migration utilities. Table 16-4 lists the additional
options that are available for file system migrations.
Migrating File Systems to OES 2018
137
Table 16-4 Additional Migration Options with File System Commands
Option
Description
--session-file
Stores migration progress. This file is used to continue migration.
--progress
Displays the progress (in terms of percentage) of the command being
executed.
--progress-interval
Specifies the time interval for displaying the progress of a command.
--debug
Executes the command in a debug mode and creates a log file.
--precheck
Validates the arguments passed in a command.
Session File
A session file stores the status of a command, checkpoint information of a command (the point at
which the execution of command was stopped), and parameters for validating the session file. You
can create a session file by executing a command with --session-file option.
An example to create a session file for the migfiles command:
migfiles -s 192.168.1.3 -iV src_volume -v dest_volume --session-file /home/
migfiles_session.session
This command migrates data from the source NSS volume src_volume to the target NSS volume
dest_volume. You can stop the command and re-execute it at a later stage. On executing the
command at a later stage, the migfiles_session.session file is taken as an input and the
migfiles command starts at the point when it was last stopped.
For example, your source volume contains 50 GB of data and after migrating 40 GB of data, migration
was stopped. On re-executing the migfiles command, the remaining 10 GB of data is migrated.
Sample Session File:
src-server: 192.168.1.3
dest-server: 192.65.1.2
src-path: "DFS:"
dest-path: "/media/nss/VOL1/"
started-on: "18-7-2008 16:8:15"
status: stopped
stopped-at: "DFS:db/"
Bytes Processed: 22
Progress
The --progress command can be executed with any command to display the progress of the
command being executed.
To view progress on executing the migtrustees command:
migtrustees -d 192.168.1.3 maptrustees.yaml -i --progress
Output of the command:
Created 200 trustees of 500
138
Migrating File Systems to OES 2018
When you execute the migtrustees command with the --progress option, it displays the progress
of trustee creation. You can set the time to display the progress by specifying the --progressinterval option.
Progress Interval
The --progress-interval option is used along with --progress option to specify the time interval
for displaying the progress of a command. The default time interval is 30 seconds for refreshing the
progress of a command.
To view progress every 10 seconds on executing the migtrustees command:
migtrustees -d 192.168.1.3 maptrustees.yaml -i --progress --progress-interval 10
The migtrustees command refreshes the progress every 10 seconds.
Debug
The --debug option executes the command in debug mode and creates a log file in /var/opt/
novell/log/migration folder.
To execute mls command in debug mode:
mls -s 192.168.1.3 -V src_volume --debug
This command creates an mls.log file that is stored in the /var/opt/novell/log/migration folder.
Precheck
The --precheck option validates the arguments passed in a command.
To execute the migfiles command:
migfiles -s 192.165.1.1 -iV src_volume -v dest_volume --precheck
On executing this command, the --precheck option validates the existence of the src_volume and
dest_volume on the source server and the target server. The command authenticates to the source
server and target server and also checks if SMS is running on the target server.
Troubleshooting
 “Same Tree Scenario” on page 139
 “Different Tree Scenario” on page 140
 “General Issues” on page 141
Same Tree Scenario
 “The Migration Tool File System GUI, Volume Information Tab Displays Empty Boxes for NonEnglish Directory Names.” on page 140
 “Error nbackup: open file” on page 140
 “Error nbackup: execute only files” on page 140
 “Error nbackup: A file cannot be read and nbackup: Failed to read dataset” on page 140
Migrating File Systems to OES 2018
139
The Migration Tool File System GUI, Volume Information Tab
Displays Empty Boxes for Non-English Directory Names.
In the migration tool file system GUI, Volume Information tab displays empty boxes for non-english
directory names.This issue occurs if the corresponding language is not installed on the source server.
To install fonts for non-english languages, run yast2 language, and select languages in the
Secondary Languages pane. After installing required languages, restart the migration project.
Error nbackup: open file
Open files on the source server are not migrated. If files are open, they are not migrated because this
causes data inconsistencies.
Close the files and then perform migration.
Error nbackup: execute only files
nbackup encountered files with the Execute-only bit set. By default, these files are not copied.
If you want to copy the Execute-only files, use the tsafs /ExcludeExecuteOnly=0 setting on the
source NetWare server.
Error nbackup: A file cannot be read and nbackup: Failed to read
dataset
Source volumes or the target volumes are unavailable or are renamed during migration.
Do not rename volumes when migration is in progress. If migration stops because a volume is
unavailable, ensure that the volume is properly activated and mounted, then restart the migration
project.
Different Tree Scenario
 “Ownership Information is Changed on Migrating from NSS to NCP” on page 140
Ownership Information is Changed on Migrating from NSS to NCP
If the ownership information is changed on migrating from NSS to NCP, make sure you LUM-enable
the users that are migrated into the target eDirectory tree before you run the migfiles command.
If you LUM-enabled the users that were migrated into the target eDirectory tree and still don’t see the
proper ownership information (for example, the owner is nobody as viewed in POSIX, or the server
name as viewed by the Novell Client), try the following:
1 At the OES server terminal prompt, enter namcd cache_refresh.
2 Synchronize the eDirectory replicas by using DSREPAIR.
3 Enter nsscon /resetidcache.
4 To verify the information of the owner, enter:
ls -l /usr/novell/NCP1
140
Migrating File Systems to OES 2018
General Issues
 “File System Migration Fails with FATAL error: nbackup command failed to complete” on
page 141
 “File System Migration Fails When TSAFS is Set to Netware Mode on a OES11 Server” on
page 141
 “When You Configure the File System GUI, an Error is Displayed that the Volumes on the Source
Server (NetWare 6.0 or Later) are Not Mapped” on page 141
 “When You Start Migration, an Error is Displayed and Migration Fails” on page 142
 “Migration Fails Due to Failure of the migtrustees Command” on page 142
 “Not Getting the Code Page and Non-English Characters” on page 143
 “Source Cluster Volumes are Not Displayed” on page 143
 “Files or Trustees are Not Synchronized” on page 144
File System Migration Fails with FATAL error: nbackup command
failed to complete
There might be two admin users in the system (local admin user and eDirectory admin user). The
failure was caused because the local admin user which does not have permission was trying to
perform file system migration.
To resolve this issue, delete or rename the local admin user, then perform file system migration.
File System Migration Fails When TSAFS is Set to Netware Mode on
a OES11 Server
To resolve this issue, set the parameter tsamode to Linux in the /etc/opt/novell/sms/tsafs.conf
file.
When You Configure the File System GUI, an Error is Displayed that
the Volumes on the Source Server (NetWare 6.0 or Later) are Not
Mapped
If the Novell Client fails, the volumes on the source server are not mapped. The file system migration
does not depend on the Novell Client commands, but it uses nwmap to map the source volumes. The
details of the error is logged in /var/opt/novell/migration/<project name>/log/
filesystem.log.
To troubleshoot this issue, perform the following:
1 Verify the status of the Novell Client by entering the following command:
rcnovfsd status
1a If the service is running, restart the service by entering the following command:
rcnovfsd restart
or
If the service is not running, start the service by entering the following command:
Migrating File Systems to OES 2018
141
rcnovfsd start
1b To configure the file system, select the file system and click Configure.
2 (Conditional) If the error is displayed again, verify the status of novell-xregd service by entering
the following command:
rcnovell-xregd status
2a If the status is running, restart the service by entering the following command:
rcnovell-xregd restart
or
If the status is not running, start the service by entering the following command:
rcnovell-xregd start
2b Restart the Novell Client by entering the following command:
rcnovfsd restart
2c To configure the file system, select the file system and click Configure.
3 (Conditional) If the error is displayed after restarting novfsd and novell-xregd services, refer to
the log file to verify if the Novell Client has failed to resolve the IP address.
3a If the IP address was not resolved, create a /etc/opt/novell/ncl/protocol.conf file
and add the following line in it: Name_Resolution_Providers=NCP,SLP,DNS
3b Restart the Novell Client by entering the following command:
rcnovfsd restart
3c To configure the file system, select the file system then click Configure.
When You Start Migration, an Error is Displayed and Migration Fails
When you click Start in the main migration window, migration fails and you receive the error that no
data sets are found.
 “Source Server is OES 2 SP3 or OES 11” on page 142
Source Server is OES 2 SP3 or OES 11
Migration might fail if there is some problem during the setup and zapi is not loaded on the source
server. To troubleshoot this issue, perform the following:
1 Verify that zapi is loaded on the source server by executing the following command:
lsmod | grep zapi
2 (Conditional) If zapi is displayed in the list then update the zapi.
3 (Conditional) If zapi is not displayed in the list, restart SMDR.
novell-smdrd restart
4 Click on Start, to start the migration.
Migration Fails Due to Failure of the migtrustees Command
The migtrustees command fails with a fatal error which is recorded in the filesystem.log file.
The migtrustees command takes input from the maptrustees.yaml file, which includes various
attributes. Some special characters are included in the loginScript attribute of the maptrustees.yaml
file which is not recognized by the migtrustees command causing failure in migration.
142
Migrating File Systems to OES 2018
To troubleshoot this issue, perform the following steps:
1. Open the iManager page on the source server.
2. Click Users > Modify Users.
3. Select the username, which has special characters in the login script.
For example, if you see the error for cn=testuser,ou=users,o=novell in the filesystem.log file,
select testuser from the user list.
4. Click General > loginScript.
5. Remove the special characters from the login script.
6. Click on apply then ok.
7. Remove the migtrustees.session, maptrustees.session and the maptrustees.yaml files
from the /var/opt/novell/migration/<Project name>/fs/ folder of the target server.
This ensures that we re-execute the maptrustees command when continuing the migration
process.
8. Click Start on the main Migration Tool window of the target server to continue migration.
Not Getting the Code Page and Non-English Characters
 “Migrating from Netware 6.5 or Later” on page 143
Migrating from Netware 6.5 or Later
The language pack is not installed on the target server, so the code page and the non-English
characters are not displayed.
You need to install the language pack of the source server on the target server before starting the
migration tool.
Source Cluster Volumes are Not Displayed
This issue occurs because the Is Cluster Resource option is not selected in Source Server
Authentication or the cluster resource is down.
If the Is Cluster Resource option is not selected, select the option from Source Server
Authentication, then reconfigure.
or
If the Is Cluster Resource option is selected and the cluster volumes are not displayed, verify the list
of cluster volumes by executing the following command:
/opt/novell/sms/bin/smstool --list-cluster-volumes -R <resourceIP> -U
<admin_credentials>
Migrating File Systems to OES 2018
143
Files or Trustees are Not Synchronized
If files are open on the source server during synchronization, those files are not synchronized with the
files on the target server. If trustees are deleted on the source server during or before
synchronization, the trustees are not migrated. Ensure that you verify the following before
synchronizing, then click Sync.
 No application or user is accessing the source volumes that are being copied.
 Select disable login in the file system GUI to restrict access to the source volumes.
144
Migrating File Systems to OES 2018
VII
Service Migration
VI
 Chapter 17, “Migrating eDirectory to OES 2018,” on page 147
 Chapter 18, “Migrating AFP to OES 2018,” on page 151
 Chapter 19, “Migrating CIFS to OES 2018,” on page 157
 Chapter 20, “Migrating DHCP to OES 2018,” on page 169
 Chapter 21, “Migrating DNS to OES 2018,” on page 183
 Chapter 22, “Migrating DSfW to OES 2018,” on page 189
 Chapter 23, “Migrating LUM to OES 2018,” on page 193
 Chapter 24, “Migrating FTP to OES 2018,” on page 195
 Chapter 25, “Migrating iPrint to OES 2018,” on page 201
 Chapter 26, “Migrating NetStorage to OES 2018,” on page 229
 Chapter 27, “Migrating NTP to OES 2018,” on page 233
 Chapter 28, “Migrating NCP to OES 2018,” on page 235
 Chapter 29, “Migrating OpenSLP to OES 2018,” on page 237
 Chapter 30, “Migrating Proxy users to OES 2018,” on page 239
Service Migration
145
146
Service Migration
17
Migrating eDirectory to OES 2018
17
eDirectory migration to Open Enterprise Server (OES) 2015 or later requires the migration of the
eDirectory data and server identity to provide seamless accessibility after migration.The eDirectory
migration utility performs all of the pre-migration tasks, health validations and server backups, server
migration, and post-migration tasks for you.
The following sections give you more details on the migration procedure for eDirectory:
 “Planning Your Migration” on page 147
 “Migration Tools” on page 148
 “Migration Procedure” on page 149
 “After the Migration” on page 150
Planning Your Migration
This section lists the important requirements that must be verified before attempting eDirectory
migration.
IMPORTANT: If the eDirectory version is 8.7.3.6 or earlier on the NetWare server, you must backup
the sys:/system/backupcr.nlm file.
On performing migration from Netware to OES 2015 or later, the backupcr.nlm on NetWare server is
overwritten with the newer version. In case of failure, restore the backupcr.nlm.
 “System Requirements” on page 147
 “Prerequisites” on page 147
 “Supported Platforms” on page 148
 “Considerations” on page 148
 “Troubleshooting” on page 148
System Requirements
 The target server must run OES 2018 with the migration pattern selected.
 OES 2015 or later does not support multiple instances of eDirectory on the same server, so any
non-default instances should not be running during migration
 The source server should be running and should not be part of any partition operation. For more
information on supported source server versions, refer to the “eDirectory Coexistence and
Migration” in the OES 2018: Planning and Implementation Guide.
Prerequisites
 The eDirectory migration utility can run only on the target server and must be able to access the
source server remotely.
Migrating eDirectory to OES 2018
147
 All servers that share a replica with the server to be restored are up and communicating. This
allows the restore verification process to check with servers that participate in the same replica
ring.
For more information, see “Preparing for a Restore” in the NetIQ eDirectory Administration
Guide.
Supported Platforms
The eDirectory migration utility is designed to run on OES 2015 or later, which is the target platform
for migration. For more information on the compatible eDirectory versions at the source and the
corresponding target servers, refer to the “Prerequisites” on page 41 and “Support Matrix for NetWare
and OES Services” on page 18.
Considerations
 IP address and DNS migrations are not performed by this migration utility.
 Only the eDirectory instance is migrated. Applications depending on eDirectory are not migrated
by this utility.
 You should not use this migration methodology if you want both the servers to be available
during the migration operation.
NOTE
Only the target server is available after the Transfer ID migration. The eDirectory DIB on the
source server is locked. Other service migrations cannot be performed after completing Transfer
ID migration for eDirectory. The source server can be brought back by restarting the eDirectory
server, but you should do this only if the Transfer ID migration is unsuccessful.
Troubleshooting
 “Migration Issue” on page 148
Migration Issue
If the source server is running eDirectory 8.6.2, the following error is encountered:
The NDS schema in this tree is out of date. You must run ndsrepair to correct it.
Please consult the readme for further instructions. ERROR -722: Setup for NDS
installation failed. Please make certain that you have provided the complete server
and admin contexts.
ERROR: /opt/novell/eDirectory/bin/ndsconfig return value = 78.
To workaround this issue, do the following:
On the master eDirectory 8.6.2 server, run dsrepair, Advanced Options Menu > Global Schema
Operations, then select Post NetWare 5 Schema Update > Yes.
Migration Tools
The eDirectory migration can be performed independently or by using the OES migration framework.
The complete migration task is performed by invoking the migedir command line utility.
148
Migrating eDirectory to OES 2018
Migration Procedure
1 Run the migedir utility by entering the following command on the target server:
migedir [-A <log directory name>] [-s <IP address>] [-t] [-h] [-i] [-u] [-a] [w] [-B] [-R]
The utility takes the following command line options:
Option
Description
-A directory name
Enables auditing. directory name specifies the directory in which log files should
be created.
-s IP address
Specifies the IP address of the source server containing the eDirectory instance to
be migrated.
IMPORTANT: -s is a mandatory parameter.
-t
Tests the validity of the input parameters.
NOTE: This option verifies the IP address; however, it does not perform the actual
migration.
-h
Prints help about using this utility.
-i
Enables the verbose mode.
-u
Enables the unattended mode.
-a
Specifies the tree adminDN.
-w
Specifies the admin password.
-B
Enables the Backup Only mode.
-R
Enables the Restore Only mode.
2 Follow the on-screen instructions as the utility performs the migration.
The migration utility does some pre-migration checks, performs the migration, then does some
post-migration tasks.
 “Pre-migration” on page 149
 “Migration” on page 150
 “Post-migration” on page 150
 “Handling Failures” on page 150
Pre-migration
The utility performs the following checks:
 The health and state of the replicas in the ring are verified.
 Time synchronization is verified between the source and target servers.
Migrating eDirectory to OES 2018
149
Migration
The utility performs the migration of the eDirectory instance from the collected configuration
information. This involves backing up the source server data, locking the eDirectory instance in the
source server, migrating data to the target server, and restoring the eDirectory instance on the target
server. The dependent NICI files are also migrated.
Post-migration
After migration, the following tasks are performed by the utility:
 The nds.conf configuration file is modified with the source server eDirectory instance
information, such as tree name and server name.
 The eDirectory instance in the target server is restarted so it can use the new data.
 Network address repair is performed to start the synchronization of the new IP address in the
replica ring.
Handling Failures
During migration, the database in the source server is locked to avoid multiple copies of the instance
running on the source and target servers. Multiple copies of the same instance can lead to data
inconsistency. If the process fails and if you intend to bring up the source server again, you need to
perform the following tasks:
1 Remove the partially migrated eDirectory instance on the target server.
For more information on removing the eDirectory instance from a server, see Removing a Server
Object And Directory Services From a Tree in the NetIQ eDirectory Installation Guide.
2 Bring up the source server by reloading the directory services. Make sure that the source server
is brought up on the network only when the migration fails. The database backup and log files
are saved in the SYS:\ folder.
After the Migration
After migration, the target eDirectory instance listens on the IP address of the target server and not on
the source server’s address. It requires additional time after migration for the eDirectory instance to
synchronize the new IP address in the replica ring. Successful eDirectory migration can be verified by
performing eDirectory operations on the new IP address.
If you want to use the existing security certificates, you must change the IP address of the target
server to that of the source server. If you don’t want to do this, you must issue new certificates.
NOTE: If you change the IP address of the target server after migration, you must modify the
nds.conf file, restart the eDirectory instance, and repair the network address and partitions replica
manually. For more information on repairing eDirectory instance, see DSRepair Options in the NetIQ
eDirectory Administration Guide.
150
Migrating eDirectory to OES 2018
18
Migrating AFP to OES 2018
18
Migration refers to the process of migrating the AFP services to target OES 2018.
For general information about the OES Migration Tool, see the Chapter 1, “Overview of the Migration
Tools,” on page 15
The following sections give you more details on the migration procedure for AFP.
 “Migrating AFP from Netware to OES 2018” on page 151
 “Migrating AFP to OES 2018” on page 153
Migrating AFP from Netware to OES 2018
In these sections, the NetWare server is referred to as the source server and the OES 2018 server as
the target server.
 “Requirements” on page 151
 “Migration Scenarios” on page 151
 “Migration Procedure” on page 152
 “Verifying the Migration Process” on page 153
 “Cross-Platform Issues” on page 153
Requirements
Make sure your source server and target server meet the following requirements:
Source Server Requirements
 NetWare 6.5 SP8
Target Server Requirements
 OES server with AFP. For instructions see, instructions in “Installing and Setting Up AFP” in the
OES 2018: Novell AFP for Linux Administration Guide.
 The NSS data should be already migrated. For details see, Chapter 16, “Migrating File Systems
to OES 2018,” on page 103
Migration Scenarios
AFP supports the following migration scenarios:
 Migrating Servers through Server Consolidation
 Migrating Servers through Transfer ID
For more information about these scenarios, see “Migration Scenarios” on page 16.
Migrating AFP to OES 2018
151
NOTE: AFP does not support migration across different eDirectory trees. However, it can be
achieved by using the Different Tree scenario to migrate the file system, then reconfiguring AFP on
the target server:
For details, see “Migrating Data to a Server in a Different Tree” on page 118 and “Installing and
Setting Up AFP” in the OES 2018: Novell AFP for Linux Administration Guide
Migration Procedure
Migrating the AFP configuration is done by using the Migration Tool or through the command line
interface.
NOTE: Before migration, manually edit afptcpd.conf file and set the number of threads within the
valid range. For more information, see “Modifying Thread Range” on page 152.
 “Modifying Thread Range” on page 152
 “Using the Migration Tool to Migrate” on page 152
 “Using Command Line Utilities to Migrate” on page 152
Modifying Thread Range
Beginning with OES 2015, the valid thread range is changed to as follows:
Minimum threads: 3 to 32, default value: 3
Maximum threads: 4 to 512, default value: 32
Before migration, manually edit afptcpd.conf file and set the number of threads within the valid
range and proceed with the migration procedure. If it is not changed and the minimum or maximum
threads is out of the range, then AFP server will use default number of threads.
Using the Migration Tool to Migrate
1 Click Applications > Other > Novell Migration Tools to access the Migration Tool Utility.
2 Authenticate to the source and target servers.
3 Select Novell AFP, then click Configure. The AFP configuration window is displayed.
4 Click Migrate to begin the migration process.
Using Command Line Utilities to Migrate
To run the AFP migration utility through the command line, run migafp with the following parameters:
152
Migrating AFP to OES 2018
Table 18-1 migafp Command Line Parameters
Parameter
Description
-h
Prints a summary of the migration process
-s
IP address of the source server
-u
DN of the source tree admin. For example : cn=user, o=company)
-w
Admin password to authenticate to the source server
For example:
migafp -s 10.10.10.1 -u cn=sourceadmin.o=novell -w password
Verifying the Migration Process
1 Ensure that all the context details from sys:/etc/ctxs.cfg (NetWare context file) are migrated
to /etc/opt/novell/afptcpd/afpdircxt.conf (OES 2015 or later server context file).
2 Verify by running the command rcnovell-afptcpd start.
Cross-Platform Issues
AFP on Linux uses Universal Password as the authentication mechanism instead of the Simple
Password authentication mechanism on NetWare. During migration from NetWare to Linux, the
simple passwords on the NetWare system are synchronized to the Universal Password, so that the
user can authenticate seamlessly to the AFP service on the Linux server.
This feature is restricted based on the following conditions:
 To synchronize the password of a first-time login user, authentication must happen using Diffie
Hellman Exchange-2, Diffie Hellman Exchange, or Clear-text authentication method. To set the
type of authentication, ensure that the authentication method (AUTH_UAM) option in /etc/opt/
novell/afptcpd/afptcpd.conf file is set to DHX2, DHX, cleartext.
The automatic password synchronization will not occur if the user authenticates by using the
Random Exchange or Two-way Random Exchange method of authentication.
 If you use the Diffie Hellman Exchange-2, Diffie Hellman Exchange, or Clear-text authentication
method, the eDirectory service (ndsd) must be started with the environment variable
NDSD_TRY_NDSLOGIN_FIRST set to TRUE.
If the above conditions are not met, all the users with Simple Passwords are required to manually
authenticate to the AFP server on NetWare after they are enabled for Universal Password, in order to
trigger the password synchronization to Universal Password.
Migrating AFP to OES 2018
This section describes how to migrate AFP from an OES source server to OES 2018 target server.
Before you proceed with the migration, review “Prerequisites” on page 154.
 “What is Migrated” on page 154
 “Prerequisites” on page 154
Migrating AFP to OES 2018
153
 “Modifying Thread Range” on page 154
 “Migration Procedure” on page 154
 “Verifying Migration” on page 155
What is Migrated
 Server configuration information
 Volume Aliases information
 Contexts
Prerequisites
 OES server is already installed and AFP is configured. For details, see OES 2018: Novell AFP
for Linux Administration Guide.
 NSS Pools and volumes are already migrated to the new OES 2018 server from supported OES
server. Use the cluster migrate resource_name node_name command to migrate the cluster
pools and volumes. For details, see “Using the Cluster Migrate Command” in the OES 2018:
Novell Cluster Services for Linux Administration Guide.
 Non-cluster NSS volumes are already migrated to the new OES 2018 server from supported
OES server. This can be done by unmounting the corresponding file system from the source
machine and mounting it on the target machine.
 Before migration, manually edit afptcpd.conf file and set the number of threads within the valid
range. For more information, see “Modifying Thread Range” on page 154.
Modifying Thread Range
Beginning with OES 2015, the valid thread range is changed to as follows:
Minimum threads: 3 to 32, default value: 3
Maximum threads: 4 to 512, default value: 32
Before migration, manually edit afptcpd.conf file and set the number of threads within the valid
range and proceed with the migration procedure. If it is not changed and the minimum or maximum
threads is out of the range, then AFP server will use default number of threads.
Migration Procedure
1 Migrating Server Configuration information:
Manual: Edit the /etc/opt/novell/afptcpd/afptcpd.conf in the source server and add
support for DHX2 authentication and subtree search in the AUTH_UAM tag. After modifying the
afptcpd.conf file, copy it from the source server to the target.
iManager: Using the iManager plug-in, enable support for DHX2 authentication and subtree
search. For details, see “Administering the AFP Server”in the OES 2018: Novell AFP for Linux
Administration Guide.
2 Migrating Volume Alias information:
Copy the volume file /etc/opt/novell/afptcpd/afpvols.conf, from the source server to the
target server.
3 Migrating Context information:
154
Migrating AFP to OES 2018
Copy the context file /etc/opt/novell/afptcpd/afpdircxt.conf from the source server to
the target server.
4 Restart the AFP service for the configuration changes to take effect.
5 On successful migration, proceed to perform service specific proxy migration. For more
information, see Chapter 30, “Migrating Proxy users to OES 2018,” on page 239.
Verifying Migration
Verify that the migration process is complete by checking for the following details:
 NMAS methods for AFP are installed and synched to the tree. For details, see “Verifying LSM
Installation” in the OES 2018: Novell AFP for Linux Administration Guide.
 Login to the AFP server and attempt accessing the data.
Migrating AFP to OES 2018
155
156
Migrating AFP to OES 2018
19
Migrating CIFS to OES 2018
19
Migration refers to the process of migrating CIFS to target server.
 “Migrating CIFS from Netware to OES 2018” on page 157
 “Migrating CIFS to OES 2018” on page 166
Migrating CIFS from Netware to OES 2018
The NetWare to Open Enterprises Server (OES) CIFS migration process can be either initiated from
the Migration Tool or through a command line utility. For detailed information on migration through the
Migration Tool, see Chapter 1, “Overview of the Migration Tools,” on page 15 and for information on
the command line utility, see “Man Page for Migration” on page 163.
 “Migration Prerequisites” on page 157
 “Migration Scenarios” on page 157
 “Migration Procedure” on page 158
 “Post-Migration Procedure” on page 162
 “Verifying the Migration” on page 162
 “Man Page for Migration” on page 163
Migration Prerequisites
For the migration to happen successfully ensure the following requirements are met:
 The CIFS server is installed and configured on the source server in one of the following
platforms:
 NetWare 6.5 SP8
For details about CIFS on a NetWare server, see the NW 6.5 SP8: AFP, CIFS, and NFS (NFAP)
Administration Guide.
 The CIFS server is installed and configured on the target server (OES 2018). For details, see
“Installing and Setting Up CIFS” in the OES 2018: Novell CIFS for Linux Administration Guide.
 NSS file system migration from the source to the target server is completed.
Migration Scenarios
The CIFS migration scenarios are explained in this section:
 “Migrate - Same Tree” on page 158
 “Migrate - Different Tree” on page 158
 “Transfer ID - Same Tree” on page 158
 “What is Migrated” on page 158
Migrating CIFS to OES 2018
157
Migrate - Same Tree
Only CIFS shares and contexts of the source servers are consolidated. The remaining server
configuration information is not consolidated. The target server configuration is overwritten with the
source server configuration. For details on consolidation migration, see “Migration Scenarios” on
page 16.
Migrate - Different Tree
CIFS consolidation for a Different Tree is not supported. However, it can be achieved by using the
following procedure:
1 Migrate the file system by using the Different Tree scenario. For details, see “Migrating Data to a
Server in a Different Tree” on page 118.
2 Re-configure CIFS on the target server. For details on configuring CIFS, see “Setting the CIFS
Server and Authentication Properties” in the OES 2018: Novell CIFS for Linux Administration
Guide.
Transfer ID - Same Tree
In this scenario, the target is installed into the same tree with a temporary name and IP address. At
the end of the procedure, the source server name and IP address are swapped for the target server
name and IP address. For details on Transfer ID migration, see Part IV, “Transfer ID Migration,” on
page 59.
What is Migrated
The following table gives you a quick overview of what is migrated from NetWare CIFS to OES 2018
CIFS for the different scenarios:
Table 19-1 Migration Support for CIFS service
Service supported
Consolidation
Transfer ID
Same Tree
Different Tree
Same Tree
Different Tree
Migrating CIFS shares
Yes
No
Yes
No
Migrating CIFS contexts
Yes
No
Yes
No
Migrating server configuration
information
No
No
Yes
No
Migration Procedure
Follow the instructions in either of these sections to perform the CIFS migration:
 “Using the Migration Tool” on page 159
 “Using the Command Line” on page 160
158
Migrating CIFS to OES 2018
Using the Migration Tool
1 Launch the Migration Tool on the target server in one of the following ways:
Desktop: Click Applications > Other > Novell Migration Tools.
Terminal: Log in as the root user and at a terminal prompt, enter miggui
For details on configuring source and target Server information, selecting a migration type,
opening a project, and all the tool buttons, see Chapter 2, “Overview of the Migration GUI,” on
page 21.
2 Click Add, select Novell CIFS to migrate, and click OK.
The Status is displayed as Not Configured.
3 Select Novell CIFS and click Configure to configure the migration parameters.
4 Under CIFS Shares, select the Source and Target shares for migration. Use Browse to browse
for target shares. Use Add to add more source and target share mappings. Use Update to
modify the configuration. Use Delete to remove the share mappings.
When you have filled in the information, the dialog will be similar to the following:
Migrating CIFS to OES 2018
159
IMPORTANT: The Migration Tool does not support migration of CIFS shares on a cluster
resource. After the file system migration, you will need to manually configure the CIFS shares on
the target Linux system. For more information, see “Managing CIFS Shares ” in the OES 2018:
Novell CIFS for Linux Administration Guide.
5 Click OK to complete the configuration.
The Status is displayed as Ready.
6 Click Migrate to start the migration process. When you are prompted to save the project, click
Yes.
7 In the next dialog box, click Yes to proceed with the migration.
Wait for the migration to be completed. The Status changes to Migrated. The message CIFS
Migration Successfully Completed is displayed.
NOTE: Use the Status > Service Information to verify for errors during migration. If there are
errors, fix them and restart the migration procedure.
Using the Command Line
CIFS migration requires the complete source and target server details. Run the migCifs utility on the
target server for migrating. An example migCifs command is shown below. For details on the
command, see Table 19-2 and see “migCifs” in “Man Page for Migration” on page 163.
migCifs -s <sourceIPaddr> -p <sourceportnum> -a <sourceFDN> -w <passwd> -f <sec/
nonsecConn> -d <targetIPaddr> -q <targetportnumber> -b <targetFDN> -x <passwd> -g
<secure/nonsecureconn> -S <MigrationType> [-m <cifssharemappings>]
migCifs -s <sourceIPaddr> -p <sourceportnum> -a <sourceFDN> -w <passwd> -f <sec/
nonsecConn> -d <targetIPaddr> -q <targetportnumber> -b <targetFDN> -x <passwd> -g
<secure/nonsecureconn> -S <MigrationType> -c
migCifs -s <sourceIPaddr> -p <sourceportnum> -a <sourceFDN> -w <passwd> -f <sec/
nonsecConn> -d <targetIPaddr> -q <targetportnumber> -b <targetFDN> -x <passwd> -g
<secure/nonsecureconn> -S <MigrationType> [-m <sourcecifsshares>] -r
160
Migrating CIFS to OES 2018
Table 19-2 migCifs Command Details
Command Option
Description
-s <sourceIPaddr>
Source server IP address. For example, -s 192.168.0.1.
-p <sourceportnum>
Port number of the source server. For example, -p 636.
-a <sourceFDN>
Source server FDN. For example, -a cn=admin,o=novell.
-w <passwd>
Password for the source server FDN. For example,
-w mysrc.
-f <sec/nonsecConn>
Secure (SSL) or non-secure (Non-SSL) connection type of
the source server. 1 for SSL and 0 for Non-SSL. SSL is
preferred. For example, -f 1 or -f 0.
-d <targetIPaddr>
Target server IP address. For example, -d 192.168.0.2.
-q <targetportnum>
Port number of the target server. For example,
-q 636.
-b <targetFDN>
Target server FDN. For example, -b cn=admin,o=novell.
-x <passwd>
Password for the target server FDN. For example,
-x mytgt.
-g <sec/nonsecConn>
Secure (SSL) or non-secure (Non-SSL) connection type of
the target server. 1 for SSL and 0 for Non-SSL. SSL is
preferred. For example, -g 1 or -g 0.
-S <MigrationType>
Sets the Migration Type. 0 for Server to Server - Same Tree
or Different Tree, 3 for Transfer ID, and 5 for Consolidation.
For example, -S 0 or -S 3 or -S 5.
-m <mapfilename>
CIFS source to the target share mapping file. This is an
optional command.
Create the file using any text editor. Separate individual
sharemaps by a line.
1. Open a new file in the text editor.
2. Specify sourcesharename#targetsharepath. For
example,
share1#CIFSV1:linuxshare1
share2#NSSvol:linuxshare2/cifsshare
3. Specify the required number of share details and save
the file.
-c
Does not migrate CIFS Shares and Server Configuration
information from the source. Migrates only the CIFS Context
information.
Migrating CIFS to OES 2018
161
Command Option
Description
-r
Removes the shares related to NetWare server from the
target server after a Transfer ID migration. If -r is passed,
migCifs considers it as repair mode and retries the server
configuration migration. If -r is not passed, then migCifs
considers it as migration.
Pass the source only CIFS share file. The source shares are
listed and each share terminated with a #. For example, /
media/nss/CIFSV1:#. Do not pass the CIFS Password
Policies files with this option.
Post-Migration Procedure
 “Restarting the CIFS Service” on page 162
 “Enabling “Share volumes by default” Option” on page 162
Restarting the CIFS Service
1 Run the following command to restart the service:
rcnovell-cifs restart
Enabling “Share volumes by default” Option
After migration of CIFS service to OES 2018, default shares will not be mounted by CIFS.
1 View the list of all available share points using the command novcifs -sl.
2 Check the status of "Share volumes by default" attribute using the command novcifs --listservers.
3 Enable the “Share volumes by default” attribute using the command novcifs --share-volsdefault=<netbios name of the physical or virtual server> --value=yes.
For example, novcifs --share-vols-default=BLR8-192.168_W --value=yes.
Verifying the Migration
After migration is complete, the CIFS server on the target server must be available and running as it
used to be on your NetWare server. This verifies that the migration has been successfully completed.
If the CIFS server is not running after migration, see “Migration” in the OES 2018: Novell CIFS for
Linux Administration Guide.
After a successful migration:
 All the CIFS shares are migrated and listed on the target server.
 All the CIFS contexts are migrated to the target server.
You can verify these steps for a successful migration by using either iManager or command line
options.
 “Using iManager to Verify the Migration” on page 163
 “Using CLI to Verify the Migration” on page 163
162
Migrating CIFS to OES 2018
Using iManager to Verify the Migration
1 Open iManager on the target server.
2 Go to File Protocols > CIFS.
3 Browse or specify the OES 2 server.
4 Click OK.
5 Click Start. This displays the CIFS status as Running.
6 Click Shares. You must be able to list the sharepoints that were running on your NetWare and
now migrated to OES 2018 server.
For details on CIFS administration through iManager, see “Using iManager to Manage CIFS”.
Using CLI to Verify the Migration
1 On the target server console, enter the command rcnovell-cifs status.
2 If the status is not running, enter the command rcnovell-cifs start to start the server.
3 If the status is running, enter the command rcnovell-cifs restart to restart the server.
4 Enter the command novcifs [-sl | --share --list] or
novcifs [-sln sharename | --share --list --name=sharename]
This displays the list of sharepoints that were available on NetWare and are now migrated to the
OES 2018 server.
For details on CIFS administration through command line utilities, see “Using the Command Line
to Manage CIFS” in the OES 2018: Novell CIFS for Linux Administration Guide.
Man Page for Migration
To access this man page with the command information, enter man migCifs at the command prompt.
 “migCifs(8)” on page 163
migCifs(8)
A command line utility that communicates with the source and target servers for migrating CIFS
configuration information from NetWare to OES 2018. The command must be run on a target server.
Syntax
Migrating the CIFS Service from NetWare to OES 2018
migCifs -s <sourceIP> -p <portnumber> -a <sourceFDN> -w <password> -f <sec/
nonsecConnType> -d <targetIP> -q <portnumber> -b <targetFDN> -x <password> -g <sec/
nonsecConnType> -S <MigType> [-m <mapfilename>]-t <source_treename>
Synchronizing after Consolidation
migCifs -s <sourceIP> -p <portnumber> -a <sourceFDN> -w <password>
-f <sec/nonsecConnType> -d <targetIP> -q <portnumber> -b <targetFDN>
-x <password> -g <sec/nonsecConnType> -S <MigType> -c
Migrating CIFS to OES 2018
163
Repair after Transfer ID
migCifs -s <sourceIP> -p <portnumber> -a <sourceFDN> -w <password>
-f <sec/nonsecConnType> -d <targetIP> -q <portnumber> -b <targetFDN>
-x <password> -g <sec/nonsecConnType> -S <MigType> [-m <sourcesharefilename>] -r
Options
Usage Options:
-s <sourceIP>
IP address of the source server.
-p <portnumber>
Port number of the source LDAP server.
-a <sourceFDN>
Fully Distinguished Name (FDN) of the source server tree administrator.
-w <password>
Password of the source server tree administrator.
-f <sec/nonsecConnType>
Enables or disables SSL connection for the source LDAP server. Set 1 for SSL and 0 for nonSSL connection.
-d <targetIP>
IP address of the target server.
-q <portnumber>
Port number of the target LDAP server.
-b <targetFDN>
Fully Distinguished Name (FDN) of the target server tree administrator.
-x <password>
Password of the target server tree administrator.
-g <sec/nonsecConnType>
Enables or disables SSL connection for the target LDAP server. Set 1 for SSL and 0 for non-SSL
connection.
-S <MigType>
Sets the Migration Type. 0 for Server to Server - Same Tree or Different Tree, 3 for Transfer ID,
and 5 for Consolidation. For example, -S 0 or -S 3 or -S 5.
-m <mapfilename>
Full path of the file that contains source and target server share mappings.
-t <source_treename>
Tree name of the source.
164
Migrating CIFS to OES 2018
-c
Does not migrate CIFS Shares and Server Configuration information from the source. Migrates
only the CIFS Context information.
-r
Removes the shares related to NetWare server from the target server after a Transfer ID
migration. If -r is passed, migCifs considers it as repair mode and retries the server configuration
migration. If -r is not passed, then migCifs considers it as migration.
Help Options
-h | --help
Displays the help information of the command and syntax.
-u | --usage
Displays the usage information of the command.
Files
/etc/opt/novell/cifs/cifs.conf
CIFS configuration file.
/etc/opt/novell/cifs/cifsctxs.conf
CIFS context file.
/etc/opt/novell/cifs/.cifspwdfile
Encrypted CIFS proxy user file.
/var/opt/novell/log/cifs.log
CIFS server log file.
/var/opt/novell/migration/Newproj[n]/log/cifs.log
CIFS migration log file.
Example
migCifs -s 192.168.0.1 -p 636 -a cn=admin,o=novell -w novell -f 1 -d 192.168.0.2 -q 636 -b
cn=admin,o=novell -x novell -g 1 -S 0 -m /cifsShares.tmp -t novelltree
Authors
Copyright 2005-2013, Novell, Inc. All rights reserved. http://www.novell.com
See Also
novcifs(8)
Report Bugs
To report problems with this software or its documentation, visit http://bugzilla.novell.com.
Migrating CIFS to OES 2018
165
Migrating CIFS to OES 2018
This section describes how to migrate CIFS from an OES server to OES 2018.
Before you proceed with the migration, review “Prerequisites” on page 166. In this section, the source
server refers to supported OES versions and the target server refers to an OES 2018 server.
 “What is Migrated” on page 166
 “Prerequisites” on page 166
 “Migration Procedure” on page 166
 “Post Transfer ID Migration Procedure” on page 167
 “Verifying Migration” on page 168
What is Migrated
 Server configuration information
 Shares
 Contexts
Prerequisites
 OES server is already installed and CIFS is configured. For details, see OES 2018: Novell CIFS
for Linux Administration Guide.
 NSS Pools and volumes are already migrated to the new OES 2018 server from a supported
source OES server. Use the cluster migrate resource_name node_name command to migrate
the cluster pools and volumes. For details, see “Using the Cluster Migrate Command” in the OES
2018: Novell Cluster Services for Linux Administration Guide.
 Non-cluster NSS volumes are already migrated to the new OES 2018 server from a supported
OES server. This can be done by unmounting the corresponding file system from the source
machine and mounting it on the target machine.
Migration Procedure
1 Migrating Server Configuration information:
In case of ID Swap, on the target server using iManager replicate the following server properties:
 Name
 Comment
 Domain/Workgroup
 Support for Oplocks
 Support for DFS
2 Migrating Share information:
During the migration process, all shares except the shares that have been manually added are
migrated. To replicate the shares that are manually added, use the CIFS iManager plug-in. For
details, see“Managing CIFS Shares ” in the OES 2018: Novell CIFS for Linux Administration
Guide.
3 Migrating Context information:
166
Migrating CIFS to OES 2018
Manual: Copy the context file /etc/opt/novell/cifs/cifsctxs.conf from the source server
to the target server.
iManager: Using CIFS iManager plug-in, replicate the CIFS user's context. For details, see
“Configuring a CIFS User Context”in the OES 2018: Novell CIFS for Linux Administration Guide.
NOTE: After completing the migrate, ensure that you reconfigure CIFS service using yast2
novell-cifs or use the iManager Add Context task to add the contexts to the cifsctxs.conf file,
before you enable subtree search feature.
4 Copying CIFS configuration file:
Copy the CIFS configuration file /etc/opt/novell/cifs/cifs.conf from the source to the
target server.
CIFS configuration settings are stored in eDirectory and configuration files. During Transfer ID
migration, the settings in eDirectory are migrated automatically, whereas the settings stored in
the configuration files are not. To migrate them manually, copy the cifs.conf file to the target
server.
5 Restart the CIFS server using the rcnovell-cifs restart command.
6 Proceed to perform proxy migration. For services using the common proxy, see “Services that
are Using Common Proxy” on page 240.
Post Transfer ID Migration Procedure
 “OES 2 SP3, OES 11 or OES 2015 to OES 2018” on page 167
OES 2 SP3, OES 11 or OES 2015 to OES 2018
After performing the migration steps in “Transfer ID Migration Procedure” on page 239, perform the
following tasks:
 “Restarting the CIFS service” on page 167
 “Re-enabling Pass-through Information Levels Capability” on page 167
 “Enabling “Share volumes by default” Option” on page 167
Restarting the CIFS service
1 Run the following command to restart the service:
rcnovell-cifs restart
Re-enabling Pass-through Information Levels Capability
1 If you have enabled pass-through information levels capability on the target server, copying the
cifs.conf file might overwrite the settings. Re-enable it on the target server after the migration
is complete by running the novcifs -info-level-passthru=yes command.
Enabling “Share volumes by default” Option
After migration of CIFS service to OES 2018, default shares will not be mounted by CIFS.
1 View the list of all available share points using the command novcifs -sl.
2 Check the status of "Share volumes by default" attribute using the command novcifs --listservers.
Migrating CIFS to OES 2018
167
3 Enable the “Share volumes by default” attribute using the command novcifs --share-volsdefault=<netbios name of the physical or virtual server> --value=yes.
For example, novcifs --share-vols-default=BLR8-192.168_W --value=yes.
Verifying Migration
After you have migrated the CIFS services to the OES 2018 target, verify that the migration process is
complete by checking for the following details:
 Verify that the NMAS methods for CIFS are installed and synchronized to the tree. For details,
see “Verifying LSM Installation” in the OES 2018: Novell CIFS for Linux Administration Guide.
 Log in to the CIFS server and attempt to access the data.
168
Migrating CIFS to OES 2018
20
Migrating DHCP to OES 2018
20
Migration refers to the process of migrating the DHCP Services running on NetWare or Open
Enterprise Server (OES) to OES 2018.
For general information about the Migration Tool, see the Chapter 1, “Overview of the Migration
Tools,” on page 15.
 “Migrating DHCP from Netware to OES 2018” on page 169
 “Migrating DHCP to OES 2018” on page 179
Migrating DHCP from Netware to OES 2018
In these sections, the NetWare server is referred to as the source server and the OES 2018 server as
the target server.
 “Migration Requirements” on page 169
 “Migrating DHCP” on page 170
 “Migration Scenarios” on page 177
 “Migrating a Cluster” on page 178
 “Post-Migration Procedures” on page 178
 “Verifying the Migration” on page 179
Migration Requirements
Make sure your setup addresses the following requirements before you migrate DHCP to the new
platform.
 An eDirectory integrated DHCP server installed and configured on the target machine. This
takes care of the schema extension on the target server tree and creation of the dhcpLocator
and DHCPGroup objects.
 The user running DHCP Migration requires read and write permissions on the target machine for
the following folders:
/opt/novell/migration/dhcpmigration/tmp
/opt/novell/migration/dhcpmigration/dhcp
Recommended: Run DHCP Migration as the root user.
 The target and source servers should have their time synchronized, or the leases might not
function properly.
 Use the following source NetWare platforms for the migration process:
 NetWare 6.5 SP8
Migrating DHCP to OES 2018
169
Migrating DHCP
To migrate the DHCP Services, you can use the Migration Tool or the command line interface.
 “Understanding the Migration Process” on page 170
 “Using the Migration Tool to Migrate Servers” on page 171
 “Using the Command Line to Migrate Servers” on page 176
Understanding the Migration Process
Make sure that you install the OES 2018 server as the target server for the DHCP Services. For more
information on installing DHCP Services, refer to “Installing and Configuring DHCP ” in the OES 2018:
DNS/DHCP Services for Linux Administration Guide.
During migration, the NetWare DHCP configuration objects are read and mapped to the
corresponding configuration objects on Linux DHCP. This helps in retaining the same functionality
after the migration process.
 Subnets: All the subnets associated with the NetWare DHCP server are migrated to the new
platform. If there is at least one address range associated with the NetWare DHCP server inside
the subnet, the subnet is migrated with all the associated address ranges. The subnet object is
created inside the dhcpService object on Linux. After migration, the subnet is identified by its IP
address.
 DHCP Server: You can specify the name of the DHCP server in the Server Name field under the
Target Options tab.
 DHCP Service: During a server-level or tree-level migration, a dhcpService object is created on
the target server corresponding to each source NetWare DHCP server. This is the container
object that contains all the DHCP configuration data associated with DHCP server. The
dhcpService object is created inside the context specified in the Service Context field during
migration. The dhcpService object name can be specified in the Service Name field under Target
Options tab.
For a subnet-level Migration, the subnets are created inside an existing dhcpService object on
target server. Specify the existing dhcpService object in the Service Context field.
 Address Range: After the migration process, all the address range objects are mapped to pool
objects on Linux.
 Zone: After the migration, all the zone objects retain the same name as they had on the
NetWare platform. Zone objects are also created inside the dhcpService object.
 Subnet Pool: On the Linux platform, subnet pools on NetWare are mapped to the Shared
Network objects.
 IP Address (manual): All manually defined IP addresses are migrated as hosts inside the
subnet object. The hosts are identified by their IP addresses. For example, if the address of an
IP address object on NetWare is 1.1.1.1, on Linux it is identified as 1_1_1_1.
 IP Address (dynamic): Information on all the dynamically leased IP addresses is maintained at
the /var/lib/dhcp/db location. This lease file contains details for every IP address leased.
 Comments: Any comments that exist on the NetWare platform are not migrated to the Linux
platform.
 Excluded Hardware Addresses: Excluded hardware addresses on NetWare after migration
are mapped to class-excluded_hosts on Linux.
170
Migrating DHCP to OES 2018
 Included Hardware Addresses: Included hardware addresses on NetWare after migration are
mapped to class-included_hosts on Linux.
NOTE: If the name of any object contains a space, the space is replace by an underscore “_” during
migration.
Using the Migration Tool to Migrate Servers
1 Open the Migration Tool GUI using the “Launch the Migration Tool Utility” on page 45.
2 Follow the Migration Process to start the process.
3 Click Add in the Services to Migrate panel, then select the Novell DHCP Service.
4 Click OK, then click Configure. The DHCP configuration window displays.
5 DHCP provides migration at the following three levels:
 “Server Level” on page 173
 “Subnet Level” on page 175
 “Tree Level” on page 176
Configuring DHCP Options
The DHCP configuration window consists of three tabs:
 Source Options
 Target Options
 Reverse Zone Selection
Source Options
This tab lets you choose the level of migration that you want to use.
 Server Level
 Subnet Level
 Tree Level
Migrating DHCP to OES 2018
171
Target Options
This tab lets you choose the DHCP options for each level of migration. The following table lists the
fields in the target options tab:
Table 20-1 DHCP Configuration fields
Field
Description
Server Context
Context of the target DHCP server object.
Server Name
Name of the target DHCP server object.
Service Context
Context of the target DHCP service object.
Service Name
Name of the target DHCP service object.
Locator Object
Distinguished name of the dhcpLocator object in the target tree.
Group Object
Distinguished name of the DHCPGroup object in the target tree.
Lease file location
Lease file name with absolute file path where the NetWare DHCP dynamic leases
are migrated.
Reverse Zone Selection
Reverse zones are used for reverse lookups. It finds the DNS name associated with the IP address.
Use this tab to select the available reverse zones on the source to be migrated to the target.
NOTE: The forward zones associated with a subnet in a DDNS setup are automatically migrated. The
forward zones are not required to be selected exclusively in this scenario.
The following table lists the fields in the DHCP configuration window:
Table 20-2 DHCP Configuration fields
Field
Description
Server DN
The distinguished name of the DHCP server to be migrated.
Subnet DN
The distinguished name of the subnet to be migrated.
Base DN
The distinguished name of the container on the target tree where the configuration is
to be migrated.
NOTE: For tree-level and server-level migration, Base DN is a container such as
Organization, Organization Unit, or Domain.
For subnet-level migration, Base DN is a DHCP Service object only. When you
browse for the Base DN, it appropriately displays all the available service objects.
Locator DN
The distinguished name of the dhcpLocator object in the target tree.
NOTE: Not applicable for a subnet-level migration.
Group DN
The distinguished name of the DHCPGroup object in the Target tree.
NOTE: Not applicable for a subnet-level migration.
172
Migrating DHCP to OES 2018
Field
Description
Lease file
The path and filename for the leases to be migrated. All the dynamic IP addresses
on NetWare are mapped to a lease file entry in this file.
NOTE: Not applicable for tree-level and server-level migration.
Migration Methods
You can choose to migrate DHCP services by any one of the following three methods:
 Server Level
 Subnet Level
 Tree Level
Server Level
In the Server Level migration, the selected NetWare DHCP server is migrated to the OES 2018
server. You can choose to migrate only one server at a time.
NOTE: Refer to Table 20-2 on page 172 for DHCP configuration field descriptions.
1 In the Source Options tab of DHCP migration window, select the Server level option.
2 Click Browse to select the Server DN.
Server DN: The Server DN is the distinguished name of the server to be migrated.You can
browse to the Source tree (only containers and server objects are displayed) to locate the server
to be migrated. Select the server object and click OK. If the selected object is not a DHCP server,
then a warning is displayed.
3 In the Target Options tab, click Browse to select the Server Context.
Migrating DHCP to OES 2018
173
4 Click Browse to select the existing Server Name or add the new server name that you want to
migrate. For more information on adding a new server, refer to “Server Management” in the OES
2018: DNS/DHCP Services for Linux Administration Guide.
5 Click Browse to select the Service Context.
6 Click Browse to select the existing Service Name or add the new service name that you want to
migrate.
7 Click Browse to select the Locator Object.
8 Click Browse to select the Group Object.
9 Specify the Lease file location.
10 In the Reverse Zone Selection tab, select the reverse zones in Available Reverse Zones. Click
Add to add all the selected zones. Use the Ctrl key to select multiple zones.
174
Migrating DHCP to OES 2018
11 Click OK to complete the configuration.
Subnet Level
In the Subnet Level migration, the selected subnets associated with the NetWare DHCP server are
migrated to the OES 2018 server. The subnet objects are created inside the dhcpService object on
the Linux server. After migration, the subnet is identified by its IP address. You can choose to migrate
multiple subnets at a time.
NOTE: Refer to Table 20-2 on page 172 for DHCP configuration field descriptions.
1 In the Source Options tab of the DHCP migration window, select the Subnet Level option.
2 Click Browse to select the Subnet DN(s). Use the Ctrl key to select multiple subnets.
Subnet DN(s): The Subnet DN is the distinguished name of the subnets to be migrated.
You can browse to select one or more subnets. The selected subnets are displayed in the list
box. If an incorrect container is selected, then a warning is displayed.
3 In the Target Options tab, click Browse to select the Service Context.
4 Click Browse to select the existing Service Name that you want to migrate.
The Server Context, Server Name, Locator Object, and Group Object options are not applicable
for subnet level migration.
5 Specify the Lease file location.
6 In the Reverse Zone Selection tab, select the reverse zones in Available Reverse Zones. Click
Add to add all the selected zones. Use the Ctrl key to select multiple zones.
7 Click OK to complete the configuration.
Migrating DHCP to OES 2018
175
Tree Level
In the Tree Level migration, all the NetWare DHCP servers in the tree are migrated to the OES 2018
server.
NOTE: Refer to Table 20-2 on page 172 for DHCP configuration field descriptions.
1 In the Source Options tab of the DHCP migration window, select the Tree Level option.
2 In the Target Options tab, click Browse to select the Server Context.
3 Click Browse to select the Service Context.
The Server Name and Service Name options are displayed by default, but they are disabled.
4 Click Browse to select the Locator Object.
5 Click Browse to select the Group Object.
6 Specify the Lease file location.
7 Click OK to complete the configuration.
Using the Command Line to Migrate Servers
1 To run the DHCP migration utility through the command line, run /opt/novell/migration/bin/
migdhcp with the following parameters:
176
Option
Description
-h
Print this summary.
-k
Level of migration (subnet|tree|server).
-i
Verbose mode - on or off.
-d
Debug mode - on or off.
-s
IP address of the source LDAP server.
-p
Port number of the source LDAP server.
-a
DN of the admin user in the source tree.
-t
IP address of the target LDAP server.
-q
Port number for the target LDAP server.
-b
DN of the admin user in the destination tree.
-l
DN of the dhcpLocator object in the destination tree (Required only for server-level or tree-level
migration).
-g
DN of the DHCPGroup object in the destination tree (Required only for server-level or tree-level
migration).
-e
DN of the server to be migrated (Required only for server-level migration).
-n
Base DN for server on the destination tree.
-m
Base DN for service on the destination tree.
-r
1 for source SSL bind, 0 for source non-SSL bind.
-u
1 for destination SSL bind, 0 for destination non-SSL bind.
Migrating DHCP to OES 2018
Option
Description
-f
Absolute path of the file containing the DNs of the subnets that you want to migrate. (Required
only for subnet-level migration). Enter the subnet DNs in the following format:
cn=subnet1,o=novell
cn=subnet2,ou=novel1,o=novell
cn=subnet3,ou=novell2,o=novell
-c
Absolute path of the file where you want to store the lease file information
-E
DHCP server object name on the Target server (Required only for server-level migration).
-S
DHCP service object name on Target server (Required only for server-level migration).
-z
Full path of the file containing the Reverse Zone DNs.
Examples for Command Line Migration
Tree Level: /opt/novell/migration/bin/migdhcp.sh -k tree -i on -d on -s
192.168.13.1 -p 636 -a cn=admin,o=novell -t 182.155.13.8 -q 636 -b
cn=admin,o=novell -l cn=dhcpLocator,o=novell -g cn=DHCPGroup,o=novell -n
o=novell -r 1 -u 1
Server Level: /opt/novell/migration/bin/migdhcp.sh -k server -i on -d on -s
192.168.13.1 -p 636 -a cn=admin,o=novell -t 182.155.13.8 -q 636 -b
cn=admin,o=novell -l cn=dhcpLocator,o=novell -g cn=DHCPGroup,o=novell -e
cn=DHCP_SERVER,o=novell -n o=novell -r 1 -u 1
Subnet Level: /opt/novell/migration/bin/migdhcp.sh -k subnet -i on -d on -s
192.168.13.1 -p 636 -a cn=admin,o=novell -t 182.155.13.8 -q 636 -b
cn=admin,o=novell -n cn=DHCPService,o=novell -r 1 -u 1 -f /somelocation/
filewithsubnetdns -c /somelocation/filename
Migration Scenarios
DHCP migration supports two scenarios:
 “Transfer ID” on page 177
 “Consolidation” on page 178
For more information about these scenarios, see “Support Matrix for NetWare and OES Services” on
page 18.
Transfer ID
In this scenario, the identity of the target server is swapped with the source server. The IP address
and the machine name of the target server change to the source IP address and machine name. The
target should be installed in the same tree as the source server. The target should be a non-replica
server.
Based on the level of migration (subnet, server, or tree), the configuration objects are created for the
Linux DHCP server on the target tree inside the dhcpService object created during migration.
Migrating DHCP to OES 2018
177
Consolidation
In this scenario, the configuration data associated with the source server is associated to a single
target server. DHCP Consolidation migration can be performed at the tree, server, or subnet-level.
Migrating a Cluster
There are two scenarios for migrating clusters:
 “NetWare and Linux Clusters Attached to the Same Tree” on page 178
 “NetWare and Linux Clusters Attached to Different Trees” on page 178
NetWare and Linux Clusters Attached to the Same Tree
Run the migration tool from one of the Linux nodes. Perform the tree-level migration with the source
and target servers on the same tree.
This ensures that all NetWare DHCP configuration data is available for Linux DHCP.
In this scenario, both the NetWare server and the OES 2018 server are on the same eDirectory tree.
The NetWare source server must be running NetWare 6.5 SP8. The Linux target server must be
running SUSE Linux Enterprise Server (SLES) 12 SP2 with OES 2018 on 64-bit hardware.
NetWare and Linux Clusters Attached to Different Trees
Run the migration tool from one of the Linux nodes. Perform the tree-level migration with the source
server (the tree to which NetWare clustered nodes are attached) on one tree and the target server
(the tree to which the Linux clustered nodes are attached) on another tree.
This ensures that all NetWare DHCP configuration data is available for Linux DHCP.
In this scenario, the NetWare server and the OES 2018 server are on different eDirectory trees. The
NetWare source server must be running NetWare 6.5 SP8. The Linux target server must be running
SUSE Linux Enterprise Server (SLES) 12 SP2 with OES 2018 on 64-bit hardware.
Post-Migration Procedures
1 In the /etc/dhcpd.conf file, change ldap-base-dn to reflect the context of the migrated DHCP
Server and change ldap-dhcp-server-cn to reflect the name of the migrated DHCP Server.
2 Check the lease file at the /var/lib/dhcp/db/dhcpd.leases folder.
3 To use DDNS after a subnet-level migration, add the following settings to the DHCP Server
Object:
 ddns-rev-domainname in-addr.arpa
 ddns-update-style interim
 client-updates deny
 update-optimization false
NOTE: DDNS updates are required only when you migrate to an existing DHCP server.
178
Migrating DHCP to OES 2018
4 Start the OES DHCP server by using the rcnovell-dhcpd start command.
5 Continue with “Cluster Migration from NetWare to Linux” on page 179 and “Running a
Preexisting DHCP Server” on page 179 as necessary.
Cluster Migration from NetWare to Linux
On the node where you ran the migration:
1 Open the <mountpath>/etc/dhcpd.conf file.
The <mountpath> parameter indicates the target directory in the shared volume where DHCPspecific directories are created.
Inside the /etc/dhcpd.conf file, which is located in the shared volume, change the ldap-dhcpserver-cn attribute to the migrated server cn.
2 Copy the migrated_server.leases file from the /var/lib.dhcp/bd folder to the <mountpath> var/
lib/dhcp/db/ folder and rename it to dhcpd.leases.
Running a Preexisting DHCP Server
After migration, the DHCP server and service objects are created in the tree. You can run a
preexisting DHCP server along with the migrated NetWare server's configuration.
1 Log in to the tree by using Java Management Console.
2 Click the DHCP (OES Linux) tab.
3 Select the service object that was created after migrating the NetWare server from the left pane
in the Java Management console.
4 Associate this service object with the existing DHCP server.
Verifying the Migration
To verify the migration, use Java Console to go to the destination tree and locate the DHCP Server
object and the corresponding DHCP Service object. All the DHCP server configuration is stored
inside the corresponding DHCP Service object.
Verify that leases are present:
 For a tree-level, server-level, or subnet-level migration, the lease filename and location are
provided by the user. Make sure the expected files are present in the specified location.
Migrating DHCP to OES 2018
In this section, the source server refers to a supported OES server and the target server refers to an
OES 2018 server.
 “Planning Your Migration” on page 180
 “Migration Scenarios” on page 180
 “Post-Migration Procedure” on page 182
 “Verifying the Migration” on page 182
Migrating DHCP to OES 2018
179
Planning Your Migration
Make sure your setup addresses the following requirements before you migrate DHCP to the new
platform.
 “Requirements” on page 180
Requirements
 An eDirectory integrated DHCP server installed and configured on the target machine. This
takes care of the schema extension on the target server tree and creation of the dhcpLocator
and DHCPGroup objects.
 If the target server is in different subnet, ensure that you create a subnet in the target server
before migration.
Migration Scenarios
To migrate DHCP to the new platform, you can use the Java Management Console. During migration,
the configuration details as well as the data are migrated to the destination platform.
NOTE: To enable DHCP to autostart after a successful migration, execute the chkconfig -a dhcpd
command on the source server.
 “Migrating Servers Within the Same eDirectory Tree” on page 180
 “Migrating Servers Across eDirectory Trees” on page 180
Migrating Servers Within the Same eDirectory Tree
1 Launch Java Console.
2 Select the service container object that you want to migrate to the target DHCP server.
3 From the Default DHCP Server list in the General Tab, select the DHCP server object of the
target machine.
4 Click the Save button.
5 Migrate the DHCP leases from OES 2 SPx to OES 2018. To migrate the DHCP leases, copy the
/var/lib/dhcp/db/dhcpd.leases file from the source OES 2 server to the corresponding
location in the OES 2018 server.
6 Perform Transfer ID. For more information, see Part IV, “Transfer ID Migration,” on page 59.
7 On successful migration, proceed to perform service specific proxy migration. For more
information, see “Migrating Proxy users to OES 2018” on page 239.
Migrating Servers Across eDirectory Trees
To migrate servers across eDirectory trees, you need to export the source server’s DHCP
configuration and import the DHCP configuration to the target server.
The import and export operation is used to transfer the DHCP service configuration from files into
eDirectory or from eDirectory to a text file in a dhcpd.conf format respectively. Only Linux DHCP
configuration files should be used to import or export the DHCP configuration.
180
Migrating DHCP to OES 2018
NOTE: Before importing a DHCP configuration file, check the syntax of the file with the rcnovelldhcpd check-syntax command. The command reads /etc/dhcpd.conf and checks the syntax.
 “Exporting the DHCP Configuration” on page 181
 “Importing the DHCP Configuration” on page 181
 “Migrating DHCP Leases from OES 2 SP3, OES 11 or OES 2015 to OES 2018” on page 181
Exporting the DHCP Configuration
The file is exported in a dhcpd.conf format. These files can be imported anywhere and can also be
imported back to eDirectory by using the DNS/DHCP Java-based Management Console Utility.
1 Click the DHCP (OES Linux) tab of the Java Management Console.
2 Click
Export DHCP Database on the toolbar to open the Export - DHCP window.
3 Specify the name of a destination file or browse to select a filename from the dialog box, then
click Next.
4 Select the services by using the Export DHCP - Service List window.
5 Click Export to store your information in a file.
6 Click Finish to complete the export.
If the export program encounters any error, the Details button is enabled in the error window.
Click Details to view the error details.
Importing the DHCP Configuration
The configuration file to import should be in DHCP V3 format. Importing the Linux DHCP
configuration file overwrites the associated DHCP server's settings.
To import the DHCP files:
1 Click the DHCP (OES Linux) tab of the Java Management Console.
2 Click
Import DHCP Database on the toolbar.
3 Click Browse to select or specify the path for the DHCP database file.
4 Click Next to open the Import - File Input window.
5 Specify the service name in the Service Name text box.
6 In the Select NDS Context text box, browse to select or enter specify the context where the
service is to be created.
7 (Optional) Select a Default DHCP Server from the drop-down list.
8 Click Import.
9 Click Finish to complete the import operation.
If the import program encounters any error, the Details button is enabled in the error window. Click
Details to view the error details.
Migrating DHCP Leases from OES 2 SP3, OES 11 or OES 2015 to OES 2018
To migrate the DHCP leases from a supported OES server to OES 2018, copy the /var/lib/dhcp/
db/dhcpd.leases file from the source OES 2 server to the corresponding location in the OES 2018
server.
Migrating DHCP to OES 2018
181
Post-Migration Procedure
1 In the /etc/dhcpd.conf file, change ldap-base-dn to reflect the context of the migrated DHCP
Server and change ldap-dhcp-server-cn to reflect the name of the migrated DHCP Server.
Verifying the Migration
1 Check the syntax of the dhcp configuration file with the rcnovell-dhcpd check-syntax command.
The command reads /etc/dhcpd.conf and checks the syntax.
2 Start the target server dhcp server using the following command:
rcnovell-dhcpd start
3 Verify the /var/log/dhcp-ldap-startup.log file to check the dhcp configuration of the
migrated server.
182
Migrating DHCP to OES 2018
21
Migrating DNS to OES 2018
21
Migration refers to the process of migrating DNS services to OES 2018.
 “Migrating DNS from Netware to OES 2018” on page 183
 “Migrating DNS to OES 2018” on page 185
Migrating DNS from Netware to OES 2018
In these sections, the NetWare server is referred to as the source server and the OES 2018 server as
the target server.
The following sections give you more information on the prerequisites and the procedure to migrate
source servers based on different scenarios:
 “Planning Your Migration” on page 183
 “Migration Scenarios” on page 184
 “Migration Procedure” on page 184
 “Post-Migration Procedure” on page 185
Planning Your Migration
Make sure your setup addresses the following requirements before you migrate DNS to the new
platform.
 “System Requirements” on page 183
 “Supported Platforms” on page 183
System Requirements
 An eDirectory integrated DNS server installed on the target machine.
NOTE: In a Server ID Swap scenario, do not select Create DNS Server option at the install time.
This avoids the creation of the DNS server for the temporary NCP server. So when migration is
completed, the existing DNS server objects are considered.
 Schema extension is already done on the destination server tree and DNS-DHCP Group, and
the RootServerInfo and DNS-DHCP Locator objects are created.
 The user running the migration process should have rights to update files on the target machine.
This user should also be included in the DNS-DHCP group in eDirectory.
Supported Platforms
The following platforms are accepted as valid source platforms for the migration process:
 NetWare 6.5 SP8
Migrating DNS to OES 2018
183
Migration Scenarios
To migrate DNS to the new platform, you can use the Java Management Console. During migration,
the configuration details as well as the data are migrated to the destination platform.
 “Migrating Servers within the Same eDirectory Tree” on page 184
 “Migrating Servers across eDirectory Trees” on page 184
Migrating Servers within the Same eDirectory Tree
In this scenario, both the NetWare server and the OES 2018 server are on the same eDirectory tree.
Migrating Servers across eDirectory Trees
In this scenario, the Netware server and the OES 2018 server are on different eDirectory trees, so the
migration is across the trees.
Depending on your setup, you can choose to migrate a single server at a time or migrate all the
servers at the same time.
Migration Procedure
 “Using Java Console to Migrate Servers within the Same eDirectory Tree” on page 184
 “Using Java Console to Migrate Servers across eDirectory Trees” on page 184
Using Java Console to Migrate Servers within the Same eDirectory
Tree
1 Launch Java Console.
2 Identify the source NCP server and the corresponding DNS server object that should be
migrated to target server.
The server and the server object will no longer exist on the NetWare server after migration. Make
sure that the DNS Service is not running on this source NCP server.
To stop the service, see “Stopping the DNS Server” in the OES 2018: DNS/DHCP Services for
Linux Administration Guide.
3 Use Java Console to move the source DNS server. This task also migrates the primary zones in
the tree.
For information about moving the DNS server, see “Moving a DNS Server” in the OES 2018:
DNS/DHCP Services for Linux Administration Guide.
Using Java Console to Migrate Servers across eDirectory Trees
1 In Java Console, create the DNS server object. For details, see OES 2018: DNS/DHCP Services
for Linux Administration Guide.
2 On the target server, create a secondary zone and specify the zone master IP address as the IP
address of the NetWare server where the primary zone exists. After the initial zone transfer,
change the zone on the source NetWare server to secondary and make the zone on the target
server to be the primary server.
184
Migrating DNS to OES 2018
Migrate primary zones on the target server by creating a secondary zone and specifying the
zone master IP address as the IP address of the NetWare/OES server where the primary zone
exists.
3 Load the DNS servers on primary and secondary server to initiate zone transfer.
4 After the initial zone transfer, change the zone on the source NetWare server to secondary and
make the zone on the target server to be the primary server zone.
5 To migrate secondary zones, create a secondary zone on the Linux server and specify it to be
the secondary zone to the target primary zone that is on the target server. Ensure that both the
primary and the secondary zones use the same name. This is essential for a successful zone
transfer.
NOTE: This method of migration is limited to migrating the zone data only.
Post-Migration Procedure
1 Use the Java Management Console to check for the existence of the following objects:
 DNS-DHCP
 DNSDHCP-GROUP
 RootServerInfo
 DNS Server object
2 Load novell-named using the rcnovell-named start command and check to see if the /etc/
opt/novell/named/named.conf file contains zone database files with valid information.
3 Use the nslookup utility to query for records in zones.
Migrating DNS to OES 2018
In these sections, the supported OES server is referred to as the source server and the OES 2018
server as the target server.
 “Planning Your Migration” on page 185
 “Migration Scenarios” on page 186
 “Post-Migration Procedure” on page 187
Planning Your Migration
Make sure your setup addresses the following requirements before you migrate DNS to the new
platform.
System Requirements
 An eDirectory integrated DNS server installed on the target machine.
Migrating DNS to OES 2018
185
NOTE: During DNS installation, do not select Create DNS Server option at the install time. This
avoids the creation of the DNS server for the temporary NCP server. So when migration is
completed, the existing DNS server objects are considered.
 Schema extension is already done on the destination server tree and DNS-DHCP Group, and
the RootServerInfo and DNS-DHCP Locator objects are created.
Migration Scenarios
To migrate DNS to the new platform, you can use the Java Management Console. During migration,
the configuration details as well as the data are migrated to the destination platform.
Migrating Servers within the Same eDirectory Tree
1 Launch Java Console.
2 Identify the source NCP server and the corresponding DNS server object that should be
migrated to target server.
The server and the server object will no longer exist on the OES 2 server after migration. Make
sure that the DNS Service is not running on this source NCP server.
To stop the service, see “Stopping the DNS Server” in the OES 2018: DNS/DHCP Services for
Linux Administration Guide.
3 Use Java Console to move the source DNS server. This task also migrates the primary zones in
the tree.
For information about moving the DNS server, see “Moving a DNS Server” in the OES 2018:
DNS/DHCP Services for Linux Administration Guide.
4 On successful migration, proceed to perform service specific proxy migration, see “Migrating
Proxy users to OES 2018” on page 239.
Using Java Console to Migrate Servers across eDirectory Trees
You can migrate DNS across eDirectory trees by exporting the DNS database from the source server
and importing the database to the target server.
Exporting DNS Database
Export DNS database operation transfers the resource record data of a zone to a text file. The text file
is in the DNS BIND master file format. These files can be used in other DNS servers, including BIND
servers, or they can be imported back into the eDirectory database using the DNS/DHCP Java-based
Management Console.
1 In the DNS Service window, select the zone you want to export and click Export DNS Database
on the toolbar.
2 In the Export - DNS window, enter the name of a destination file or browse to select a filename
from the dialog box.
3 Click Export to store your zone data in a file.
4 If the export program encounters any error, the Details button is enabled. Click Details to view
the error details.
186
Migrating DNS to OES 2018
Importing DNS Database
Import DNS database operation transfers resource record data present in the BIND formatted DNS
zone files into the eDirectory database.
1 In the DNS Service tab, click Import DNS Database on the toolbar.
2 Enter the DNS BIND formatted filename in the field provided. You can also browse to select the
filename from the File Selection dialog box.
3 Click Next to select the context where the zone objects will be created.
4 Click Next to select the server name that manages the zone.
You can select an existing DNS server or an NCP server, where DNS server object will be
created. The selected DNS server must have the DNS/DHCP services installed in it.
If you select the zone type as primary, this DNS server will act as a designated primary. If you
select the zone type as secondary, this DNS server will act as a designated secondary.If you do
not want to assign a DNS server for this zone leave this field empty.
5 Click Next to specify the zone type.
If you select the zone type as primary, DNS servers act as primary servers for this zone or if you
select secondary, servers act as secondary DNS servers.
6 Click Next to view the configuration that you selected.
7 Click Import to begin importing with this configuration.
If the import program encounters any error, the Details button is enabled. Click Details to view
the error details. Some resource records might not have been transferred because of incorrect
data. Click Create on the tool bar to recreate these resource records.
8 Click Finish to complete the import operation.
Post-Migration Procedure
1 Use the Java Management Console to check for the existence of the following objects:
 DNS-DHCP
 DNSDHCP-GROUP
 RootServerInfo
 DNS Server object
2 Load novell-named using the rcnovell-named start command and check to see if the /etc/
opt/novell/named/named.conf file contains zone database files with valid information.
3 Use the nslookup utility to query for records in zones.
Migrating DNS to OES 2018
187
188
Migrating DNS to OES 2018
22
Migrating DSfW to OES 2018
2
This section describes how to migrate DSfW to an OES 2018 environment.
NOTE: The migration procedure described in this section is applicable only for the migration of an
OES server acting as a DSfW server.
Before you proceed with the migration, review “Planning Your Migration” on page 147.
 “Planning Your Migration” on page 189
 “Migration Procedure” on page 190
 “Post-Migration Procedure” on page 191
Planning Your Migration
Make sure your setup addresses the following requirements before you migrate DSfW.
 “Prerequisites” on page 189
 “What is Migrated” on page 189
Prerequisites
Before you proceed with the migration, review the details in “Prerequisites” on page 61. For a
successful migration:
 The source server and the target server must be in the same eDirectory tree.
 Ensure that the time is synchronized between the source and the target server.
 The source and target servers must be in the same subnet and gateway.
 The target server must be a non-replica server in the eDirectory tree. To make the target server a
non-replica server, select the Novell Pre-migration Server option while installing OES 2018 on
the target server.
 The target server DNS entry must point to DSfW source server IP address.
 Hostname of the target server should not be same as any other server in the DSfW tree.
What is Migrated
 DSfW configuration data present in eDirectory.
 Configuration files for DSfW services like kerberos, samba, xad, and rsync.
 Non DSfW services like iPrint and NSS. Non DSfW services need to be migrated as per the
migration procedure for a particular service.
Migrating DSfW to OES 2018
189
Migration Procedure
DSfW migration follows the Transfer ID migration process. For more information about Transfer ID,
see Part IV, “Transfer ID Migration,” on page 59.
IMPORTANT: Ensure that you do not patch or register the migration server for updating before
installing the Novell Pre-migration Server pattern and the DSfW pattern.
Follow the instructions given below to perform the migration:
1 Install and configure eDirectory with pre-migration pattern on the target server.
NOTE: You must ensure that the target server is installed only with eDirectory and the Novell
pre-migration pattern. Novell pre-migration and eDirectory pattern must be installed using
Software Management tool provided by the YaST utility.
If services such as iPrint, NSS, and SMS are configured on the DSfW server that is migrated,
then configuration data related to these services will also be migrated as part of the DSfW
migration process. However, migration of service?specific data needs to be migrated as per the
migration procedure for a particular service. For information on migrating iPrint, see Chapter 25,
“Migrating iPrint to OES 2018,” on page 201. For information on migrating NSS, see Chapter 16,
“Migrating File Systems to OES 2018,” on page 103.
2 If the source server has proxy user configured for services such as LUM, see Chapter 30,
“Migrating Proxy users to OES 2018,” on page 239.
3 Install the DSfW pattern on top of the preexisting patterns on the target server but do not
configure it.
4 Reboot the target server.
5 Ensure that you have copied the SSH keys to avoid multiple password prompts:
5a Enable SSH on the source server and the target server.
5b Enter the # ssh-keygen -t rsa command on the target server.
5c When you are prompted to enter the file in which to save the key, press Enter.
The ssh keys are stored in the default location (/root/.ssh/id_rsa).
5d When you are prompted to enter the passphrase, leave it empty for no passphrase, then
press Enter.
5e Copy the key value (the output of the # ssh-keygen -t rsa command) to the source
server using the following command:
ssh-copy-id -i /root/.ssh/id_rsa.pub root@source-ip-address
Where -i /root/.ssh/id_rsa.pub is the output of # ssh-keygen -t rsa command.
Replace <source-ip-address> with the IP address or the hostname of the source server.
6 Run the DSfW migration script on the target server. The purpose of this script is to migrate the
DSfW-specific data to the target server.
./opt/novell/xad/sbin/migrate_dsfw.pl --source=source-ip --all
The migration script invokes the miggui tool.
The Transfer ID operation migrates eDirectory, LUM, and other associated services of the
source server. For more information, see “Select the Source and Target Server and the Migration
Type” on page 69.
7 Reboot the target server.
190
Migrating DSfW to OES 2018
8 After you reboot the server, you are prompted to configure additional features like WINS and
Sites. This can be done using the DSfW Feature Configuration Wizard.
IMPORTANT: You are prompted to configure these features only once. If you fail to configure
these features during the first instance, you will not be able to configure these features later.
Enter the authentication details in the login dialog box, depending on the scenario in which you
are provisioning, then click OK.
Provisioning Scenario
Authentication Details Required
Non-name-mapped, forest root domain
The current domain credentials.
Name-mapped, forest root domain
The current domain credentials and the tree admin
credentials.
Non-name-mapped child
The current domain credentials, the parent domain
credentials, and the tree/container admin
credentials.
Name-mapped child
The current domain credentials, the parent domain
credentials, and the tree/container admin
credentials.
Additional Domain Controller
The current domain credentials and the tree admin
credentials.
IMPORTANT: If you are installing a first-level child domain in a non-name-mapped scenario, the
tree admin and the parent domain credentials are the same.
9 Select the feature that you want to configure, then click Next.
10 On the task list page, click Run to manually execute a task or click Run All to execute all the
tasks sequentially without any manual intervention.
11 After you complete executing the DSfW Feature Configuration Wizard, you must verify if all the
daemons are up and running by executing the following command:
xadcntrl status
12 Run the following command to verify if the schema has been extended, rights on the domain
controller objects have been added, and the unique domain id on the domain root has been
added.
/opt/novell/xad/sbin/domaincntrl --preps
Post-Migration Procedure
After the migration procedure has completed, you need to manually cleanup certain eDirectory
objects. For more information, follow the instructions specified in Chapter 13, “Post Transfer ID
Migration,” on page 87.
Migrating DSfW to OES 2018
191
192
Migrating DSfW to OES 2018
23
Migrating LUM to OES 2018
23
This section describes how to migrate LUM from a supported OES server to OES 2018.
 “Planning the Migration” on page 193
 “Migration Scenarios” on page 193
Planning the Migration
Make sure your setup addresses the following requirements before you migrate LUM to the
destination platform.
 “Prerequisite” on page 193
Prerequisite
 If the source server is OES 2 SP2, the proxy credential retrieval binary (32 or 64 bit) for LUM
(lum_retrieve_proxy_cred) should be copied to /usr/bin folder on the source server.
Migration Scenarios
The following three scenarios are supported for LUM migration:
 Common Proxy Migration: If LUM is configured to use common proxy, refer to “Services that
are Using Common Proxy” on page 240.
 Transfer ID Migration: If LUM is not configured to use proxy user, refer to Part IV, “Transfer ID
Migration,” on page 59.
For common proxy and service specific proxy migration scenarios, you must also do a Transfer ID
migration. Transfer ID migration effects changes such as setting of the nam configuration and
mapping the target server with the existing eDirectory users and groups.
Migrating LUM to OES 2018
193
194
Migrating LUM to OES 2018
24
Migrating FTP to OES 2018
24
Migration refers to the process of migrating FTP services from a supported NetWare or OES server to
a OES 2018 server. The Open Enterprise Server (OES) migration tools follow a source/target model.
The following sections give you more details on the migration procedure for FTP.
 “Migrating FTP from Netware to OES 2018” on page 195
 “Migrating FTP to OES 2018” on page 198
Migrating FTP from Netware to OES 2018
This section describes how to migrate FTP from Netware or OES to OES 2018.
Planning the Migration
Make sure your setup addresses the following requirements before you migrate FTP to the
destination platform.
 “System Requirements” on page 195
 “Source Servers” on page 195
 “Target Server” on page 195
System Requirements
 Pure-FTPd
Source Servers
 NetWare 6.5 SP8
Target Server
 OES 2018
Migration Scenarios
The following three scenarios are supported for FTP migration:
 Consolidation on the Same Tree
 Consolidation on a Different Tree
 Transfer ID on the Same Tree
For details on these three scenarios, see “Migration Scenarios” on page 16.
Migrating FTP to OES 2018
195
Prerequisites
For all three scenarios, eDirectory should be running so eDirectory users can log in.
What is Migrated
When the migration is complete, the FTP parameters on NetWare are mapped to the corresponding
parameters in Pure-FTPd on Linux. For details on mapped parameters, see Table 24-1 on page 197.
Migrating FTP
Migration of FTP configuration can be done from the Migration Tool or through the command line
interface.
NOTE: Before you start the Pure-FTPd server, ensure that eDirectory is up and running on the target
server. This is to ensure that all the eDirectory users can be used for Pure-FTPd access. For the
Server ID Swap, all eDirectory objects are migrated as part of the DIB migration step. For complete
details on eDirectory migration, read Appendix 17, “Migrating eDirectory to OES 2018,” on page 147.
 “Using the Migration Tool” on page 196
 “Using the Command Line” on page 196
Using the Migration Tool
1 Launch the Migration Tool in one of the following ways:
Desktop: Click Applications > Other > Novell Migration Tools
Terminal: Log in as the root user and at a terminal prompt, enter miggui
2 Configure the source and target parameters.
For details on configuring source and target server information, selecting a migration type, and
the Open, Save Project, and all other tool buttons, see Chapter 2, “Overview of the Migration
GUI,” on page 21.
3 Select Novell FTP from Services and click Configure. The status now changes from Not
Configured to Ready.
4 When the status is Ready, click Start to start the migration process.
The status changes from Migrating to Migrated on success.
NOTE: Use the Status > Logs tab to check for errors during migration. Fix the errors and restart
the migration procedure if necessary.
Using the Command Line
1 Run the FTP migration utility from the command line with the required parameters:
migftp -s <source_server>
For example:
migftp -s 192.168.1.54
If the migration is successful, a message indicating success is displayed.
196
Migrating FTP to OES 2018
2 Start the eDirectory server to allow eDirectory users to log in.
3 Start the FTP server by using the rcpure-ftpd start command.
Post-Migration Procedure
1 All the FTP services users must be LUM enabled.
2 Map these parameters during FTP migration from NetWare to Linux:
Table 24-1 NetWare Linux FTP FTPd Mapping Parameters
NetWare FTP Parameters
Linux Pure FTPd Parameters
SECURE_CONNECTIONS_ONLY
TLS
PASSIVE_PORT_MIN
PassivePortRange
PASSIVE_PORT_MAX
PassivePortRange
MAX_FTP_SESSIONS
MaxClientsNumber
HOST_IP_ADDR
Bind
FTP_PORT
Bind
FORCE_PASSIVE_ADDR
ForcePassiveIP
ANONYMOUS_ACCESS
AnonymousOnly
IDLE_SESSION_TIMEOUT
MaxIdleTime
DEFAULT_USER_HOME_SERVER
DefaultHomeDirectoryServer
DEFAULT_USER_HOME
DefaultHomeDirectory
IGNORE_REMOTE_HOME
EnableRemoteHomeDirectory
Important:
 If ANONYMOUS_ACCESS is commented irrespective of the value set to yes or no on the
source server (NetWare), after migration the value set for AnonymousOnly on the target server
(OES 2018) is retained.
For example, #ANONYMOUS_ACCESS=yes or #ANONYMOUS_ACCESS=no is set on the
source server, AnonymousOnly=yes or AnonymousOnly=no is set on the target server, whatever
the value set on the target server is retained after migration.
If ANONYMOUS_ACCESS is uncommented irrespective of the value set to yes or no on the
source server (NetWare), after migration the value set for AnonymousOnly on the target server
(OES 2018) is overwritten with the value set on the source server.
For example, ANONYMOUS_ACCESS=no is set on the source server, AnonymousOnly=yes is
set on the target server, AnonymousOnly will be set to no after migration.
 If you use BIND parameter in the NetWare ftpserv.cfg file, after migrating to OES, your FTP
login will be blocked. This happens as FTP still tries to bind to the source IP address and port
that you have specified in the NetWare ftpserv.cfg file.
To resolve this issue, change the IP address and port to that of an OES target server. This
workaround is not required in case of a Transfer ID migration.
Migrating FTP to OES 2018
197
 If Passive Port Range on NetWare is not set or is less than twice the number of maximum
allowed clients, after migrating to Linux, set the PassivePortRange twice the MaxClientsNumber.
For example, if you set MaxClientsNumber as 10, then set the PassivePortRange as 30000
30020.
 If SECURE_CONNECTIONS_ONLY is set in NetWare and an FTP migration certificate does not
exist on Linux, a default FTP certificate (/etc/ssl/private/pure-ftpd.pem) is created, using
either an eDirectory certificate (/etc/ssl/servercerts/eDircert.pem) of the target server or
the server certificate (/etc/ssl/servercerts/servercert.pem). If neither of them exists, the
migration creates a certificate with default parameters. The admin can replace this by creating a
new certficate using the steps listed in “Create Certificate Procedure” (http://
download.pureftpd.org/pub/pure-ftpd/doc/README.TLS).
 The ForcePassiveIP field in NetWare when left blank or set as 0.0.0.0 indicates none specified.
However, on linux, it is interpreted as is and therefore can lead to server binding to invalid IP
address resulting in loss of functionality. The migration script is updated to ignore IP 0.0.0.0, and
created .bak file for preserving the original linux conf file for administrative reference.
Migrating FTP to OES 2018
This section describes how to migrate FTP from a supported OES environment to OES 2018.
Before you proceed with the migration, review “Prerequisites” on page 198. In this section, the source
server refers to a supported OES server and the target server refers to an OES 2018 server.
 “Prerequisites” on page 198
 “What is Migrated” on page 198
 “Migration Procedure” on page 198
Prerequisites
 Ensure that OES 2018 server is already installed along with the FTP pattern on the target server.
For details see, “Installing Pure-FTPd” in the OES 2018: Planning and Implementation Guide.
What is Migrated
 Configuration file and script
Migration Procedure
Same tree migrations with identity transfer
Perform the following procedures on the target server:
1 Copy the /etc/pure-ftpd/pure-ftpd.conf file from the source server.
NOTE: If the migration is being performed on a cluster setup, copy the pure-ftpd.conf file on
the shared volume of cluster.
2 Run /opt/novell/pure-ftpd/novell-pure-ftpd-config.sh script. This will update the
pure-ftpd.conf file with the new parameters added in OES2015 or later.
198
Migrating FTP to OES 2018
3 Remove LD_PRELOAD statement from the /usr/lib/systemd/system/pure-ftpd.service
file, if present.
4 Restart pure-ftpd using the systemctl restart pure-ftpd.service command.
Same tree migrations without identity transfer
1 Execute steps Step 1 to Step 3.
2 Update the IP address of the target server for ForcePassiveIP and Bind parameters in the pureftpd.conf file.
3 Update DefaultHomeDirectoryServer if it refers to the IP of the source server.
Migrating FTP to OES 2018
199
200
Migrating FTP to OES 2018
25
Migrating iPrint to OES 2018
25
Migration refers to the process of migrating iPrint from supported NetWare or OES versions to OES
2018. For general information about the OES 2018 Migration Tool, see Chapter 1, “Overview of the
Migration Tools,” on page 15.
The following sections give more details on the migration procedure for iPrint.
 “Prerequisites” on page 201
 “Supported Migration Scenarios” on page 202
 “What is Migrated” on page 202
 “Migration Procedure” on page 203
 “Migrating an iPrint Cluster Resource” on page 211
 “Migrating ZENworks iPrint Policies” on page 212
 “Verifying Migration” on page 215
 “Cleaning Up Stale Objects” on page 215
 “Troubleshooting iPrint Migration” on page 216
 “iPrintmig Man Page” on page 222
Prerequisites
This section covers the migration prerequisites for all the migration scenarios supported by iPrint.
 “Platform Specifications” on page 201
 “General Prerequisites” on page 202
Platform Specifications
 “Target Server Requirements” on page 201
Target Server Requirements
 OES 2018 server with iPrint installed, and with Print Manager and the Driver Store configured.
For more information, see “Installing and Setting Up iPrint on Your Server”, “Creating a Print
Manager”, and “Creating a Driver Store” in the OES 2018: iPrint Administration Guide.
IMPORTANT: If your target server is in a non-replica eDirectory tree, both the target Driver Store
and Print Manager must be active for migration to be successful. Configure SLP to make them
active. For details on SLP configuration, see “Configuration Parameters” in the NetIQ eDirectory
Administration Guide.
Migrating iPrint to OES 2018
201
General Prerequisites
 Before starting the migration, ensure that the source and target Print Managers are running. If
you are using command line tools for migration, ensure that the source Print Managers are
running.
 When you upgrade to OES, ensure that you migrate NDPS to iPrint. NDPS is not supported on
OES Linux.
 Ensure that the file containing the printers to be migrated does not contains extra spaces or
characters. For troubleshooting extra spaces, see “Printers are not migrating with the -f option”
on page 218.
 Ensure that the driver paths are correct and accessible. For troubleshooting a bad driver
assignment, see “Invalid driver path assignments” on page 218.
 Ensure that you retain the Print Agent redirection on the source servers.
 For NetWare source servers, follow the instructions in “Setting Up DNS for the Print
Manager” in the NW 6.5 SP8: iPrint Administration Guide.
 For Linux source servers, follow the instructions in “Creating a Print Manager” in the OES
2018: iPrint Administration Guide.
 Ensure that the user has the following rights and permissions assigned explicitly on the source
server so that the user can access and execute the psminfo.nlm, even if there is a mismatch of
source server and container admin credentials for the user:
 Read permission to sys:ndps folder on the migration source server.
 Add the user as a trustee with supervisor rights to the source server NCP server object.
 Back up the Print Manager database files on the source server prior to migration. For NetWare,
see “Understanding the Print Manager Database” in the NW 6.5 SP8: iPrint Administration
Guide. For Linux, see “Understanding the Print Manager Database”.
 The servers involved should be accessible via SSH. If the SSH ports are not open in the firewall,
ensure that they are open before trying to access the servers.
Supported Migration Scenarios
iPrint supports the following migration scenarios:
 Migrating servers within the same eDirectory tree
 Migrating servers across different eDirectory trees
 Migrating servers through consolidation
 Migrating servers through a Transfer ID
For more information about these scenarios, see “Migration Scenarios” on page 16.
What is Migrated
During the migration process, the following objects are replicated seamlessly from the source server
to the target server:
 Printers
 Drivers
 Banners
202
Migrating iPrint to OES 2018
 Printer pools
 Redirected printers
 ACL (only if the source and target servers are in the same tree)
 Printer profiles
 The iPrint.ini file (only if the source server is NetWare 6.5)
 iPrint Client Management (only if the source and target servers are in the same tree and are
sharing a common user)
Migration Procedure
Perform the following tasks for iPrint migration.
 “Pre-Migration iPrint Configuration” on page 203
 “iPrint Consolidate Migration” on page 204
 “Verifying the Result of the iPrint Migration” on page 211
 “Transfer ID” on page 211
Pre-Migration iPrint Configuration
Perform the following pre-migration steps on the target server:
1 Create the Driver Store. For more information, see “Creating a Driver Store” in the OES 2018:
iPrint Administration Guide.
If the eDirectory server1 value is not pointing to a server that holds a reliable replica, go to /etc/
opt/novell/iprint/conf/idsd.conf and modify the eDirectory server1 value to a server that
holds a reliable replica. Change the IDSHostAddress value to the IP address (temporary IP
address) of the migration server. Restart the Driver Store (rcnovell-idsd restart).
2 Create the Print Manager. For more information, see “Creating a Print Manager” in the OES
2018: iPrint Administration Guide.
If eDirectory server1 value is not pointing to a server that holds a reliable replica, go to /etc/
opt/novell/iprint/conf/ipsmd.conf and modify the eDirectory server1 value to a server
that holds a reliable replica. Change the PSMHostAddress value to the IP address (temporary IP
address) of the migration server. Restart the Print Manager (rcnovell-ipsmd restart).
3 Change the iPrint Apache configuration.
If AuthLDAPDNURL is not pointing to a reliable LDAP server, change AuthLDAPDNURL in /
etc/opt/novell/iprint/httpd/conf/iprint_ssl.conf to a reliable LDAP server. Restart
Apache (rcapache2 restart).
4 Ensure that the admin user is LUM-enabled.
To check this, enter id admin at the terminal. If the admin user is LUM-enabled, UID and GID
information is returned.
5 Ensure that iprintman authentication is successful.
To check the authentication by using the IP address, enter
iprntman psm -l -s <IP address>
To check the authentication by using the DNS name, enter
iprntman psm -l -s <DNS name>
6 Test iPrint prior to the migration on the target server.
Migrating iPrint to OES 2018
203
Using iManager, view the Print Manager and Driver Store. Click a few options to verify that you
donot encounter any errors.
7 Continue with “iPrint Consolidate Migration” on page 204.
NOTE: You can run psminfo.nlm on the source server, then copy the psminfo.xml file to the target
server at the /opt/novell/iprint/share location. This avoids contacting the source server during
migration.
iPrint Consolidate Migration
Migration of the iPrint configuration can be done through the Migration Tool or through the command
line interface.
 “Using the Migration Tool” on page 204
 “Using the Command Line Utility” on page 210
NOTE: When you migrate iPrint from NetWare to OES 11SP2, Public Access Printers are not
migrated.
Using the Migration Tool
1 Launch the Migration Tool on the target server in one of the following ways:
Desktop: Click Applications > Other > Novell Migration Tools.
Terminal: Log in as the root user and enter miggui at the terminal prompt.
For details on configuring the source and target server information, selecting a migration type,
opening a project, and on all the tool buttons, see Chapter 2, “Overview of the Migration GUI,” on
page 21.
2 Authenticate to the source and target servers.
3 Click Add.
4 Select Novell iPrint, then click Yes to configure. The iPrint configuration window is displayed.
204
Migrating iPrint to OES 2018
5 Configure the following parameters to proceed with the migration process:
Print Objects
Parameter
Description
Print
Managers
Source Print Manager
Specify the active Print Manager on the source server. The
source Print Manager can be either an NDPS manager (for
NetWare 6.5) or iPrint Manager (for OES Linux). To go directly
to a context of your choice, specify the context in the search
base and click Search. The objects in the specified context are
displayed.
Migrating iPrint to OES 2018
205
Print Objects
Parameter
Description
Target Print Manager
The Target Print Manager field is populated with the name of
the active Print Manager running on the target server. This field
is editable, and you can also specify a different name for the
active Print Manager. To go directly to a context of your choice,
specify the context in the search base and click Search. The
objects in the specified context are displayed.
Click Get Printers to select printer objects from the source
Print Manager.
Click Get Printers to select printer objects from the source
Print Manager.
Printer
Objects
eDirectory Server
Select this option if the target server does not hold an
eDirectory replica. Specify the IP address of the target server
that holds the reliable eDirectory replica.
Source printers
Displays all the printers of the active Print Manager available
on the source server. The printers that already exist on the
target server are indicated by an asterisk (*).
Select All
Selects all the printers listed in the Printer Objects dialog box.
NOTE: When you apply a new filter, or modify an existing filter
and click Select All, only printers that are displayed after
applying the filter are selected. When you manually select all
printers, the selected printers are migrated.
Create target
printer
objects in
Filter
Specify the search pattern in the Filter field. This displays the
printers in the Printer Agents list. This field is case sensitive.
Context same as
source printer context
Select this option to use the same context as the source
printers on the target server.
NOTE: If you are migrating to a different tree, and you select
Context same as Source printer context, you must ensure
that the context exists in the target tree.
Target context
This option is selected by default. It allows you to create source
printers under a different context on the target server. This
option does not maintain the context hierarchy of the source
printer.
To go directly to a context of your choice, specify the context in
the search base and click Search. The objects in the specified
context are displayed.
Do Not Migrate Existing If the printer names on source server match the printer names
Target Printers
on the target server, the target printer properties and attributes
are overwritten by the source printer properties and attributes.
The printers that already exist on the target server are
represented by an asterisk (*).
206
Migrating iPrint to OES 2018
Other Options Parameter
Description
Source Driver The Source Driver
Store
Store is not on the
same server as the
Source Print Manager
If the source Driver Store is running on a server different from
the source Print Manager's server, this check box is selected.
Specify the IP address or the DNS Name and the root
password of the server on which the source Driver Store is
located.
For more details on using this panel, see Step 6 on page 209.
Migrate the following
additional Source Print
Brokers to the Target
Driver Store
This section lists the names and IP/DNS addresses of the
source Print Broker volumes that need to be migrated to the
target Driver Store.
Use the + and - icons to add and delete the source Print
Brokers.
Migrating iPrint to OES 2018
207
Other Options Parameter
Description
Target Driver
Store
The Target Driver Store DN field is auto populated with the
Driver Store associated with the PSM object, if the driver store
is running. This field is editable, and you can also specify the
name of the Driver Store. To directly go to a context of your
choice, specify the context in the search base and click
Search. The objects in the specified context are displayed.
Target Driver Store DN
Specify the IP address or the DNS name and the root password
of the server on which the source Driver Store is located. For
more details on using this panel, see Step 6 on page 209.
To directly go to a context of your choice, specify the context in
the search base and click Search. The objects in the specified
context are displayed.
IMPORTANT: If the target Driver Store is hosted by a server
that is not hosting the Print Manager, you cannot select the
Driver Store's eDirectory server. To resolve this, go to the Driver
Store's /etc/opt/novell/iprint/conf/idsd.conf file
and update the DSServer1 value to the address of a server that
holds the replica. Restart the Driver Store (rcnovell-idsd
restart) after making the change.
Target Driver Store is
remote
If the Driver Store is running on the remote server (other than
the target server), the Target Driver Store is remote check
box is enabled.
Specify the IP address or the DNS name of the remote server
and the root password of the remote server in the
corresponding entry fields.
Additional source Print
Broker to be migrated
to the above target
Driver Store (optional)
Click the plus button (+) and specify the IP address or the DNS
name of the Source Broker. Select the Source Broker volume
from the drop-down list and click OK. The list is populated with
the IP address or DNS name of the Source Broker and Broker
volume name. You can add multiple Source Brokers to the list.
To remove the Source Broker from the list, select the IP
address or DNS name and click the minus button (-). You can
remove one Broker at a time.
Printer
Drivers
Do not Migrate Printer
Drivers and the
association of the
Printer Agents with the
Driver
Selecting this option ensures that printer drivers and the
association of Printer Agents with the drivers are not migrated.
Migrate Printer Driver if
the driver is not present
in the target Driver
Store
Selecting this option migrates the printer drivers for the driver
platforms you have selected from the Select Driver Platforms to
Migrate list if they are not present in the target Driver Store.
This also migrates all the associations of the Printer Agents
with the driver.
NOTE: The default driver platform selection is All.
208
Migrating iPrint to OES 2018
Other Options Parameter
Description
Migrate all Printer
Drivers. This overwrites
the Printer Driver on
the target Driver Store
Selecting this option overwrites the target drivers for the driver
platforms you have selected from the Select Driver Platforms to
Migrate list, if the driver names in the target Driver Store are
same as the source Driver Store. This also migrates all the
associations of the Printer Agents with the driver.
NOTE: The default Driver Platform selection is All.
Printer Driver
Profile
Migrate Printer Driver
Profile
If the profiles are the same on the target server as the source
server, the target profiles are overwritten.
iPrint.ini File
Migrate iPrint.ini File
If you migrate printer agents from two or more print managers,
the iPrint.ini file on the target server is replaced by the
iPrint.ini of the last source server.
NOTE: After migration, if the target server's iprint.ini file is
overwritten by the source server's file, and if the target server's
iprint.ini file had new parameters that were erased, you
can restore them by copying the parameters manually from the
iprint.bak file. The iprint.bak file is a backup of the target
server's iprint.ini file. After migration, the iprint.bak file
is saved in the /var/opt/novell/iprint/htdocs directory.
6 In the Source Driver Store and Target Driver Store panels, the default user name is displayed as
root. To use a user name other than root, make the following changes:
 Add the intended user name to the sudoers database by using the following command <new non-root user name>
ALL = (ALL) ALL
 Comment out the following two lines from visudo -f /etc/sudoers:
1. Defaults targetpw # ask for the password of the target user i.e. root
2. ALL ALL=(ALL) ALL
targetpw'!
# WARNING! Only use this together with 'Defaults
This ensures that the system does not prompt you for a root password.
7 Click OK to finish the configuration and go back to the migration screen.
8 Click Migrate.
Migrating iPrint to OES 2018
209
Using the Command Line Utility
You can use iprintmig to migrate iPrint. For more information, see “iPrintmig Man Page” on
page 222.
Use one of the following methods to migrate to OES 2018:
 From a terminal prompt on the target server, run iprintmig to migrate the printers on the
source server to the target server. Before running the utility, set the environment variable for
safely transferring the password.
For safe transmission of passwords to the script via an environment variable or via the -P/-T
options, see “Using Passwords” on page 226.
IMPORTANT: This method is safe and recommended.
Syntax: iprintmig -s source_server -u source_username_only -U
target_username_only -a -x psminfo.xml -I cn=ids,o=example,c=us -i
ids.example.com -c ou=iPrint,o=example,c=us
 From a terminal prompt on the target server, run iprintmig to migrate the printers on the source
server to the target server by specifying the password.
IMPORTANT: The password is visible to users in this method.
Syntax: iprintmig -s source_server -u source_username_only -p source password U target_username_only -t target password -a -x psminfo.xml -I
cn=ids,o=example,c=us -i ids.example.com -c ou=iPrint,o=example,c=us
Migrating One Printer at a Time
Example: iprintmig -s source_server_name -u source_admin -U target_admin -n
printer1 -x psminfo.xml -I cn=ids,o=example,c=us -i ids.example.com -c
ou=iPrint,o=example,c=us -N
Migrating a Few Printers at a Time
Example: iprintmig -s source_server_name -d target_server_name -u source_admin -U
target_admin -x psminfo.xml -I cn=ids,o=example,c=us -i ids.example.com -c
ou=iPrint,o=example,c=us -n printer1 -n printer2 -n printer3 -n printer4 -L
Migrating All Printers
Example: iprintmig -s source_server_name -d target_server_name -u source_admin -U
target_admin -x psminfo.xml -I cn=ids,o=example,c=us -i ids.example.com -c
ou=iPrint,o=example,c=us -a -N
Migrating Printers by Using SSL
Example: iprintmig -s source_server -u source username -U target username -a -I
cn=ids,o=example,c=us -i ids.example.com -c ou=iPrint,o=example,c=us -ssl -port
LDAP port -N
210
Migrating iPrint to OES 2018
Migrating Printers without SSL
Example: iprintmig -s source_server -u source username -U target username -a -I
cn=ids,o=example,c=us -i ids.example.com -c ou=iPrint,o=example,c=us -port LDAP
port -N
IMPORTANT: Ensure that you verify the result of iPrint migration after completing migration, as
described in “Verifying the Result of the iPrint Migration” on page 211.
Verifying the Result of the iPrint Migration
1 Open iManager on the server you use for iPrint management.
2 Install some printers on the test workstation.
3 Run reports to verify all the migrated information:
3a Go to https://<MigrationServerIP>/PsmStatus/GenerateReportSettings.
3b Select the check box for Printer Drivers, Associated NDS Printer, and other options for the
NetWare Printer Agents.
3c Click Generate Report.
3d Verify that all the printer agents have the expected values.
Transfer ID
To perform an identity transfer, configure the iPrint service for migration, then select Transfer ID. This
migrates iPrint to an OES 2018 server, and then transfers the source server’s identity. Migrate iPrint
services to the target server before starting the Transfer ID process. For more information, see
Chapter 10, “Using the Migration GUI Tool for Transfer ID,” on page 67.
Before starting the Transfer ID process you must migrate all services to the target server. See
Chapter 9, “Preparing for Transfer ID,” on page 61.
IMPORTANT: Do not start the Transfer ID process until the migrated iPrint service on the target
server successfully completes the outlined tests. To verify the result of iPrint migration, see “Verifying
the Result of the iPrint Migration” on page 211.
Migrating an iPrint Cluster Resource
Perform the following steps to migrate the iPrint cluster resource from NetWare to OES 2018 without
reinstalling the printers on the workstations.
NOTE: When you upgrade to OES, ensure that you migrate NDPS printers to iPrint. NDPS is not
supported on OES Linux. For more information, see “How to automate the upgrade from NDPS to
iPrint” (http://www.novell.com/support/php/
search.do?cmd=displayKC&docType=kc&externalId=7004661&sliceId=2&docTypeID=DT_TID_1_1
&dialogID=159879519&stateId=0%200%20159881359)
1 Set up iPrint for a cluster environment.
For more information, see “Setting up the Cluster Environment for iPrint” in the OES 2018: iPrint
Administration Guide.
Migrating iPrint to OES 2018
211
2 Migrate the target cluster resource hosting iPrint from node to node.
On each node, check the status of the Print Manager and Driver Store.
rcnovell-ipsmd status
rcnovell-idsd status
Test the ability of the Print Manager to authenticate the admin user (or the user given in the
Migration Tool.
iprntman psm -l -u admin
3 Perform the pre-migration for iPrint configuration.
For more information, see “Pre-Migration iPrint Configuration” on page 203.
4 Perform a consolidated migration of the iPrint service. For more information, see “iPrint
Consolidate Migration” on page 204.
When the source or target iPrint service is hosted on a cluster resource, transferring a node's
identity is not necessary and not recommended.
5 Verify the result of the iPrint migration.
For more information, see “Verifying the Result of the iPrint Migration” on page 211.
6 Transition end-user printing from NetWare to Linux:
6a Offline the NetWare iPrint cluster resource.
6b View the NetWare iPrint cluster load script's /DNSNAME value.
6c Configure DNS to resolve the /DNSNAME value to the IP address of the target Linux cluster
resource hosting the Print Manager.
The propagation of the DNS change might take time, depending on your network.
DNSNAME is the address that the clients use to find the NetWare Print Manager. The same
DNSNAME is used to find the Linux Print Manager.
6d Update each of the Linux node /etc/hosts files to resolve to the Linux iPrint cluster IP
address.
6e Update the /etc/opt/novell/iprint/conf/ipsmd.conf PSMHostAddress value to the /
DNSNAME.
6f Restart the Print Manager.
7 Perform the post-migration steps. For more information, see xxxx.
Migrating ZENworks iPrint Policies
The ZENworks 10 Configuration Management and ZENworks 7 iPrint policies contain a list of printers
to be distributed via the policy. The printer names are back-linked to the eDirectory object of the
corresponding printer. When the iPrint service is migrated from source server to an OES 2018 server,
iPrint policies containing migrated printers must also be updated. For example, if the ZENworks7
iPrint policy contains a printer from the source server, after migration it must contain a corresponding
printer from the target server.
The novell-iprint-migration.rpm also contains the scripts for migrating ZENworks 10
Configuration Management and ZENworks 7 policies. You must run the scripts to migrate the policies.
212
Migrating iPrint to OES 2018
IMPORTANT: The target server and the source server must be in the same tree and in the same
container.
 “Policy Migration in ZENworks 10 Configuration Management” on page 213
 “Policy Migration in ZENworks 7” on page 214
Policy Migration in ZENworks 10 Configuration
Management
 “Prerequisites” on page 213
 “Options” on page 213
Prerequisites
 The file with the list of printers to be migrated must be copied from the target server to the
ZENworks 10 Configuration Management server.
 Ensure that the latest version of ZENworks 10 Configuration Management is installed. You can
get the ippmanagement utilities from there.
 Install Perl on your server to run the policy migration script on the ZENworks 10 Configuration
Management windows server.
Syntax: zcm-migrate-print-policy.pl -a <Administrator name> -p <Administrator password>
-s <Source server> -d <Destination server> .
The zcm-migration-print-policy.pl script is located in /opt/novell/bin. Copy and run the
script on the ZENworks 10 Configuration Management server. This script copies the original printer
policies and the policies are formed in the target server. If you encounter any error, refer to the log file
available at zcm10-migration.log.
Options
-a, --admin
Administrator name.
-p, --passwd
Administrator password.
-P, --port
(Optional) Port number (The default port is 80).
-l, --linux
(Optional) The source operating system is Linux.
-n, --netware
(Optional) The source operating system is NetWare.
-s, --src
Source server IP address or the DNS name.
Migrating iPrint to OES 2018
213
-d, --dest
Target server IP address or the DNS name.
-r, --rem
(Optional) Deletes old policies.
-c, --change
(Optional) Changes the default printer.
-f, --file
The filename that has the list of printers to be migrated.
-x, --xml
(Optional) The directory containing the policies in XML form.
Policy Migration in ZENworks 7
The zen7-migration-print-policy.pl script is located in /opt/novell/bin/. Run the script on
the target server where the replica of the eDirectory tree is present. This script copies the original
printer policies, and the policies are defined on the target server. If you encounter any error, refer to
the log file at /var/opt/novell/log/iprint/zenpolicy_migration.log.
Syntax: <script name> -v -v -v <log file> -s <Host name or IP address> -a
<Administrator FDN> -p <Administrator password> -b <Base DN> -d <Keep default> -r
<Deletes the old policies> -n <Source Operating System> -f <Filename containing a
list of files containing migrated printer list>.
Options:
-v -v -v
Log file.
-s, --host
Hostname or IP address. Source server IP address.
-a, --admin
Administrator FDN (such as cn=admin,o=novell).
-p, --passwd
Administrator password.
-b, --base-dn
DN of a container to search for the ZENworks 7 iprint policy objects (e.g. o=novell).
-d, --keepdefault
Retains your default printer in the ZENworks 7 policy.
-l, --linux
The source operating system is Linux (For an ID swap always specify -l, even if the source is
Netware.).
214
Migrating iPrint to OES 2018
-n, --netware
The source operating system is NetWare.
-f, --file
A filename that has a list of printers to be migrated.
For more information on ZENworks, refer to ZENworks 10 Configuration Management (http://
www.novell.com/documentation/zcm10/index.html).
Verifying Migration
After migration is complete, the desired Print Manager on the target server must be active. This
ensures that the migration has been successfully completed. Use the procedures in this section to
check for the Print Manager and printers.
 “Using iManager” on page 215
 “Using the Command Line” on page 215
IMPORTANT: If the Print Manager is down after migration, see “Troubleshooting iPrint Migration” on
page 216.
Using iManager
1 Open iManager on the target server.
2 Go to iPrint > Manage Print Manager.
3 Specify the iPrint Manager name or NDPS Manager name.
4 Click OK, then ensure the Print Manager status is Active.
5 Click Printer Agents.
Depending on your setup, it might take some time to display the printers on the target server.
Using the Command Line
1 At the console, enter iprintman psm -l -u admin.
2 Enter the admin password when prompted.
This displays the status of all the Print Managers with their status. Ensure that the desired Print
Manager is Active.
3 At the console, enter iprintman printer -l -u admin.
4 Enter the admin password when prompted.
This displays the printers on the target server.
Cleaning Up Stale Objects
You can clean up stale iPrint objects by using the /opt/novell/iprint/bin/iprintcleanup.pl -s
<source_server> -u <source_user(FDN format)> --ssl --port <LDAP_Port> -f <filename>
command.
Migrating iPrint to OES 2018
215
-h | --help
Print the summary
-s | --src <source_server>
Source server IP address.
-u | --src-user <user>
Admin user FDN for the source server. For example, cn=admin,o=novell.
-p | --src-pass <pswd>
Password of the source server admin user.
-f | --renamed-printers-file <filename>
Filename to clean up. For example, /etc/opt/novell/iprint/conf/renamed_printer_objects.
--ssl
Use this option if SSL is enabled on the server.
--port
LDAP enabled port.
Troubleshooting iPrint Migration
 “iPrint Service Does not Work After Transfer ID Process” on page 217
 “Printers are not migrating to OES” on page 217
 “Target server authentication fails in a cluster environment” on page 218
 “Printers are not migrating with the -f option” on page 218
 “Invalid driver path assignments” on page 218
 “Printers are not migrating in the same eDirectory tree under the same context” on page 219
 “Migration fails even after a pre-check is passed” on page 219
 “Migration fails when the Print Manager does not have a clean shutdown” on page 219
 “Migration fails when a printer is assigned to a Print Manager” on page 219
 “Migration fails when the SYS volume folder is not available on the source server” on page 220
 “Migration fails for container admin credentials on the source server” on page 220
 “Migration fails with an error message” on page 220
 “The Driver Store and Print Manager are not initialized after migration on the target server” on
page 220
 “Printers not coming up after Transfer ID migration” on page 221
 “Printer fails to install with the error “wrong printer URL”” on page 221
 “Migration is completed with the status displaying as “Successful with warnings. Please refer the
migration log”” on page 221
 “Printers migrated from the source to target in the same context, are not migrated to the target in
a different context” on page 221
216
Migrating iPrint to OES 2018
 “Problems with accessing newly created printer agents after copying the padbtxt.xml file from the
source to the target” on page 222
 “Redirections are not successful when printers are migrated” on page 222
iPrint Service Does not Work After Transfer ID Process
Source: The iPrint service does not work after the Transfer ID process is complete.
Action: On completion of the Transfer ID process, confirm the following values:
1 Go to /etc/opt/novell/iprint/conf/ipsmd.conf and change the
PSMHostAddress value to the source server's IP address or DNS name
(preferably a CNAME was used). Use the address that was used when you
loaded with the /dnsname or /ipaddress switch. If you are unsure, view the
name by which the iPrint printers are installed at the workstations.
2 Change the eDirectory server1 value to a reliable eDirectory server
address.
3 Go to /etc/opt/novell/iprint/conf/idsd.conf and change the
IDSHostAddress value to the source server's IP address or DNS name
(which is now the target server's IP or DNS).
4 Change the eDirectory server1 value to a reliable eDirectory server
address.
5 Go to /etc/hosts and ensure that entries are correct for the new identity.
6 Go to /etc/opt/novell/iprint/httpd/conf/iprint_ssl.conf and
update the AuthLDAPDNURL "ldaps://[address..]" to any reliable LDAP
server.
7 Go to /etc/opt/novell/iprint/httpd/conf/iprint_g.conf and update
the address after the ServerName entry. Ensure that you choose the new
identity IP address.
8 Restart the Print Manager (rcnovell-ipsmd restart), Driver Store
(rcnovell-idsd restart), and Apache (rcapache2 restart).
9 Use iManager to test iPrint by using the Print Manager, Driver Store, and
printers.
If you encounter an error while managing the Print Manager, one of the
certificates may need to be updated. To troubleshoot, see the Cool
Solutions article “Certificate Re-creation Script for OES” (https://
www.novell.com/communities/coolsolutions/cool_tools/certificaterecreation-script-oes1-and-oes2/).
Printers are not migrating to OES
Explanation: Occasionally the iPrint migration status is successful but the specified Print
Manager is not active or is down, and so printers are not migrated to the OES
server.
Possible Cause: Some other Print Manager is active or is already loaded on the OES server.
Migrating iPrint to OES 2018
217
Action: On the OES server:
1 Search for the ipsmd daemons by executing the ps ax | grep ipsmd
command. This displays two running ipsmd processes.
2 Kill the individual ipsmd daemons by executing
kill -9 pid_of_ipsmd
3 Restart migration by executing iprintmig.
Target server authentication fails in a cluster environment
Explanation: The loopback address is not authenticated.
Possible Cause: The loopback address is not being resolved to the IP address of the target server
in the cluster environment.
Action: Enter the IP address or DNS name of the target server.
Printers are not migrating with the -f option
Explanation: iprintmig skips adding printers from the file containing the printer list.
Possible Cause: If the file with the printers to be migrated contains extra spaces or characters, the
file is skipped by the utility.
Action: Delete the extra spaces or characters and restart the migration process.
Invalid driver path assignments
Explanation: Specific printers are not being migrated, and you see the error message
XMLToDoCIMInstance::doWork(): CIMException encountered (general
error) <Operating System Name> GetDriverInfo failed:<Printer Name>
during migration.
Possible Cause: The printers are associated with deleted or missing drivers.
Possible Cause:
The driver is associated with a remote path that no longer exists. The path can
be a remote server or an unmounted volume.
Action: Verify the driver path and generate a report to correct the driver assignment:
1 In iManager, select Manage Print Manager.
2 Select an NDPS Manager.
3 Click OK.
NOTE: If the Print Manager is down, click Startup to change the status to
Active.
4 Click Printer Agents Configuration Report.
5 Select one or more configuration options for the operating system name
displayed in the error message.
6 Click Generate Report.
7 The driver assignment path is displayed for individual Printer Agents in the
report.
8 Verify that the complete driver path is a valid assignment.
218
Migrating iPrint to OES 2018
9 (Conditional) If the path is invalid, select Manage Printer and do the
following:
9a Choose a required printer under NDPS Printer Name.
9b Click OK.
9c In the the Drivers tab, select the specific operating system for which
the assignment is invalid. A message displays this message - The
current driver does not exist.
9d Click OK.
9e Select either NONE or a suitable driver.
Printers are not migrating in the same eDirectory tree under the
same context
Explanation: Printers are not being migrated, and you see an error message:
CIMException encountered (general error): Creation of printer
'CN=<PrinterName>,o=<organization>' object failed. Object exists,
but failed to get iPrintPrinterManager value.
Possible Cause: The migration was in the same eDirectory tree, and the source Print Manager
and target Print Manager were under the same context.
Action: Use iManager to create a Print Manager on the target server in a different
context. Restart the migration with the target Print Manager as the newly created
Print Manager.
Migration fails even after a pre-check is passed
Explanation: When you restart the source server, the migration fails if the Print Manager was
not successfully unloaded.
Possible Cause: The eDirectory attributes for the unloaded PSM are not cleaned up.
Action: Restart the Print Manager.
Migration fails when the Print Manager does not have a clean
shutdown
Explanation: When the Print Manager does not have a clean shutdown, migration fails with an
error message stating this is an invalid print manager on target.
Possible Cause: The eDirectory status for the Print Manager is not updated when the Print
Manager shutdown is not clean.
Action: Restart the Print Manager.
Migration fails when a printer is assigned to a Print Manager
Explanation: The migration fails with an error message: CIMException encountered (general
error): Creation of printer <Printer FDN> ( Eg:
cn=Printer1,o=novell) object failed. Object exists,
iPrintPrinterManager value indicates that the printer is
associated with another ipsmd.
Possible Cause: Trying to reassign a printer to a new Print Manager when the existing Print
Manager assigned to this printer is down.
Migrating iPrint to OES 2018
219
Action: Do not select the printer that is currently assigned to a Print Manager on the
target server when it is down.
Migration fails when the SYS volume folder is not available on the
source server
Possible Cause: The sys:ndps folder was renamed or deleted from the source server.
Action: Ensure that the sys:ndps folder is on the source server.
Migration fails for container admin credentials on the source server
Explanation: Printer objects with the container admin credentials are not being migrated.
Possible Cause: There is a mismatch between the source server and container admin credentials
for the user. The source server might not be in the same container where full
access rights are defined.
Action: Ensure that the user has the following rights and permissions assigned explicitly
so that the user can access and execute psminfo.nlm:
 The read permission to the sys:ndps folder on the migration source server.
 Add the user as a trustee with supervisor rights to the source server NCP
Server object.
Migration fails with an error message
Explanation: Migration fails with the following error message: 'OpenWBEM4::HTTPException'
what(): Unable to process request: 401: Authentication failure
Aborted.
Possible Cause: The admin user is not correctly LUM-enabled.
Action: LUM-enable the admin user:
1 Run yast2 novell-lum from the command prompt.
2 Click Continue.
3 Enter the admin password.
4 Click Next and follow the on-screen prompts.
The Driver Store and Print Manager are not initialized after migration
on the target server
Explanation: The Driver Store and Print Manager are not initialized on the target server when
SLP configuration is used.
Possible Cause: Problems in SLP configuration before starting migration.
Action: Enter the slptool findsrvs service:ndap.novell | grep <TREE NAME>
command to list the TREENAME. If the tree name is not listed, fix the SLP
configuration. For details, see “Prerequisites” on page 41.
220
Migrating iPrint to OES 2018
Printers not coming up after Transfer ID migration
Explanation: You migrate printers by using the Transfer ID option, but printers are not coming
up.
Possible Cause: Printers are not being associated with the drivers after a Transfer ID action.
Action: Use the following procedure:
1 Run the /opt/novell/bin/ipsmd -x /tmp/psmimport_idswap.xml -s
<Server IP Address> -u admin -f command on the OES 2018 console.
2 Enter the admin password.
Printer fails to install with the error “wrong printer URL”
Explanation: On successful migration, the redirected printers fail to install on the target server.
Action: If the iPrint service is configured with the IP address and if the source server is
down, installation fails.
Ensure that the source server is up and running and then install the redirected
printer.
Action: If the iPrint service is configured with DNS and the DNS is not resolved with the
target server IP address, installation fails.
Ensure that the DNS is resolved to the target server IP address and then install
the redirected printer.
Migration is completed with the status displaying as “Successful
with warnings. Please refer the migration log”
Explanation: The message is displayed when the drivers associated with the printers are not
migrated to the target server.
The printers are migrated, but you cannot install the printers for which the driver
download or upload has failed.
Action: Check the migration log for the drivers that failed to migrate. Do not perform a
migration; instead, manually upload or download those drivers to the target
server.
Printers migrated from the source to target in the same context, are
not migrated to the target in a different context
Explanation: When you migrate printers from the source to the target in the same context,
then you restart the Printer Manager and try to migrate those printers again in a
different context, the printers fail to migrate.
Action: Do not migrate printers in a different context if they have already been migrated
from the source to the target in the same context.
Migrating iPrint to OES 2018
221
Problems with accessing newly created printer agents after copying
the padbtxt.xml file from the source to the target
Explanation: When you copy the padbtxt.xml file from the source to the /opt/novell/
iprint/share directory on the target, the Migration Tool cannot access any
newly created Printer Agents that were added to the source after copying the file.
Action: Copy the padbtxt.xml file from the source to the target everytime you create
printer agents. When you select printers to migrate and migration passes
successfully, but the printers selected for migration are still not migrated, one
possible reason could be the presence of an outdated padbtxt.xml file in the
directory. Remove the file and retry the migration procedure.
Redirections are not successful when printers are migrated
Explanation: When you redirect one printer to another on the source, migrate both the
redirected printer and the other printer to the target, associate a driver to the
redirected printer on the target server, then try to install the other printer from the
target server, the printer installation fails. This is because this printer on the
target server points to the redirected printer on the source, which does not have
any drivers asssociated with it.
iPrintmig Man Page
 “iprintmig(1)” on page 223
222
Migrating iPrint to OES 2018
iprintmig(1)
Name
iprintmig - Migration utility for iPrint
Syntax
This section contains iPrint commands and utilities used on the Linux platform.
iprintmig
-s <server> -u <user> <options> -n <printer1>...<printerN>
iprintmig
-s <options>
Description
iprintmig is a management tool used to migrate printers to OES 2018.
Options
-h, --help
Prints this summary.
-v, -vv, -vvv, -vvvv, -verbose
Specify the level of detail to display about the execution of operations with -v displaying minimum
information and -vvvv displaying maximum information.
-V, --version
Prints version information.
-s <server>, --src <server>
Specifies the source server hostname or address to migrate from.
-d <server>, --dst <server>
Specifies the target server hostname or address to migrate to.
-D <PSM DN>, --dst-dn <PSM DN>
Specifies the destination print manager DN to migrate to.
-u <user>, --src-user <user>
Specifies the FDN format admin for the source server, such as cn=admin, 0=example.
-U <user>, --dst-user <user>
Specifies the FDN format admin for the target server, such as cn=admin, 0=example.
-p <pass> , --src-pass <pass>
Password of the source server admin user.
-P<fd>, --src-pass-fd <fd>
File descriptor number (to read the source admin password).
Migrating iPrint to OES 2018
223
-t<password>, --dst-pass <password>
Password of the user on the target server.
-T<fd>, --dst-pass-fd <fd>
File descriptor number (to read the destination admin password).
-i<IDS_server>, --ids <IDS_server>
Target iPrint Driver Store (IDS) server hostname or address. Defaults to dst.
-I<IDS_DN>, --ids-dn <IDS_DN>
Distinguished name of the target IDS.
-e<server>, --edir <server>
Server hostname or address of the eDirectory server for the target server to use.
-n<printer>, --printer-name <printer>
Name of the printer to migrate. Can be specified multiple times.
-f <file>, -printers-file <file>
File containing names of printers (1 per line) to migrate.
-F <fd>, -printers-fd <fd>
File descriptor number listing names of printers to migrate.
-a, --all
Migrates all printers from the source.
-c<DN>, --dst-container <DN>
DN of the container to create print objects in (conflicts with -S).
-S, --same-dn
Creates objects on the target server with the same DN as the source server. Only valid when
migrating to a new tree.
-H, --same-hostname
Creates a manager on the target server with the same hostname as the source manager. Useful
when migrating the entire print server.
-x<file>, --xml-outfile <file>
Saves the XML migration processing file to <file>.
--o, --remoteDS-root-pass<pass>
Root password of the remote driver store server.
--O, --remoteDS-root-pass-fd<fd>
File descriptor number (to read the root password of the remote driver store server).
--q, --src-root-pass<pass>
Root password of the source server.
--Q, --src-root-pass-fd<fd>
File descriptor number (to read the root password of the source server).
224
Migrating iPrint to OES 2018
--srcversion
Indicates the version of the operating system on the source server.
--nodrivers
Do not migrate drivers. If drivers are not present in the destination IDS, clients cannot install
printers.
--overwrite-drivers
If the destination IDS has a driver with the same name as a corresponding driver on the source
server, overwrite it.
--noacls
Stops migration of Access Control Lists (ACLs).
--noprofiles
Stops migration of profiles. If profiles are not present on the target server, clients cannot install
printers.
--overwrite-profiles
Overwrites the target server profile for a driver with the same name as a profile on the source
server.
--nogo
Prepares but does not perform migration. This option creates an output XML file and migrates
drivers (unless --nodrivers was specified) but does not perform migration.
--debug
Prints debug messages to a /var/opt/novell/log/migration/iprintmig.log file.
--update
Synchronizes any changes in the source server data with the target server after the migration
process is complete. This option must be used in conjunction with the -a option.
--resume
Lets you resume the migration process from where it was suspended.
--precheck
Validates the parameters passed for the migration process and returns the status without
actually starting the migration.
--consolidation
Aggregates services on a single target server from multiple source servers.
--ssl
Enables secure authentication.
--port
Indicates the LDAP port.
--treeflattening
Creates the contexts of the source printers under a different context on the target server. The
context of the target printer is specified by using the -c<DN>, --dst-container <DN> option.
Migrating iPrint to OES 2018
225
--idswap
Migrates printers from the source server to the target server without changing their identities.
--driver-platform
Identifies the names of the platforms to migrate. All the drivers for the selected platforms are
migrated. The driver platforms should be specified every time you configure the print options. For
example, --driver-platform "Windows XP" --driver-platform "Vista 64".
Using Passwords
For security reasons, it is safest to transmit passwords to the script via an environment variable or via
the -P/-T options, because any user of the system can view the password if it is on the command line
(-p/-t options).
Instead, have the calling program set its environment with the following two variables:
IPRINTMIG_SRC_PASSWORD=examplePassword1
IPRINTMIG_DST_PASSWORD=examplePassword2
Then you can execute the following command, which migrates all the printers from
server1.example.com to the server where the script is being run.
iprintmig -s server1.example.com -u admin.example.us -U admin -a -x psminfo.xml -I
cn=ids,o=example,c=us \-i ids.example.com -c ou=iPrint,o=example,c=us
Examples
The following example migrates several printers at a time while explicitly specifying the hostname of
the new print manager:
iprintmig -s server1.example.com -d newserver.example.com -u admin.example.us -U
admin -x psminfo.xml \ -I cn=ids,o=example,c=us -i ids.example.com -c
ou=iPrint,o=example,c=us -n printer1 -n printer2 \-n printer3 -n printer4
If a calling program specifies a large number of printers, there are three ways to proceed:
 The -n (or --printer-name) option can be specified with a printer name one or more times, as in
the example above. This can create a very long command line if many printers are being
migrated, so this usage is discouraged.
 A file containing printer names, one per line, can be specified by using the -f (or --printers-file)
option. For a calling program to use this file, the program must first write the list of printers to a
temporary file.
 The calling program can avoid the use of a temporary file by using the -F (or --printers-fd) option,
which allows the calling program to send the list of printer names over a pipe, such as a pipe
created with socketpair(). When you use the -f (or --printers-file) option, printer names are read
from the file descriptor, one per line.
226
Migrating iPrint to OES 2018
A simple example of this usage follows in C. Similar methods are available with the
Mono.Posix.Syscall members.
char *printers[] = { "p1", "p2", "p3" };
int fds[2], pid, rc;
rc = socketpair(AF_UNIX, SOCK_STREAM, 0, fds);
if (rc < 1)
{
perror("Error creating socket pair");
exit(1);
}
pid = fork();
switch (pid)
{
case -1: //Error
perror("Fork failed");
exit(1);
case 0: //Parent
close(fds[1]);
for (int i; i < (sizeof(printers)/sizeof(char**)); ++i)
{
write(fds[0], printers[i], strlen(printers[i]));
write(fds[0], "\n", 1);
}
close(fds[0]);
break;
default: //Child
close(fds[0]);
//Set an environment that contains the password env vars
//Make sure that close on exec isn't set for fds[1]
//exec the iprintmig script with "-F" and fds[1] converted from an int to
a string as arguments
}
Notes
Most of the information that this program requires can be obtained from the eDirectory objects that
you select. For example, to migrate all printers from a NetWare server to the new Linux server, you
need to select the old PSM object, which contains the address of the server it is running on. Then you
need to select the destination PSM, which has attributes for its network address, the eDirectory
server it is using, and the IDS it is using. The corresponding IDS object has its own address.
There are some details that you must manually provide instead of selecting or discovering, such as
details about credentials and whether or not to migrate profiles or drivers.
You can select a destination container to hold the objects created during migration, or you can choose
to keep the same path for objects. This only works for a move from one tree to another, because
NetWare objects already exist in the source tree and might conflict with the new Linux versions of the
objects.
Authors
Novell, Inc.
Copyright
Copyright ©2011, Novell, Inc. All rights reserved.
Migrating iPrint to OES 2018
227
See Also
iprintman
228
Migrating iPrint to OES 2018
26
Migrating NetStorage to OES 2018
26
This section describes the procedures to migrate NetStorage from supported OES versions to OES
2018.
 “Migrating NetStorage to OES 2018” on page 229
Migrating NetStorage to OES 2018
The supported OES servers are referred as the source server and the OES 2018 server as the target
server.
Prerequisites
Before proceeding to migrate, meet the following prerequisites:
 NetStorage is installed and configured on OES 2 SP3 32-bit machine.
 NetStorage is installed on target OES 2018 machine.
For more information about installing and configuring NetStorage, see “Installing NetStorage” section
in the OES 2018: NetStorage Administration Guide for Linux.
What is Migrated
The following data is migrated from the source server to the target server:
 Xtier registry settings and configurations
Migration Procedure
Source Server
1 Backup the /var/opt/novell/netstorage/shared folder.
2 Backup the /opt/novell/netstorage/webapp/WEB-INF/classes/Settings.properties file.
3 At the terminal prompt use the following command to stop the xregd user: rcnovell-xregd
stop
4 Export the registry available at /var/opt/novell/xtier/xregd/db as an xml file using the
following commands:
/opt/novell/xtier/bin/regutil -e srcReg.xml
Target Server
1 Copy the /var/opt/novell/netstorage/shared folder in the same volume and directory
structure.
2 Copy the /opt/novell/netstorage/webapp/WEB-INF/classes/Settings.properties file in
the same volume and directory structure.
Migrating NetStorage to OES 2018
229
3 Ensure that file permissions are retained.
4 Copy srcReg.xml to any location. For example, /opt/novell/xtier/bin/regutil -i
<location>/srcReg.xml, where <location> is the location of your choice.
5 At the terminal prompt use the following command to stop the xregd user: rcnovell-xregd
stop
6 Navigate to /var/opt/novell/xtier/xregd/db/ and verify that the directory db is empty using
the following command: ls -l. If the directory is empty, continue to step 5.
7 If any files exist in the db directory, move all the files to a temporary directory, say /tmp.
8 Generate files inside the xtier registry using the following commands:
8a To restore the source server registry:
/opt/novell/xtier/bin/regutil -i srcReg.xml
9 Navigate to /var/opt/novell/xtier/xregd/db/ and run the command ls –l /var/opt/
novell/xtier/xregd/db to ensure that the following files are generated:
 xtier_registry.db
 xtier_registry.lck
 xtier_registry.rfl
10 Start the xregd user using the rcnovell-xregd start command.
11 Navigate to the xtier registry using the following command /opt/novell/xtier/bin/regedit.
12 At the regedit prompt, execute the cd local_machine command and ls -l command to view
the contents inside the directory. If a directory named software is present in the local_machine
directory, then the registry is rebuilt without any error.
13 Similarly, enter the following commands in the sequence listed along with ls -l command to view
the content in the respective directories:
 cd software
 cd Novell
 cd Xtier
 cd Configuration
If the content exists in all the respective directories, then the Xtier registry is completely
rebuilt.
14 Enter exit.
15 Restart the machine.
Transfer ID - Same Tree
In this scenario, the target server is installed in the same tree as the source server. On successful
completion of Transfer ID, the target server functions with the same credentials (such as IP address
and host name) as the source server and source server node is no longer available in the network.
For more information, see Chapter 10, “Using the Migration GUI Tool for Transfer ID,” on page 67
230
Migrating NetStorage to OES 2018
Post Migration
After migrating NetStorage,
 Login to iManager and go through the NetStorage Task, the configurations should have been
properly migrated.
 Access NetStorage from a browser http://<IP-ADDRESS>/NetStorage/ and should be able to
login and access files and folders.
Migrating NetStorage to OES 2018
231
232
Migrating NetStorage to OES 2018
27
Migrating NTP to OES 2018
27
Migration refers to the process of migrating Timesync services from a NetWare system to NTP on a
Linux system. The OES Migration tool follows a source/target model.
The following sections give more details on the migration procedure for Timesync.
 “Planning the Migration” on page 233
 “Migration Scenarios” on page 233
 “Migration Procedure” on page 233
 “Post-Migration Procedure” on page 234
Planning the Migration
You can migrate the NTP services running on one of the following source platforms to the listed target
platform:
Source Servers
 NetWare 6.5 SP8
Target Server
 OES 2018
Migration Scenarios
The following scenarios are supported for Timesync/NTP migration:
 Consolidation on the same tree
 Consolidation on a different tree
 Transfer ID on the same tree
For details on these three scenarios, see “Migration Scenarios” on page 16.
Migration Procedure
Migration of NTP configuration can be done from the Migration Tool or through the command line.
The migration procedure reads the NetWare NTP/Timesync configuration file and maps its
parameters to the equivalents in NTP Linux. During the migration process, the existing ntp.conf file
is backed up and saved as ntp.conf.old in the /etc directory and the new parameters are saved in
/etc/ntp.conf. If NTP is already configured on the target server while configuring eDirectory, this
configuration is overwritten.
 “Using the Migration Tool to Migrate Servers” on page 234
 “Using the Command Line to Migrate Servers” on page 234
Migrating NTP to OES 2018
233
Using the Migration Tool to Migrate Servers
1 Launch the Migration Tool in one of the following ways:
Desktop: Click Applications > Other > Novell Migration Tools
Terminal: Log in as the root user and at a terminal prompt, enter miggui
2 Configure the source and target parameters.
For details on configuring source and target server information, selecting a migration type,
loading and saving a project, and all buttons, see Chapter 2, “Overview of the Migration GUI,” on
page 21.
3 Select Novell NTP from Services and click Configure. The status changes from Not Configured
to Ready.
4 Click Migrate to start the migration process. The status changes from Migrating to Migrated.
NOTE: Use the Status > Logs tab to check for errors during migration. Fix the errors and restart
the migration procedure if necessary.
Using the Command Line to Migrate Servers
To run the NTP migration utility through the command line, run the following command on the target
server with the required parameters:
migtime -s <source IP address>
For example:
migtime -s xxx.xxx.xxx.xxx
Post-Migration Procedure
Load the XNTPD daemon by entering the following command at the prompt:
rcntp restart
234
Migrating NTP to OES 2018
28
Migrating NCP to OES 2018
28
This section describes how to migrate NCP environment to OES 2018.
Before you proceed with the migration, review “Prerequisites” on page 235. In this section, the source
server refers to a supported OES server and the target server refers to an OES 2018 server.
 “Prerequisites” on page 235
 “What is Migrated” on page 235
 “Migration Procedure” on page 235
Prerequisites
 OES server is already installed and NCP is configured. For details, see OES 2018: NCP Server
for Linux Administration Guide.
 NSS Pools and volumes are already migrated to the new OES 2018 server. Use the cluster
migrate resource_name node_name command to migrate the cluster pools and volumes. For
details, see “Using the Cluster Migrate Command” in the OES 2018: Novell Cluster Services for
Linux Administration Guide.
 NCP (posix) volumes and non-cluster NSS volumes are already migrated to the new OES 2018
server. This can be done by unmounting the corresponding file system from the source machine
and mounting it on the target machine.
What is Migrated
 Configuration files
Migration Procedure
1 Copy the following files from the OES 2 servers to OES 11 server
 /etc/opt/novell/ncpserv.conf
 /etc/opt/novell/ncp2nss.conf
 /etc/opt/novell/ncp/ncp2nss.audit.conf
 /etc/opt/novell/ncp/ncp2nss.log.conf
 /etc/opt/novell/ncp/ncpserv.audit.conf
 /etc/opt/novell/ncp/ncpserv.log.conf
IMPORTANT: The /etc/opt/novell/ncpserv.conf file contains the file server name in
NCP_FILE_SERVER_NAME <server_name> format. If the source and target server names are
different, ensure that you modify the parameter NCP_FILE_SERVER_NAME as
NCP_FILE_SERVER_NAME <new_server_name> before proceeding to the next step.
Migrating NCP to OES 2018
235
2 After the files are copied restart ndsd daemon and ncp2nss daemon using the following
commands on the target server:
systemctl restart ncp2nss.service
systemctl restart ndsd.service
236
Migrating NCP to OES 2018
29
Migrating OpenSLP to OES 2018
29
This section describes how to migrate OpenSLP environment to OES 2018.
Before you proceed with the migration, review “Prerequisites” on page 237. In this section, the source
server refers to supported version of OES server and the target server refers to an OES 2018 server.
 “What is Migrated” on page 237
 “Prerequisites” on page 237
 “Migration Procedure” on page 237
 “Verification” on page 238
What is Migrated
 Configuration information
 Cache of service registrations
Prerequisites
Source Server
Back up the /etc/slp.conf and /etc/slp.reg.d/slpd/DABackup files on the source SLP DA
server.
Target Server
The target OES server need not be a SLP DA server.
Migration Procedure
1 Copy the following files from the source SLP server to the target server.
 /etc/slp.conf
 /etc/slp.reg.d/slpd/DABackup
NOTE: The /etc/slp.reg.d/slpd/DABackup file will only be present in the source server if the
net.slp.isDABackup parameter is set to true in the /etc/slp.conf file.
Migrating OpenSLP to OES 2018
237
2 The following steps are needed only if the IP address of the target server is different from the IP
address of the source server.
2a If the SLP agent has been configured to listen on only selected interfaces in the /etc/
slp.conf file, then after copying the configuration file to the target server, in the
net.slp.interfaces section include the IP address of the target system.
2b If DHCP is used in the network to advertise SLP Agent addresses to clients, then the
dhcpd.conf file must be updated with IP address of the new system.
2c If the SLP clients are configured to contact SLP agents through configuration files or by
providing SLP Agent IP address in the Novell Client, then the changes should be manually
updated on the clients.
3 Stop the SLP service on the source SLP DA by executing the following command:
rcstop slpd
4 Reboot the target SLP server.
Verification
Check if the Clients are able to connect to services already registered before migration and whose
service registration life time is still valid.
238
Migrating OpenSLP to OES 2018
30
Migrating Proxy users to OES 2018
30
This section describes how to migrate Proxy users to the OES 2018 server.
Ensure to review “Prerequisites” on page 41, before proceeding with proxy migration. In this section,
the source server refers to supported version of OES server and the target server refers to an OES
2018 server.
 “What is Migrated” on page 239
 “Transfer ID Migration Procedure” on page 239
What is Migrated
 The proxy users (common proxy and service proxy users) and their access rights.
Transfer ID Migration Procedure
 “Using Migration GUI for Proxy Migration” on page 239
 “Using the Migration Commands for Proxy Migration” on page 240
 “Troubleshooting” on page 241
 “Enabling SSH” on page 242
Using Migration GUI for Proxy Migration
Beginning with OES 2015 or later, you can perform Common Proxy or Service Proxy migration using
the Migration GUI tool.
The Transfer ID GUI now supports migration of Common proxy and Service Proxy and there is no
need to perform any additional manual steps.
In the eDirectory Precheck step, the source server’s proxy credentials are copied to the target server.
In the Repair step, these proxy credentials are used to reconfigure the proxy user on the target
server.
Supported Scenarios:
 Source server and target server are both configured with Common Proxy.
 Source server and target server are both configured with Service Proxy
Cross proxy migration (Service proxy to Common proxy or vice versa) or mixed proxy migration
(service proxy + common proxy to target or vice versa) is not supported.
Migrating Proxy users to OES 2018
239
Using the Migration Commands for Proxy Migration
 “Services that are Using Common Proxy” on page 240
Services that are Using Common Proxy
 “Prerequisite” on page 240
 “Pre-Migration Procedure” on page 240
 “Proxy Migration” on page 240
 “Post-Migration Procedure” on page 241
Prerequisite
 Ensure that the source server and target server is updated with the latest patches.
 Enable SSH on the source server. For more information, see “Enabling SSH” on page 242.
Pre-Migration Procedure
Before services are migrated to OES 2018 server, you must identify the services using common
proxy and the common proxy credentials on the source server.
1 On the source server, login as a root user.
2 Retrieve the common proxy credentials on the source server by executing the following
commands:
/opt/novell/proxymgmt/bin/cp_retrieve_proxy_cred username
Displays common proxy DN.
IMPORTANT: The dot format is not supported by the common proxy scripts. Ensure to use
comma format for common proxy users and contexts.
/opt/novell/proxymgmt/bin/cp_retrieve_proxy_cred password
Displays common proxy password.
Make a note of the common proxy credentials.
3 Identify the services using common proxy on the source server by executing the following
command:
/opt/novell/proxymgmt/bin/retrieve_proxy_list.sh
This command writes all the OES services and their proxy users to the file /var/opt/novell/
log/proxymgmt/pxylist.txt. Using the common proxy credentials that are identified in Step 2,
determine the services using common proxy from the pxylist.txt file.
IMPORTANT: Do not delete, modify, or rename the common proxy user from eDirectory.
Proxy Migration
Migrate all the services that are using common proxy to the target server. On successful migration
proceed with the post-migration procedure.
240
Migrating Proxy users to OES 2018
Post-Migration Procedure
After the services are migrated to OES 2018 server, you must update OES Credential Store (OCS) on
the target server with common proxy credentials and reconfigure the services using common proxy to
use the updated credentials.
1 Update OCS on the target server with common proxy credentials retrieved in Step 2 on
page 240.
1a On the target server, login as a root user.
1b Run the following command:
/opt/novell/proxymgmt/bin/cp_update_proxy_cred.sh
You are prompted to enter common proxy user DN and password. Enter details that are
retrieved in Step 2 on page 240. This updates OCS with common proxy credentials.
2 Verify if common proxy credentials are updated properly by executing the following commands:
/opt/novell/proxymgmt/bin/cp_retrieve_proxy_cred username
Displays common proxy DN.
/opt/novell/proxymgmt/bin/cp_retrieve_proxy_cred password
Displays common proxy password.
3 Reconfigure the services identified in Step 3 on page 240 to use updated common proxy
credentials.
/opt/novell/proxymgmt/bin/move_to_common_proxy.sh -d <Admin DN> -w <Admin
Password> -i <Destination system IP> -p 636 -s <comma separated list of
services>
For example:
/opt/novell/proxymgmt/bin/move_to_common_proxy.sh -d cn=admin,o=novell -w
novell -i 192.168.1.254 -p 636 -s novell-afp,novell-cifs,novell-dns
Troubleshooting
 “AFP Does Not Come Up After Transfer ID Migration to OES 2018 if Service Proxy is
Configured” on page 241
AFP Does Not Come Up After Transfer ID Migration to OES 2018 if
Service Proxy is Configured
AFP service configured with service proxy fails to come up after Transfer ID migration to OES 2018.
This is because the service proxy users are not migrated to OES Credential Store (OCS). To resolve
this issue, perform the following:
1 Login as a root user.
2 Run yast2 novell-afp and then enter eDirectory user password.
3 Specify the AFP proxy user password.
4 Click Next and continue with AFP configuration.
5 Verify the AFP service is up and running by using the following command:
systemctl status novell-afptcpd.service
Migrating Proxy users to OES 2018
241
6 Verify the service entry is present in OES Credential Store by using the following command:
oescredstore -l
Enabling SSH
1 Enable SSH on the source server and the target server.
2 Enter the # ssh-keygen -t rsa command on the target server.
3 When you are prompted to enter the file in which to save the key (/root/.ssh/id_rsa), press
Enter.
The ssh keys are stored in the default location.
4 When you are prompted to enter the passphrase (empty for no passphrase), press Enter.
We recommend that you do not include the passphrase.
5 Copy the key value (the output of the # ssh-keygen -t rsa command) to the source server.
# scp ~/.ssh/id_rsa.pub root@<source-server>:/root/
where <source-server> is the IP address or the hostname of the source server.
6 Log in to the source server by using ssh. If the.ssh directory is not available, create the
directory, then append the key value to the list of authenticated keys.
cat id_rsa.pub >> /root/.ssh/authorized_keys
242
Migrating Proxy users to OES 2018