Novell Open Enterprise Server 2, NetWare 6.5 User guide

Novell Open Enterprise Server 2, NetWare 6.5  User guide
www.novell.com/documentation
Upgrading to OES—Best Practices
Guide
Open Enterprise Server 2 SP3
January 21, 2013
Legal Notices
Novell, Inc., makes no representations or warranties with respect to the contents or use of this documentation, and specifically
disclaims any express or implied warranties of merchantability or fitness for any particular purpose. Further, Novell, Inc.,
reserves the right to revise this publication and to make changes to its content, at any time, without obligation to notify any
person or entity of such revisions or changes.
Further, Novell, Inc., makes no representations or warranties with respect to any software, and specifically disclaims any
express or implied warranties of merchantability or fitness for any particular purpose. Further, Novell, Inc., reserves the right
to make changes to any and all parts of Novell software, at any time, without any obligation to notify any person or entity of
such changes.
Any products or technical information provided under this Agreement may be subject to U.S. export controls and the trade
laws of other countries. You agree to comply with all export control regulations and to obtain any required licenses or
classification to export, re-export or import deliverables. You agree not to export or re-export to entities on the current U.S.
export exclusion lists or to any embargoed or terrorist countries as specified in the U.S. export laws. You agree to not use
deliverables for prohibited nuclear, missile, or chemical biological weaponry end uses. See the Novell International Trade
Services Web page (http://www.novell.com/info/exports/) for more information on exporting Novell software. Novell assumes
no responsibility for your failure to obtain any necessary export approvals.
Copyright © 2009 Novell, Inc. All rights reserved. No part of this publication may be reproduced, photocopied, stored on a
retrieval system, or transmitted without the express written consent of the publisher.
Novell, Inc., has intellectual property rights relating to technology embodied in the product that is described in this
document. In particular, and without limitation, these intellectual property rights may include one or more of the U.S. patents
listed on the Novell Legal Patents Web page (http://www.novell.com/company/legal/patents/) and one or more additional
patents or pending patent applications in the U.S. and in other countries.
Novell, Inc.
1800 South Novell Place
Provo, UT 84606
U.S.A.
www.novell.com
Online Documentation: To access the latest online documentation for this and other Novell products, see the Novell
Documentation Web page (http://www.novell.com/documentation).
Novell Trademarks
For Novell trademarks, see the Novell Trademark and Service Mark list (http://www.novell.com/company/legal/trademarks/
tmlist.html).
Third-Party Materials
All third-party trademarks are the property of their respective owners.
Contents
About This Guide
9
1 Frequently Asked Questions
1.1
1.2
1.3
1.4
1.5
1.6
1.7
1.8
11
Why Not Stay on NetWare? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
What About My Older NetWare Servers? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12
What’s New in OES 2?. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12
What Do Novell Customers Recommend?. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12
What Are the Differences Between NetWare and OES 2? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14
1.5.1
System and Administrative User and Group Differences . . . . . . . . . . . . . . . . . . . . . . . . . . 14
1.5.2
Comparing Services Between NetWare and OES 2 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
1.5.3
Services Not Included in OES 2 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21
How Much Training Is Needed? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22
1.6.1
What Our Customers Tell Us . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22
1.6.2
Conduct a Training Assessment . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22
What Training Is Available? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23
1.7.1
Novell Training Services . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23
1.7.2
Complimentary Free Training . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24
1.7.3
Product Documentation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24
Does Novell Have Community Support to Help Me with My Migration? . . . . . . . . . . . . . . . . . . . . . . 24
2 Getting Started
2.1
2.2
25
Assessing Your Current Network . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25
2.1.1
Running Novell Support Advisor . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25
2.1.2
Recording Your Current Network Information . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25
Identifying Needed Improvements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27
2.2.1
Server Hardware Considerations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28
2.2.2
Consolidation Considerations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29
2.2.3
Virtualization Considerations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29
2.2.4
File System Considerations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30
2.2.5
Method Considerations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30
2.2.6
Network Considerations. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30
2.2.7
eDirectory/LDAP Considerations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30
2.2.8
Time Synchronization . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31
2.2.9
Cluster Considerations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31
2.2.10 Application Compatibility Considerations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31
2.2.11 LAN/WAN Connection Considerations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32
3 Upgrading eDirectory to OES
3.1
3.2
3.3
33
About eDirectory in OES 2 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33
3.1.1
The Role of eDirectory in OES 2 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33
3.1.2
eDirectory Version Considerations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34
3.1.3
About eDirectory Management Tools in OES 2 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35
Planning Your eDirectory Upgrade . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36
3.2.1
Deciding Whether to Redesign Your Tree . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36
3.2.2
Checking eDirectory Health . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38
3.2.3
For More Information . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40
Upgrading eDirectory . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40
3.3.1
Do Not Install or Upgrade to eDirectory 8.8 Separately from OES 2 . . . . . . . . . . . . . . . . . . 40
Contents
3
3.4
3.5
3.6
3.3.2
Choosing an Upgrade Strategy . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40
3.3.3
Moving, Creating, or Importing eDirectory Users . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41
Post-Upgrade Checks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42
About Domain Services for Windows . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42
Additional eDirectory Resources . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45
4 Upgrading NSS and Data Storage to OES
4.1
4.2
4.3
4.4
4.5
4.6
About NSS in OES 2 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47
4.1.1
NSS Is Designed for the Enterprise . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47
4.1.2
More Reasons to Consider NSS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47
Platform Differences in NSS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 48
Planning to Upgrade NSS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 48
4.3.1
Identify NSS Coexistence and Migration Issues . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 48
4.3.2
Limitations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 49
Moving NSS and Data . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 50
4.4.1
Moving NSS Devices Cross-Platform . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 50
4.4.2
Moving Data from NSS on NetWare to NSS on OES 2 . . . . . . . . . . . . . . . . . . . . . . . . . . . . 50
4.4.3
Moving Data from NSS to Other Volume Types . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51
Post-Upgrade Procedures . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51
Upgrading Distributed File Services (DFS) to OES . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52
5 Upgrading File Services to OES
5.1
5.2
5.3
5.4
5.5
5.6
4
Contents
47
53
Upgrading AFP File Services to OES . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 53
5.1.1
About AFP File Services in OES 2 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 53
5.1.2
Platform Differences in AFP File Services . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 54
5.1.3
Planning to Transfer AFP Services . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 56
5.1.4
Upgrading AFP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 56
5.1.5
Post-Upgrade Checks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 57
Upgrading CIFS File Services to OES . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 57
5.2.1
About CIFS File Services in OES 2 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 57
5.2.2
Platform Differences in CIFS File Services . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 58
5.2.3
Planning to Upgrade CIFS Services . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 59
5.2.4
Upgrading CIFS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 60
5.2.5
Post-Upgrade Checks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 61
Upgrading Novell FTP to OES . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 61
5.3.1
About FTP File Services . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 61
5.3.2
Platform Differences in FTP File Services . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 61
5.3.3
Planning. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 61
5.3.4
Transferring FTP Services to OES . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 62
5.3.5
Post-Upgrade Checks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 62
Upgrading iFolder to OES . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 62
5.4.1
About iFolder on OES 2 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 62
5.4.2
Platform Differences in iFolder File Services . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 64
5.4.3
Planning. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 64
5.4.4
Upgrading iFolder . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 65
5.4.5
Post-Upgrade Checks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 65
Upgrading NetWare Core Protocol (NCP) File Services . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 65
5.5.1
About NCP File Services in OES 2 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 65
5.5.2
Planning to Upgrade NCP File Services . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 67
5.5.3
Only Data Transfers Are Required . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 68
Upgrading NetStorage . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 68
5.6.1
About NetStorage . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 68
5.6.2
Platform Differences in NetStorage File Services . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 70
5.6.3
NetStorage Is Not Transferred . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 71
6 Upgrading Print Services to OES
6.1
6.2
6.3
6.4
6.5
73
About iPrint. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 73
Platform Differences in iPrint . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 73
Planning to Upgrade iPrint to OES. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 73
6.3.1
Requirements and Recommendations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 74
6.3.2
Limitations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 74
Upgrading iPrint to OES . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 75
Additional Information . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 75
7 Upgrading QuickFinder to OES
7.1
7.2
7.3
7.4
7.5
77
About QuickFinder in OES 2 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 77
Platform Differences in QuickFinder . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 77
Planning to Upgrade QuickFinder . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 78
Upgrading QuickFinder to OES . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 78
Post-Upgrade Considerations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 78
8 Upgrading Backup Services to OES
8.1
8.2
79
Upgrading Novell Archive and Versioning Services to OES . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 79
8.1.1
About Archive and Versioning Services in OES 2 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 79
8.1.2
Platform Differences in Archive and Versioning Services . . . . . . . . . . . . . . . . . . . . . . . . . . 79
8.1.3
Planning to Upgrade Archive and Versioning Services . . . . . . . . . . . . . . . . . . . . . . . . . . . . 79
8.1.4
Upgrading Archive and Versioning Services . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 80
8.1.5
Post-Upgrade Procedures . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 80
About Upgrading Storage Management Services (SMS) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 80
9 Upgrading Network Services to OES
9.1
9.2
9.3
9.4
81
Upgrading DNS Services to OES. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 81
9.1.1
About Novell DNS in OES 2 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 81
9.1.2
Platform Differences in Novell DNS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 81
9.1.3
Planning to Upgrade Novell DNS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 81
9.1.4
Upgrading DNS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 82
Upgrading DHCP Services to OES . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 82
9.2.1
About Novell DHCP in OES 2 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 82
9.2.2
Platform Differences in Novell DHCP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 83
9.2.3
Planning to Upgrade Novell DHCP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 83
9.2.4
Upgrading DHCP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 83
Time Synchronization . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 83
9.3.1
About Time Synchronization in OES 2 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 83
9.3.2
Planning to Upgrade Time Synchronization Services . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 84
9.3.3
Transferring Time Synchronization Services . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 85
Service Location Protocol (SLP) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 85
9.4.1
About SLP in OES 2 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 85
9.4.2
Platform Differences in SLP Services . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 85
9.4.3
Setting Up SLP on OES 2 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 86
10 Upgrading Novell Cluster Services to OES
10.1
10.2
10.3
89
Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 89
Planning to Upgrade Novell Cluster Services . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 90
10.2.1 Reviewing the Current Cluster . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 90
10.2.2 Upgrading Novell Cluster Services to OES 2 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 90
10.2.3 Additional Information . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 91
Prerequisites . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 91
Contents
5
10.4
10.5
Caveats . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 92
Rolling Cluster Conversions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 92
11 Upgrading Other Novell Products to OES
11.1
11.2
11.3
GroupWise 7 and GroupWise 8 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 93
11.1.1 Source Platform Requirements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 93
11.1.2 Target Platform Requirements. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 93
11.1.3 Preparing to Migrate . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 94
11.1.4 Caveats . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 94
11.1.5 Tool Options . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 94
11.1.6 Migration Instructions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 95
11.1.7 Migrating GroupWise as Part of a Transfer ID Migration . . . . . . . . . . . . . . . . . . . . . . . . . . . 95
11.1.8 Additional Information . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 96
Identity Manager . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 97
ZENworks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 97
11.3.1 Upgrading to ZENworks 10 Configuration Manager . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 97
11.3.2 Migrating ZENworks 7 from NetWare to Linux . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 97
12 About Third-Party Applications
A Tools for Upgrading to OES 2 SP3
A.1
A.2
A.3
A.4
B.2
B.3
101
105
Novell iManager 2.7 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 105
B.1.1
What's New in Version 2.7 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 105
B.1.2
Supported Web Browsers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 106
B.1.3
Caveats . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 106
B.1.4
Upgrading to iManager 2.7 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 106
Novell Remote Manager (NRM) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 106
B.2.1
Prerequisites . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 107
B.2.2
About Novell Remote Manager and OES 2 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 107
About Other Management Tools . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 107
C Workstation Considerations
109
D Server Consolidation
111
E Examples
113
E.1
E.2
6
99
OES 2 SP3 Migration Tool . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 101
A.1.1
Consolidating Selected Data or Services . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 101
A.1.2
Transferring an Entire NetWare Server . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 102
A.1.3
More About Using the Migration Tool . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 102
Server Consolidation and Migration Tool (SCMT) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 103
NetWare Migration Wizard . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 103
Additional Information . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 103
B About the Management Tools in OES 2
B.1
93
Contents
Replica and CA Server Migration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 113
E.1.1
Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 113
E.1.2
FAQs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 114
E.1.3
Preparing and Transferring Your Replica Server. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 114
E.1.4
Post-Migration Configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 115
Cluster Migration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 115
E.3
E.2.1
Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 115
E.2.2
General Notes and Tips . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 116
E.2.3
Preparing to Migrate the Cluster . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 116
E.2.4
Transferring DHCP in the Cluster . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 117
E.2.5
Transferring DNS in a Cluster . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 118
E.2.6
iPrint Migration in a Cluster . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 120
E.2.7
Transferring AFP in a Cluster . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 122
E.2.8
Transferring CIFS in a Cluster . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 122
Server Identity Migration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 122
E.3.1
Preparing and Transferring Your Replica Server. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 123
E.3.2
Post-Migration Steps . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 124
F Documentation Updates
127
Contents
7
8
OES 2 SP3: Upgrading to OES—Best Practices Guide
About This Guide
Open Enterprise Server (OES) 2 SP3 is the next generation of the Novell® services that have long
been valued by a wide variety of businesses and other organizations, ranging from small businesses
to multi-national enterprises.
When you install OES 2 SP3, you install SUSE® Linux Enterprise Server (SLES) 10 SP4 as the core OS
and the OES 2 SP3 components as an “add-on product.”
OES
is
Novell Services
• AFP
• eDirectory
• Novell Client Access
• Backup (SMS)
• CIFS
• Management Tools
• Clustering (High Availability)
• FTP
• iPrint
• DNS/DHCP
• iFolder 3.x
• QuickFinder
• Domain Services for Windows
• NetStorage
• Novell Storage Services (NSS)
running
on
SUSE Linux Enterprise Server
What This Guide Provides
This guide provides an overview of the planning and implementation processes involved in
upgrading from NetWare® to OES 2 SP3. It provides overview and planning information along with
links to specific implementation instructions.
What This Guide Does Not Replace
This guide does not replace the specific upgrading and planning instructions found in the regular
installation and migration guides that you should follow carefully to ensure a successful upgrade to
OES.
Audience
This guide is intended for network administrators.
About This Guide
9
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 to enter your comments.
Documentation Updates
For the most recent version of this guide, see the OES 2 Documentation Web site (http://
www.novell.com/documentation/oes2/upgrade_to_oes_lx/data/front.html).
Documentation Conventions
In Novell documentation, a greater-than symbol (>) is used to separate actions within a step and
items in a cross-reference path.
A trademark symbol (®, ™, etc.) denotes a Novell trademark. An asterisk (*) denotes a third-party
trademark.
When a single pathname can be written with a backslash for some platforms or a forward slash for
other platforms, the pathname is presented with a backslash. Users of platforms that require a
forward slash, such as Linux* or UNIX*, should use forward slashes as required by your software.
10
OES 2 SP3: Upgrading to OES—Best Practices Guide
1
Frequently Asked Questions
1
You probably have a few questions up front. Here are some answers.
 Section 1.1, “Why Not Stay on NetWare?,” on page 11
 Section 1.2, “What About My Older NetWare Servers?,” on page 12
 Section 1.3, “What’s New in OES 2?,” on page 12
 Section 1.4, “What Do Novell Customers Recommend?,” on page 12
 Section 1.5, “What Are the Differences Between NetWare and OES 2?,” on page 14
 Section 1.6, “How Much Training Is Needed?,” on page 22
 Section 1.7, “What Training Is Available?,” on page 23
 Section 1.8, “Does Novell Have Community Support to Help Me with My Migration?,” on
page 24
1.1
Why Not Stay on NetWare?
There are distinct advantages to moving to OES 2 over staying on NetWare®. Gartner has issued
report (http://mediaproducts.gartner.com/reprints/novell/vol2/article4/article4.html) which you
should find enlightening. Novell has also published a technical white paper (http://www.novell.com/
rc/docrepository/public/37/basedocument.2009-03-19.8740935430/
OES%20v%20WIN%20FINAL_en.pdf) on this subject.
Here are a few of the benefits of upgrading to OES 2.
 NetWare Enters Extended Support in 2010: As Novell® has stated for a number of years now,
NetWare enters its extended support phase in 2010.
 Continued Hardware Support: When NetWare enters extended support, hardware vendors will
cease to certify it on new server hardware.
 Continued Third-party Solutions Support: As hardware vendors cease certification support,
third-party software solutions providers, such as anti-virus and backup software vendors, will
stop developing for the NetWare platform.
 Dynamic Storage Technology: This breakthrough Novell technology drastically reduces
storage costs and runs only on OES 2, not on NetWare. However, NSS volumes on NetWare can
be assigned as secondary volumes in a pair.
 iFolder 3.8: NetWare supports only Novell iFolder® 2.x, which lacks important features found
in the latest version, such as automatic server provisioning, multiple iFolders per user, iFolder
sharing between users, reassigning iFolder ownership, provisioning for LDAP groups, and
numerous administrative enhancements.
 Open Source Solutions: Open source initiatives such as Apache* and Tomcat* have been
supported on NetWare only as Novell or others have ported them to the platform, but they are
automatically available on OES.
Frequently Asked Questions
11
 Xen virtualization technology: This no-cost virtualization solution runs on OES 2 servers and
lets you create NetWare virtual machines for those services that you want to keep on NetWare
for the time being.
 Domain Services for Windows: This OES 2 technology integrates eDirectory™ and Active
Directory* users as well as Windows* and Novell file services.
 File Systems: OES 2 not only supports the Novell Storage Services™ (NSS) file system, but also
traditional Linux file systems, such as Ext3, XFS, and Reiser FS.
 OES Services enhancements: As Novell OES services continue to evolve, the new features and
technologies are almost always only available on OES 2.
1.2
What About My Older NetWare Servers?
Earlier versions of NetWare should be upgraded to OES 2 as outlined in Table 1-1.
Table 1-1 Upgrade Paths from Earlier Versions of NetWare
1.3
NetWare Version
Minimum DS
Version
Tool to Use
Other Information
NetWare 4.11 SP9
NDS® 6.21
n/a
You must perform a down-server
upgrade to NetWare 5.1 SP8 as an
interim step.
NetWare 4.2
NDS 6.21
n/a
You must perform a down-server
upgrade to NetWare 5.1 SP8 as an
interim step.
NetWare 5.0 SP6a
NDS 7.62c of 8.85c
n/a
You must perform a down-server
upgrade to NetWare 5.1 SP8 as an
interim step.
NetWare 5.1 SP8
eDirectory 8.7.3.7 or
later
OES 2 Migration Tool
For more information, see “Transfer ID
Migration” in the OES 2 SP3:
Migration Tool Administration Guide.
NetWare 6.0 SP5
eDirectory 8.7.3.7 or
later
OES 2 Migration Tool
For more information, see “Transfer ID
Migration” in the OES 2 SP3:
Migration Tool Administration Guide.
What’s New in OES 2?
The “What’s New or Changed” section in the OES 2 SP3: Planning and Implementation Guide includes
brief summaries of the new features and services in OES 2 plus a list of links to the What’s New
sections in each OES 2 guide. We recommend you take a few minutes to look at the section. The list is
quite impressive.
1.4
What Do Novell Customers Recommend?
Periodically, Novell polls customers to get a reality check. The table below summarizes customer
advice from a survey of OES 2 customers.
12
OES 2 SP3: Upgrading to OES—Best Practices Guide
Table 1-2 From a Recent Novell Customer Survey
Customer Tip
Learn basic Linux skills first (before starting) or have someone handy. Make sure you:
 Understand the Linux file system and rights.
For help, see “Understanding Directory Structures in Linux POSIX File Systems” in the OES 2 SP3:
File Systems Management Guide and “Aligning NCP and POSIX File Access Rights” in the OES 2
SP3: Planning and Implementation Guide
 Know Linux command line tools for the equivalent NetWare commands (DSTrace, DSRepair, etc.).
Learn the commands by setting up a test server and playing out the scenario you want to see on
your production server.
For help, see the OES2 SP3: Linux Tips for NetWare Administrators guide.
 Understand that in-house Linux expertise is a necessary prerequisite. (The good news is that fully
89% of survey respondents who have deployed OES 2 discovered that they already had Linux
expertise on their deployment teams.)
For help, see Section 1.6, “How Much Training Is Needed?,” on page 22 and Section 1.7, “What
Training Is Available?,” on page 23.
Plan ahead and know your NetWare, OES, and eDirectory environments very well:
 Make sure eDirectory is clean and that you are current on all patches.
 Plan the deployment scenario and find the holes and gotchas.
 Plan data locations, file systems, and LUM configuration objects.
 Perform a complete inventory of all applications (and their dependencies) before you get too far into
planning in case they or their dependencies can't be moved to OES/SLES.
Upgrade slowly and cautiously, but start now
 Start in small scale (a couple of servers) or just move DHCP for a couple of weeks, then DNS for a
couple of weeks, then GroupWise®, WebAccess, etc.
 Be careful; you can harm your OES production environment if you don't understand what you are
doing; don't start with your most important servers.
Test, test, test.
 Test everything multiple times, including third-party products like backup solutions, before full
deployment.
 Create an initial test box if you don't have previous Linux experience.
For help, see the OES 2 SP3: Getting Started with OES 2 and Virtualized NetWare.
 Use VMware* (or other virtualization products) and install many times to get the feel for it, then test,
test, test.
Give it a try.
 Moving to OES 2 is easy and relatively painless.
Start your upgrade in a lab environment first and play with the product.
Frequently Asked Questions
13
Customer Tip
 Try installing Linux at home and use it as your primary OS.
 Make sure you have a test environment that mimics your production installation.
It works the same as NetWare.
 The Novell management Interfaces look the same. iPrint, iManager, etc.—all of the benefits of
NetWare are available on OES 2.
Don't freak out about service and management differences
 Learn the iMonitor and iManager Web tools for service and server management.
 Become familiar with the basic management commands, such as ndsconfig for eDirectory
management.
Do your homework and read everything you can find.
 Scour the discussion forums and see what problems others are having and how they solved them,
ask questions, and make notes.
Avoid mixing OES 2 and NetWare, if possible.
 Create separate servers providing other services such as DNS, DHCP, etc., on OES first to gain
familiarity with Linux as a whole.
YaST is your friend.
 It's not always the answer, though. Learn which things are best configured in the configuration files
and which things you really should use YaST for.
Find out how well your hardware vendor supports Linux.
 Make sure your hardware vendor not only “supports Linux,” but also provides regular driver updates
for the version of SLES you are planning to deploy.
1.5
What Are the Differences Between NetWare and OES 2?
 Section 1.5.1, “System and Administrative User and Group Differences,” on page 14
 Section 1.5.2, “Comparing Services Between NetWare and OES 2,” on page 15
 Section 1.5.3, “Services Not Included in OES 2,” on page 21
1.5.1
System and Administrative User and Group Differences
Because OES 2 services run on Linux rather than on NetWare, there are noticable differences between
the system and administrative users and groups on OES 2 servers. For example, many OES 2 services,
Novell CIFS require proxy users to retrieve service-related information and service attributes, and in
some cases to write service information in eDirectory.
For more information, see “System User and Group Management in OES 2 SP3” and “Administrative
Users in OES 2 SP3” in the OES 2 SP3: Planning and Implementation Guide.
14
OES 2 SP3: Upgrading to OES—Best Practices Guide
1.5.2
Comparing Services Between NetWare and OES 2
Table 1-3 Service Comparison Between NetWare 6.5 SP8 and OES 2
Service
NetWare 6.5
SP8
OES 2
Platform Differences / Migration Issues
Access Control Lists
Yes
Yes
In combination with NCP™ Server, Linux
supports the Novell® trustee model for file
access on NSS volumes and NCP volumes
on Linux.
AFP (Apple* File
Protocol)
Yes - NFAP
Yes - Novell
AFP
AFP services on NetWare and OES are
proprietary and tightly integrated with
eDirectory™ and Novell Storage Services
(NSS).
Apache Web Server
Yes - NetWare® Yes - Standard Administration Instance vs. Public Instance
port of open
Linux
on NetWare (http://www.novell.com/
source product
documentation/nw65/web_apache_nw/
data/aipcu6x.html#aipcu6x).
What’s Different about Apache on NetWare
(http://www.novell.com/documentation/
nw65/web_apache_nw/data/ail8hvj.html) .
Archive and Version
Services (Novell)
Yes
Yes
Setup varies slightly, but there are no
functional differences.
Backup (SMS)
Yes
Yes
SMS provides backup applications with a
framework to develop complete backup and
restore solutions. For information, see the
OES 2 SP3: Storage Management Services
Administration Guide for Linux.
 SMS
 NSS-Xattr
NSS provides extended attribute handling
options for NSS on Linux. For information,
see “Using Extended Attributes (xAttr)
Commands” in the OES 2 SP3: NSS File
System Administration Guide for Linux.
CIFS (Windows File
Services)
Yes - NFAP
Yes - Novell
CIFS
and
Novell Samba
Both NFAP and Novell CIFS are Novell
proprietary and tightly integrated with
eDirectory and Novell Storage Services
(NSS).
Samba is an open source product
distributed with SUSE® Linux Enterprise
Server (SLES).
Novell Samba is enhanced by Novell with
configuration settings for eDirectory LDAP
authentication via Linux User Management
(LUM). Novell Samba is not tightly
integrated with NSS on Linux and works
with any of the “File Systems Available on
OES 2 Servers.” (See the OES 2 SP3:
Planning and Implementation Guide.)
Frequently Asked Questions
15
Service
NetWare 6.5
SP8
OES 2
Platform Differences / Migration Issues
Clustering
Yes
Yes
“Product Features” in the OES 2 SP3:
Novell Cluster Services 1.8.8 Administration
Guide for Linux.
“Product Features” in the NW6.5 SP8:
Novell Cluster Services 1.8.5 Administration
Guide.
DFS (Novell Distributed Yes
File Services)
Yes
In combination with NCP Server, DFS
supports junctions and junction targets for
NSS volumes on Linux and NetWare. DFS
also supports junction targets for NCP
volumes on non-NSS file systems such as
Reiser and Ext3. The VLDB command
offers additional options to manage entries
in the VLDB for NCP volumes.
DHCP
Yes
For a comparison between what is available
on OES 2 and NetWare, see “DHCP
Differences Between NetWare and OES 2”
in the OES 2 SP3: Planning and
Implementation Guide.
Yes
To plan your DHCP implementations, see
“Planning a DHCP Strategy” in the OES 2
SP3: Novell DNS/DHCP Administration
Guide and “Planning a DHCP Strategy” in
the NW 6.5 SP8: Novell DNS/DHCP
Services Administration Guide.
DNS
Yes
Yes
For a comparison between what is available
on OES 2 and NetWare, see “DNS
Differences Between NetWare and OES 2”
in the OES 2 SP3: Planning and
Implementation Guide.
See “Planning a DNS Strategy” in the OES
2 SP3: Novell DNS/DHCP Administration
Guide and “Planning a DNS Strategy” in the
NW 6.5 SP8: Novell DNS/DHCP Services
Administration Guide.
16
Dynamic Storage
Technology
No
Yes
DST runs on OES 2. An NSS volume on
NetWare is supported only as the
secondary volume in a shadow pair. When
using DST in a cluster, each of the NSS
volumes in a shadow pair must reside on
OES 2.
eDirectory 8.8
Yes
Yes
No functional differences.
eDirectory Certificate
Server
Yes
Yes
No functional differences.
OES 2 SP3: Upgrading to OES—Best Practices Guide
Service
NetWare 6.5
SP8
OES 2
Platform Differences / Migration Issues
eGuide (White Pages)
Yes
No
This functionality is now part of the Identity
Manager 3.6 User Application. For more
information, see the Identity Manager 3.6
Documentation Web Site. (http://
www.novell.com/documentation/idm36/
index.html).
FTP Server
Yes
Yes
Support for eDirectory LDAP authentication
has been added to PureFTP on OES 2. The
FTP/SFTP gateway available on NetWare is
not currently available on Linux. See “FTP
Services”.
See “Features of the NetWare FTP Server”
in the NW 6.5 SP8: Novell FTP
Administration Guide.
Health Monitoring
Services
Yes
Yes
The Health Monitoring Server, which was
included in OES 1, has been removed in
OES 2.
This is now available in various Novell
Remote Manager dialog boxes on both
platforms.
For more information, see “Health
Monitoring Services” in the OES 2 SP3:
Planning and Implementation Guide.
Identity Manager 3.6.1
Bundle Edition
No
Yes
IDM 3.6.1 is not available on NetWare.
iPrint
Yes
Yes
See “Overview” in the OES 2 SP3: iPrint for
Linux Administration Guide, and “Overview”
in the NW 6.5 SP8: iPrint Administration
Guide.
IPX™ (Internetwork
Packet Exchange™)
from Novell
Yes
No
Novell has no plans to port IPX to OES.
iSCSI
Yes
Yes
The iSCSI target for Linux does not support
eDirectory access controls like the NetWare
target does. Nor is the iSCSI initiator or
target in OES 2 integrated with NetWare
Remote Manager management. You use
YaST management tools instead.
On the other hand, the iSCSI
implementation for Linux is newer and
performs better.
See Linux-iSCSI Project on the Web (http://
linux-iscsi.sourceforge.net).
See “Overview” in the NW 6.5 SP8: iSCSI
1.1.3 Administration Guide.
LDAP Server for
eDirectory
Yes
Yes
No functional differences.
Frequently Asked Questions
17
NetWare 6.5
SP8
OES 2
Platform Differences / Migration Issues
Multipath Device
Management
Yes
Yes
NetWare uses NSS multipath I/O. Linux
uses Device Mapper - Multipath that runs
underneath other device management
services.
MySQL*
Yes - NetWare
port of open
source product
Yes - Standard See MySQL.com on the Web (http://
Linux
www.mysql.com).
No
Yes
Service
NCP Volumes
See “Overview: MySQL” in the NW 6.5 SP8:
Novell MySQL Administration Guide.
NCP Server on Linux supports creating
NCP volumes on Linux POSIX file systems
such as Reiser and Ext3.
For information, see “Managing NCP
Volumes” in the OES 2 SP3: NCP Server for
Linux Administration Guide.
NCP Server
Yes
Yes
NCP services are native to NetWare 6.5
and NSS volumes; to have NCP services on
OES, the NCP Server must be installed.
See “Benefits of NCP Server” in the OES 2
SP3: NCP Server for Linux Administration
Guide.
NetStorage
Yes
Yes
NetStorage on Linux offers connectivity to
storage locations through the CIFS, NCP,
and SSH protocols. NetWare uses only
NCP.
These and other differences are
summarized in “NetStorage” in the OES 2
SP3: Planning and Implementation Guide.
18
NetWare Traditional
File System
Yes
No
NetWare Traditional
Volumes
Yes
N/A
NFS
Yes - NFAP
Yes - native to
Linux
For NetWare, see “Working with UNIX
Machines” in the NW 6.5 SP8: AFP, CIFS,
and NFS (NFAP) Administration Guide.
NICI (Novell
International
Cryptography
Infrastructure)
Yes
Yes
No functional differences.
NMAS™ (Novell
Yes
Modular Authentication
Services)
Yes
No functional differences.
Novell Audit
No
Novell Audit is not included with OES.
However, the Novell Audit 2.0 Starter pack
is available for download at no cost on
Novell.com (http://www.novell.com/
downloads).
Yes
OES 2 SP3: Upgrading to OES—Best Practices Guide
Novell has no plans to port the NetWare
Traditional File System to Linux.
NetWare 6.5
SP8
OES 2
Platform Differences / Migration Issues
Novell Client™ for
Windows and Linux
support
Yes
Yes
Novell Client connectivity to OES 2 requires
that the NCP Server be installed.
Novell Cluster
Services™
Yes
Yes
See “Product Features” in the OES 2 SP3:
Novell Cluster Services 1.8.8 Administration
Guide for Linux.
Service
See “Product Features” in the NW6.5 SP8:
Novell Cluster Services 1.8.5 Administration
Guide.
Novell iFolder® 2.x
Yes
No
For migration information, see “Migrating
iFolder 2.x” in the OES 2 SP3: Migration
Tool Administration Guide
Novell iFolder 3.8
No
Yes
OES 2 includes Linux, Macintosh*, and
Windows clients.
Novell Licensing
Services
Yes
No
See “OES 2 Doesn’t Support NLS” in the
OES 2 SP3: Planning and Implementation
Guide.
NSS (Novell Storage
Services™)
Yes
Yes
Most NSS services are available on both
platforms. For a list of NSS features that are
not used on Linux, see “Cross-Platform
Issues for NSS” in the OES 2 SP3: NSS File
System Administration Guide for Linux.
NTPv3
Yes
Yes
The ntpd.conf file on NetWare can
replace an OES server’s NTP configuration
file without modification.
OpenSSH
Yes
Yes
Netware includes a port of the open source
product. Linux includes the open source
product itself.
See “Functions Unique to the NetWare
Platform” in the NW 6.5 SP8: OpenSSH
Administration Guide.
PAM (Pluggable
Authentication
Modules)
No
Yes
PAM is a Linux service that Novell
leverages to provide eDirectory
authentication. eDirectory authentication is
native on NetWare.
Pervasive.SQL*
Yes
No
Pervasive.SQL is available for Linux from
the Web (http://docs.pervasive.com/
products/database/psqlv11/wwhelp/
wwhimpl/js/html/
wwhelp.htm#href=welcome/
libwelcome.html).
PKI (Public Key
Infrastructure)
Yes
Yes
No functional differences.
Printing
Yes
Yes
See “iPrint” in the OES 2 SP3: Planning and
Implementation Guide.
QuickFinder™
Yes
Yes
Frequently Asked Questions
19
Service
NetWare 6.5
SP8
OES 2
Platform Differences / Migration Issues
RADIUS
Yes
Yes
See the information on forge.novell.com
(http://forge.novell.com/modules/xfmod/
project/?edirfreeradius).
Samba
No
Yes
Samba is an open source technology
available on OES. Novell provides
automatic configuration for authentication
through eDirectory. For more information,
see the OES2 SP3: Samba Administration
Guide.
Search (QuickFinder)
Yes
Yes
When indexing a file system, the
QuickFinder engine indexes only what it has
rights to see.
On NetWare, it has full access to all
mounted volumes. On Linux, it has rights to
only the files that the novlwww user in the
www group has rights to see.
For more information, see “Security
Characteristics” and “Generating an Index
For a Linux-Mounted NSS Volume” in the
OES 2 SP3: Novell QuickFinder Server 5.0
Administration Guide.
SLP
Yes - Novell
SLP
Yes - OpenSLP For OES 2, see “SLP Services in the
Network” (http://www.novell.com/
documentation/sles10/book_sle_reference/
data/cha_slp.html) in the SLES 10 SP4:
Installation and Administration Guide (http://
www.novell.com/documentation/sles10/
book_sle_reference/data/
book_sle_reference.html) and
“Implementing the Service Location
Protocol” (http://www.novell.com/
documentation/edir87/edir87/data/
a2iiimc.html).
NetWare uses Novell SLP, which provides
caching of Directory Agent scope
information in eDirectory. This provides for
sharing of scope information among DAs.
Novell SLP is not available on Linux.
OpenSLP on Linux is not customized to
provide DA synchronization. Therefore, DA
synchronization is only available for
eDirectory on NetWare.
Software RAIDS (NSS
volumes)
20
Yes (0, 1, 5, 10, Yes (0, 1, 5)
15)
OES 2 SP3: Upgrading to OES—Best Practices Guide
See “Understanding Software RAID
Devices” in the OES 2 SP3: NSS File
System Administration Guide for Linux.
Service
Storage Management
Services™ (SMS)
NetWare 6.5
SP8
OES 2
Platform Differences / Migration Issues
Yes
Yes
No functional differences, except that the
SBCON backup engine is not supported on
Linux.
The nbackup engine is available for
exploring SMS capabilities, but in a
production environment, you should use a
third-party, full-featured backup engine.
TCP/IP
Yes
Yes
No functional differences.
Timesync NLM™
Yes
No
Timesync will not be ported to Linux.
However, NTPv3 is available on both Linux
and NetWare.
See “Time Services” in the OES 2 SP3:
Planning and Implementation Guide.
Tomcat
Yes
Yes
NetWare includes Tomcat 4 and a Tomcat 5
servlet container for iManager 2.7. OES 2
includes Tomcat 5. There is no impact to
any of the OES 2 administration tools, which
are tested and supported on both platforms.
See “Administration Instance vs. Public
Instance on NetWare” (http://
www.novell.com/documentation/nw65/
web_tomcat_nw/data/
ahdyran.html#ahdyran)
1.5.3
Virtual Office
(Collaboration)
Yes
No
WAN Traffic Manager
Yes
No
Xen Virtualization
Guest
Yes
Yes
Xen Virtualization Host
Server
N/A
Yes
Virtual Office has been replaced by Novell
Teaming + Conferencing. A separate
purchase is required. For more information,
see the Novell Teaming + Conferencing
Web Site (http://www.novell.com/products/
teaming/index.html).
NetWare 6.5 SP8 (and NetWare 6.5 SP 7)
can run on a paravirtualized machine. OES
2 can run on a paravirtualized machine or
fully virtualized machine.
Services Not Included in OES 2
See “eGuide, IFolder 2, and Virtual Office Are Still Available on Netware” in the NW 6.5 SP8:
Planning and Implementation Guide.
Frequently Asked Questions
21
1.6
How Much Training Is Needed?
 Section 1.6.1, “What Our Customers Tell Us,” on page 22
 Section 1.6.2, “Conduct a Training Assessment,” on page 22
1.6.1
What Our Customers Tell Us
Some customers have found that their administrators need Linux training. Novell provides several
training courses to help bring administers up to speed with administering OES services on Linux.
Familiar tools, such as iManager and Novell Remote Manager (NRM), and utilities such as NSSMU
are also used to administer Novell services on OES 2. Many administrators are pleasantly surprised
when they see that their knowledge and skills apply very well to managing Novell services on OES 2.
We recognize that time and resources are a problem for customers, and we recommend following the
example of one of our customers: Four months prior to rollout, Novell provided OES and SLES
training for their administrators at their site and on their hardware and software.
When we survey customers, they consistently tell us they want training that addresses:
 Differences in day-to-day support and management versus NetWare
 How to install and upgrade existing NetWare servers to OES 2
 Differences between NetWare and OES: services, features, and interoperability
 Troubleshooting
1.6.2
Conduct a Training Assessment
Novell recommends that you conduct a training needs assessment. You should determine whether
current skill sets are absent, adequate, or proficient, so that you can recommend a training package.
Three levels of Linux expertise are recommended:
Table 1-4 Recommended Linux Training Levels
Level of Expertise
Training Needed
Certified Linux Expert
You will probably want at least some of
your technical staff to be Linux certified
(LPI level1 and/or LPI level 2). Many
third-party Linux certification courses
are available to meet this need.
Qualities of Potential Candidates
 Are typically already UNIX (AIX*,
Solaris*, etc.) experts.
 Have some Linux experience.
 Are willing to attend additional
class and lab sessions.
 Are willing to serve as trainers
and mentors.
 Have accredited certifications.
22
OES 2 SP3: Upgrading to OES—Best Practices Guide
Level of Expertise
Training Needed
Linux Administrator
Novell recommends SUSE Linuxspecific training.
Novell offers a variety of instructor-led
and self-study certification and training
options including Novell Advanced
Technical Training (ATT), which is
highly recommend.
Qualities of Potential Candidates
 Are currently UNIX or NetWare
administrators who are willing to
expand skills
 Have data center and server farm
administrative experience. Deep
technical skills are less important.
 Have expertise in services above
the OS level. OS knowledge is
necessary.
The comprehensive courses address a
wide range of advanced topics
including support issues, in-depth
architectural reviews, and enterprise
solutions. ATT classes provide realworld expertise that can be put to
immediate use.
Linux Support Staff
Support staff need to be
knowledgeable about how specific
network services (eDirectory, edge
services, iPrint, etc.) work on Linux.
 Support current file, print, and
other network systems.
 Will need to move to more Linux
Novell offers service-specific courses
for most major services.
1.7
support, but system focus will
remain the same.
What Training Is Available?
Here are some of the avenues you can use to get the training you need:
 Section 1.7.1, “Novell Training Services,” on page 23
 Section 1.7.2, “Complimentary Free Training,” on page 24
 Section 1.7.3, “Product Documentation,” on page 24
1.7.1
Novell Training Services
Novell certification and training options change periodically as new needs are identified and courses
are developed. To learn more about these and other training options, visit the OES Novell training
Web site at www.novell.com/training (http://www.novell.com/training/courseware/
catalog.jsp?pl=7660).
 To find the dates and local availability of the Novell Advanced Technical Training and other
Novell offerings, go to: www.novell.com/training/pep/map.html (http://www.novell.com/
training/att/map.html).
 To request additional information on Novell Advanced Technical Training, send an e-mail to
[email protected] (mailto:[email protected])
 To subscribe to the Technical Training Newsletter, see http://www.novell.com/info/list (http://
www.novell.com/company/subscribe/)
Frequently Asked Questions
23
1.7.2
Complimentary Free Training
For a good introduction to OES, see Bridging NetWare Skills to Novell Open Enterprise Server for
Linux (http://www.novell.com/training/promotions/netwaretolinux/modules.html)
To help you get started with OES and Linux, Novell also provides some training material at no cost
on the Web (http://www.novell.com/training/complimentary/).
1.7.3
Product Documentation
Yes, the old adage is true: “If all else fails, read the documentation.” This document contains
numerous cross-references to sections relative to a specific topic or service. If you can't find what you
need on Novell's documentation site, add a comment, tell us what we missed, and we'll see that you
get the answer you need. Open Enterprise 2 documentation is available at the following URL: http://
www.novell.com/documentation/oes2/index.html (http://www.novell.com/documentation/oes2/
index.html).
One especially useful guide for those who are transitioning from NetWare to OES and Linux is the
OES2 SP3: Linux Tips for NetWare Administrators guide. Novell partner BrainStorm, Inc. (http://
www.brainstorminc.com/oes) provides a printed Administrator’s Command Reference card based
on the tips guide; it shows common NetWare commands and their OES/Linux counterparts. This
reference card is nicely formatted and very helpful in bridging the gap between NetWare and OES/
Linux commands.
And finally, Novell also publishes all of the SLES 10 documentation on the Web (http://
www.novell.com/documentation/sles10/index.html).
1.8
Does Novell Have Community Support to Help Me with My
Migration?
There are a two good places to connect with other administrators, ask questions, and find answers to
your specific migration questions.
 Novell Forums (http://forums.novell.com/)
 Cool Solutions Upgrade to OES Community Page (http://www.novell.com/communities/
coolsolutions/upgradetooes)
There is a list of the top TIDs (http://www.novell.com/communities/node/8781/top-oes-upgrade-tids)
to help you troubleshoot and deal with migration issues.
Finally, you can get OES information from Twitter by following NovellOES (http://www.twitter.com/
novelloes), and there’s a FaceBook Page (http://www.facebook.com/
desktopapp.php?api_key=97e8a45d27cbe2bd96a957cb9cd22f10#/pages/I-Upgraded-to-Novell-OpenEnterprise-Server-on-SUSE-Linux-Enterprise/154405544072?ref=ts) as well.
24
OES 2 SP3: Upgrading to OES—Best Practices Guide
2
Getting Started
2
You can ensure a successful upgrade by
 Section 2.1, “Assessing Your Current Network,” on page 25
 Section 2.2, “Identifying Needed Improvements,” on page 27
2.1
Assessing Your Current Network
 Section 2.1.1, “Running Novell Support Advisor,” on page 25
 Section 2.1.2, “Recording Your Current Network Information,” on page 25
2.1.1
Running Novell Support Advisor
To ensure you are equipped with the latest pre-upgrade information and area aware of known issues,
we recommend you validate your OES upgrade readiness using the Novell Support Advisor 1.1 (or
later) tool. For more information and to obtain this free tool, access the Novell Support Advisor Web
page (http://support.novell.com/advisor).
2.1.2
Recording Your Current Network Information
Whether you will be upgrading on your own, using Novell® Global Services, or working with
another consulting firm, you need a complete and accurate record of your current network setup.
1 If you don’t already have one, create one or more diagrams of your network, including the
following information:
 Router/switch/subnet/firewall diagrams; note particularly any blocked ports
 Current WAN configuration, including link speeds for all sites running NetWare®.
Duplicate the following tables or use a spreadsheet, as necessary, to accommodate multiple
sites.
Getting Started
25
Table 2-1 Sample WAN Environment Overview
Site Location
WAN Speed
# of Servers
Server Breakdown
Home Office
Local
25
3-NW4.11
3-NW5.0
4-NW5.1
3-NW6.0
3-NW6.5
5-W2K3
2-W2K
2-RHEL3
Table 2-2 Sample WAN Location Environment Overview
Site
Location
Southwest
Office
# of
NetWar NetWare
e
Versions
Servers
6
2-NW4.11
1-NW5.1
3-NW6.5
Server Notes
# of
Client
s
All NetWare are 30
being retired.
Users will be
moved to OES 2
servers
Client
Client Notes
Breakdown
4–Win98
6-W2K
20-WinXP
Win9x clients will
be migrated to
Windows XP
Professional SP2
2 If you don’t already have a current directory design document, create one that includes:
 NDS®/eDirectory™ tree diagrams.
 Partition and replication diagrams.
 NDS versions, such as NDS v6, v7, and/or v8.
 Versions of NDS/eDirectory that are installed on non-NetWare operating systems.
 Other Novell applications that are directly dependent on eDirectory, such as Novell
Account Management, DirXML®, and Identity Manager.
 Any bindery contexts currently in use, including a brief description of how they are used.
3 List all of the NetWare servers in your tree along with their context, IP address information, and
any other information you might need as you plan to migrate them.
4 Identify any NetWare traditional (non-NSS) volumes being used on your NetWare servers.
5 Identify the file services provided by NetWare servers, including AFP, CIFS, iFolder, NetStorage,
FTP, and NCP™ (Novell Client™), then list the servers that provide them and the contexts of the
users that use them.
26
OES 2 SP3: Upgrading to OES—Best Practices Guide
6 Identify the printers that are serviced by NetWare servers, along with the print services
associated with them, including iPrint, NDPS-based printing, and legacy queue-based printing.
7 Identify any in-house applications developed specifically for NetWare and briefly describe the
services that these provide.
8 Identify other Novell products, such as GroupWise®, ZENWorks®, or Identity Manager that are
currently running on NetWare, and verify which of these are supported on OES 2 SP3.
9 Document how your e-mail infrastructure is currently set up.
10 Identify any third-party applications currently running on the NetWare servers, such as backup/
restore and anti-virus solutions.
Verify with the vendors whether these applications are supported on SLES 10/OES 2 SP3 and
whether they are Novell YES Approved.
Specify which applications will be ported to OES 2 SP3 and which must continue to run on
NetWare for the time being.
11 List any databases (critical or otherwise) that are stored on NetWare servers.
12 Create a design document that outlines your network service configurations, including time
synchronization, SLP, DNS, DHCP, and any other network protocols or services that might be
impacted by an upgrade to OES, such as IPX™.
13 Collect any standards documents you have, such as server standards and naming standards.
14 Collect or document the hardware information for your NetWare servers, including processor
specs, RAM configuration and storage adapters.
15 Document any NetWare clusters in your network, both Novell Clustering Services™ clusters
and Business Continuity Clustering clusters. Specify the function of each cluster node, including
service failover configurations.
16 Specify any security standards that must be met on OES/Linux. Unlike NetWare, Linux security
is much more modular/granular.
The tables in the next section suggest additional information you might need to collect before you
begin planning your upgrade to OES.
2.2
Identifying Needed Improvements
 Section 2.2.1, “Server Hardware Considerations,” on page 28
 Section 2.2.2, “Consolidation Considerations,” on page 29
 Section 2.2.3, “Virtualization Considerations,” on page 29
 Section 2.2.4, “File System Considerations,” on page 30
 Section 2.2.5, “Method Considerations,” on page 30
 Section 2.2.6, “Network Considerations,” on page 30
 Section 2.2.7, “eDirectory/LDAP Considerations,” on page 30
 Section 2.2.8, “Time Synchronization,” on page 31
 Section 2.2.9, “Cluster Considerations,” on page 31
 Section 2.2.10, “Application Compatibility Considerations,” on page 31
 Section 2.2.11, “LAN/WAN Connection Considerations,” on page 32
Getting Started
27
2.2.1
Server Hardware Considerations
How is your server hardware holding up? Do you need to invest in some new hardware for the
upgrade to OES 2 SP3 to succeed?
Many customers tell us that choosing the right hardware is not a straightforward task.
Your best bet is to start with the Novell OES Partner Products page (http://www.novell.com/
partnerguide/section/677.html), particularly the Server Hardware List (http://www.novell.com/
partnerguide/section/677.html#c_531).
If you don’t already have an agreement with a hardware vendor, all Novell Partners deserve
consideration. Be sure to communicate with your chosen hardware vendors regarding server sizing
guidelines to ensure that you select the right server and hardware configuration.
Table 2-3 outlines both “minimum” and “recommended” requirements for running OES 2 SP3.
NOTE: The RAM and disk space amounts shown in Table 2-3 are for system components only. The
OES 2 components you install might require additional RAM and disk space.
Table 2-3 Minimum and Recommended Hardware Requirements
System
Compone
nt
Minimum
Recommended
Server-class computer
with Intel Pentium* II or
AMD * K7 450 MHz
processor
Server-class computer that has been certified by the hardware
vendor for SLES 10 SP4.
Memory
1 GB of RAM
2 GB of RAM
Free Disk
Space
10 GB of available,
unpartitioned disk
space.
20 GB of available, unpartitioned disk space. Additional disk
space might be required depending on which OES components
are selected and how they are used.
CD-ROM
Drive
4X CD-ROM or DVD
drive if installing from
physical media
48X CD-ROM drive or DVD drive if installing from physical media.
Network
Board
Ethernet 100 Mbps
Storage
Adapter
N/A
Computer
Pentium III, Pentium III Xeon *, Pentium 4, Intel * Xeon 700 MHz,
AMD K8 CPUs (Athlon* 64 and Opteron*), Intel EM64T or higher
processor.
When determining what hardware bus adapters (HBAs) to use for
SAN-attached OES 2 servers, take all of the software and
hardware components into account. Linux drivers are available
for almost all enterprise-class HBAs and many of them are OES
2 certified.
However, hardware vendors tend to be more restrictive with
certification than the operating system is. Any HBA used with
OES 2 must be certified by both the storage vendor for a specific
model as well as the Fibre Channel switch vendor.
28
OES 2 SP3: Upgrading to OES—Best Practices Guide
System
Compone
nt
IP Address
Minimum
Recommended
 One IP address on Internet connectivity from the server in order to complete
a subnet
registration and configure patches
 Subnet mask
 Default gateway
2.2.2
Mouse
N/A
Server
Computer
BIOS
If you are doing a CDROM installation,
prepare the BIOS on
your server computer so
that it boots from the
CD-ROM drive first.
USB or PS/2
Consolidation Considerations
This might be a good time to consider taking advantage of today's more powerful hardware
platforms and doing some server consolidation. Server consolidation often pays off in lower
hardware costs, as well as lower cooling, power consumption, and rack space costs. For example,
Novell recently consolidated fourteen older file and print servers to two new servers.
Which combinations of eDirectory, file, print, GroupWise, WebAccess, etc., might reasonably work
together on the same host server?
2.2.3
Virtualization Considerations
To help with the transition from NetWare to OES 2, virtualization has been optimized in OES 2 so
that you can run NetWare 6.5. SP7 and later as a paravirtualized guest operating system on OES
servers.
Doing this provides another option for running NetWare-dependent applications and services. For
example, most third-party NLM™ software can be accommodated this way until suitable alternatives
can be developed for Linux.
Which NetWare-dependent applications and services will you need to run on an interim basis as part
of your transition to OES 2? Will virtualization help with this?
Installing Hosts: For information about installing a virtual machine host and setting up virtual
machines in general, see Virtualization with Xen (http://www.novell.com/documentation/sles10/
xen_admin/data/bookinfo.html), particularly “Setting Up Virtual Machines” (http://
www.novell.com/documentation/sles10/xen_admin/data/xen_virtualization_vm.html).
Installing Guest Operating Systems: For information about installing NetWare as a guest operating
system, see “Installing and Managing NetWare on a Xen-based VM” in the OES 2 SP3: Installation
Guide. For information about installing OES 2 SP3 as a guest operating system, “Installing,
Upgrading, or Updating OES on a Xen-based VM” in the OES 2 SP3: Installation Guide.
Getting Started
29
2.2.4
File System Considerations
Which file system should be used: Linux traditional volumes (ReiserFS and ext3), NSS, or another file
system?
 Does it make sense to have different servers using different file systems depending on the
server's primary role?
 Are you already using Novell Storage Services™ (NSS) volumes on NetWare?
If so, you should probably preserve all the rights, metadata, and trustee information associated
with the data on those volumes, so it makes sense to stay with Novell Storage Services.
 Are your volumes already in a SAN environment with NSS?
If so, switching to a SAN environment that uses NSS on Linux is quite easy. Using DFS junctions
also requires NSS to support volume moves and splits. And if business continuity clusters are in
your plans, you might find them easier to implement if you're using NSS.
NOTE: For Groupwise under Linux, the recommended filesystem for GW7 was reiserfs (http://
www.novell.com/documentation/gw7/gw7_install/data/b3kipez.html#b77qw4a) and the
recommended filesystem for GW8 is ext3 (http://www.novell.com/documentation/gw8/
gw8_install/data/b3kipez.html#b77qw4a).
2.2.5
Method Considerations
Which of the various tools best meets your needs? Knowing which tools you will use is important to
planning your upgrade strategy.
2.2.6
Network Considerations
Is the network functioning optimally, or do you need to make changes before you upgrade?
Are required ports available?
Make sure that services such as DNS, DHCP, and SLP are optimally configured and in good working
order. This is critical for all installations and upgrades.
2.2.7
eDirectory/LDAP Considerations
Is the eDirectory partition and replication layout optimal:
 Where are the replica rings located?
 Which servers have partitions on them?
 Where do your want replication rings and partitions to be after you finish your upgrade to OES?
If you fail to plan properly in this area, you can count on running into network replication
problems. Refer to the Novell eDirectory 8.8 Administration Guide, particularly “Designing Your
Novell eDirectory Network” for detailed information.
 If your current eDirectory tree structure doesn’t meet your needs, is it time to redesign it?
Novell recommends implementing multiple LDAP servers because of the critical nature of the LDAP
service. LDAP servers should be fronted with an L4 switch for load sharing and redundancy. If an L4
switch is not available, then DNS round-robin could be used as an alternative.
30
OES 2 SP3: Upgrading to OES—Best Practices Guide
2.2.8
Time Synchronization
Is time synchronization on your network in order?
 Are all NetWare virtual machines using Timesync rather than NTP?
 Is the TCP/IP protocol is loaded on any physical NetWare servers that use NTP?
 Is only one server used as the ultimate time source?
NTP uses a time provider group in which all servers in a geographical network obtain time from
other servers in the same network. Only one network server should communicate with a server
outside the network in order to keep traffic across routers and WANs at a minimum.
To understand time synchronization requirements and possibilities in an OES 2 network, see “Time
Services” in the OES 2 SP3: Planning and Implementation Guide.
2.2.9
Cluster Considerations
If clusters are part of your plan, how will your cluster environment impact your efforts to upgrade to
OES?
 What is the primary role of your cluster (GroupWise high availability, file and print services,
directory services)?
 Do you need to consider splitting large clusters into multiple smaller clusters, one for each
service?
By separating clusters this way, problems in one service cluster won't spill over and potentially
affect other clustered services.
Splitting your clusters can also simplify administration efforts, because you can independently
manage each cluster. Also, if you need to do a cluster update, a rolling upgrade of a six-node
cluster is much easier than a rolling upgrade of a 32-node cluster.
 Are you planning to implement Novell Business Continuity Clustering to allow automated
management of site-to-site failovers? If so, how will this affect your efforts and will your
network topology be affected? Business Continuity Clustering lets you define which of your
resources are considered “vital,” so only those services move to an off-site location rather than
the entire cluster.
 Will a rolling upgrade help you upgrade your clustered services?
Refer to the “Upgrading OES 2 Clusters (Rolling Cluster Upgrade)” in the OES 2 SP3: Novell
Cluster Services 1.8.8 Administration Guide for Linux for detailed information.
2.2.10
Application Compatibility Considerations
What applications are currently hosted on your NetWare servers? Are comparable Linux applications
available and are they certified for OES 2 or SLES 10?
Because of the multitude of applications being used by our customers, it is impossible for Novell to
make recommendations in every instance, so you might need to contact the vendor directly. But first
check the Novell Partner Products site (http://www.novell.com/partnerguide/section/677.html) for
the latest certifications.
Getting Started
31
2.2.11
LAN/WAN Connection Considerations
Is the performance of all of your WAN links within acceptable limits? Are there any indications of
systemic problems? Are all replica rings maintaining proper synchronization?
It is essential that all of your LAN/WAN connections be performing within the expected parameters
before you begin your upgrade to OES.
32
OES 2 SP3: Upgrading to OES—Best Practices Guide
3
Upgrading eDirectory to OES
3
This section discusses upgrading eDirectory™ to OES 2 and includes the following sections:
 Section 3.1, “About eDirectory in OES 2,” on page 33
 Section 3.2, “Planning Your eDirectory Upgrade,” on page 36
 Section 3.3, “Upgrading eDirectory,” on page 40
 Section 3.4, “Post-Upgrade Checks,” on page 42
 Section 3.5, “About Domain Services for Windows,” on page 42
 Section 3.6, “Additional eDirectory Resources,” on page 45
3.1
About eDirectory in OES 2
 Section 3.1.1, “The Role of eDirectory in OES 2,” on page 33
 Section 3.1.2, “eDirectory Version Considerations,” on page 34
 Section 3.1.3, “About eDirectory Management Tools in OES 2,” on page 35
3.1.1
The Role of eDirectory in OES 2
 “eDirectory Is Essential to OES 2 Services” on page 33
 “About Installing eDirectory and OES Services” on page 34
 “The First Server Is Critical” on page 34
 “eDirectory Provides Additional Security for the Server” on page 34
eDirectory Is Essential to OES 2 Services
eDirectory is an integral component of the services that make up OES 2. As with NetWare®, service
users are created as User objects in eDirectory and authenticate to gain service access.
OES servers exist as Server objects and there are numerous other objects and configurations stored
“behind the scenes” in eDirectory that work together to deliver the same functionality that people are
accustomed to with NetWare.
eDirectory even provides eDirectory users with access to some services that would normally require
the creation of local user accounts on the server itself.
Upgrading eDirectory to OES
33
About Installing eDirectory and OES Services
During the install, when you reach the software selections screens, none of the OES services is
selected by default.
You can specifically select eDirectory for installation, or, if you select a service that requires
eDirectory, eDirectory is automatically selected for installation.
If you are installing into an existing eDirectory tree and you don’t want eDirectory installed on the
server, you can deselect it.
When you configure the services that require eDirectory, you enter the information for an eDirectory
server in the tree (either the server you are installing or an existing server), including the name,
context, and password of an administrative user with rights to install the required objects in the tree.
The First Server Is Critical
If you are creating a new eDirectory tree on your network, the first server you install is important for
two reasons:
 The basic eDirectory tree structure is created during the first installation.
 The first server permanently hosts the Certificate Authority for your organization.
eDirectory Provides Additional Security for the Server
When you install eDirectory on a server, the server is configured by default to use eDirectory
certificates for HTTPS services, providing a significantly enhanced level of security for the server.
For more information, see “Certificate Management” in the OES 2 SP3: Planning and Implementation
Guide.
3.1.2
eDirectory Version Considerations
Novell® recommends that all servers in a tree be of the same fully supported eDirectory and OS
versions.
 “eDirectory 8.8.6” on page 34
 “eDirectory 8.7.3 on NetWare 6.5 SP8” on page 35
 “Migrating Earlier DS Versions” on page 35
eDirectory 8.8.6
OES 2 SP3 includes eDirectory 8.8.6. Where possible, you should upgrade existing servers to
eDirectory 8.8.6 before or during the process of introducing OES 2 SP3 into the environment.
For complete information, refer to the Novell eDirectory 8.8 What's New Guide available at
www.novell.com/documentation/edir88 (http://www.novell.com/documentation/edir88/).
34
OES 2 SP3: Upgrading to OES—Best Practices Guide
eDirectory 8.7.3 on NetWare 6.5 SP8
Novell supports eDirectory 8.7.3.9 or later on NetWare to facilitate the transition from NetWare to
OES 2. Although they have somewhat different feature sets, these two versions of eDirectory are
tested and certified to inter-operate within the same tree.
eDirectory must be hosted on a current fully supported OS. At this time, the only version of NetWare
that is under support (limited) is NetWare 6.5.
Migrating Earlier DS Versions
Earlier versions of DS/eDirectory should be migrated to eDirectory 8.7.3.7 as outlined in Table 1-1,
“Upgrade Paths from Earlier Versions of NetWare,” on page 12.
3.1.3
About eDirectory Management Tools in OES 2
Several tools, many of them Web-based, can be used to manage aspects of eDirectory. The primary
tools are listed here.
 iManager 2.7: A browser-based tool that lets you set up and manage your Novell eDirectory
tree; manage eDirectory objects, schema, partitions, and replicas; and create and manage users,
groups, and other objects. For more information, see Novell iManager 2.7.4 Administration Guide.
 iMonitor: A browser-based tool that provides cross-platform monitoring and diagnostic
capability for all servers in an eDirectory tree. For more information, see “Using Novell iMonitor
2.4” in the Novell eDirectory 8.8 Administration Guide.
 Novell Remote Manager for OES: A browser-based utility for monitoring server health,
changing the server configuration, or performing diagnostic and debugging tasks. Novell
Remote Manager (NRM) provides functionality that is not available in other management
utilities. For information, see the OES 2 SP3: Novell Remote Manager for Linux Administration
Guide.
 Novell Import Conversion Export Utility (ICE): You use ICE to:
 Import data from LDIF files to an LDAP directory
 Export data from the LDAP directory to an LDIF file
 Move data between LDAP servers
 Perform a schema compare and update
 Load information into eDirectory by using a template
 Import schema from SCH files to an LDAP directory
For more information, see “Novell Import Conversion Export Utility” in the Novell eDirectory 8.8
Administration Guide.
 DSBK: This is a thin command line parser that performs the same operations as the Backup
eMTool, but it lets you initiate a backup from the server console without logging in first or
setting up Role-Based Services.
For more information, see “Using DSBK ” in the Novell eDirectory 8.8 Administration Guide.
 eDirectory Management Toolbox (eMBox): Lets you access all of the eDirectory back-end
utilities remotely or on the server and works with Novell iManager to provide Web-based access
to eDirectory utilities such as DSRepair, DSMerge, and Service Manager.
For more information, see “The eDirectory Management Toolbox” in the Novell eDirectory 8.8
Administration Guide.
Upgrading eDirectory to OES
35
 Terminal Prompt Configuration Tools. The following tools are also available:
 ndsconfig: Lets you configure eDirectory, add an eDirectory replica server to an existing
tree, or create a new tree. For usage information, enter man ndsconfig at the terminal
prompt.
ldapconfig: On OES servers, only use this when explicitly instructed to in the OES-specific
documentation.
nmasinst: Lets you configure Novell Modular Authentication Service (NMAS™) and install
login methods. For usage information, enter man nmasinst at the terminal prompt.
General Utilities. Refer to “Novell eDirectory Linux and UNIX Commands and Usage” in
the Novell eDirectory 8.8 Administration Guide for a list and description of command line
tools along with syntax, and refer to “LDAP-Specific Commands” for LDAP-specific
commands.
 ConsoleOne: This utility is not supported to perform administration tasks on OES 2 server.
However, if you have a service that requires ConsoleOne®, such as Novell GroupWise®, it is
supported for administration of those applications.
3.2
Planning Your eDirectory Upgrade
Installing eDirectory on OES 2 provides an excellent opportunity to review your current directory
structure to ensure that it meets your organization's needs and growth patterns.
 Section 3.2.1, “Deciding Whether to Redesign Your Tree,” on page 36
 Section 3.2.2, “Checking eDirectory Health,” on page 38
 Section 3.2.3, “For More Information,” on page 40
3.2.1
Deciding Whether to Redesign Your Tree
Upgrading to OES 2 provides an excellent opportunity to evaluate whether changes are necessary to
better accommodate your current and future needs.
 “Questions to Ask” on page 36
 “Deciding Whether to Move Services” on page 37
 “For File and Print, Design around Your WAN” on page 37
 “Verify Your Redesign in a Lab First” on page 37
Questions to Ask
 Type of Tree: Does a Traditional (pyramid-shaped, single tree environment) or specialized tree
(flat tree designed for a specific situation such as an identity vault or LDAP authentication)
make better sense in your environment? Many Novell customers are opting for a flat tree so
LDAP can walk the tree more efficiently to find a user object.
 Physical Network Layout—Location-based and Designed Around WAN links): Analyze the
number of offices, where they are located, how many users are at each site, how sites
communicate with each other, whether offices share the same data, and how data is routed
among the sites.
 Organizational Structure—Function-based Design): Is your organization static or dynamic?
What growth patterns do you anticipate?
 Security: How secure does your data need to be? Does some data need enhanced security?
36
OES 2 SP3: Upgrading to OES—Best Practices Guide
 Server configuration: What types of servers are on your network? Do they need to interact?
Where are they located? What applications and services does each host? Are they managed
locally or centrally?
 User accessibility needs: Which applications and services are needed by which users? Do users
need to read data or modify it? which rights need to flow from the root? How many users need
remote access? Where will remote users access data from?
 Application needs: Which offices use the same applications? How many users are there per
application? Are applications installed locally or centrally?
 Administrative strategies: Do you intend to manage eDirectory centrally or from many
dispersed locations?
 Naming standards for eDirectory objects: What naming standards are in force? Do any of them
need to be changed or updated?
 Scalability and interoperability: How important are these on your network? Are you willing to
compromise scalability and/or performance for other worthwhile goals?
 Speed and efficiency: How important are these on your network? Are you willing to
compromise speed and efficiency for other worthwhile goals?
 Fault tolerance: What steps have you taken to provide fault tolerance? Do additional options
need to be implemented?
Deciding Whether to Move Services
If you decide to redesign your system, you need to determine whether to keep services in their
original tree or move them to a new tree. As part of this process, you probably also want to remove
any objects that are no longer being used.
For File and Print, Design around Your WAN
It is important that the WAN configuration is the first and foremost consideration for designing any
eDirectory tree that caters primarily to file and print, particularly if your organization includes
several remote facilities. In most cases, you should provide a partition for each remote location, even
when it is a single-server site.
For example, if you plan to have five OES 2 servers in place that are primarily dedicated to providing
eDirectory replica services, all of the Master replicas could be contained on one of these servers along
with multiple replicas of the higher levels of the tree. Each remote server should include an R/W
replica of its local partition. Make sure you have three writable replicas in place to provide adequate
redundancy.
Verify Your Redesign in a Lab First
If you decide to re-engineer your tree, it’s a good idea to create the new tree in a lab to make sure you
can work with its structure and that it’s actually going to work the way you want before you put it
into production.
Upgrading eDirectory to OES
37
3.2.2
Checking eDirectory Health
Problems with eDirectory can derail a rollout very quickly. Make sure there are no significant health
issues before you begin the upgrade. Determine whether the prerequisites have been met for
introducing OES 2 and eDirectory 8.8 into an existing tree or for transferring eDirectory from
NetWare to OES.
 “What to Check For” on page 38
 “Health Check Tools To Use” on page 39
 “Check Requirements, Prerequisites, and Compatibility” on page 39
 “Check Application Compatibility” on page 39
What to Check For
NOTE: When you upgrade to eDirectory 8.8, a server health check is conducted by default to ensure
that the server is safe for the upgrade.
Whichever option you choose, make sure each of the following is checked:
 eDirectory Version: Running different versions of NDS® or eDirectory on the same version of
NetWare can cause synchronization problems. All NDS versions should be at the latest version
on their respective operating system platforms. If your version of NDS or eDirectory is outdated,
download the latest software patch from Novell Directory Services Patches and Files (http://
support.novell.com/patches.html).
 Time Synchronization: NDS communication uses time stamps to uniquely identify objects and
the object's modification time for synchronization purposes. Time stamps are assigned to each
object and property to ensure the correct order for object and property updates. If servers in the
tree are not synchronized to the correct local time (or more importantly, to each other) replica
synchronization is not reliable and severe object corruption and data loss can be experienced. To
avoid these problems, time needs to be in sync across all servers in the network.
 Server-to-Server Synchronization: NDS servers communicate changes made to objects and
partition boundaries. This step verifies that no errors exist when NDS performs synchronization
processes.
 Replica Ring Synchronization: This operation reads the Synchronization Status attribute from
the replica object on each server that holds replicas of the partitions. It displays the time of the
last successful synchronization to all servers as well as any errors that have occurred since.
 Synchronization Tolerances: This operation indicates the time periods since a server has synced
with inbound and outbound data changes, how much data is outstanding, etc.
 Background Processes: These processes perform a variety of tasks, including replication of
changes and maintenance of system information.
 External References: This check determines whether a replica containing the object can be
located.
 Stuck Obituaries: These are object delete and move operations that have not completed
successfully because mixed versions of DS have been used. Significant overhead is expended by
the replica servers in retrying the obituary process constantly without success. Check the Flag
States of the obituaries on all servers in the backlink lists for the obituaries.
 Collision and Unknown Objects: In most cases, these objects can be deleted, but each
should be investigated for origin and references first.
 Replica States: Check the partitions and states of the replicas stored in the server's NDS
database files.
38
OES 2 SP3: Upgrading to OES—Best Practices Guide
 eDirectory Schema Synchronization: Each NDS server has schema definitions that are
used for creating and maintaining objects. Verify that schema synchronization between
servers is working correctly.
Health Check Tools To Use
Depending on your preference, you can perform an eDirectory server health check in several ways:
 Use the health check utilities in eDirectory 8.8: Novell eDirectory 8.8 runs a health check by
default with every upgrade before the actual package upgrade.
 OES health checks are run by default before an upgrade operation starts.
 NetWare health checks happen as part of the installation wizard.
You can run the diagnostic tools (ndscheck on OES 2; dscheck on NetWare), to complete a
health check at anytime.
For additional information, including command parameters for each operating system, refer to
“eDirectory Health Checks” in the Novell eDirectory 8.8 Installation Guide.
 Use iMonitor: You can use either of two methods (manual and automated) in iMonitor, a webbased diagnostic tool:
 Use the Navigator Frame (iMonitor > Navigator > Reports).
 Use the Assistant Frame (iMonitor > Assistant > Agent Health).
Even with a large number of servers, this procedure tends to run very quickly (less than 5
minutes for 15-20 servers if all of the servers are healthy). The process is the same for all
operating systems.
 Use TID 10060600: You can view a tutorial or access a text version of the TID at http://
support.novell.com/additional/tutorials/index.html (http://support.novell.com/additional/
tutorials/index.html)
Check Requirements, Prerequisites, and Compatibility
For system requirements and prerequisites, see Installing or Upgrading Novell eDirectory on Linux
in the Novell eDirectory 8.8 Installation Guide for a complete listing and explanation.
Check Application Compatibility
Check currently installed Novell and third-party applications to determine if eDirectory 8.8 is
supported before upgrading your existing eDirectory environment. You can find the current status
for Novell products in TID 31714342 “What Novell products are supported with Novell eDirectory
8.8” (http://www.novell.com/support/php/
search.do?cmd=displayKC&docType=kc&externalId=3171434&sliceId=1&docTypeID=DT_TID_1_1&
dialogID=48117155&stateId=0%200%2048113961)
If a product is not supported:
 Do not install eDirectory 8.8 on the same server as the product.
 Do not configure the product to search an eDirectory 8.8 server.
As long as these conditions are met, you can still upgrade unaffected servers and services to OES 2
and eDirectory 8.8 and run with a mixed tree until a replacement for the older application is found.
Upgrading eDirectory to OES
39
3.2.3
For More Information
For additional eDirectory design information, refer to “Designing Your Novell eDirectory Network”
in the Novell eDirectory 8.8 Administration Guide.
3.3
Upgrading eDirectory
Use the information in the following sections to ensure a smooth eDirectory upgrade in connection
with upgrading NetWare to OES.
 Section 3.3.1, “Do Not Install or Upgrade to eDirectory 8.8 Separately from OES 2,” on page 40
 Section 3.3.2, “Choosing an Upgrade Strategy,” on page 40
 Section 3.3.3, “Moving, Creating, or Importing eDirectory Users,” on page 41
3.3.1
Do Not Install or Upgrade to eDirectory 8.8 Separately from OES 2
Because OES services are tightly integrated with eDirectory, both the services and eDirectory must be
upgraded at the same time. The OES 2 install is not designed to handle a separate installation or
upgrade of eDirectory 8.8.
3.3.2
Choosing an Upgrade Strategy
There are several basic strategies for setting up eDirectory on OES 2 or upgrading to the OES 2
platform:
 “Transferring eDirectory to a New Server” on page 40
 “Starting Fresh with OES 2” on page 40
 “Adding a branch to an existing tree” on page 41
 “Manual Upgrade Using Replicas” on page 41
Transferring eDirectory to a New Server
If your current tree is meeting your needs, the simplest upgrade method is to transfer an existing
NetWare server to a new OES 2 server.
Use the OES 2 SP3 Migration Tool for this purpose, specifically the Identity Transfer functionality. For
more information, see “Transfer ID Migration” in the OES 2 SP3: Migration Tool Administration Guide.
Starting Fresh with OES 2
This is a good choice if you are unhappy with your existing tree (the tree hasn't kept up with
organizational changes and growth). Moving to OES 2 provides an opportunity to update the tree by
starting from scratch. You might consider consolidating more services while adding new OES
servers. Some Novell customers have incorporated specialty trees, such as an identity vault on SLES
10 rather than on OES 2.
In cases where eDirectory or the operating system and services are outdated, it sometimes makes
sense to just redo the whole environment (new tree design, partitioning, replication strategies, newer
utilities/services) rather than port the existing structure.
40
OES 2 SP3: Upgrading to OES—Best Practices Guide
The single biggest issue in many organizations is that NetWare and eDirectory haven't been patched,
so starting fresh is the easier option. This is true of file and print as well. Most customers who use this
strategy are moving to OES 2 from NetWare 5 and NDS 6 (which is limited to 1500 users).
Adding a branch to an existing tree
Some Novell customers transfer objects to a new OES 2 branch and then gradually retire the older
NetWare branch. By adding a branch, it's easier to drag and drop users and login scripts, certificates,
and PKI so they don't need to be re-created.
Manual Upgrade Using Replicas
If all you want to do is copy the existing eDirectory information from a NetWare server to a new OES
2 server, without the OES server assuming the NetWare server's identity, you can move objects to a
new OES 2 branch and then gradually retire the older NetWare branch. When you've added a branch,
it's easy to drag and drop users and login scripts, certificates, and PKI so they don't need to be recreated.
1 Create a new OES 2 server with a new eDirectory 8.8 tree.
2 Create an eDirectory replica on the target OES server by attaching it to the same replica ring as
the source NetWare server.
This creates two instances of eDirectory in the environment. The OES Migration Tool does a nondestructive move of all services, and it needs both servers with their respective directories up
and running.
3 Allow the OES eDirectory installation to synchronize.
If necessary, you can rework the layout of your tree structure, remap the location of all user
objects in your new tree, and delete any user objects that are no longer needed.
4 When eDirectory synchronization of the replica is complete, move the impacted services with
the OES 2 SP3 Migration Tool.
5 Retire the older NetWare server.
Except where dependencies exist, there is no required order for moving services in the same tree. An
example of a dependency would be that the Archive and Versioning service depends on the file
system.
3.3.3
Moving, Creating, or Importing eDirectory Users
If you have opted to create a new tree, you need to decide how to move user objects from one tree to
another. Several options are available:
 “Using Novell Identity Manager” on page 41
 “Creating and Importing an LDIF file” on page 42
 “Using the OES 2 Migration Tool” on page 42
Using Novell Identity Manager
One method is setting up a Novell Identity Manager connection between your old tree and your new
one. This lets you easily synchronize user objects to the new tree. You can also use Identity Manager
to remap the location of all user objects in your new tree.
Upgrading eDirectory to OES
41
Creating and Importing an LDIF file
Create an LDIF file containing user objects and use iManager to import it. Configure the LDIF file so
it creates a Users' organization container and then places an object for each user in it.
IMPORTANT: Replica and partition information cannot be imported by using an LDIF file.
Using the OES 2 Migration Tool
If you are creating a new tree, the Migration Tool can not only move the data but also create new
users in the tree and match them to the data being moved. It can also match up users and trustees in
the old tree with those in the new tree.
It is probably easiest to create the new users by using one of the other methods and then match them
up through the Migration Tool.
3.4
Post-Upgrade Checks
Check to be sure that your upgraded tree is healthy, that the services are running correctly, and that
services are usable by all network users as expected.
3.5
About Domain Services for Windows
NOTE: The following overview of DSfW is copied from the OES 2 SP3: Planning and Implementation
Guide for your convenience.
Novell Domain Services for Windows (DSfW) allows eDirectory users on Windows workstations to
access storage on both OES servers and Windows servers by using native Windows and Active
Directory authentication and file service protocols.
DSfW enables companies with Active Directory and Novell eDirectory deployments to achieve better
coexistence between the two platforms.
 Users can work in a pure Windows desktop environment and still take advantage of some OES
back-end services and technology, without the need for a Novell Client™ or even a matching
local user account on the Windows workstation.
 Network administrators can use either Microsoft* Management Console (MMC) or iManager to
administer users and groups within the DSfW domain, including their access rights to Sambaenabled storage on OES servers.
42
OES 2 SP3: Upgrading to OES—Best Practices Guide
Figure 3-1 DSfW File Access Overview
Access Methods
eDirectory
User
Authentication
File Storage Services
Windows Explorer
or
Internet Explorer
eDirectory
DSfW server
Could be on a
seperate OES 2 server
in or out of the domain
Cross-Forest
Trust
AD User
Windows Explorer
or
Internet Explorer
AD Windows
server
Could be on a separate
Windows server
The following table explains the information illustrated in Figure 3-1.
Access Methods
Authentication
File Storage Services
eDirectory and Active Directory users on
Windows workstations can access files
through Windows Explorer* (CIFS) or
Internet Explorer (WebDAV Web
Folders). No Novell Client can be on the
machine.
For eDirectory users, file service
access is controlled by
authentication through the
eDirectory server, using common
Windows authentication
protocols, including Kerberos*,
NTLM, and SSL/TLS.
On OES 2 servers, file
storage services are
provided by Samba to NSS
or traditional Linux file
systems.
Unlike Windows workgroup or Novell
Samba, the user doesn’t need to have a For AD users, file service access
matching username and password on
is controlled by authentication
the local workstation.
through the AD server.
Although not shown, Novell Client users
can also access files through a normal
NCP™ connection.
For eDirectory users,
access to storage on
Windows servers is
available through a crossforest trust. Access rights
are granted by the AD
administrator following the
establishment of the crossforest trust.
Upgrading eDirectory to OES
43
Figure 3-2 DSfW User Management Overview
Management Tools
Users
Novell iManager
DSfW
Administrators
DSfW
eDirectory server
Microsoft Management
Console
AD server
The following table explains the information illustrated in Figure 3-2.
44
Management Tools
Users
iManager manages DSfW users exactly
like other eDirectory users.
DSfW users must have the Default Domain Password policy
assigned and a valid Universal Password.
MMC manages both AD users and
DSfW users as though they were AD
users.
DSfW users are automatically enabled for Samba and LUM.
OES 2 SP3: Upgrading to OES—Best Practices Guide
Figure 3-3 DSfW Storage Management Overview
Management Tools
Storage
OES
Storage Management
Tools
Network
Administrators
OES 2 servers
Windows
Storage Management
Tools
Windows servers
The following table explains the information illustrated in Figure 3-3.
Management Tools
Storage
Network administrators use native OES
and Windows storage management
tools to create and manage storage
devices on OES and Windows servers,
respectively.
Storage devices on OES 2 servers can be either NSS or
traditional Linux volumes. Samba management standards
apply to both volume types.
Windows management tools can also
manage share access rights and
POSIX* file system rights on DSfW
storage devices after the shares are
created. They cannot create the shares
or perform other device management
tasks.
For planning information, see the OES 2 SP3: Domain Services for Windows Administration Guide.
For implementation information, see the OES 2 SP3: Domain Services for Windows Administration
Guide.
3.6
Additional eDirectory Resources
Click the following links to access additional eDirectory resources.
 eDirectory 8.8 Documentation (http://www.novell.com/documentation/edir88/)
Upgrading eDirectory to OES
45
 eDirectory Health Check - Online Tutorial (http://support.novell.com/additional/tutorials/
tid10060600/)
 eDirectory Training Courses (http://www.novell.com/training/courseware/catalog.jsp?pl=112)
46
OES 2 SP3: Upgrading to OES—Best Practices Guide
4
Upgrading NSS and Data Storage to OES
4
 Section 4.1, “About NSS in OES 2,” on page 47
 Section 4.2, “Platform Differences in NSS,” on page 48
 Section 4.3, “Planning to Upgrade NSS,” on page 48
 Section 4.4, “Moving NSS and Data,” on page 50
 Section 4.5, “Post-Upgrade Procedures,” on page 51
 Section 4.6, “Upgrading Distributed File Services (DFS) to OES,” on page 52
4.1
About NSS in OES 2
Novell® Storage Services™ is available with NetWare® 5.0 and later. The NSS kernel has been open
sourced and is included in Novell SUSE® SLES 9 SP1 Linux distribution and later and with Novell
OES 2. The tools to manage NSS are available only in OES.
 Section 4.1.1, “NSS Is Designed for the Enterprise,” on page 47
 Section 4.1.2, “More Reasons to Consider NSS,” on page 47
4.1.1
NSS Is Designed for the Enterprise
The NSS file system is unique in many ways, mostly in its ability to simultaneously manage and
support shared file services from different file access protocols. It is designed to manage access
control in enterprise file sharing environments.
One of its key features is the Novell Access Control Model, which securely scales to hundreds of
thousands of users accessing the same storage. NSS and its predecessor (NWFS) are the only file
systems that can restrict the visibility of the directory tree based on the user accessing the file system.
Both NSS and NWFS have built-in ACL rights inheritance.
NSS includes mature and robust features tailored for the file sharing environment of the largest
enterprises.
Dynamic Storage Technology works with NSS volumes on OES 2.
4.1.2
More Reasons to Consider NSS
Novell Storage Services is generally the best file system solution for customers transferring file
sharing services from NetWare to OES. NSS file systems created on NetWare can be mounted on OES
servers.
The following characteristics of NSS on OES 2 should be noted in your planning:
 NSS volumes are cross-compatible between OES and NetWare. NSS data volumes can be
mounted on either NetWare or OES and the data can be moved between them.
Upgrading NSS and Data Storage to OES
47
 NSS devices and storage can be managed in the Web-based Novell iManager utility. NSS also
supports third-party tools on both platforms for advanced data protection and management,
virus scanning, and traditional archive and backup solutions.
 In a mixed-platform cluster with Novell Cluster Services™, NSS volumes can fail over between
OES and NetWare, allowing for full data, trustee, and file system feature preservation when
moving data to OES. However, best practice requires that you create all of the NSS volumes you
need in the cluster on NetWare before you join any OES nodes to the cluster. After that point,
you should not create additional NSS volumes or modify any of them until the cluster has only
OES servers remaining.
 In addition, NSS on OES 2:
 Retains all files, rights, metadata, restrictions, etc.
 Includes NetWare Trustee access control (richer than POSIX)
 Retains file system access (NCP™)
 Retains all file system administration and management features
 Can be easily clustered with Novell Cluster Services (NCS)
 Is best for shared LAN file serving: excellent scalability in number of files; scales to millions
of files in a single directory
 Supports multiple data streams and rich metadata (its features are a superset of existing file
systems on the market for data stream, metadata, namespace, and attribute support)
 Is journaled
4.2
Platform Differences in NSS
Most NSS features that have been available on NetWare are now also available on OES 2.
For the most up-to-date feature comparison, see “Comparison of NSS on NetWare and NSS on
Linux” in the OES 2 SP3: NSS File System Administration Guide for Linux.
4.3
Planning to Upgrade NSS
As you plan your NSS implementation, the following file system guidelines should be noted:
 Section 4.3.1, “Identify NSS Coexistence and Migration Issues,” on page 48
 Section 4.3.2, “Limitations,” on page 49
4.3.1
Identify NSS Coexistence and Migration Issues
For a complete discussion of the issues involved in the coexistence and migration of Novell Storage
Services for OES 2 that might affect your planning, see the following sections in the OES 2 SP3: NSS
File System Administration Guide for Linux:
 “Cross-Platform Issues for NSS”
Discusses pool snapshots, NSS volumes and features, file access, and management tools
 “Migrating NSS Devices from NetWare 6.5 SP8 to OES 2 Linux”
Includes guidelines for moving NSS pools and volumes between NetWare and OES 2 servers
and instructions for moving both clustered and non-clustered devices from previous versions of
NetWare and OES 1.
48
OES 2 SP3: Upgrading to OES—Best Practices Guide
4.3.2
Limitations
 “Traditional NetWare File System Is Not Supported” on page 49
 “Installing NSS on the System Disk” on page 49
 “Samba Access Requires LUM” on page 49
 “The Linux OS Can’t Be Installed on NSS” on page 49
 “Moving Volumes Cross-Platform Has Limitations” on page 49
 “Pool Snapshots Cannot Be Moved” on page 50
Traditional NetWare File System Is Not Supported
The NetWare File System (NWFS) was used in NetWare 3.x through 5.x as the default file system, and
is supported in NetWare 6.x for compatibility. It is one of the fastest file systems available; however, it
does not scale and is not journaled. An Open Source version of this file system is available for Linux
to allow access to its file data. However, the open source version lacks the identity management tieins, and therefore, has little utility.
NWFS is not supported on OES 2 and should, therefore, be moved—probably to the Novell Storage
Services (NSS) file system.
Installing NSS on the System Disk
Novell recommends against including NSS on the system disk (the disk containing the /boot and /
partitions) unless your server configuration requires it. If this is required, you must carefully follow
the instructions in “Installing with EVMS as the Volume Manager of the System Device” in the OES 2
SP3: Installation Guide.
Samba Access Requires LUM
For a broad explanation of Linux User Management (LUM), see “Linux User Management: Access to
Linux for eDirectory Users” in the OES 2 SP3: Planning and Implementation Guide. For information
specific to NSS, see “Planning NSS Storage Solutions” in the OES 2 SP3: NSS File System
Administration Guide for Linux.
The Linux OS Can’t Be Installed on NSS
You cannot install the Linux operating system on an NSS volume. OES 2 requires a Linux traditional
file system volume for the operating system, such as Ext3, ReiserFS, or XFS.
Moving Volumes Cross-Platform Has Limitations
You can move an NSS volume that was created on NetWare cross-platform to an OES server.
However, you should not move an NSS system (SYS:) volume from NetWare to OES unless you
intend to use it as a data volume (or not at all) while it is mounted on the OES server.
If you move an NSS system pool cross-platform, any volumes it contains function as data volumes on
the OES server, including the SYS: volume.
Upgrading NSS and Data Storage to OES
49
You can move storage devices containing NSS volumes between NetWare servers and OES 2 servers.
When you move an unshared device to a different server, you must decommission its volumes in
eDirectory for the current server, then recommission them for the new server. For shared NSS pools
and volumes, Novell Cluster Services provides this service automatically.
NSS volumes that were originally created on NetWare can be moved cross-platform to an OES server.
But only volumes that were originally created on NetWare can be moved back from OES to NetWare.
Pool Snapshots Cannot Be Moved
NSS pools that are a source pool or a destination pool for NSS pool snapshots on NetWare cannot
move cross-platform if you want to keep the pool snapshots. A pool snapshot is no longer available if
you move its source pool or destination pool to an OES server. The snapshot no longer works even
after you move the pools back to NetWare.
Before you move an NSS pool cross-platform, make sure you delete any of its snapshots stored on
other pools and any snapshots for other pools it might contain.
4.4
Moving NSS and Data
 Section 4.4.1, “Moving NSS Devices Cross-Platform,” on page 50
 Section 4.4.2, “Moving Data from NSS on NetWare to NSS on OES 2,” on page 50
 Section 4.4.3, “Moving Data from NSS to Other Volume Types,” on page 51
4.4.1
Moving NSS Devices Cross-Platform
This is arguably the simplest method of all. NSS supports moving devices containing NSS volumes
between any servers that support a compatible media format, including moves between NetWare
servers and OES 2 servers.
For instructions, see “Moving Non-Clustered Devices From NetWare 6.5 SP8 Servers to OES 2 Linux
Servers” in the OES 2 SP3: NSS File System Administration Guide for Linux includes information on
moving NSS volumes cross-platform between servers in the same Novell eDirectory tree. See also
“Cross-Platform Issues for NSS”.
4.4.2
Moving Data from NSS on NetWare to NSS on OES 2
The OES 2 SP3 Migration Tool supports transferring data from a source NSS volume on NetWare to a
target NSS volume on OES 2. This method preserves both the Novell Trustee Rights for eDirectory
users and the NSS directory and file attributes supported by only the NSS file system.
For more instructions, see “Migrating File System from NetWare, OES 1 or OES 2 to OES 2 SP3
Linux” in the OES 2 SP3: Migration Tool Administration Guide.
50
OES 2 SP3: Upgrading to OES—Best Practices Guide
4.4.3
Moving Data from NSS to Other Volume Types
The OES 2 SP3 Migration Tool also supports moving data from an NSS volume on NetWare to a
Linux POSIX volume on OES 2.
 If you configure the target Linux POSIX volume as an NCP volume and carefully follow the
instructions, the Novell Trustee Rights are retained and only the NSS file and directory
attributes are lost.
 If you move the data to a Linux POSIX volume target without configuring it as an NCP volume,
the POSIX access model applies. eDirectory users must be enabled for Linux User Management
to access data on Linux POSIX volumes.
If you are unsure about the implications briefly stated above, you should read the following sections
in the OES 2 documentation:
 OES 2 SP3: Planning and Implementation Guide
 “The Traditional Novell Access Control Model”
 “NSS Access Control on OES”
 “Novell Client (NCP File Services) Access”
 “eDirectory User Access to OES 2 Servers”
 OES 2 SP3: File Systems Management Guide
 “Understanding File System Access Control Using Trustees”
 “Coexistence and Migration Issues”
4.5
Post-Upgrade Procedures
After files are transferred, file permissions might need to be reset. As discussed earlier, Linux file
system permissions are different from and not as granular as those used by NetWare. This becomes
especially apparent for directories where multiple groups previously had access to the data within a
file. On Linux file systems, this is not possible, so an alternative must be found.
Novell recommends the following permissions as a starting point. You might need to change the
permissions to better fit your needs.
Table 4-1 File Permissions Recommended for File Types
Permissions:
Type of files
user group other numeric value
Home directories, such as /home/userid
rwx --- ---
700
User files, such as /home/userid/myfile
rw- r-- ---
740
Shared directory for a team (where the group is used for
access.)
rwx rwx ---
760
Shared team files (where the group is used for access.)
rw- rw- ---
660
Upgrading NSS and Data Storage to OES
51
4.6
Upgrading Distributed File Services (DFS) to OES
The new DFS junction support on OES 2 brings the NetWare Novell Distributed File System feature
set to Linux with the following additions:
 VLDB services are cluster-enabled.
 Junctions can point to subdirectories, not just the root of a volume.
 All administration is performed via iManager.
 Junctions can be created on any file system, not just Novell Storage Services.
Novell Distributed File Services (DFS) for the Novell Storage Services (NSS) file system provides
location transparency of file data to end users. You can modify the underlying physical organization
of data on NSS volumes to maximize the use and performance of available storage resources. With
DFS, you can create a single virtual file system for data on NSS volumes that span multiple machines.
DFS preserves the logical file organization from the user perspective by maintaining a Volume
Location Database (VLDB) for all volumes in a DFS management context. Using junctions and the
VLDB eliminates the user’s need to know the path to the physical location of the data.
For information and instructions, see “Migrating DFS from NetWare to OES 2 Linux.” in the OES 2
SP3: Novell Distributed File Services Administration Guide for Linux.
For additional instructions for moving NSS devices cross-platform, see “Migrating NSS Devices from
NetWare 6.5 SP8 to OES 2 Linux” in the OES 2 SP3: NSS File System Administration Guide for Linux.
52
OES 2 SP3: Upgrading to OES—Best Practices Guide
5
Upgrading File Services to OES
5
 Section 5.1, “Upgrading AFP File Services to OES,” on page 53
 Section 5.2, “Upgrading CIFS File Services to OES,” on page 57
 Section 5.3, “Upgrading Novell FTP to OES,” on page 61
 Section 5.4, “Upgrading iFolder to OES,” on page 62
 Section 5.5, “Upgrading NetWare Core Protocol (NCP) File Services,” on page 65
 Section 5.6, “Upgrading NetStorage,” on page 68
5.1
Upgrading AFP File Services to OES
 Section 5.1.1, “About AFP File Services in OES 2,” on page 53
 Section 5.1.2, “Platform Differences in AFP File Services,” on page 54
 Section 5.1.3, “Planning to Transfer AFP Services,” on page 56
 Section 5.1.4, “Upgrading AFP,” on page 56
 Section 5.1.5, “Post-Upgrade Checks,” on page 57
5.1.1
About AFP File Services in OES 2
Starting with OES 2 SP1, the AFP file services that were previously available only on NetWare®
through the Native File Access Protocols (NFAP) service have now been ported to OES as Novell®
AFP.
The Novell AFP service lets users on Macintosh workstations access and store files on OES 2 SP1 and
later servers with NSS volumes without installing any additional software, such as the Novell
Client™ (see Figure 5-1).
Upgrading File Services to OES
53
Figure 5-1 How Novell AFP Works
Access Points
Authentication
AFP Services
AFP
AFP server
processes
Macintosh
eDirectory
LDAP server
OES 2 server
The following table explains the information illustrated in Figure 5-1.
Access Points
Authentication
AFP File Services
eDirectory™ users on Macintosh
workstations have native access to the
OES 2 server.
All file service access is
controlled by LDAP-based
authentication through the
eDirectory LDAP server.
Of course, the same files can
also be accessed through
other OES file services (such
as NetStorage) that connect to
Linux volumes.
Although shown separately,
eDirectory could be installed
on the OES 2 server.
5.1.2
Platform Differences in AFP File Services
The differences in AFP services on NetWare and OES 2 are summarized in the following table.
Table 5-1 Platform Differences in AFP File Services
Feature Description
AFP for NetWare
AFP for OES
Administering
Limited to starting and stopping the Ability to configure AFP server
server.
parameters through iManager.
See “Enabling and Disabling AFP” See “Administering the AFP Server”
in the NW 6.5 SP8: AFP, CIFS, and in the OES 2 SP3: Novell AFP For
NFS (NFAP) Administration Guide Linux Administration Guide.
54
OES 2 SP3: Upgrading to OES—Best Practices Guide
Feature Description
AFP for NetWare
AFP for OES
Filenames and Paths
sys:\etc\ctxs.cfg
/etc/opt/novell/afptcpd/
afpdircxt.conf
sys:\etc\afpvol.cfg
/etc/opt/novell/afptcpd/
afpvols.conf
sys:\etc\afptcp.log
/etc/opt/novell/afptcpd/
afptcpd.conf
/var/log/afptcpd/
afptcp.log
Installation
Customized installation during
installation of NetWare 6.5.
Installation through YaST along with
associated dependencies.
See, “Installing Novell Native File
See “Installing and Setting Up AFP”
Access Protocols on a NetWare 6.5 in the OES 2 SP3: Novell AFP For
Server” in the NW 6.5 SP8: AFP,
Linux Administration Guide.
CIFS, and NFS (NFAP)
Administration Guide
Simple Password support
Yes
No
Universal Password
Yes. Limited to 8 characters.
Yes. Over 8 characters.
Upgrade/migration support
Not Applicable
Support to upgrade AFP from
NetWare to OES.
See “Migrating AFP from NetWare
to OES 2 SP3 Linux” in the OES 2
SP3: Novell AFP For Linux
Administration Guide.
Mac versions supported
Classic Mac, Mac OS* 10.3, 10.4
and 10.5
Mac OS 10.3, 10.4 and 10.5
Cross-protocol locking
Supported among AFP, CIFS, and
NCP™.
Supported among AFP, CIFS, and
NCP.
Authentication methods
Clear text
Clear text
Two-Way Random Key Exchange
Random Exchange
Diffie-Hellman Exchange
Dynamic detection of volumes
Yes
Yes, but the AFP server needs to be
reloaded.
Choosing volumes to be exported
Yes
No. Exports all the volumes.
Support for 64-bit architecture
No
Yes
Upgrading File Services to OES
55
5.1.3
Planning to Transfer AFP Services
The OES 2 SP3 Migration Tool supports transferring AFP file services from NetWare to OES 2 SP3.
The process is quite straightforward, but there are, of course, some planning steps that you must take
to ensure a successful upgrade.
 “Requirements” on page 56
 “Limitations” on page 56
 “Universal Password” on page 56
Requirements
Table 5-2 AFP Source and Target Server Requirements
Source Server
Target Server
NetWare 5.1 or later
OES 2 SP3
The Novell AFP service pattern is installed but not
configured.
Data can be moved independently of the service.
Users can always see what they have rights to see.
Limitations
The OES 2 SP3 Migration Tool does not support transferring AFP services across eDirectory trees.
However, AFP services can be effectively transferred by first moving the data to an OES 2 SP3 target
server in the other tree, and then configuring AFP on the target server.
For details, see “Migrating Data to a Server in a Different Tree” in the OES 2 SP3: Migration Tool
Administration Guide and “Installing and Setting Up AFP” in the OES 2 SP3: Novell AFP For Linux
Administration Guide.
Universal Password
Although Simple Passwords were an option with AFP on Netware, Novell AFP requires Universal
Password, as listed in Section 5.1.2, “Platform Differences in AFP File Services,” on page 54.
The process of upgrading AFP services to OES ensures that a Universal Password policy is assigned
to all of the eDirectory contexts listed for AFP users on the NetWare server. If users currently have a
Universal Password policy assigned, the tool checks for compliance with AFP requirements and
modifies the policy if required.
5.1.4
Upgrading AFP
You can use either of the two migration types offered by the Migration Tool to transfer AFP file
services from NetWare to OES 2:
 Consolidate: If you are transferring just the AFP service and associated data to an OES 2 SP3
server, you should perform a consolidation migration. For more information, see Section A.1.1,
“Consolidating Selected Data or Services,” on page 101.
56
OES 2 SP3: Upgrading to OES—Best Practices Guide
 Transfer ID: If you are transferring an entire NetWare server, including the AFP service and
associated data, to an OES 2 SP3 server, you should transfer the entire server configuration. For
more information, see Section A.1.2, “Transferring an Entire NetWare Server,” on page 102.
To transfer Novell AFP from NetWare to OES 2, follow the instructions in “Migrating AFP from
NetWare to OES 2 SP3 Linux ” in the OES 2 SP3: Migration Tool Administration Guide.
5.1.5
Post-Upgrade Checks
 “Verify Upgrade Success” on page 57
 “Preparing for the First Login” on page 57
Verify Upgrade Success
After the process is complete, be sure to complete the instructions in “Verifying the Migration
Process” in the OES 2 SP3: Migration Tool Administration Guide.
Preparing for the First Login
You must do two things to ensure that users can authenticate seamlessly to the transferred AFP
service:
1. Restart eDirectory with the environment variable NDSD_TRY_NDSLOGIN_FIRST set to TRUE.
2. Make sure that each user logs in for the first time by using either the Diffie-Hellman Exchange or
clear-text authentication method.
For more information, see “Cross-Platform Issues” in the OES 2 SP3: Migration Tool Administration
Guide.
5.2
Upgrading CIFS File Services to OES
 Section 5.2.1, “About CIFS File Services in OES 2,” on page 57
 Section 5.2.2, “Platform Differences in CIFS File Services,” on page 58
 Section 5.2.3, “Planning to Upgrade CIFS Services,” on page 59
 Section 5.2.4, “Upgrading CIFS,” on page 60
 Section 5.2.5, “Post-Upgrade Checks,” on page 61
5.2.1
About CIFS File Services in OES 2
Starting with OES 2, the CIFS file services that were previously available only on NetWare through
the Native File Access Protocols (NFAP) service have now been ported to OES as Novell CIFS.
The Novell CIFS service lets users on Windows workstations access and store files on OES 2 servers
with NSS volumes without installing any additional software, such as the Novell Client (see Figure 52).
Upgrading File Services to OES
57
Figure 5-2 How Novell CIFS Works
Access Methods
Authentication
File Storage Services
CIFS
Any CIFS/SMB Client
(such as Windows Explorer)
eDirectory users have
automatic access
to Novell CIFS file
services.
CIFS server
processes
WebDAV
Web Folders
(Windows Explorer or
Internet Explorer browser)
OES 2 server
eDirectory
LDAP server
The following table explains the information illustrated in Figure 5-2.
Access Methods
Authentication
CIFS File Services
eDirectory users on Windows
workstations have two native Windows
file access options:
All file service access is
controlled by LDAP-based
authentication through the
eDirectory LDAP server.
Of course, the same files can
also be accessed through
other OES file services (such
as NetStorage) that connect to
NSS volumes.
 CIFS Client Access: Windows
Explorer users can access and
modify files on the OES 2 server
just as they would on any
workgroup server share.
Although it is shown
separately, eDirectory could
be installed on the OES 2
server.
 Web Folder: Users can create Web
Folders in Windows Explorer or
Internet Explorer.
Files on the OES 2 server are
accessed and maintained with the
HTTP-WebDAV protocol.
5.2.2
Platform Differences in CIFS File Services
The differences in CIFS services on NetWare and OES 2 are summarized in the following table.
58
OES 2 SP3: Upgrading to OES—Best Practices Guide
Table 5-3 CIFS services on NetWare and OES 2
5.2.3
Service
NetWare
OES 2
64-Bit Support
No
Yes
Distributed File Services for NSS
Volumes
Yes
Future
OpLocks
Yes
Yes
Cross Protocol Locking
Yes
Future
NSS Support
Yes
Yes
CIFS-enabled shared NSS pool/
Yes
volume in a NetWare-to-NetWare or
OES-to-OES cluster
Yes
CIFS-enabled shared NSS pool/
No
volume in a mixed NetWare-to-OES
cluster
No
iManager Support and
Administration tool
Yes
Yes
File and Record Locking
Yes
Yes
Domain Emulation
Yes
Future
Monitoring
No
Future
Xen Virtualized Host Server
Environment
NA
No
Xen Virtualized Guest Server
Environment
Yes
Yes
Multi-processor/Multicore Server
Support
No
Yes
Multi-File System Support
No
Future
NTLMv2/Kerberos
No
Future
Planning to Upgrade CIFS Services
The OES 2 SP3 Migration Tool supports transferring CIFS file services from NetWare to OES 2. The
upgrade process is quite straightforward, but there are, of course, some planning steps that you must
take to ensure success.
 “Requirements” on page 60
 “Limitations” on page 60
 “Universal Password” on page 60
Upgrading File Services to OES
59
Requirements
Table 5-4 CIFS Source and Target Server Requirements
Source Server
Target Server
NetWare 5.1 or later
OES 2 SP3.
The Novell CIFS service pattern is installed but not
configured.
Data can be moved independently of the service.
Users can always see what they have rights to see.
Limitations
 “Cross-Tree Migration Not Supported” on page 60
 “Server Configuration Information Not Transferred with Consolidation” on page 60
 “Upgrading Novell Samba Not Supported” on page 60
Cross-Tree Migration Not Supported
The OES 2 SP3 Migration Tool does not support transferring CIFS services across eDirectory trees.
However, CIFS services can be effectively transferred by first moving the data to an OES 2 SP3 target
server in the other tree, and then configuring CIFS on the target server.
For details, see “Migrating Data to a Server in a Different Tree” in the OES 2 SP3: Migration Tool
Administration Guide and “Installing and Setting Up AFP” in the OES 2 SP3: Novell AFP For Linux
Administration Guide.
Server Configuration Information Not Transferred with Consolidation
The CIFS shares configuration and CIFS Users contexts are transferred by using both migration types
(Consolidate and Transfer ID), but the server configuration information is transferred only with a
Transfer ID migration.
Upgrading Novell Samba Not Supported
The OES 2 SP3 Migration Tool does not support Novell Samba as a source service for transferal to
Novell CIFS.
Universal Password
A Universal Password policy is required for Novell CIFS.
60
OES 2 SP3: Upgrading to OES—Best Practices Guide
5.2.4
Upgrading CIFS
You can use either of the two migration types offered by the Migration Tool to transfer CIFS file
services from NetWare to OES 2:
 Consolidate: If you want to move just the CIFS shares and associated data to an OES 2 SP3
server, you can perform a consolidation migration. The CIFS server configuration is not
transferred. For more information, see Section A.1.1, “Consolidating Selected Data or Services,”
on page 101.
 Transfer ID: If you are transferring an entire NetWare server, including the CIFS service and
associated data, to an OES 2 SP3 server, then you should perform a Transfer ID migration. For
more information, see Section A.1.2, “Transferring an Entire NetWare Server,” on page 102.
To upgrade Novell CIFS from NetWare to OES 2, follow the instructions in “Migrating CIFS from
NetWare to OES 2 SP3 Linux” in the OES 2 SP3: Migration Tool Administration Guide.
5.2.5
Post-Upgrade Checks
 “Restarting CIFS” on page 61
 “Verifying Success” on page 61
Restarting CIFS
After the CIFS service is transferred, restart CIFS at a terminal prompt by using the following
command:
rcnovell-cifs restart
Verifying Success
Be sure to complete the instructions in “Verifying the Migration” in the OES 2 SP3: Migration Tool
Administration Guide.
5.3
Upgrading Novell FTP to OES
 Section 5.3.1, “About FTP File Services,” on page 61
 Section 5.3.2, “Platform Differences in FTP File Services,” on page 61
 Section 5.3.3, “Planning,” on page 61
 Section 5.3.4, “Transferring FTP Services to OES,” on page 62
 Section 5.3.5, “Post-Upgrade Checks,” on page 62
5.3.1
About FTP File Services
Novell FTP (File Transfer Protocol) is integrated with Novell eDirectory so that users can securely
transfer files to and from OES 2 or OES NetWare volumes.
5.3.2
Platform Differences in FTP File Services
There are no significant differences.
Upgrading File Services to OES
61
5.3.3
Planning
 “Requirements” on page 62
 “Limitations” on page 62
Requirements
Table 5-5 FTP Source and Target Server Requirements
Source Server
Target Server
NetWare 5.1 or later
OES 2 SP3 with the Novell FTP service pattern
installed but not configured.
Limitations
If a configuration exists on the target server, it is overwritten regardless of the migration type.
5.3.4
Transferring FTP Services to OES
You can use either of the two migration types offered by the Migration Tool to transfer FTP file
services from NetWare to OES 2:
 Consolidate: Both consolidation on the same tree and consolidation to a different tree are
supported. For more information, see Section A.1.1, “Consolidating Selected Data or Services,”
on page 101.
 Transfer ID: If you are transferring an entire NetWare server, including the FTP service and
associated data, to an OES 2 SP3 server, then you should transfer the entire server configuration.
Transfer ID migrations must occur within in the same tree. For more information, see
Section A.1.2, “Transferring an Entire NetWare Server,” on page 102.
To transfer Novell FTP from NetWare to OES 2, follow the instructions in “Migrating FTP from
NetWare to OES 2 Linux” in the OES 2 SP3: Migration Tool Administration Guide.
5.3.5
Post-Upgrade Checks
Verify a successful upgrade by making sure that the FTP service works as expected. For more
information, see “Post-Migration Procedure” in the OES 2 SP3: Migration Tool Administration Guide.
For help with LUM-enabling FTP users, see TID 3503915 (http://www.novell.com/support/php/
search.do?cmd=displayKC&docType=kc&externalId=3503915&sliceId=1&docTypeID=DT_TID_1_1&
dialogID=76627759&stateId=0%200%2076625913).
5.4
Upgrading iFolder to OES
 Section 5.4.1, “About iFolder on OES 2,” on page 62
 Section 5.4.2, “Platform Differences in iFolder File Services,” on page 64
 Section 5.4.3, “Planning,” on page 64
 Section 5.4.4, “Upgrading iFolder,” on page 65
 Section 5.4.5, “Post-Upgrade Checks,” on page 65
62
OES 2 SP3: Upgrading to OES—Best Practices Guide
5.4.1
About iFolder on OES 2
NetWare runs only iFolder 2.x while OES 2 runs iFolder 3.8, and as the version numbers imply,
iFolder on OES 2 is much more robust and flexible.
Figure 5-3 How Novell iFolder 3.8 Works
Access Methods
Authentication/File Encryption
iFolder 3.8 Services
iFolder 3.8
Enterprise servers
HTTP(S)
iFolder Client
for SLED
Sync
HTTP(S)
Master server
provides
access
Slave servers
provide
scalability
iFolder Client
for Macintosh
HTTP(S)
HTTP(S)
iFolder 3.8
Web Access Server
iFolder Client
for Windows
Upload or Download
HTTP(S)
Can run on an
iFolder 3.8 Enterprise server
or a different OES 2 server
eDirectory LDAP
server on the
same or different
OES 2 server
iFolder 3.8 Web Access
via a Web browser
eDirectory
LDAP server
The following table explains the information illustrated in Figure 5-3.
Upgrading File Services to OES
63
Access Methods
Authentication/File Encryption
Linux, Macintosh, and Windows
workstation users who have the Novell
iFolder® Client installed can access and
modify their files in one or more
workstation folders. Changes are
automatically synchronized with the
iFolder 3.8 Enterprise servers.
All file service access is
controlled by LDAP- based
authentication through the
eDirectory LDAP server.
A Web interface lets users access their
files from any computer with an active
network or Internet connection.
Although it is shown separately,
eDirectory could be installed on
the OES 2 server.
Files can be encrypted for
transport using SSL connections
(HTTPS).
Novell iFolder 3.8
Services
Slave servers can be
added as needed,
providing the ability to
dynamically grow iFolder
services without disrupting
users.
Local and network copies
of each file are
automatically
synchronized by the Novell
iFolder Client and Server
pieces.
Additional overview information is available in “Overview of Novell iFolder” in the Novell iFolder
3.8.4 Administration Guide.
5.4.2
Platform Differences in iFolder File Services
There are numerous significant differences between iFolder 2.x and iFolder 3.8, including:
 Automatic Service Provisioning: Multiple servers participate in a single iFolder domain, and
iFolder user assignments are automatically balanced across the domain.
 Multiple iFolders: Users can use a virtually unlimited number of iFolders.
 Sharing iFolders: Users can share their iFolders with other iFolder users, granting them full,
read/write, or read only access.
 File-type Synchronization: If desired, you can limit which file types are synchronized.
For a complete list of differences, see “Comparing Novell iFolder 2.x with 3.7 and Later Versions” in
the Novell iFolder 3.8.4 Administration Guide.
5.4.3
Planning
 “Requirements” on page 64
 “Limitations” on page 64
Requirements
Table 5-6 iFolder Source and Target Server Requirements
Source Server
Target Server
NetWare server with iFolder 2.x installed
One or more OES 2 SP3 servers installed.
The iFolder 3.8 service pattern is installed on each
server but not configured.
All iFolder 3.8 servers, the iFolder 3.8 Web Access
server, and eDirectory are up and running.
64
OES 2 SP3: Upgrading to OES—Best Practices Guide
Source Server
Target Server
Data must be moved before the iFolder service is
transferred.
If multiple servers are targeted, data migration is
balanced by default. Users are then assigned to the
appropriate iFolder. However, other provisioning
options are available.
For more information, see “Multi-Server Migration” in
the OES 2 SP3: Migration Tool Administration Guide.
Limitations
 “Moving Encrypted iFolders” on page 65
 “iFolder 2.x User Policies Not Transferred” on page 65
Moving Encrypted iFolders
The Migration Tool doesn’t move encrypted iFolders because user passphrases are needed. Each user
with an encrypted iFolder needs to perform a client-side migration if they want their iFolder 2.x data
moved to iFolder 3.8. For more information, see “Migrating from iFolder 2.x to iFolder 3.8.4” in the
Novell iFolder 3.8.4 Cross-Platform User Guide.
iFolder 2.x User Policies Not Transferred
iFolder 2.x configuration settings, such as user policies, are not compatible with iFolder 3.8 and are
therefore not transferred. You must set the policies for each user after the migration is complete.
5.4.4
Upgrading iFolder
You can use either of the two migration types offered by the Migration Tool to upgrade iFolder file
services from NetWare to OES 2:
 Consolidate: Both consolidation on the same tree and consolidation to a different tree are
supported. For more information, see Section A.1.1, “Consolidating Selected Data or Services,”
on page 101.
 Transfer ID: If you are transferring an entire NetWare server, including the iFolder service and
associated data to an OES 2 SP3 server, then you should transfer the entire server configuration.
Transfer ID migrations must occur within in the same tree. For more information, see
Section A.1.2, “Transferring an Entire NetWare Server,” on page 102.
To upgrade Novell iFolder on NetWare to OES 2, follow the instructions in “Migrating iFolder 2.x” in
the OES 2 SP3: Migration Tool Administration Guide.
5.4.5
Post-Upgrade Checks
As mentioned in “iFolder 2.x User Policies Not Transferred” on page 65, you must set a policy for
each user after the upgrade is finished.
Upgrading File Services to OES
65
5.5
Upgrading NetWare Core Protocol (NCP) File Services
The NetWare Core Protocol (NCP) Server provides the same file services on OES 2 that are available
on NetWare.
 Section 5.5.1, “About NCP File Services in OES 2,” on page 65
 Section 5.5.2, “Planning to Upgrade NCP File Services,” on page 67
 Section 5.5.3, “Only Data Transfers Are Required,” on page 68
5.5.1
About NCP File Services in OES 2
 “What NCP Server Provides” on page 66
 “What NCP Server Alone Doesn’t Provide” on page 67
What NCP Server Provides
With NCP Server, you can define NCP volumes (NCP shares on Linux Ext3 and Reiser file systems).
The advantage of using an NCP server is that you can control access using the Novell trustee model.
Windows and Linux workstations running Novell Client software can access data and manage file
sharing on OES 2 servers just as they do on NetWare servers, unless they need NSS file attributes (see
“What NCP Server Alone Doesn’t Provide” on page 67).
Novell NCP Server for OES enables support for login scripts, mapping drives to OES 2 servers, and
other services commonly associated with Novell Client access. This means that Windows users with
the Novell Client installed can be seamlessly transitioned to file services on OES 2.
Services provided by NCP include file access, file locking, security, resource allocation tracking, event
notification, and synchronization with other servers.
NCP is a client/server LAN protocol. Workstations create NCP requests and use TCP/IP to send them
over the network. At the server, NCP requests are received, unpacked, and interpreted.
Figure 5-4 illustrates the basics of NCP file services.
66
OES 2 SP3: Upgrading to OES—Best Practices Guide
Figure 5-4 NCP Services for OES and NetWare
Access Points
Authentication
NCP Server
OES 2 server
NCP
Novell Client
on SUSE Linux
Enterprise Desktop
and Windows
NetWare server
eDirectory
server
The following table explains the information illustrated in Figure 5-4.
Access Methods
Authentication
NCP Services
Access is through an NCP
client—specifically, the Novell
Client.
All file service access is
controlled by eDirectory
authentication.
Files are stored on NetWare or
NCP volumes that the
administrator has created.
The same core set of NetWare file
attributes are available on both
OES and NetWare.
What NCP Server Alone Doesn’t Provide
NSS file attributes and NCP services tend to get mixed together in the minds of NetWare
administrators. It is important to remember that file and directory attributes are supported and
enforced by the file system that underlies an NCP volume, not by the NCP server.
For example, even though the Rename Inhibit attribute appears to be settable in the NCP client
interface, if the underlying file system is Linux POSIX (Reiser, etc.) there is no support for the
attribute and it cannot be set.
Salvage (undelete) and Purge are other features that are available only on NSS and only where the
Salvage attribute has been set (the NSS default). They can be managed in the NCP client and through
NetStorage, but they are not available on NCP volumes where the underlying file system is Linux
POSIX.
Upgrading File Services to OES
67
Some administrators assume they can provide NSS attribute support by copying or moving files,
directories, and metadata from an NSS volume to a defined NCP volume on a Linux POSIX partition.
However, this doesn’t work, because NSS file attributes are only supported on NSS volumes.
5.5.2
Planning to Upgrade NCP File Services
 “Requirements” on page 67
 “Deciding Between a Linux POSIX File System and NSS” on page 68
 “The Novell Client Is Required” on page 68
Requirements
Table 5-7 NCP Source and Target Server Requirements
Source Server
Target Server
NetWare 5.1 or later
OES 2 SP3
The NCP Server pattern is installed.
Data can be moved independently of the server. Users
can always see what they have rights to see.
Deciding Between a Linux POSIX File System and NSS
For most system administrators, the most critical point of this decision is whether your organization
relies on NSS file and directory attributes as a key component of the Novell Trustee Access model. If
the answer is yes, then you should move your data to NSS volumes on OES 2, or mount existing NSS
volumes on the OES 2 servers.
If your organization doesn’t rely on NSS file and directory attributes and wants to transition to NCP
volumes defined on Linux POSIX file systems, then you can create those volumes on the target
servers and move the data by using the OES 2 SP3 Migration Tool.
The Novell Client Is Required
Novell Client software is required to initiate an NCP connection between a Windows or Linux
workstation running Novell Client software and an OES server running NCP Server services.
Intelligence at both ends of the connection works together to verify that clients are who they claim to
be, and that access controls are followed when using shared server files.
5.5.3
Only Data Transfers Are Required
You provide NCP services on an OES 2 server by installing the NCP Server pattern. There is no
upgrade path for the NCP server running on NetWare to NCP Server on OES.
If the data is properly moved to ensure that trustee assignments are left intact, users can access their
data using a Novell Client on a Linux or Windows workstation just as they did when the data resided
on a NetWare server.
68
OES 2 SP3: Upgrading to OES—Best Practices Guide
5.6
Upgrading NetStorage
 Section 5.6.1, “About NetStorage,” on page 68
 Section 5.6.2, “Platform Differences in NetStorage File Services,” on page 70
 Section 5.6.3, “NetStorage Is Not Transferred,” on page 71
5.6.1
About NetStorage
NetStorage provides secure Web access to files and folders on your OES and NetWare servers. It is a
bridge between a company's protected Novell storage network and the Internet. Using a Web
browser, your eDirectory users can securely copy, move, rename, delete, read, write, recover, and set
trustee assignments for their files from any Internet-attached workstation, anywhere in the world,
with nothing to download or install on the workstation.
NetStorage on OES provides local and Web access to files on many systems without requiring the
Novell Client (see Figure 5-5).
Figure 5-5 How NetStorage Works on OES 2
Access Methods
Authentication
Target Servers
NetStorage Server
Windows
Explorer
CIFS share
(NFAP)
WebDAV
CIFS share
(Samba)
Browser
CIFS
Windows
servers
SSH
HTTP
NCP
NetStorage
on
OES 2
to manage
Linux
traditional
volume
PDA
HTTP
NSS
volume
NetWare
Traditional
volume
NCP
volume
eDirectory/LDAP
(OES 2)
The following table explains the information illustrated in Figure 5-5.
Upgrading File Services to OES
69
Access Methods
Authentication
NetStorage Server
Target Servers
Users have read and write
access to files from
File service access is
controlled by LDAPbased authentication
through the eDirectory
LDAP server.
The NetStorage
server receives and
processes
connection requests
and provides access
to storage on various
servers on the
network.
NetStorage on OES can
connect eDirectory users
to their files and folders
stored in the following
locations:
 Windows Explorer: Is
enabled by the HTTP
protocol with WebDAV
extensions.
 Browsers: Users can
access files directly by
connecting to the
NetStorage server.
Although it is shown
separately, eDirectory
could be running on
the OES 2 server.
NetWare if the NCP
server is running
 Windows workgroup
shares (CIFS or
Samba shares)
 PDAs: PDA users with
 Linux POSIX
network connections
can also access their
files.
volumes through an
SSH connection.
Access is granted through
login script drive mapping
(NCP server required) or
through Storage Location
Objects.
5.6.2
 The same targets as
Linux volumes can also
be made available as
NCP volumes.
Management of NSS
volumes on OES 2
through NetStorage
requires SSH access to
the server. See “When Is
SSH Access Required?”
in the OES 2 SP3:
Planning and
Implementation Guide.
Platform Differences in NetStorage File Services
Although NetStorage provides the same basic services on NetWare and OES 2, there are significant
configuration differences, most of which are a natural result of the platform differences between
NetWare and OES:
Table 5-8 NetStorage Platform Differences
NetWare
OES 2
NetWare servers store data on NSS volumes.
OES servers accommodate many different file
systems, including NSS.
NetStorage is completely integrated with eDirectory
and NetWare.
NetStorage is well integrated with eDirectory and OES.
NetStorage relies heavily on NCP login scripts to
NetStorage uses Storage Location Objects to provision
provision user access to the storage locations it points storage locations that users access based on their
to.
rights.
NetStorage provides automatic Web access for iFolder An integration with iFolder 3.8 is not needed because
2.x when that service is installed on the same server
the iFolder 3.8 Web Server provides Web access for
as NetStorage.
iFolder users.
70
OES 2 SP3: Upgrading to OES—Best Practices Guide
Despite these differences, NetStorage on OES 2 is every bit as valuable as NetStorage on NetWare
and is well worth the small amount of time required to install and configure it.
5.6.3
NetStorage Is Not Transferred
Because of the differences explained above, it doesn’t make sense to transfer an exact NetStorage
configuration from NetWare to OES 2. Instead, you should move your data by using the Migration
Tool, then install and configure NetStorage on the OES2 server.
For most networks, NetStorage needs to be installed on only one server; however, this might vary
depending on the size of your network and your organization's needs. For example, if your company
is geographically dispersed, you might want to install NetStorage on one server in each geographic
region.
NetStorage can also be set up in a clustered environment so that if a NetStorage server goes down,
another NetStorage server in the cluster can take over the function of the downed server, and users
don't lose access to data.
For more information, see
 “NetStorage Implementation and Maintenance” in the OES 2 SP3: Planning and Implementation
Guide
 OES 2 SP3: NetStorage Administration Guide.
Upgrading File Services to OES
71
72
OES 2 SP3: Upgrading to OES—Best Practices Guide
6
Upgrading Print Services to OES
6
 Section 6.1, “About iPrint,” on page 73
 Section 6.2, “Platform Differences in iPrint,” on page 73
 Section 6.3, “Planning to Upgrade iPrint to OES,” on page 73
 Section 6.4, “Upgrading iPrint to OES,” on page 75
 Section 6.5, “Additional Information,” on page 75
TIP: If any printers in your environment have IPX™ enabled but not configured, you should disable
them to free up JetDirect* and LAN bandwidth.
6.1
About iPrint
The currently supported Novell® print service, iPrint, is a greatly enhanced version of NDPS that is:
 Completely IP-based and platform independent on both the client and server side
 Not dependent on the Novell Client™
 Web-based for both printer provisioning and deployment
 Fully cluster-aware
6.2
Platform Differences in iPrint
There are two basic differences between iPrint on NetWare® and iPrint on OES 2, neither of which
should impact your upgrade plans:
 The back end infrastructures are different
 iPrint on OES does not support NDPS/NCP™ client-based printing
Both OES and NetWare support the same iPrint workstation agent.
6.3
Planning to Upgrade iPrint to OES
 Section 6.3.1, “Requirements and Recommendations,” on page 74
 Section 6.3.2, “Limitations,” on page 74
Upgrading Print Services to OES
73
6.3.1
Requirements and Recommendations
 “Platforms” on page 74
 “Prepare the Workstations First” on page 74
 “Use DNS Names Rather than IP Addresses” on page 74
Platforms
Table 6-1 iPrint Source and Target Server Requirements
Source Server
Target Server
NetWare 5.1 or later
OES 2 SP3 with iPrint installed and the Driver Store
configured
Prepare the Workstations First
Novell recommends deploying the iPrint agent to workstations before converting the backend
infrastructure to OES 2. This will allow for the phased removal of the NDPS-based printers from the
workstations before it becomes a requirement with the deployment of iPrint on OES 2. This will
allow for a phased and transparent OES 2 printing services for users.
Automated tools are available to deploy the iPrint agent to any workstations still using NDPS. This
can also be done using a ZENworks application deployment. A silent install option is available.
Use DNS Names Rather than IP Addresses
An additional consideration is the use of literal IP addresses vs. DNS entries with the printer
configurations deployed to the workstations. If the printer/manager configurations are using IP
address assignments rather than DNS, Novell recommends deploying the iPrint agent to all of the
workstations and changing the existing iPrint managers to a DNS configuration. This will allow you
to convert to iPrint in OES without having to revisit the workstations.
If you use DNS, the new iPrint infrastructure can be transferred to OES in phases while leaving the
existing NetWare infrastructure in place. The users are converted over when the DNS entry for each
individual print manager is changed.
6.3.2
Limitations
You can't migrate printer object ACL (Access Control List) assignments when migrating cross-tree.
When migrating from OES 1 to OES2, the iPrint Direct setting from the source printer agents will not
get transferred to OES 2.
74
OES 2 SP3: Upgrading to OES—Best Practices Guide
6.4
Upgrading iPrint to OES
iPrint can be installed and configured on OES 2 in parallel with an existing print environment to
allow for a phased migration of users to the iPrint infrastructure. While iPrint can be used to support
queue-based printing, it is not the preferred method (the only normal requirement to maintain a
queue is to support legacy DOS-based applications that print directly to a queue rather than to a
Windows printer or LPT port).
Novell recommends the following steps to bring a current printing environment up to supported
standards before transferring your print infrastructure to OES 2 clusters as required:
 Install and configure iPrint on any NetWare 6.5 clusters.
 Install and configure all network printers in iPrint.
 Install and configure web-based client deployment tools.
 Set up iPrint on OES 2.
 Deploy iPrint agents to workstations.
Novell's Server Consolidation and Migration Tool or the OES 2 SP3 Migration Tool are available to
copy a NetWare-based iPrint/NDPS environment to an OES iPrint infrastructure. This allows for a
phased parallel installation approach to an OES upgrade with minimal user and administrative
impacts. Using a mixed OES and NetWare based printing environment within the same tree is fully
supported.
6.5
Additional Information
See “Migrating iPrint from NetWare or OES 2 Linux to OES 2 SP3 Linux” in the OES 2 SP3: Migration
Tool Administration Guide.
Upgrading Print Services to OES
75
76
OES 2 SP3: Upgrading to OES—Best Practices Guide
7
Upgrading QuickFinder to OES
7
This section provides information about upgrading QuickFinder™ from NetWare® to OES. For
complete information, refer to the OES 2 SP3: Novell QuickFinder Server 5.0 Administration Guide.
 Section 7.1, “About QuickFinder in OES 2,” on page 77
 Section 7.2, “Platform Differences in QuickFinder,” on page 77
 Section 7.3, “Planning to Upgrade QuickFinder,” on page 78
 Section 7.4, “Upgrading QuickFinder to OES,” on page 78
 Section 7.5, “Post-Upgrade Considerations,” on page 78
7.1
About QuickFinder in OES 2
QuickFinder lets users search for information on any of your public and private Web sites, partners'
sites, and any number of additional Web sites across the Internet or on internal file servers, all from a
single search form on your Web page.
The look and feel of the search page is configurable so you can match your corporate design.
Using the QuickFinder Unicode* indexing engine, you can create full-text indexes of
 HTML
 XML
 PDF
 Word
 OpenOffice.org documents
 Many other document formats in almost any language
You can also configure and maintain such indexes remotely from anywhere on the network with the
QuickFinder Web-based administration module.
7.2
Platform Differences in QuickFinder
There are no significant differences between QuickFinder running on NetWare and QuickFinder
running on OES 2.
Upgrading QuickFinder to OES
77
7.3
Planning to Upgrade QuickFinder
Upgrading QuickFinder to OES is a manual process, but it is also very straightforward, as is the
planning process:
1. Identify the QuickFinder service you plan to upgrade from NetWare to OES 2.
2. Install QuickFinder on the OES 2 server, using the Novell QuickFinder service pattern.
7.4
Upgrading QuickFinder to OES
Complete the instructions in “Migrating QuickFinder Server from NetWare to OES 2 Linux” in the
OES 2 SP3: Novell QuickFinder Server 5.0 Administration Guide.
7.5
Post-Upgrade Considerations
Complete the instructions in “Post-Migration Considerations” in the OES 2 SP3: Novell QuickFinder
Server 5.0 Administration Guide.
78
OES 2 SP3: Upgrading to OES—Best Practices Guide
8
Upgrading Backup Services to OES
8
 Section 8.1, “Upgrading Novell Archive and Versioning Services to OES,” on page 79
 Section 8.2, “About Upgrading Storage Management Services (SMS),” on page 80
8.1
Upgrading Novell Archive and Versioning Services to OES
 Section 8.1.1, “About Archive and Versioning Services in OES 2,” on page 79
 Section 8.1.2, “Platform Differences in Archive and Versioning Services,” on page 79
 Section 8.1.3, “Planning to Upgrade Archive and Versioning Services,” on page 79
 Section 8.1.4, “Upgrading Archive and Versioning Services,” on page 80
 Section 8.1.5, “Post-Upgrade Procedures,” on page 80
8.1.1
About Archive and Versioning Services in OES 2
Archive and Versioning Services provide a convenient and cost-effective way for individual users to
instantly restore previous versions of modified, renamed, or deleted files. Interval-based file versions
are archived and presented for restoration based on the date of the file change or the user who
modified the files. To restore a file, users simply view a list of the archived file versions and select the
version they want.
8.1.2
Platform Differences in Archive and Versioning Services
The setup process varies slightly between NetWare and OES 2, but there are no functional
differences.
8.1.3
Planning to Upgrade Archive and Versioning Services
 “Requirements” on page 79
 “Limitations” on page 80
Requirements
Before upgrading, make sure to do the following:
1. Install an NSS volume on the OES 2 server.
2. Make sure the Archive server and the Primary volume reside in the same eDirectory™ tree.
3. Make sure the Archive server, PostgreSQL database, and Archive volume are installed on the
same machine.
Upgrading Backup Services to OES
79
Table 8-1 Archive and Versioning Source and Target Server Requirements
Source Server
Target Server
NetWare 6.5 SPX
OES 2 SP3.
The Novell Archive and Versioning Services pattern is
installed but not configured.
The Archive volume, configuration file, and the
database are moved as part of the process.
Limitations
If a configuration exists on the target server, it is overwritten regardless of the migration type.
8.1.4
Upgrading Archive and Versioning Services
You can use either of the two migration types offered by the Migration Tool to transfer Archive and
Versioning Services from NetWare to OES 2:
 Consolidate: Only consolidation on the same tree is supported. For more information, see
Section A.1.1, “Consolidating Selected Data or Services,” on page 101.
 Transfer ID: You can transfer an entire NetWare server, including Novell Archive and
Versioning Services, to an OES 2 SP3 server. Transfer ID migrations must occur within in the
same tree. For more information, see Section A.1.2, “Transferring an Entire NetWare Server,” on
page 102.
To upgrade Novell Archive and Versioning Services from NetWare to OES 2, follow the instructions
in “Migrating Novell Archive and Version Services to OES 2 SP3 Linux” in the OES 2 SP3: Migration
Tool Administration Guide.
8.1.5
Post-Upgrade Procedures
Before restarting the Archive server, be sure to complete the steps in “Verifying Migration” in the
OES 2 SP3: Migration Tool Administration Guide.
8.2
About Upgrading Storage Management Services (SMS)
The Novell Storage Management Services™ (SMS) backup infrastructure provides backup
applications with the framework to develop a complete backup and restore solution.
SMS helps back up file systems (such as NSS) or application data, such as data from GroupWise® on
NetWare and SUSE® Linux Enterprise Server (SLES), to removable tape media or other media for offsite storage. It provides a single consistent interface for all file systems and applications across
NetWare and SLES.
The upgrade path for SMS is to install it on the OES 2 server.
80
OES 2 SP3: Upgrading to OES—Best Practices Guide
9
Upgrading Network Services to OES
9
Network services are critical to event coordination and service discovery.
 Section 9.1, “Upgrading DNS Services to OES,” on page 81
 Section 9.2, “Upgrading DHCP Services to OES,” on page 82
 Section 9.3, “Time Synchronization,” on page 83
 Section 9.4, “Service Location Protocol (SLP),” on page 85
9.1
Upgrading DNS Services to OES
With OES 2, DNS has been integrated with eDirectory™. This means you can transition your existing
DNS infrastructure from NetWare® to OES, as well as centrally administer it the same way you do on
NetWare.
 Section 9.1.1, “About Novell DNS in OES 2,” on page 81
 Section 9.1.2, “Platform Differences in Novell DNS,” on page 81
 Section 9.1.3, “Planning to Upgrade Novell DNS,” on page 81
 Section 9.1.4, “Upgrading DNS,” on page 82
9.1.1
About Novell DNS in OES 2
To accomplish eDirectory integration for DNS, Novell® did a full port of NetWare DNS to OES to
make it functionally equivalent to DNS in NetWare 6.5. Novell plans in the future to fully integrate all
of the required functionality into the open source BIND project.
The administration of DNS does not change between NetWare and OES 2; either iManager or the
Java* console can be used as the administrative tool. If you are using the Novell NetWare DNS and
DHCP services and hosting it via a cluster, this configuration can also be carried forward into an OES
2 environment.
9.1.2
Platform Differences in Novell DNS
DNS platform differences are summarized in “DNS Differences Between NetWare and OES 2” in the
OES 2 SP3: Planning and Implementation Guide.
9.1.3
Planning to Upgrade Novell DNS
 “Requirements” on page 82
 “Limitations” on page 82
Upgrading Network Services to OES
81
Requirements
Table 9-1 DNS Source and Target Server Requirements
Source Server
Target Server
NetWare 5.1 SP8
OES 2 SP3.
NetWare 6.0 SP5 or later
NetWare 6.5 SP5 or later
The Novell DNS service pattern is installed.
The schema is extended, the DNS-DHCP group is
created, and the RootServerInfo and DNS-DHCP
Locator objects are created.
The installing administrator has rights to update files
on the target server and is a member of the DNSDHCP Group.
Limitations
9.1.4
Upgrading DNS
DNS servers can be transferred both within and across eDirectory trees by using either iManager or
the Java Console. The OES 2 SP3 Migration Tool doesn’t support DNS migrations.
For instructions, see “Migrating DNS from NetWare to OES 2 SP3 Linux” in the OES 2 SP3: Migration
Tool Administration Guide.
9.2
Upgrading DHCP Services to OES
With OES 2, DHCP has been integrated with eDirectory. This means you can transition your existing
DHCP infrastructure from NetWare to OES, as well as centrally administer it the same way you do on
NetWare.
 Section 9.2.1, “About Novell DHCP in OES 2,” on page 82
 Section 9.2.2, “Platform Differences in Novell DHCP,” on page 83
 Section 9.2.3, “Planning to Upgrade Novell DHCP,” on page 83
 Section 9.2.4, “Upgrading DHCP,” on page 83
9.2.1
About Novell DHCP in OES 2
The DHCP services in OES 2 have been enhanced to store configuration information in eDirectory
just as NetWare implementations do.
After the DHCP information has been migrated to OES 2, administration can be performed through
iManager and also an update to the DNS/DHCP Java Console.
82
OES 2 SP3: Upgrading to OES—Best Practices Guide
9.2.2
Platform Differences in Novell DHCP
DHCP platform differences are summarized in “DHCP Differences Between NetWare and OES 2” in
the OES 2 SP3: Planning and Implementation Guide.
9.2.3
Planning to Upgrade Novell DHCP
 “Requirements” on page 83
 “Limitations” on page 83
Requirements
Table 9-2 DHCP Source and Target Server Requirements
Source Server
Target Server
NetWare 5.1 or later
OES 2 SP3.
The Novell DHCP service pattern is installed and
configured.
The source and target servers have their times
synchronized.
Limitations
9.2.4
Upgrading DHCP
To transfer Novell DHCP services from NetWare to OES 2, follow the instructions in “Migrating
DHCP from NetWare to OES 2 SP3 Linux” in the OES 2 SP3: Migration Tool Administration Guide.
9.3
Time Synchronization
Time synchronization is critical to maintaining the integrity of the tree.
 Section 9.3.1, “About Time Synchronization in OES 2,” on page 83
 Section 9.3.2, “Planning to Upgrade Time Synchronization Services,” on page 84
 Section 9.3.3, “Transferring Time Synchronization Services,” on page 85
9.3.1
About Time Synchronization in OES 2
In earlier versions of eDirectory, replica synchronization required proper time synchronization.
Currently, replica synchronization uses time stamps from host servers without checking for proper
time synchronization. This means that if the host servers are not time-synchronized, events can be
logged out of sequence, resulting in inconsistent information about what took place and in what
order.
Upgrading Network Services to OES
83
What NTP Provides
All servers with Internet access can get time from NTP servers on the Internet. NTP synchronizes
clocks to the Universal Time Coordinated (UTC) standard, which is the international time standard.
The hierarchy that indicates where each server is getting its time is referred to as a stratum, with the
first time provider designated as stratum 1.
A server that gets its time from a stratum 1 server is stratum 2, and so on.
The TIMESYNC NLM™ can consume and provide NTP time, but it always functions as stratum 5.
Use a Reliable, External Time Source
By default, NTP uses the server’s internal clock as its time provider, but it can be configured to use
other time providers via the /etc/ntp.conf file.
NTP time can be supplied from several sources:
 Public Time Server. For small organizations (fewer than 100 servers), synchronizing servers to
accurate public NTP servers provides sufficient time synchronization. To reduce traffic, it's best
to have one or two servers synchronize with a public NTP source and have those servers provide
time for the remaining servers. See http://ntp.isc.org/bin/view/Servers/WebHome.
Reference Clock. Reference clocks are devices that synchronize via a variety of technologies
including long wave radio signals, GPS transmissions, or CDMA technology. These can be
expensive.
Server's Local Clock. The server's internal clock can be used as a time source, but because time
can wander, this is generally not a preferred solution.
Network NTP Time Source. This is the recommended option for larger networks. In this case,
you need to set up a server as an NTP time provider and then add the IP address of the time
source to the /etc/ntp.conf file for servers that will use the designated server as the time
provider.
9.3.2
Planning to Upgrade Time Synchronization Services
Both the OES and the NetWare installs automate the time synchronization process where possible.
For complete information about planning and implementing a time synchronization strategy and
setting up time providers and consumers, see “Time Services”, particularly “Implementing Time
Synchronization” in the OES 2 SP3: Planning and Implementation Guide.
Also consider the following points.
 Designate the most reliable server in the subnet as the time provider.
 Configure at least two time providers to set fault tolerance.
 Configure time consumers to contact a time provider within its own local network (so they don't
contact time providers across costly WANs).
 Generally, only one server in a network should communicate with an external time provider.
This reduces network traffic across geographical locations and minimizes traffic across routers
and WANs.
NOTE: The time synchronization modules in Novell Open Enterprise Server (OES) have been
designed to ensure that new OES 2 servers can be introduced into an existing network environment
without disrupting any of the products and services that are in place.
84
OES 2 SP3: Upgrading to OES—Best Practices Guide
9.3.3
Transferring Time Synchronization Services
You can use either of the two migration types offered by the Migration Tool to transfer time
synchronization services from NetWare to OES 2:
 Consolidate: Both consolidation on the same tree and consolidation to a different tree are
supported. For more information, see Section A.1.1, “Consolidating Selected Data or Services,”
on page 101.
 Transfer ID: Transfer ID migrations must occur within in the same tree. For more information,
see Section A.1.2, “Transferring an Entire NetWare Server,” on page 102.
To transfer time synchronization services from NetWare to OES 2, follow the instructions in
“Migrating Timesync/NTP from NetWare to NTP on OES 2 Linux” in the OES 2 SP3: Migration Tool
Administration Guide.
9.4
Service Location Protocol (SLP)
SLP is not a migratable service, however, it is a critical component of OES 2 and must be planned as
part of your upgrade strategy.
 Section 9.4.1, “About SLP in OES 2,” on page 85
 Section 9.4.2, “Platform Differences in SLP Services,” on page 85
 Section 9.4.3, “Setting Up SLP on OES 2,” on page 86
9.4.1
About SLP in OES 2
SLP lets network services register their availability on the network. SLP agents then keep track of
which services are available and provide that information to applications that need it, such as the
Novell Client™.
For example, without an advertisement or discovery mechanism like SLP, users must know the IP
address or DNS name of a server hosting the tree in order to log in and use network services. Without
SLP, browsing for trees on the network would not be possible.
9.4.2
Platform Differences in SLP Services
 “SLP on NetWare” on page 85
 “SLP on OES 2 SP3” on page 86
 “Caveats” on page 86
SLP on NetWare
NetWare uses a Novell customized version of SLP called Novell SLP that provides an additional
agent type, the Directory Agent or DA, which can synchronize information between DAs.
On NetWare, SLP services are integrated with and configured to automatically work with eDirectory
and other services; if eDirectory is configured correctly, the services work without SLP.
If you have a NetWare tree, you automatically have Novell SLP on your network and you can
continue to use it as the SLP service during your upgrade to OES 2.
Upgrading Network Services to OES
85
The Novell version of SLP takes certain liberties with the SLP standard in order to provide a more
robust service advertising environment, but it does so at the expense of some scalability. For a
discussion of SLP and OpenSLP and references to documents essential to understanding the
protocol, refer to “Configuring OpenSLP for eDirectory” in the Novell eDirectory 8.8 Installation Guide.
SLP on OES 2 SP3
Novell provides a basic level of SLP support when eDirectory is installed on an OES server. OES
servers are configured with an SA that registers SLP-aware applications (such as eDirectory) with the
server.
However, you should configure OpenSLP (the default SLP service for OES), especially if you are
installing more than three servers in a replica ring or eDirectory partition. The first three servers in a
replica ring or eDirectory partition have an eDirectory replica installed automatically. The fourth and
subsequently installed servers in a replica ring or eDirectory partition must have SLP configured for
all services to work properly.
Caveats
 DA synchronization is not part of OpenSLP.
 If you are running NetWare 5.1 in your tree, it must be at SP8 to have SLP version 2 functionality.
Older versions are not compatible with OpenSLP running on OES 2.
 If your workstations can connect to the server using its IP address but not its DNS name, you
need to update to Novell Client 4.91 SP5 or later. See TID 3890003 (http://www.novell.com/
support/php/
search.do?cmd=displayKC&docType=kc&externalId=3890003&sliceId=1&docTypeID=DT_TID_
1_1&dialogID=66172729&stateId=0%200%2066174133).
9.4.3
Setting Up SLP on OES 2
 “Enabling Multicasting” on page 86
 “Installing and Configuring OpenSLP” on page 87
 “Additional Information” on page 87
Enabling Multicasting
SLP relies on multicasting; however, most Linux systems are not configured, by default, to provide
multicast support. Enter the following at the shell prompt to determine whether multicasting is
supported:
route -n
If multicasting is supported, you see an entry in the routing table for the 224.0.0.0 destination.
If not:
1 Open a terminal session.
2 Change to the root user account.
3 At the shell prompt, enter the following command:
route add -net 224.0.0.0 netmask 240.0.0.0 dev interface
86
OES 2 SP3: Upgrading to OES—Best Practices Guide
(eth0 is usually the interface parameter)
4 Verify that the route has been added by entering route -n at the shell prompt.
Installing and Configuring OpenSLP
Open SLP is available as an RPM and provides UA, SA. and DA functionality. You can download a
copy from http://www.openslp.org./ (http://www.openslp.org./), It is also included with SLES 10 SP1.
OpenSLP installs like any other RPM by using the rpm -i command. The slpd daemon is installed in
the /usr/sbin directory on the server.
After it is installed, you can configure the slpd daemon by editing the /etc/slp.conf file.
 To configure the daemon to run every time the server is booted, use the following command:
chkconfig slpd 345
 To configure an OES 2 server as a DA, edit the “Static Scope and DA Configuration” portion of
the file.
 To run the daemon, enter slpd at the shell prompt.
For additional OpenSLP setup instructions, see “Setting Up OpenSLP on OES 2 Networks” in the
OES 2 SP3: Planning and Implementation Guide.
Additional Information
 Novell eDirectory 8.8 Administration Guide, “Configuring OpenSLP for eDirectory”
Upgrading Network Services to OES
87
88
OES 2 SP3: Upgrading to OES—Best Practices Guide
10
Upgrading Novell Cluster Services to
OES
10
Novell® Cluster Services™ is a server clustering system that allows you to configure up to 32 OES
servers into a high-availability cluster. You can move resources, either manually or automatically, to
any server in the cluster. It is enabled for Novell eDirectory™ and supports failover, failback, and
load balancing of individually managed cluster resources including data, applications, and services.
 Section 10.1, “Overview,” on page 89
 Section 10.2, “Planning to Upgrade Novell Cluster Services,” on page 90
 Section 10.3, “Prerequisites,” on page 91
 Section 10.4, “Caveats,” on page 92
 Section 10.5, “Rolling Cluster Conversions,” on page 92
10.1
Overview
You can add OES nodes to an existing NetWare 6.5 cluster without bringing down the cluster, or you
can create an all-OES cluster. With a mixed cluster, you can transfer services between OS kernels, and
if services (such as NSS) are alike on both platforms, you can set the services to fail over across
platforms.
Typical cluster configurations normally include a shared disk subsystem connected to all servers in
the cluster. This disk subsystem can be connected via high-speed Fibre Channel cards, cables, and
switches for best performance, or by a shared SCSI or iSCSI for a low-cost SAN. If a server fails,
another designated server in the cluster automatically mounts the shared disk directories previously
mounted on the failed server. This gives network users continuous access to the directories on the
shared disk subsystem.
Novell Cluster Services can be set up on OES in several ways:
 Implementing a new installation on OES that is separate from your NetWare cluster. The pattern
install also installs these complementary services:
 Novell Backup/Storage Management Services (SMS)
 Novell Linux User Management (LUM)
 Novell Remote Manager (NRM)
 Adding OES nodes to an existing NetWare cluster
 Changing existing NetWare cluster nodes to OES cluster nodes (Rolling Cluster Conversion)
 Using a mixed NetWare/OES cluster
Using the Novell Cluster Services tool to manage live cluster transfers from the Novell NetWare OS
to Novell SUSE® Linux via a rolling conversion is one of the easier methods and is documented here.
Upgrading Novell Cluster Services to OES
89
10.2
Planning to Upgrade Novell Cluster Services
 Section 10.2.1, “Reviewing the Current Cluster,” on page 90
 Section 10.2.2, “Upgrading Novell Cluster Services to OES 2,” on page 90
 Section 10.2.3, “Additional Information,” on page 91
10.2.1
Reviewing the Current Cluster
Typically, the primary purpose of a cluster is to provide file and print services. Make sure you check
the volume resources because it is easy to overload these services. As a general guideline, Novell
recommends that NSS volume resources be kept at a total capacity of 80% or less. If you need to
reduce the number of standalone servers in production, the logical approach is to move data and
transfer services into the high availability resources of a cluster.
 Review the health of NCS background operations to resolve any operational issues with the
cluster.
 Make sure all cluster nodes are up to the latest support pack levels.
 Avoid spanning LUNs across NSS pools
 Where necessary, review and modify the cluster design to take full advantage of the High
Availability capabilities of current release software.
Novell recommends the following steps to address both the reliability and the performance of your
current cluster:
 Make sure all NetWare nodes are at NetWare 6.5 SP7 or later
 Use relatively small LUNs and data volumes
 Introduce OES 2 nodes as required
 Reconfigure the SAN to host DST shadow volumes
10.2.2
Upgrading Novell Cluster Services to OES 2
There are a two paths for moving existing NetWare clusters to OES: converting the existing clusters
(also referred to as a rolling cluster conversion) or using a parallel build.
 Cluster Conversion (Same Cluster). In order to convert existing clusters, new OES 2 servers
need to be built with the same LUN visibility as the existing NetWare nodes and the new servers
added to the existing cluster. The new OES nodes then mount the existing volumes and services,
and the NetWare servers are removed from the cluster and removed from eDirectory. Although
it is feasible to use a mixed NetWare and OES cluster temporarily as an upgrade strategy, Novell
does not recommend it as a permanent production implementation.
 Parallel Build (New Cluster). A parallel-build OES upgrade strategy entails building a new
separate OES 2 cluster on the same SAN as the existing NetWare clusters. Doing so allows
resources to be moved to the new cluster by changing LUN visibility from the old cluster nodes
to the new. This can also be done in a phased approach. After the last resource is moved, the
NetWare cluster can be removed from the tree. Because it is a new cluster, the virtual server
names will change and login scripts and other references will need to be updated during the
upgrade process.
There are pros and cons to each approach so you need to do a more detailed analysis and have
assistance from Novell Consulting before upgrading a cluster.
90
OES 2 SP3: Upgrading to OES—Best Practices Guide
Novell Cluster Services software must be running on the OES server (SLES 10 and OES 2 must be
installed on every server you want to add to a cluster). You can install Novell Cluster Services and
create a new cluster, or add a server to an existing cluster either during the SLES 10/OES installation
or afterwards, using YaST.
See “Installing Novell Cluster Services during a OES 2 Linux Installation” and “Installing Novell
Cluster Services on an Existing OES 2 Linux Server” in the OES 2 SP3: Novell Cluster Services 1.8.8
Administration Guide for Linux.
10.2.3
Additional Information
Refer to the following sections in the OES 2 SP3: Novell Cluster Services 1.8.8 Administration Guide for
Linux for additional information about transferring Novell Cluster Services to OES:
 “Converting NetWare 6.5 Clusters to OES 2 Linux”
 “Upgrading OES 1 Linux Clusters to OES 2 Linux”
10.3
Prerequisites
 Any NetWare cluster to be converted must be running at least NetWare 6.0. If you have a
NetWare 5.1 cluster, you must upgrade to a NetWare 6.5 cluster before adding new OES cluster
nodes or converting existing NetWare cluster nodes to OES cluster nodes. The process for
converting 6.0 and 6.5 nodes is the same.
 Each OES server must contain at least one local disk device.
 At least 512 MB of memory must be available on each server in the cluster.
While identical hardware for each cluster server is not required, having servers with the same or
similar processors and memory can reduce differences in performance between cluster nodes.
 All nodes in a given cluster, whether NetWare or OES:
 Must be configured with a static IP address.
An additional IP address needs to be available for the cluster and for each cluster resource
and cluster-enabled pool.
 Must reside on the same IP subnet and in the same eDirectory tree.
 A shared disk subsystem should be connected to all servers in the cluster (optional, but
recommended for most configurations) and should be properly set up and functional according
to the manufacturer's instructions.
 We recommend configuring the disks contained in the shared disk system to use mirroring or
RAID to add fault tolerance to the shared disk system.
 At least 20 MB of free disk space on the shared disk system needs to be available for creating a
cluster partition.
The Novell Cluster Services installation automatically allocates one cylinder on one drive of the
shared disk system for the cluster partition. Depending on the location of the cylinder, the actual
amount of space used by the cluster partition might be less than 20 MB.
 High-speed Fibre Channel cards, cables, and switch or SCSI cards and cables need to be installed
to connect the servers to the shared disk subsystem.
 If you are using a fibre channel SAN, the host bus adapters (HBAs) for each cluster node
should be identical.
 If you are using iSCSI for shared disk system access, make sure you have configured iSCSI
initiators and targets prior to installing Novell Cluster Services.
Upgrading Novell Cluster Services to OES
91
 Novell Cluster Services software must be running on the OES server (SLES 10 and OES must be
installed on every OES 2 server added to a cluster). You can install Novell Cluster Services and
create a new cluster, or add a server to an existing cluster either during the SLES 10/OES
installation or afterwards, using YaST.
See “Installing Novell Cluster Services during a OES 2 Linux Installation” and “Installing Novell
Cluster Services on an Existing OES 2 Linux Server” in the OES 2 SP3: Novell Cluster Services 1.8.8
Administration Guide for Linux."
10.4
Caveats
There are several caveats that you need to be aware of:
 Resources created on OES cannot run on NetWare.
 You cannot add additional NetWare nodes to your cluster after adding a new OES node or
changing an existing NetWare cluster node to an OES cluster node. If you want to add NetWare
cluster nodes after converting part of your cluster to OES, you must first remove the OES nodes
from the cluster.
 The server that holds the master eDirectory replica needs to be converted last, at the end of the
rolling cluster conversion, not first.
 You can't change existing shared pools or volumes (storage reconfiguration) in a mixed
NetWare/OES cluster. If you need to make changes to existing pools or volumes, you must
temporarily bring down either all OES cluster nodes or all NetWare cluster nodes prior to
making changes. Attempting to reconfigure shared pools or volumes in a mixed cluster can
cause data loss.
10.5
Rolling Cluster Conversions
Performing a rolling cluster conversion from NetWare 6.5 to OES is one of the easier ways to upgrade
Cluster Services to OES and keep your cluster up and running during the process.
In this method, one server is converted to OES while the other servers in the cluster continue running
NetWare 6.5. Then, as needed, other nodes can be converted to OES incrementally until all servers in
the cluster have been converted. Although it is feasible to use a mixed NetWare and OES cluster
temporarily as an upgrade strategy, Novell does not recommend it as a permanent production
implementation.
Refer to “Converting NetWare 6.5 Clusters to OES 2 Linux” in the OES 2 SP3: Novell Cluster Services
NetWare to Linux Conversion Guide for instructions on performing a rolling cluster upgrade.
92
OES 2 SP3: Upgrading to OES—Best Practices Guide
11
Upgrading Other Novell Products to OES
1
The information in this section was contributed by the GroupWise® and ZENworks® teams.
 Section 11.1, “GroupWise 7 and GroupWise 8,” on page 93
 Section 11.2, “Identity Manager,” on page 97
 Section 11.3, “ZENworks,” on page 97
11.1
GroupWise 7 and GroupWise 8
 Section 11.1.1, “Source Platform Requirements,” on page 93
 Section 11.1.2, “Target Platform Requirements,” on page 93
 Section 11.1.3, “Preparing to Migrate,” on page 94
 Section 11.1.4, “Caveats,” on page 94
 Section 11.1.5, “Tool Options,” on page 94
 Section 11.1.6, “Migration Instructions,” on page 95
 Section 11.1.7, “Migrating GroupWise as Part of a Transfer ID Migration,” on page 95
 Section 11.1.8, “Additional Information,” on page 96
11.1.1
Source Platform Requirements
You can migrate directly from any of the NetWare® platforms that support GroupWise 7 or
GroupWise 8 as listed in the GroupWise documentation (http://www.novell.com/documentation/
gwutilities/gw8_svrmig/data/b6ub1ga.html).
11.1.2
Target Platform Requirements
Although other suppored platforms are listed in the GroupWise documentation (http://
www.novell.com/documentation/gw8/gw8_admin_qs/data/gw8_admin_qs.html#aix5v8a), this
guide focuses on migrating to OES 2.
For specific planning instructions, see the following information:
 GroupWise 7: “Planning Your Basic GroupWise System” (http://www.novell.com/
documentation/gw7/gw7_install/data/a4bblzn.html) in the GroupWise 7 Installation Guide (http://
www.novell.com/documentation/gw7/gw7_install/data/a20gkue.html).
 GroupWise 8: “Planning a Basic GroupWise System” (http://www.novell.com/documentation/
gw8/gw8_install/data/a4bblzn.html) in the GroupWise 8 Installation Guide (http://
www.novell.com/documentation/gw8/gw8_install/data/a20gkue.html).
Upgrading Other Novell Products to OES
93
11.1.3
Preparing to Migrate
Probably the most important tip to a successful migration is to make sure, before starting the
migration, that the source NetWare server has the latest GroupWise support pack installed, and that
GroupWise is running without problems.
The GroupWise documentation includes thorough migration planning instructions in “Planning
Your GroupWise Server Migration” (http://www.novell.com/documentation/gwutilities/
gw8_svrmig/data/b65pbe1.html) in the GroupWise Server Migration Utility Installation and Migration
Guide (http://www.novell.com/documentation/gwutilities/gw8_svrmig/data/ab32nt1.html).
11.1.4
Caveats
 Earlier Version of GroupWise: If you are running an earlier version of GroupWise on NetWare,
you must upgrade to GroupWise 7 or GroupWise 8 with the latest support pack before
migration to OES 2.
 Migrating vs. installing GWIA and WebAccess: Novell Support recommends deleting the
NetWare-based GWIA and WebAccess objects and then installing new GWIA and WebAccess
services on OES, even though there are instructions for migrating the GWIA and WebAccess
services from NetWare to OES in the documentation.
11.1.5
Tool Options
You have two options for migrating GroupWise from NetWare to OES 2:
 GroupWise Server Migration Utility: This lets you identify the components (Post Office agents,
etc.) to be migrated from NetWare to OES and then installs GroupWise, configures the agents,
and migrates the data—all in real time. The process is flexible, allowing you to choose which
components to migrate when.
During the initial transfer, the original server is maintained, letting you continue to run
GroupWise on NetWare until the migration is complete and you are satisfied with the results.
After the initial transfer, the utility guides you through testing the system on the new OES
server, and then when you are ready to switch, it migrates any data that was altered since the
initial transfer and activates GroupWise on the OES server. This is the only point in the process
when post office agents are taken down.
 Manual Process: Although it is much more involved and labor-intensive, some prefer to migrate
GroupWise manually. The results are the same as the automated process, if all of the instructions
are followed carefully.
Installation Is Included
Some administrators have incorrectly assumed that they must install GroupWise on the target server
prior to the migration. Actually, GroupWise is installed on the OES 2 server as part of the migration.
Upgrading the GroupWise Version Is Not Included
You cannot upgrade GroupWise as part of the migration to OES. Specifically, you cannot migrate
from GroupWise 7 on NetWare to GroupWise 8 on OES 2.
94
OES 2 SP3: Upgrading to OES—Best Practices Guide
11.1.6
Migration Instructions
 “Manual Method” on page 95
 “Automated Method” on page 95
Manual Method
Table 11-1 Instructions for Manual GroupWise Migrations
GroupWise Version
See
GroupWise 7
“Migration” (http://www.novell.com/documentation/
gw7/gw7_install/data/b2qqon2.html) in the GroupWise
7 Installation Guide (http://www.novell.com/
documentation/gw7/gw7_install/data/a20gkue.html)
GroupWise 8
“Manual Migration Steps” (http://www.novell.com/
documentation/gwutilities/gw8_svrmig/data/
b2qqon2.html) in the GroupWise Server Migration
Utility Installation and Migration Guide (http://
www.novell.com/documentation/gwutilities/
gw8_svrmig/data/ab32nt1.html)
Automated Method
Table 11-2 Instructions for an Automatic GroupWise Migration
11.1.7
GroupWise Version
See
GroupWise 7 and GroupWise 8
GroupWise Server Migration Utility Installation and
Migration Guide (http://www.novell.com/
documentation/gwutilities/gw8_svrmig/data/
ab32nt1.html)
Migrating GroupWise as Part of a Transfer ID Migration
Migrating GroupWise as part of a Transfer ID migration is essentially a three-phase process.
 “Migrating GroupWise” on page 96
 “Verifying that the GroupWise Migration Succeeded” on page 96
 “Transferring the NetWare Server’s Identity” on page 96
Upgrading Other Novell Products to OES
95
Migrating GroupWise
If your NetWare server is currently running GroupWise, you must run the GroupWise Server
Migration Utility before performing the Transfer ID migration.
The GroupWise Server Migration Utility does the following:
 It moves all GroupWise data and agents from a NetWare source server to an OES target server.
 It sets up the GroupWise Agents to run on the IP address and DNS name of the target OES
server.
For instruction on running the GroupWise Server Migration Utility, see the GroupWise Server
Migration Utility 1.1 Installation and Migration Guide (http://www.novell.com/documentation/
gwutilities/index.html).
Verifying that the GroupWise Migration Succeeded
You should verify that GroupWise has migrated correctly and is running successfully for several
weeks in the OES environment before completing the Identity Swap.
After the GroupWise migration, a copy of the GroupWise data is still located on the NetWare server.
After you perform the Transfer ID migration, the GroupWise data is no longer accessible on the
NetWare server.
Transferring the NetWare Server’s Identity
1 In ConsoleOne, change the IP address or DNS names for the POA, WebAccess, and GWIA to
reflect the NetWare server IP address or DNS information. This is only required for the agents
that were transferred using the GroupWise Server Migration Utility.
2 Ensure that the changes have replicated through the system.
3 If a domain was transferred during the GroupWise Server migration, change the IP address or
DNS name for the MTA.
4 Shut down the GroupWise agents running on the OES server.
5 Perform the Identity Swap.
6 After the Identity Swap has completed, bring up the GroupWise agents on the Linux server.
11.1.8
Additional Information
 Product Documentation:
 GroupWise 7 (http://www.novell.com/documentation/gw7).
 GroupWise 8 (http://www.novell.com/documentation/gw8).
 GroupWise Utilities Web page (http://www.novell.com/documentation/gwutilities/).
 Novell GroupWise Web site (http://www.novell.com/products/groupwise/)
 Additional GroupWise articles (http://www.novell.com/products/groupwise/productinfo/)
96
OES 2 SP3: Upgrading to OES—Best Practices Guide
11.2
Identity Manager
For information about upgrading from NetWare to OES Linux, see this Cool Solutions article (http://
www.novell.com/communities/node/6764/migration-identity-manager-351-netware-65-sp7-oes-2sp1-linux).
11.3
ZENworks
Many ZENworks features, such as policies and application distribution, are completely eDirectory™
and file system dependent. There is no dependency on the server OS. The remaining services that do
have modules that run on a server, such as inventory and imaging, are dependent on a host OS.
11.3.1
Upgrading to ZENworks 10 Configuration Manager
ZENworks 10 Configuration Manager is fully supported on OES 2 SP2 and later. If you are running
an older version of ZENworks on NetWare, the following guides will help you upgrade to ZENworks
10 running on OES 2 SP3.
 ZENworks 10.1 Configuration Management ZENworks Migration Guide (http://www.novell.com/
documentation/zcm10/zcm10_zen_migration/data/bookinfo.html)
IMPORTANT: If you are upgrading using an Transfer ID migration, be sure to complete the upgrade
to Linux before migrating to ZENworks 10.
11.3.2
Migrating ZENworks 7 from NetWare to Linux
The ZENworks 7 suite of products (except for ZENworks Middle Tier) is also fully tested and
supported on the OES 2 SP2 and later platform.
For an example of migrating ZENworks 7 from NetWare to OES 2 SP3 by using the OES 2 SP3
Migration Tool, see Section E.3, “Server Identity Migration,” on page 122.
Upgrading Other Novell Products to OES
97
98
OES 2 SP3: Upgrading to OES—Best Practices Guide
12
About Third-Party Applications
12
Two of the most important categories of third-party applications are anti-virus software and backup
software.
Anti-Virus Software
For a current list of antivirus software vendors that support Novell Open Enterprise Server, see
Novell Open Enterprise Server Partner Support: Backup and Antivirus Support (http://
www.novell.com/products/openenterpriseserver/partners_communities.html). This list is updated
quarterly.
IMPORTANT: If you run server-based anti-virus software, configure it so that it does not scan
GroupWise directory structures such as domains and post offices where file locking conflicts can
create problems for the GroupWise agents. If you need virus scanning on GroupWise data, check the
GroupWise Partner Products page (http://www.novell.com/partnerguide/p100031.html) for
compatible products.
Backup Software
For a current list of backup software vendors that support Novell Open Enterprise Server, see Novell
Open Enterprise Server Partner Support: Backup and Antivirus Support (http://www.novell.com/
products/openenterpriseserver/partners_communities.html). This list is updated quarterly.
About Third-Party Applications
99
100
OES 2 SP3: Upgrading to OES—Best Practices Guide
A
Tools for Upgrading to OES 2 SP3
A
The following utilities are available to assist with migrations to OES 2 SP3. Each tool fulfills a specific
migration or service-consolidation purpose as explained in the following sections:
 Section A.1, “OES 2 SP3 Migration Tool,” on page 101
 Section A.2, “Server Consolidation and Migration Tool (SCMT),” on page 103
 Section A.3, “NetWare Migration Wizard,” on page 103
 Section A.4, “Additional Information,” on page 103
A.1
OES 2 SP3 Migration Tool
The OES 2 SP3 Migration Tool is the main tool for upgrading from NetWare® to OES 2 SP3. The
Migration Tool includes a consolidated GUI interface that lets you drag and drop the volumes and
services that you want to migrate. Terminal commands are also provided for those who prefer to
work at a terminal prompt (command line). Both the GUI and command line methods are
documented in the OES 2 SP3: Migration Tool Administration Guide.
The OES 2 SP3 Migration Tool runs exclusively on the destination OES server and pulls service
configuration information and data from the NetWare source server. A Windows workstation is not
required.
The OES 2 SP3 Migration Tool is installed on every OES 2 SP3 server.
When you run the GUI Migration Tool, after selecting the source and target servers, you are
prompted to specify one of two migration types, as explained in the sections that follow.
 Section A.1.1, “Consolidating Selected Data or Services,” on page 101
 Section A.1.2, “Transferring an Entire NetWare Server,” on page 102
 Section A.1.3, “More About Using the Migration Tool,” on page 102
A.1.1
Consolidating Selected Data or Services
The first option is the Consolidate migration type.
Just as the name implies, a Consolidate migration is designed to migrate the services on multiple
servers to a single, more powerful OES 2 SP3 server. However, the type is very adjustable, letting you
specify only a single volume or service to migrate at a time. Obviously this lets you move data and
services with absolute flexibility.
As with all migrations using the Migration Tool, the target server must be installed using the PreMigration Server installation pattern, and the patterns for the services you are planning to migrate to
the server must be installed but not configured.
For more information on this type of migration, see “Server Consolidations” in the OES 2 SP3:
Migration Tool Administration Guide.
Tools for Upgrading to OES 2 SP3
101
A.1.2
Transferring an Entire NetWare Server
The second option is the Transfer ID migration type.
This powerful functionality lets you transfer an existing NetWare server’s identity, including its IP
address, host name, eDirectory™ and security components, services, and data to an OES 2 SP3 server.
There are, of course, preparation steps to ensure that eDirectory and the NetWare server are healthy,
and the services being migrated must be shut down during the migration process, but after the
migration is finished, network users won’t realize that anything has changed.
Those customers who have used this tool have been very pleased with the results.
For more information on this type of migration, see “Transfer ID Migration” in the OES 2 SP3:
Migration Tool Administration Guide.
A.1.3
More About Using the Migration Tool
 “Data Migration Support” on page 102
 “Batch Data Migration Support” on page 102
 “Service Migration Support” on page 102
 “eDirectory Migration Support” on page 103
Data Migration Support
The primary purpose of the OES Migration Tool is to migrate data from the NetWare platform to the
OES 2 platform. Data migration tools can also be used to migrate data from OES 1 servers and from
Microsoft Windows servers. A good place to start is the OES 2 SP3: Migration Tool Administration
Guide, which provides general information about moving data in the following sections:
 “Migrating File System from NetWare, OES 1 or OES 2 to OES 2 SP3 Linux”
 “Migrating Data from Windows to OES 2 SP3 Linux”
Batch Data Migration Support
If you want to migrate data from multiple NetWare servers to a single OES 2 SP3 server, you can
create a cron job to automatically run multiple instances of the migfiles command sequentially. The
Migration Tool GUI interface doesn’t currently support batch migrations.
Service Migration Support
Information about transferring individual services is in “Migration Scenarios” in the OES 2 SP3:
Migration Tool Administration Guide
In most cases, you first need to install the service on the OES 2 SP3 target server. Refer to the
following sections in the Migration Tool Administration Guide:
 “Migrating AFP from NetWare to OES 2 SP3 Linux ”
 “Migrating Novell Archive and Version Services to OES 2 SP3 Linux”
 “Migrating CIFS from NetWare to OES 2 SP3 Linux”
 “Migrating DHCP from NetWare to OES 2 SP3 Linux”
 “Migrating DNS from NetWare to OES 2 SP3 Linux”
102
OES 2 SP3: Upgrading to OES—Best Practices Guide
 “Migrating FTP from NetWare to OES 2 Linux”
 “Migrating iFolder 2.x”
 “Migrating iPrint from NetWare or OES 2 Linux to OES 2 SP3 Linux”
 “Migrating Timesync/NTP from NetWare to NTP on OES 2 Linux”
eDirectory Migration Support
In OES 2, you migrate eDirectory using the new Identity Transfer functionality in the Migration Tool.
See “Migrating eDirectory to OES 2 SP3 Linux ” in the OES 2 SP3: Migration Tool Administration Guide.
A.2
Server Consolidation and Migration Tool (SCMT)
Support for migrating from newer NetWare platforms has not been removed from SCMT (as
reflected in the Novell Server Consolidation and Migration Toolkit Administration Guide). However,
Novell recommends using the OES 2 SP3 Migration Tool rather than SCMT when possible.
A.3
NetWare Migration Wizard
The primary purpose of the Novell® NetWare Migration Wizard is to migrate NetWare servers to
new hardware or NetWare virtual machines.
When the migration is complete, the new server replaces and assumes the identity of the old server
on the network.
IMPORTANT: For migrating to OES 2, use the new Identity Transfer feature found in the OES 2 SP3
Migration Tool. For more information, see “Transfer ID Migration” in the OES 2 SP3: Migration Tool
Administration Guide.
A.4
Additional Information
 Novell Upgrade or Migrate Web site. For information on the tools and resources currently
available from Novell, visit the OES Upgrade or Migrate Web site (http://www.novell.com/
promo/upgradeormigrate.html).
 Links to Documentation. For a complete list of links to data and service migration instructions
in the OES 2 documentation, see the Migrate, Consolidate, and Coexist (http://www.novell.com/
documentation/oes2/migrate-consolidate-coexist.html#migrate-consolidate-coexist) page on the
OES 2 Documentation Web site (http://www.novell.com/documentation/oes2).
Tools for Upgrading to OES 2 SP3
103
104
OES 2 SP3: Upgrading to OES—Best Practices Guide
B
About the Management Tools in
OES 2
B
 Section B.1, “Novell iManager 2.7,” on page 105
 Section B.2, “Novell Remote Manager (NRM),” on page 106
 Section B.3, “About Other Management Tools,” on page 107
B.1
Novell iManager 2.7
Novell® iManager is a Web-based administration console that provides secure, customized access to
network administration utilities and content from virtually anywhere administrators have access to
the Internet and a Web browser.
 Section B.1.1, “What's New in Version 2.7,” on page 105
 Section B.1.2, “Supported Web Browsers,” on page 106
 Section B.1.3, “Caveats,” on page 106
 Section B.1.4, “Upgrading to iManager 2.7,” on page 106
B.1.1
What's New in Version 2.7
Novell iManager 2.7 contains the following new features:
Tree View: The iManager tree view in the left navigation frame approximates functionality available
in the ConsoleOne® Console View. You can navigate the tree structure, expanding and collapsing
container objects as necessary. The right content frame displays contents and menu items for the
object selected in the navigation frame.
File System Browse: iManager 2.7 lets you browse through an eDirectory™ Volume object to the
underlying NCP™ enabled volume. Within the volume structure, you can select File and Directory
objects. The actual tasks you can perform on file system objects is provided by the NSS iManager
plug-in, which is available separately.
File system browsing does not support accessing the file system through NCP™ Server objects or
NSS junction point objects.
File system browsing is available from the Object Selector, Object Browse, and Tree view, but is not
available in Advanced Browsing mode. Also, file system browsing is not accessible from the Search
or Advanced Search panes.
Available Novell Plug-in Modules: iManager 2.7 lists all the available iManager plug-ins contained
in the packages directory/download site by default. You can download and install plug-ins from
within iManager by querying the Novell download Web site. The previous versions of iManager
listed only the updates to the installed plug-in modules.
About the Management Tools in OES 2
105
NOTE: With NetWare, iManager 2.7 now requires and installs only Tomcat 5. However, OES 2
installs both Tomcat and Apache. iManager is supported only with the version of Tomcat that is
installed with iManager.
B.1.2
Supported Web Browsers
 Microsoft IE 6 SP1 or later or IE 7
 Firefox* 1.5. x or 2. x
NOTE: You might be able to access iManager via a Web browser not listed, but Novell does not
guarantee or support full functionality with any other browser.
B.1.3
Caveats
 In order for some iManager wizards and help to work, you must enable pop-up windows in
your Web browser.
 iManager 2.7 can coexist in the same eDirectory tree with iManager 2.6.
 If your network has more than three servers, or one or more servers that do not host eDirectory
replicas, you must have SLP properly configured for iManager to log in. For more information,
see “SLP” in the OES 2 SP3: Planning and Implementation Guide.
 iManager 2.7 can manage any server running Novell eDirectory 8.6.2 or later.
 iManager 2.7 plug-ins are not compatible with previous versions of iManager. Additionally, any
custom plug-ins you want to use with iManager 2.7 must be re-compiled in the iManager 2.7
environment.
B.1.4
Upgrading to iManager 2.7
In light of the Caveats mentioned above, Novell recommends that you simply install iManager 2.7 on
your OES 2 servers and download all of the plug-ins that apply to your services. For more
information, see the Novell iManager 2.7 Installation Guide.
B.2
Novell Remote Manager (NRM)
Novell Remote Manager for OES is a browser-based utility that can be used to manage one or more
OES servers from a remote location to monitor server health, change the server configuration, or
perform diagnostic and debugging tasks.
 It does not require a special client.
 It provides a graphical interface that makes interpreting diagnostic information much more
comprehensive and easier to manage.
 It provides added functionality that is not available in other management utilities.
 Section B.2.1, “Prerequisites,” on page 107
 Section B.2.2, “About Novell Remote Manager and OES 2,” on page 107
106
OES 2 SP3: Upgrading to OES—Best Practices Guide
B.2.1
Prerequisites
 OES services must be installed when you install the OES 2 server.
 Supported browsers include Mozilla* Firefox 1.0, Microsoft Internet Explorer 6 or later, Mozilla
1.7 (SLES 9 SP1 and Linux Professional 9.2), KDE 3.2 Konqueror (limited functionality), or
Safari* 1.2 (limited functionality).
 The HTTPSTKD module must be loaded and running on the server. This module is selected,
installed, and configured with a default configuration when you install any of the OES 2
patterns (unless you deselect it).
B.2.2
About Novell Remote Manager and OES 2
There is no need to migrate Novell Remote Manager (NRM) from NetWare to OES 2. Instead, this
service can be installed when any Open Enterprise Server pattern is installed. Then, if you have
created server groups for monitoring NetWare 6.5 servers, they can be accessed and monitored from
Remote Manager on OES just as they can from a NetWare server running NetWare 6.0 or later.
However, NRM is configured somewhat differently on OES than on NetWare. When NRM is
installed, it sets up a small Web server on the OES server. The interface and module is called
HTTPSTKD. Basic configuration parameters are pre-set; however, these can be changed by editing
the httpstkd config or httpstkd PAM config files. See “Changing the Configuration” in the OES
2 SP3: Novell Remote Manager for Linux Administration Guide."
You can log in as user Root, a local Linux user, or as an eDirectory user who is Linux User
Management (LUM) enabled.
 If Linux User Management is enabled in your tree and is installed and configured on the local
server, you can log in to Novell Remote Manager using your eDirectory credentials. See the OES
2 SP3: Novell Linux User Management Administration Guide for details.
 If you log in as a local Linux user or as a non-Admin eDirectory user, you can see only the
information that the user you log in as has rights to view.
B.3
About Other Management Tools
Section 3.1.3, “About eDirectory Management Tools in OES 2,” on page 35 discusses additional
management tools in OES 2, especially those for eDirectory.
About the Management Tools in OES 2
107
108
OES 2 SP3: Upgrading to OES—Best Practices Guide
C
Workstation Considerations
C
There are some impacts on network workstations resulting from a migration to OES 2.
Domain Services for Windows
Domain Services for Windows (DSfW) provides Windows users with seamless integration between
eDirectory™ and Active Directory. For an overview of this new functionality, see Section 3.5, “About
Domain Services for Windows,” on page 42.
Novell Client
As OES 2 is implemented, existing clients can be used (Windows XP, 2000, NT, Vista). However, an
upgrade to the latest clients and workstation OS is required to take full advantage of the new features
of eDirectory and OES 2, such as NMAS™ and Password Self Service.
iFolder
The iFolder client must be installed on all Macintosh, Linux, and Windows workstations that use this
functionality in OES 2.
iPrint
The iPrint agent must also be installed on all Macintosh, Linux, and Windows workstations that use
this functionality in the OES 2 environment.
Workstation Considerations
109
110
OES 2 SP3: Upgrading to OES—Best Practices Guide
D
Server Consolidation
D
The OES 2 SP3 Migration Tool includes a Consolidate migration type that is specifically designed to
support server consolidation. For more information, see Section A.1.1, “Consolidating Selected Data
or Services,” on page 101.
Server Consolidation
111
112
OES 2 SP3: Upgrading to OES—Best Practices Guide
E
Examples
E
This section contains a few real-world examples of upgrades to OES 2 that Novell® customers have
done. If you have an example you want to share, please submit a User Comment for this page with
your e-mail address, and we’ll contact you.
 Section E.1, “Replica and CA Server Migration,” on page 113
 Section E.2, “Cluster Migration,” on page 115
 Section E.3, “Server Identity Migration,” on page 122
E.1
Replica and CA Server Migration
The following is an example of transferring a NetWare® 6.5 SP7 CA and eDirectory™ replica server
to an OES 2 server using the Transfer ID option in the OES 2 SP3 Migration Tool.
 Section E.1.1, “Overview,” on page 113
 Section E.1.2, “FAQs,” on page 114
 Section E.1.3, “Preparing and Transferring Your Replica Server,” on page 114
 Section E.1.4, “Post-Migration Configuration,” on page 115
E.1.1
Overview
Table E-1 Service Migration Summary
Pre-Migration
Post-Migration
A NetWare 6.5 SP7 server running as the master
replica server and certificate authority for the
eDirectory tree.
A single OES 2 server running as the master replica
server and certificate authority for the eDirectory tree.
This server currently provides these services:
This server provides these services:
The server has the same name and IP address as the
NetWare server.
 SLPDA
 SLPDA
 iManager
 iManager
 VLDB (DFS)
 VLDB (DFS)
 NetStorage
 NetStorage
 LDAP
 LDAP
 NTP
Examples
113
E.1.2
FAQs
 Q: Do we need to remove the Certificate Authority and create a new one on the new server?
A: No. The Identity Transfer option migrates the existing eDirectory Certificate Authority to the
new server.
 Q: To migrate the master, do we need to remove all eDirectory replicas, remove the server from
eDirectory, build a new server with the same name, add replicas back, etc.?
A: No. The Identity Transfer option migrates the existing eDirectory database to the new server.
E.1.3
Preparing and Transferring Your Replica Server
1 Prepare your servers by following the instructions in “Preparing for Transfer ID” in the OES 2
SP3: Migration Tool Administration Guide.
Make sure you do the following:
 Install the OES target server in the same context as the NetWare source server, using the
Novell Pre-Migration Server pattern and the patterns for all services that correspond to the
services running on the NetWare server.
This ensures that eDirectory is installed on the target server without a replica and that the
target server is prepared for all of the services being migrated.
IMPORTANT: You must select the "Pre-Migration Server" install pattern during the initial
OES installation. Otherwise, an eDirectory replica is installed and/or configured on the
server, and the server is not a valid migration target server.
Selecting the pattern later will not remove the replica configuration.
If you install a server without selecting the pre-migration pattern initially, you must start
fresh by performing a New Server installation and being sure to select Pre-Migration Server as
one of the initial OES patterns.
For instructions, see “Installing OES 2 SP3 as a New Installation” in the OES 2 SP3:
Installation Guide.
 If you are moving data from NSS volumes on the NetWare source server, create
corresponding NSS volumes on the OES target server. Be sure to use the same names as on
the source server.
Do not create any new volumes that will not have data migrated to them until after the
Identity Transfer migration is completed.
 Verify that the host name and DNS entries in your local /etc/hosts files and on the DNS
server are correct.
 Apply the latest SLES 10 SP4 and OES 2 SP3 patches from the Novell Customer Center to
the target server. For more information, see “Updating (Patching) an OES 2 SP3 Server” in
the OES 2 SP3: Installation Guide.
 If the source server is running NetWare 6.5 SP7, install the SMS patch (http://
support.novell.com/docs/Readmes/InfoDocument/patchbuilder/readme_5042400.html)
first. If the source server is running SP8, this is not necessary.
2 Migrate your server by following the instructions in “Using the Migration GUI Tool for Transfer
ID” in the OES 2 SP3: Migration Tool Administration Guide.
114
OES 2 SP3: Upgrading to OES—Best Practices Guide
Make sure you do the following:
 If you are moving data from NSS volumes on the NetWare source server, follow the
instructions in “Migrating File System from NetWare, OES 1 or OES 2 to OES 2 SP3 Linux”
in the OES 2 SP3: Migration Tool Administration Guide.
 Do not select iManager, VLDB, NetStorage or LDAP for migration. These services work
automatically after the ID Transfer is complete.
 SLPDA must be manually reconfigured after the migration completes.
E.1.4
Post-Migration Configuration
1 Set up the SLP DA on your OES server by following the instructions in “Setting Up an OpenSLP
DA Server” in the OES 2 SP3: Planning and Implementation Guide.
2 Clean up the old eDirectory target server objects by following the instructions in “Cleanup
Objects” in the OES 2 SP3: Migration Tool Administration Guide.
3 If you have DFS junctions, check one of them in this VLDB management context to make sure it
is still working. If it is not working, rebuild the VLDB using the instructions in “Repairing the
VLDB” in the OES 2 SP3: Novell Distributed File Services Administration Guide for Linux.
4 For information about time synchronization services on a Novell network, see “Time Services”
in the OES 2 SP3: Planning and Implementation Guide.
5 Verify that all of the other services are working as expected.
E.2
Cluster Migration
The following is an example of doing a rolling cluster upgrade from an NetWare 6.5 SP7 cluster to an
OES 2 SP3 cluster.
 Section E.2.1, “Overview,” on page 115
 Section E.2.2, “General Notes and Tips,” on page 116
 Section E.2.3, “Preparing to Migrate the Cluster,” on page 116
 Section E.2.4, “Transferring DHCP in the Cluster,” on page 117
 Section E.2.5, “Transferring DNS in a Cluster,” on page 118
 Section E.2.6, “iPrint Migration in a Cluster,” on page 120
 Section E.2.7, “Transferring AFP in a Cluster,” on page 122
 Section E.2.8, “Transferring CIFS in a Cluster,” on page 122
E.2.1
Overview
Table E-2 summarizes the pre-migration and post-migration status of the cluster being migrated.
Table E-2 Service Migration Summary
Pre-Migration: Three-node NetWare 6.5 SP7
Cluster
Post-Migration: Three-node OES 2 SP3 Cluster
Each node contains some eDirectory replicas
Each node contains some eDirectory replicas
Examples
115
Pre-Migration: Three-node NetWare 6.5 SP7
Cluster
Post-Migration: Three-node OES 2 SP3 Cluster
Each node has access to fiber-attached shared
storage that includes:
Each node has access to fiber-attached shared
storage that includes:
 Several clustered NSS volumes for home
 Several clustered NSS volumes for home
directories and shared file systems
E.2.2
directories and shared file systems
 One clustered NSS volume for NDPS and iPrint
 One clustered NSS volume for iPrint
 Clustered DHCP
 Clustered DHCP
 Clustered DNS
 Clustered DNS
 Clustered AFP (NFAP)
 Clustered Novell AFP
 Clustered CIFS (NFAP)
 Clustered Novell CIFS
General Notes and Tips
 In the YaST install, clustering is disabled by default. To set up clustering, you must enable it for
configuration. See “Novell Cluster Services Parameters and Values” in the OES 2 SP3: Installation
Guide.
 Clustering on OES 2 SP3 is case-sensitive. Always make sure that you have specified the correct
case for each name, etc. The SPD on the OES node is created exactly as you specify it. (NetWare
was case-insensitive.)
 NetWare cluster names display in uppercase. Using lowercase for OES cluster names makes
them easier to distinguish from the NetWare names.
 On NetWare nodes, the load and unload scripts are stored in eDirectory and accessible through
iManager.
 On OES nodes, the load and unload scripts are dynamically created in /var/run/ncs from the
scripts stored in eDirectory each time that you cluster-migrate a cluster resource to the OES
node.
Scripts are retained only while the OES server is running. If the server goes down for any reason,
the scripts are removed. This is not a problem, however, because they are created again when
you cluster-migrate the cluster resources.
 NetWare has a limitation of 1024 characters in scripts. Linux doesn't have this limitation.
The best solution for this limitation is to create a small script to call the larger scripts. The script
must be the same on each box. Section E.2.4, “Transferring DHCP in the Cluster,” on page 117
illustrates this concept.
 There's a utility called sbdutil that lets you manage the sbd on OES. For documentation, access
the sbdutil man page on a clustered server.
E.2.3
Preparing to Migrate the Cluster
1 Read through Table E-3 to understand what happens to the existing volumes during a cluster
migration.
116
OES 2 SP3: Upgrading to OES—Best Practices Guide
Table E-3 What Happens to Existing Volumes During a Cluster Migration
Pre-Migration Status
Migration Action
Post-Migration Status
Users volume active on NetWare
Cluster-migrates to an OES node Users volume active on OES
Shared volume active on
NetWare
Cluster-migrates to an OES node Shared volume active on OES
NDPS volume active on NetWare Migration Tool migrates
configuration, etc. to the new
iPrint volume.
Offline
DNS volume active on NetWare
Offline
Moved by iManager to the new
DNS2 volume on OES.
2 Create all of the NSS volumes that are required for your service migrations as listed in Table E-3.
WARNING: This must be done while the cluster has only NetWare nodes. If you have already
joined OES nodes to your cluster, make sure that you remove them from the cluster before you
create the NSS volumes.
Table E-4 New NSS Pools and Volumes Are Required
E.2.4
Create These
Migration Action
Post-Migration Status
Destination iPrint pool and
volume (newly created through
the NetWare server)
Cluster-migrates to an OES node iPrint volume active on OES
Destination DHCP pool and
volume (newly created through
the NetWare server)
Cluster-migrates to an OES node DHCP volume active on OES
Destination DNS2 pool and
volume (newly through the
NetWare server).
Cluster-migrates to an OES node DNS2 volume active on OES
Transferring DHCP in the Cluster
1 Before starting the migration, create the Destination DHCP volume specified in Table E-4.
2 Add one or more OES 2 SP3 servers to the cluster. For more information, see “Adding New OES
2 Linux Nodes to Your NetWare Cluster” in the OES 2 SP3: Novell Cluster Services 1.8.8
Administration Guide for Linux.
3 Set up an OES DHCP cluster resource using the instructions in the first three section only of
“Installation and Configuration” in the OES 2 SP3: Novell DNS/DHCP Administration Guide.
4 Edit the destination DHCP pool resource load script and insert the following line just before the
last (exit 0) line:
/destination_dhcp_volume/dhcp_cluster.sh
where destination_dhcp_volume is the path to the destination DHCP volume listed in Table E-3.
For example, insert the following line:
/media/nss/DHCP_VOLUME/dhcp_cluster.sh
Examples
117
IMPORTANT: This step is required to circumvent the 1024 byte script-size limitation on
NetWare mentioned in Section E.2.2, “General Notes and Tips,” on page 116.
5 Download the dhcp_cluster.sh (http://www.novell.com/documentation/oes2/scripts/
dhcp_cluster.sh) script file from the OES 2 Documentation Web site.
6 Using a UNIX-compatible text editor, replace <DHCP_VOLUME> in the dhcp_cluster.sh script
with the local mount point of your destination DHCP volume.
For example, MOUNT_POINT="/media/nss/DHCP_VOLUME".
7 Using the instructions in “Migrating DHCP from NetWare to OES 2 SP3 Linux” in the OES 2
SP3: Migration Tool Administration Guide, migrate the NetWare DHCP configuration to one of the
OES servers added to the cluster in Step 2.
8 Copy the /etc/dhcpd.conf file to the destination DHCP volume.
For example cp /etc/dhcpd.conf /media/nss/DHCP_VOLUME/dhcpd.conf.
9 Edit the dhcpd.conf file you copied in Step 8, as follows:
9a Change the ldap-server IP address to the IP address associated with your destination
DHCP pool.
9b Change the ldap-dhcp-server-cn to the OES DHCP Server Object created by the
Migration Tool in Step 7.
10 Copy the migrated_server.leases file from the /var/opt/novell/dhcp/leases folder to the
/var/lib/dhcp/db folder on your Destination DHCP Volume and rename it to dhcpd.leases.
Continuing with the same example, you use the following command to copy and rename the
file:
cp /var/opt/novell/dhcp/leases/DHCP_SERVER.leases /media/nss/DHCP_VOLUME/var/
lib/dhcp/db/dhcpd.leases.
11 Offline the DHCP cluster resource that has been running on NetWare.
12 Online the OES DHCP cluster resource.
13 (Optional) Use iManager to enable the DHCP server as the authoritative server.
E.2.5
Transferring DNS in a Cluster
 “Using iManager to Migrate DNS Servers within the Same eDirectory Tree” on page 118
 “Installing and Configuring a Cluster-Enabled DNS” on page 119
Using iManager to Migrate DNS Servers within the Same eDirectory Tree
1 Before starting the migration, create the Destination DNS2 volume specified in Table E-4.
2 Launch iManager.
3 Identify the source NCP™ server object and the corresponding DNS server object to be migrated
to the OES 2 SP3 target server.
4 Unload the source DNS Server use the following command:
unload named.nlm
5 In iManager, click DNS > DNS Server Management.
6 Select Move DNS Server from the drop-down menu and click OK.
7 In the Select DNS Server Name field, select the source NetWare DNS Server name.
118
OES 2 SP3: Upgrading to OES—Best Practices Guide
8 In the Enter NCP server Name field, browse and select the virtual cluster NCP server object that
represents the destination DNS2 pool.
9 Click Move.
10 Click OK.
11 Use the following command to load the newly migrated DNS server on the target OES 2 SP3
server:
rcnovell-named start
12 Query the New DNS server for the zones and rr requests, ensure that all the associated zones are
served and that the server roles are maintained on the zone.
IMPORTANT: If you are not able to locate the DNS servers, make sure that the scope settings
point to the correct context for the DNS/DHCP locator object.
Installing and Configuring a Cluster-Enabled DNS
1 Verify that all OES 2 SP3 cluster nodes have the DNS pattern installed with a common locator
group context.
2 Mount the shared volume on one of the OES 2 SP3 nodes in the cluster.
3 Execute the following script at the command prompt:
/opt/novell/named/bin/ncs_dir.sh mount_point username
where mount_point is the Destination DNS2 volume listed in Table E-4 and username is the fully
distinguished name of the DNS user (named by default).
For example, you might enter the following command:
/opt/novell/named/bin/ncs_dir /media/nss/DNSVOL/ cn=named.o=novell.T=MyTree
The script creates the following directory:
/media/nss/DEST_DNS2_VOL/etc/opt/novell/named
The script also assigns access and ownership rights for the preceding directory to the DNS user.
4 Run the DNS Server by using the following command:
/opt/novell/named/bin/novell-named -u DNS_User -V DEST_DNS2_VOL
This step ensures that DNS server is running on the cluster node.
5 Click Cluster > Cluster Options, then select the Destination DNS2 cluster pool resource and click
Details.
6 Click the Scripts tab.
6a Click Load Script.
6b Add following line before exit 0 to load DNS.
exit_on_error /opt/novell/named/bin/novell-named -u DNS_User -V
DESTINATION_DNS2_VOLUME
6c Click Unload Script.
6d Add following line at the beginning to unload DNS.
killproc -p /var/opt/novell/run/named/named.pid -TERM /opt/novell/named/
bin/novell-named
7 Set the Destination DNS2 cluster resource offline and then online by using the Clusters > Cluster
Manager task in iManager.
8 Verify that DNS services are functioning correctly.
Examples
119
E.2.6
iPrint Migration in a Cluster
 “How Clustered iPrint Migration Works” on page 120
 “Tips and Caveats” on page 120
 “Transferring iPrint in a Cluster” on page 120
How Clustered iPrint Migration Works
The OES 2 SP3 Migration Tool (miggui) contains an NLM™ named PSMINFO.NLM that copies all of
the iPrint data from the cluster to an XML text file named psminfo.xml on the iPrint NSS volume
that you created in Step 2 on page 117. The psminfo.xml file is located in an /ndps directory at the
root of the volume.
The migration tool uses the information in psminfo.xml to create new printer objects, set up the
driver store, create printer agents, etc. The tool also changes the names of the old iPrint objects in
eDirectory by appending _nw to each name. The old names can then be applied to the new printer
objects. All changes are completely transparent to iPrint users.
Tips and Caveats
 Legacy queue-based printing cannot be serviced by an OES 2 Printer Agent.
 You can manage both OES iPrint and NetWare iPrint from NetWare, but you can only manage
OES iPrint from OES.
 You must create the iPrint NSS pool and volume as instructed in Step 2 on page 117 prior to
adding OES nodes to the cluster or running the migration.
Transferring iPrint in a Cluster
1 Download the iprint_load.sh script (http://www.novell.com/documentation/oes2/scripts/
iprint_load.sh) and the iprint_unload.sh script (http://www.novell.com/documentation/oes2/
scripts/iprint_unload.sh) from the OES 2 Documentation Web site.
2 Customize the iPrint load script for your iPrint pool resource by doing the following:
2a In iManager, access the load script for the destination iPrint pool resource.
2b Copy and paste the contents of the downloaded iprint_load.sh file below the last line of
the current load script.
2c Using the information in the current script, replace each variable (indicated by <angle
brackets>) with the correct values for the cluster resource.
For example, if the first line in the current script reads
nss /poolactivate=POOLNAME
Modify the third line in the downloaded script to read
exit_on_error nss /poolact=POOLNAME
2d Remove all of the lines down to the first line you inserted.
2e Click Apply.
3 Customize the iPrint unload script for your iPrint pool resource by doing in the following:
3a In iManager, access the unload script for the destination iPrint pool resource.
3b Copy and paste the contents of the downloaded iprint_unload.sh file below the last line
of the current unload script.
120
OES 2 SP3: Upgrading to OES—Best Practices Guide
3c Using the information in the current script, replace each variable (indicated by <angle
brackets>) with the correct values for the cluster resource.
For example, if the first line in the current script reads
ncpcon unbind
--ncpservername=CLUSTERNAME_POOLNAME_SERVER --ipaddress=192.168.10.10
Modify the third line in the downloaded script to read
ignore_error ncpcon unbind
--ncpservername=CLUSTERNAME_POOLNAME_SERVER --ipaddress=192.168.10.10
3d Remove all of the lines down to the first line you inserted.
3e Click Apply > OK.
4 In iManager > Cluster Options, select the iPrint cluster resource object and click the Details link.
5 On the Cluster Pool Properties page, click the Preferred Nodes tab and move all of the NetWare
nodes to the Unassigned column.
6 Offline and then online the cluster resource.
7 On the server where the iPrint cluster resource is running, open a terminal and enter the
following commands:
cd /opt/novell/iprint/bin
./iprint_nss_relocate -a admin.fqdn -p password -n NSS/path -l cluster
For example, enter
./iprint_nss_relocate -a cn=admin,o=novell -p novell -n /media/nss/NSSVOLNAME l cluster
8 Migrate the iPrint resource to another OES 2 SP3 node in the cluster, then repeat Step 7 until all
of the OES 2 SP3 nodes in the cluster have run the iprint_nss_relocate script.
9 Create the Print Manager and Driver Store on the OES cluster.
When choosing the target server, use the IP address of the cluster resource. This specifies where
the driver store and Print Manager database will reside. Begin by using the IP address of the
new resource. This will need to be changed to a DNS name later by editing the .conf file.
When you receive a certificate management error, allow the error and proceed.
While you are creating the Print Manager, the lower dialog box indicates where the Print
Manager will be located. Specify the IP address of the cluster resource. This changes later to a
DNS name.
The iPrint service doesn’t “know” that it's running on a cluster because the script creates a
symbolic link. If the link exists, you know that the service is clustered.
10 After you create the Print Manager and Driver Store, modify the /etc/opt/novell/iprint/
conf/ipsmd.conf and idsd.conf to have multiple DSServer values.
For example:
DSServer1 replicaServer
DSServer2 replicaServer
DSServer3 replicaServer
11 Remove the pound sign (#) from the following two lines in the load script:
exit_on_error rcnovell-idsd start
exit_on_error rcnovell-ipsmd start
12 Offline and online the cluster resource and verify that the Print Manager and Driver Store load.
Examples
121
13 Create a printer to test that the service is working.
14 Follow the instructions in “Migrating iPrint from NetWare or OES 2 Linux to OES 2 SP3 Linux”
in the OES 2 SP3: Migration Tool Administration Guide.
IMPORTANT: When you authenticate to the source and target servers, use the IP address of the
source Novell Cluster Services™ iPrint resource (secondary IP) and the IP address of the target
Novell Cluster Services iPrint resource (secondary IP).
The ipsmd.conf file is located in the /etc/opt/novell/iprint/conf directory.
E.2.7
Transferring AFP in a Cluster
1 Install AFP on each OES 2 SP3 server that will be in the cluster. For details, see the OES 2 SP3:
Novell AFP For Linux Administration Guide.
2 Cluster-enable the AFP service. For details, see “Configuring AFP with Novell Cluster Services
for an NSS File System” in the OES 2 SP3: Novell AFP For Linux Administration Guide.
E.2.8
Transferring CIFS in a Cluster
1 Install CIFS on each OES 2 SP3 server that will be in the cluster. For details, see the OES 2 SP3:
Novell CIFS for Linux Administration Guide.
2 Cluster-enable the CIFS service. For details, see “Configuring CIFS with Novell Cluster Services
for an NSS File System” in the OES 2 SP3: Novell CIFS for Linux Administration Guide.
E.3
Server Identity Migration
The following is an example of transferring a NetWare 6.5 SP7 server to an OES 2 SP3 server, using
the Transfer ID option in the OES 2 SP3 Migration Tool.
 Section E.3.1, “Preparing and Transferring Your Replica Server,” on page 123
 Section E.3.2, “Post-Migration Steps,” on page 124
Table E-5 Service Migration Summary
Pre-Migration (Source Server)
Post-Migration (Target Server)
A NetWare 6.5 SP7 server with the following:
An OES 2 SP3 server on new hardware with the same
name and eDirectory identity
 eDirectory replicas
 NSS volumes for home directories and shared
file systems
 An NSS volume for NDPS and iPrint
 DHCP services
 ZENworks® for Desktops 7 SP1 IR3a HP3 (or
newer update)
 eDirectory replicas
 NSS volumes for home directories and shared
file systems
 An NSS volume for iPrint
 DHCP services
 ZENworks for Desktops 7 SP1 IR3a HP3 (or
newer update)
122
OES 2 SP3: Upgrading to OES—Best Practices Guide
E.3.1
Preparing and Transferring Your Replica Server
1 Prepare your servers by following the instructions in “Preparing for Transfer ID” in the OES 2
SP3: Migration Tool Administration Guide.
Make sure you do the following:
 Install the OES target server in the same context as the NetWare source server, using the
Novell Pre-Migration Server pattern and the patterns for all services that correspond to the
services running on the NetWare server.
This ensures that eDirectory is installed on the target server without a replica and that the
target server is prepared for all of the services being migrated.
For instructions, see “Installing OES 2 SP3 as a New Installation” in the OES 2 SP3:
Installation Guide.
 If you are moving data from NSS volumes on the NetWare source server, create
corresponding NSS volumes on the OES target server. Be sure to use the same names as on
the source server.
Do not create any new volumes that will not have data migrated to them until after the
Identity Transfer migration is completed.
 Verify that the host name and DNS entries in your local /etc/hosts files and on the DNS
server are correct.
 Apply the latest SLES 10 SP4 and OES 2 SP3 patches from the Novell Customer Center to
the target server. For more information, see “Updating (Patching) an OES 2 SP3 Server” in
the OES 2 SP3: Installation Guide.
 If the source server is running NetWare 6.5 SP7, install the SMS patch (http://
support.novell.com/docs/Readmes/InfoDocument/patchbuilder/readme_5042400.html)
first. If the source server is running SP8, this is not necessary.
 If you are migrating ZENworks 7 Server Management, delete the Distributor and
Subscriber objects on the NetWare servers that will be migrated to OES 2 SP3.
2 Migrate your server by following the instructions in “Using the Migration GUI Tool for Transfer
ID” in the OES 2 SP3: Migration Tool Administration Guide.
Make sure you do the following:
 If you are moving data from NSS volumes on the NetWare source server, follow the
instructions in “Migrating File System from NetWare, OES 1 or OES 2 to OES 2 SP3 Linux”
in the OES 2 SP3: Migration Tool Administration Guide.
 If you are migrating Novell ZENworks 7 Desktop Management, migrate the directories
where you store your MSI, AOT, etc. You do not need to migrate the ZENworks
program directory itself.
 If you are migrating Novell ZENworks 7 Server Management, migrate the directories
where you store your user applications, etc.
 If you are transferring iPrint, follow the instructions in “Migrating iPrint from NetWare or
OES 2 Linux to OES 2 SP3 Linux” in the OES 2 SP3: Migration Tool Administration Guide. Do
not perform the post-migration procedures at this point.
 If you are transferring DHCP, follow the instructions in “Migrating DHCP from NetWare to
OES 2 SP3 Linux” in the OES 2 SP3: Migration Tool Administration Guide. Do not perform the
post-migration procedures at this point.
3 After all the services above have been successfully migrated, click the button to transfer the
server identity and complete the Transfer ID Wizard.
Examples
123
E.3.2
Post-Migration Steps
 “iPrint” on page 124
 “DHCP” on page 124
 “ZENworks 7” on page 124
iPrint
1 Complete the remaining iPrint instructions, starting with “Migrating ZENworks iPrint Policies”
in the OES 2 SP3: Migration Tool Administration Guide.
DHCP
1 Complete the remaining iPrint instructions, starting with “Post-Migration Procedures” in the
OES 2 SP3: Migration Tool Administration Guide.
ZENworks 7
 “Novell ZENworks 7 Desktop Management” on page 124
 “Novell ZENworks 7 Server Management” on page 124
IMPORTANT: You need the ZENworks for Desktops 7 SP1 IR3a HP4 patch for imaging on 64bit
Linux .
Novell ZENworks 7 Desktop Management
1. Mount the ZENworks 7 Desktop Management Linux CD on the OES 2 SP3 server.
2. Install ZENworks 7 Desktop Management, selecting the features that you will use.
You can also do the silent install by modifying the silent.properties file and copying it to
your machine.
3. Modify each NAL object to reflect the new path to the files on the OES Volume
4. Modify the Workstation objects so that they have the correct location for the images.
5. Open the ports in the firewall on the OES 2 SP3 server.
See “Ports used by ZEN” (http://www.novell.com/support/php/
search.do?cmd=displayKC&docType=kc&externalId=3880659&sliceId=1&docTypeID=DT_TID_
1_1&dialogID=22570644&stateId=1%200%2022568512)
Novell ZENworks 7 Server Management
1. Install ZENworks 7 Server Management on the OES 2 SP3 server
2. Make sure that the Distributor and Subscriber objects are created.
IMPORTANT: If you did not delete the objects before the migration (Step 1 on page 123), you
get an error and they are not created. In this case, all of the paths still point to the NetWare
volumes and ZENworks 7 Server Management does not function properly.
3. Resolve the certificates by using ConsoleOne®.
4. Right-click any of the distributions that you created and assign them to the new distributor
created when you installed ZENworks 7 Server Management on the server.
124
OES 2 SP3: Upgrading to OES—Best Practices Guide
5. Access the Distributions that have paths, and modify them with the new paths.
6. If you were using variables, access the Subscriber and re-create the variables, making sure they
point to the new location on the OES 2 SP3 server.
7. Open the ports in the firewall on the OES 2 SP3 server.
See “Ports used by ZEN” (http://www.novell.com/support/php/
search.do?cmd=displayKC&docType=kc&externalId=3880659&sliceId=1&docTypeID=DT_TID_
1_1&dialogID=22570644&stateId=1%200%2022568512)
Examples
125
126
OES 2 SP3: Upgrading to OES—Best Practices Guide
F
Documentation Updates
F
This section summarizes the changes made to this guide since its initial release.
January 21, 2013
Chapter or Section Changed
Summary of Changes
Various
Addressed various user comments.
January 18, 2012
Chapter or Section Changed
Summary of Changes
Various
Updated format to comply with new corporate standard.
September 5, 2011
Chapter or Section Changed
Summary of Changes
Various
Updated to reflect support for SLES 10 SP4 as the base
platform for OES 2 SP3.
June 3, 2011
Chapter or Section Changed
Summary of Changes
Section 2.2.4, “File System
Considerations,” on page 30
Updated the information about GroupWise
recommendations.
December 21, 2010
Chapter or Section Changed
Summary of Changes
Various
Made changes throughout to update links and correct
version information for the SP3 release.
Documentation Updates
127
128
OES 2 SP3: Upgrading to OES—Best Practices Guide
Was this manual useful for you? yes no
Thank you for your participation!

* Your assessment is very important for improving the work of artificial intelligence, which forms the content of this project

Download PDF

advertisement