Novell OPEN ENTERPRISE SERVER 2.0 SP2 Implementation Manual

Download

Page 1

Novell®

www.novell.com

AUTHORIZED DOCUMENTATION

Upgrading to OES—Planning and Implementation Guide

Open Enterprise Server

novdocx (en) 7 January 2010

2.0 SP2

December, 2009

OES 2 SP2: Upgrading to OES—Planning and Implementation Guide

Page 2

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.

novdocx (en) 7 January 2010

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. 404 Wyman Street, Suite 500 Waltham, MA 02451 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).

Page 3

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.

novdocx (en) 7 January 2010

Page 4

novdocx (en) 7 January 2010

4 OES 2 SP2: Upgrading to OES—Planning and Implementation Guide

Page 5

Contents

About This Guide 11

1 Frequently Asked Questions 13

1.1 Why Not Stay on NetWare?. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13

1.2 Can I Move My NetWare Disks to an OES 2 Server? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14

1.3 What About My Older NetWare Servers? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14

1.4 What’s New in OES 2?. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15

1.5 What Do Novell Customers Recommend?. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15

1.6 What Are the Differences Between NetWare and OES 2? . . . . . . . . . . . . . . . . . . . . . . . . . . . 16

1.6.1 System and Administrative User and Group Differences . . . . . . . . . . . . . . . . . . . . . 17

1.6.2 Comparing Services Between NetWare and OES 2 SP2 . . . . . . . . . . . . . . . . . . . . . 17

1.6.3 Services Not Included in OES 2 SP2 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24

1.7 How Much Training Is Needed? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24

1.7.1 What Our Customers Tell Us. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24

1.7.2 Conduct a Training Assessment . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25

1.8 What Training Is Available? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26

1.8.1 Novell Training Services . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26

1.8.2 Complimentary Free Training . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26

1.8.3 Product Documentation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26

1.9 Does Novell Have Community Support to Help Me with My Migration? . . . . . . . . . . . . . . . . . 27

novdocx (en) 7 January 2010

2 Getting Started 29

2.1 Assessing Your Current Network . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29

2.1.1 Running Novell Support Advisor . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29

2.1.2 Recording Your Current Network Information . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29

2.2 Identifying Needed Improvements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31

2.2.1 Server Hardware Considerations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32

2.2.2 Consolidation Considerations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33

2.2.3 Virtualization Considerations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33

2.2.4 File System Considerations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34

2.2.5 Method Considerations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34

2.2.6 Network Considerations. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34

2.2.7 eDirectory/LDAP Considerations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34

2.2.8 Time Synchronization . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35

2.2.9 Cluster Considerations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35

2.2.10 Application Compatibility Considerations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35

2.2.11 LAN/WAN Connection Considerations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36

3 Upgrading eDirectory to OES 37

3.1 About eDirectory in OES 2 SP2 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37

3.1.1 The Role of eDirectory in OES 2 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37

3.1.2 eDirectory Version Considerations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38

3.1.3 About eDirectory Management Tools in OES 2 . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39

3.2 Planning Your eDirectory Upgrade . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40

3.2.1 Deciding Whether to Redesign Your Tree . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40

3.2.2 Checking eDirectory Health . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41

3.2.3 For More Information . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43

3.3 Upgrading eDirectory . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44

Contents 5

Page 6

3.3.1 Do Not Install or Upgrade to eDirectory 8.8 Separately from OES 2 SP2 . . . . . . . . . 44

3.3.2 Choosing an Upgrade Strategy . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44

3.3.3 Moving, Creating, or Importing eDirectory Users . . . . . . . . . . . . . . . . . . . . . . . . . . . 45

3.4 Post-Upgrade Checks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 46

3.5 About Domain Services for Windows. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 46

3.6 Additional eDirectory Resources . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 49

4 Upgrading NSS and Data Storage to OES 51

4.1 About NSS in OES 2 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51

4.1.1 NSS Is Designed for the Enterprise. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51

4.1.2 More Reasons to Consider NSS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51

4.2 Platform Differences in NSS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52

4.3 Moving Data from NetWare to OES 2 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52

4.3.1 Moving Devices from NetWare to OES 2 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52

4.3.2 Moving Data from NSS on NetWare to NSS on OES 2 SP2. . . . . . . . . . . . . . . . . . . 53

4.3.3 Moving Data from NSS to Other Volume Types . . . . . . . . . . . . . . . . . . . . . . . . . . . . 53

4.4 Planning to Upgrade NSS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 53

4.4.1 Identify NSS Coexistence and Migration Issues . . . . . . . . . . . . . . . . . . . . . . . . . . . . 53

4.4.2 Limitations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 54

4.5 Post-Upgrade Procedures . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 55

4.6 Upgrading Distributed File Services (DFS) to OES . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 56

novdocx (en) 7 January 2010

5 Upgrading File Services to OES 57

5.1 Upgrading AFP File Services to OES . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 57

5.1.1 About AFP File Services in OES 2 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 57

5.1.2 Platform Differences in AFP File Services. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 58

5.1.3 Planning to Transfer AFP Services . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 59

5.1.4 Upgrading AFP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 60

5.1.5 Post-Upgrade Checks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 60

5.2 Upgrading CIFS File Services to OES . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 61

5.2.1 About CIFS File Services in OES 2 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 61

5.2.2 Platform Differences in CIFS File Services . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 62

5.2.3 Planning to Upgrade CIFS Services . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 63

5.2.4 Upgrading CIFS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 65

5.2.5 Post-Upgrade Checks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 65

5.3 Upgrading Novell FTP to OES . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 65

5.3.1 About FTP File Services . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 65

5.3.2 Platform Differences in FTP File Services . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 65

5.3.3 Planning. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 66

5.3.4 Transferring FTP Services to OES . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 66

5.3.5 Post-Upgrade Checks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 66

5.4 Upgrading iFolder to OES . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 66

5.4.1 About iFolder on OES 2 SP2 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 67

5.4.2 Platform Differences in iFolder File Services . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 68

5.4.3 Planning. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 68

5.4.4 Upgrading iFolder . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 69

5.4.5 Post-Upgrade Checks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 69

5.5 Upgrading NetWare Core Protocol (NCP) File Services . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 70

5.5.1 About NCP File Services in OES 2 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 70

5.5.2 Planning to Upgrade NCP File Services . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 72

5.5.3 Only Data Transfers Are Required . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 72

5.6 Upgrading NetStorage . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 73

5.6.1 About NetStorage . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 73

5.6.2 Platform Differences in NetStorage File Services . . . . . . . . . . . . . . . . . . . . . . . . . . . 74

6 OES 2 SP2: Upgrading to OES—Planning and Implementation Guide

Page 7

5.6.3 NetStorage Is Not Transferred . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 75

6 Upgrading Print Services to OES 77

6.1 About iPrint. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 77

6.2 Platform Differences in iPrint . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 77

6.3 Planning to Upgrade iPrint to OES. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 77

6.3.1 Requirements and Recommendations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 77

6.3.2 Limitations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 78

6.4 Upgrading iPrint to OES. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 78

6.5 Additional Information . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 79

7 Upgrading QuickFinder to OES 81

7.1 About QuickFinder in OES 2 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 81

7.2 Platform Differences in QuickFinder . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 81

7.3 Planning to Upgrade QuickFinder . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 81

7.4 Upgrading QuickFinder to OES . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 82

7.5 Post-Upgrade Considerations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 82

novdocx (en) 7 January 2010

8 Upgrading Backup Services to OES 83

8.1 Upgrading Novell Archive and Versioning Services to OES . . . . . . . . . . . . . . . . . . . . . . . . . . 83

8.1.1 About Archive and Versioning Services in OES 2 . . . . . . . . . . . . . . . . . . . . . . . . . . . 83

8.1.2 Platform Differences in Archive and Versioning Services . . . . . . . . . . . . . . . . . . . . . 83

8.1.3 Planning to Upgrade Archive and Versioning Services . . . . . . . . . . . . . . . . . . . . . . . 83

8.1.4 Upgrading Archive and Versioning Services . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 84

8.1.5 Post-Upgrade Procedures . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 84

8.2 About Upgrading Storage Management Services (SMS) . . . . . . . . . . . . . . . . . . . . . . . . . . . . 84

9 Upgrading Network Services to OES 85

9.1 Upgrading DNS Services to OES. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 85

9.1.1 About Novell DNS in OES 2 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 85

9.1.2 Platform Differences in Novell DNS. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 85

9.1.3 Planning to Upgrade Novell DNS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 85

9.1.4 Upgrading DNS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 86

9.2 Upgrading DHCP Services to OES . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 86

9.2.1 About Novell DHCP in OES 2 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 86

9.2.2 Platform Differences in Novell DHCP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 87

9.2.3 Planning to Upgrade Novell DHCP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 87

9.2.4 Upgrading DHCP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 87

9.3 Time Synchronization . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 87

9.3.1 About Time Synchronization in OES 2 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 87

9.3.2 Planning to Upgrade Time Synchronization Services . . . . . . . . . . . . . . . . . . . . . . . . 88

9.3.3 Transferring Time Synchronization Services . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 89

9.4 Service Location Protocol (SLP) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 89

9.4.1 About SLP in OES 2 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 89

9.4.2 Platform Differences in SLP Services . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 89

9.4.3 Setting Up SLP on OES 2 SP2 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 90

10 Upgrading Novell Cluster Services to OES 93

10.1 Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 93

10.2 Planning to Upgrade Novell Cluster Services . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 94

Contents 7

Page 8

10.2.1 Reviewing the Current Cluster . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 94

10.2.2 Upgrading Novell Cluster Services to OES 2 SP2 . . . . . . . . . . . . . . . . . . . . . . . . . . 94

10.2.3 Additional Information . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 95

10.3 Prerequisites . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 95

10.4 Caveats . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 96

10.5 Rolling Cluster Conversions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 96

11 Upgrading Other Novell Products to OES 97

11.1 GroupWise 7 and GroupWise 8 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 97

11.1.1 Source Platform Requirements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 97

11.1.2 Target Platform Requirements. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 97

11.1.3 Preparing to Migrate . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 98

11.1.4 Caveats . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 98

11.1.5 Tool Options . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 98

11.1.6 Migration Instructions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 99

11.1.7 Migrating GroupWise as Part of a Transfer ID Migration . . . . . . . . . . . . . . . . . . . . . . 99

11.1.8 Additional Information . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 100

11.2 Identity Manager . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 100

11.3 ZENworks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 101

11.3.1 Upgrading to ZENworks 10 Configuration Manager . . . . . . . . . . . . . . . . . . . . . . . . 101

11.3.2 Migrating ZENworks 7 from NetWare to Linux . . . . . . . . . . . . . . . . . . . . . . . . . . . . 101

novdocx (en) 7 January 2010

12 About Third-Party Applications 103

A Tools for Upgrading to OES 2 SP2 105

A.1 OES 2 SP2 Migration Tool . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 105

A.1.1 Consolidating Selected Data or Services . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 105

A.1.2 Transferring an Entire NetWare Server . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 106

A.1.3 More About Using the Migration Tool . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 106

A.2 Server Consolidation and Migration Tool (SCMT) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 107

A.3 NetWare Migration Wizard . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 107

A.4 Additional Information . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 107

B About the Management Tools in OES 2 SP2 109

B.1 Novell iManager 2.7 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 109

B.1.1 What's New in Version 2.7 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 109

B.1.2 Supported Web Browsers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 110

B.1.3 Caveats . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 110

B.1.4 Upgrading to iManager 2.7 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 110

B.2 Novell Remote Manager (NRM) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 110

B.2.1 Prerequisites . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 110

B.2.2 About Novell Remote Manager and OES 2 SP2 . . . . . . . . . . . . . . . . . . . . . . . . . . 111

B.3 About Other Management Tools . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 111

C Workstation Considerations 113

D Server Consolidation 115

E Examples 117

E.1 Replica and CA Server Migration. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 117

8 OES 2 SP2: Upgrading to OES—Planning and Implementation Guide

Page 9

E.1.1 Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 117

E.1.2 FAQs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 117

E.1.3 Preparing and Transferring Your Replica Server. . . . . . . . . . . . . . . . . . . . . . . . . . . 118

E.1.4 Post-Migration Configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 118

E.2 Cluster Migration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 119

E.2.1 Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 119

E.2.2 General Notes and Tips . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 120

E.2.3 Preparing to Migrate the Cluster . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 120

E.2.4 Transferring DHCP in the Cluster . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 121

E.2.5 Transferring DNS in a Cluster . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 122

E.2.6 iPrint Migration in a Cluster . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 123

E.2.7 Transferring AFP in a Cluster . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 126

E.2.8 Transferring CIFS in a Cluster . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 126

E.3 Server Identity Migration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 126

E.3.1 Preparing and Transferring Your Replica Server. . . . . . . . . . . . . . . . . . . . . . . . . . . 127

E.3.2 Post-Migration Steps . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 128

F Documentation Updates 131

novdocx (en) 7 January 2010

Contents 9

Page 10

novdocx (en) 7 January 2010

10 OES 2 SP2: Upgrading to OES—Planning and Implementation Guide

Page 11

About This Guide

running

onon

OES 2 SP1

• AFP

• Backup (SMS)

• Clustering (High Availability)

• DNS/DHCP

• eDirectory

• CIFS

• FTP

• iFolder 3.x

• NetStorage

• Novell Client Access

• Management Tools

• iPrint

• QuickFinder

• Novell Storage Services (NSS)

SUSE Linux Enterprise Server 10 SP2SUSE Linux Enterprise Server 10 SP2

Novell ServicesNovell Services

Open Enterprise Server (OES) 2 SP2 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 SP2, you install SUSE OS and the OES 2 SP2 components as an “add-on product.”

Linux Enterprise Server (SLES) 10 SP3 as the core

novdocx (en) 7 January 2010

What This Guide Provides

This guide provides an overview of the planning and implementation processes involved in upgrading from NetWare

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.

to OES 2 SP2. It provides overview and planning information along with

About This Guide 11

Page 12

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 (

, TM, 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.

novdocx (en) 7 January 2010

12 OES 2 SP2: Upgrading to OES—Planning and Implementation Guide

Page 13

Frequently Asked Questions

You probably have a few questions up front. Here are some answers.

 Section 1.1, “Why Not Stay on NetWare?,” on page 13

 Section 1.2, “Can I Move My NetWare Disks to an OES 2 Server?,” on page 14

 Section 1.3, “What About My Older NetWare Servers?,” on page 14

 Section 1.4, “What’s New in OES 2?,” on page 15

 Section 1.5, “What Do Novell Customers Recommend?,” on page 15

 Section 1.6, “What Are the Differences Between NetWare and OES 2?,” on page 16

 Section 1.7, “How Much Training Is Needed?,” on page 24

 Section 1.8, “What Training Is Available?,” on page 26

 Section 1.9, “Does Novell Have Community Support to Help Me with My Migration?,” on

page 27

novdocx (en) 7 January 2010

1.1 Why Not Stay on NetWare?

There are distinct advantages to moving to OES 2 SP2 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 SP2.

 NetWare Enters Extended Support in 2010: As Novell

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.

 iFolder 3.8: NetWare supports only Novell iFolder

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.

has stated for a number of years

2.x, which lacks important features found

 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.

 Xen virtualization technology: This no-cost virtualization solution runs on OES 2 SP2 and

lets you create NetWare virtual machines for those services that you want to keep on NetWare for the time being.

Frequently Asked Questions

Page 14

novdocx (en) 7 January 2010

 Domain Services for Windows: This OES 2 SP2 technology integrates eDirectory

and

Active Directory* users as well as Windows* and Novell file services.

 File Systems: OES 2 SP2 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 SP2.

1.2 Can I Move My NetWare Disks to an OES 2 Server?

Yes, you can.

“Moving Non-Clustered Devices From NetWare Servers to OES 2 Linux Servers” in the OES 2

SP2: NSS File System Administration Guide includes information on moving NSS volumes cross-

platform between servers in the same Novell eDirectory tree. See also “Cross-Platform Issues for

NSS.”

1.3 What About My Older NetWare Servers?

Earlier versions of NetWare should be upgraded to OES 2 SP2 as outlined in Ta ble 1-1 .

Table 1-1 Upgrade Paths from Earlier Versions of NetWare

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

NetWare 6.0 SP5 eDirectory 8.7.3.7 or

later

OES 2 SP2 Migration To ol

For more information, see “Transfer

ID Migration” in the OES 2 SP2:

Migration Tool Administration Guide.

For more information, see “Transfer

ID Migration” in the OES 2 SP2:

Migration Tool Administration Guide.

14 OES 2 SP2: Upgrading to OES—Planning and Implementation Guide

Page 15

1.4 What’s New in OES 2?

The “What’s New or Changed” section in the OES 2 SP2: 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.5 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 SP2 customers.

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.

novdocx (en) 7 January 2010

For help, see “Understanding Directory Structures in Linux POSIX File Systems” in the OES 2 SP2:

File Systems Management Guide and “Aligning NCP and POSIX File Access Rights” in the OES 2 SP2: 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 SP2: 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 SP2 discovered that they already had Linux expertise on their deployment teams.)

For help, see Section 1.7, “How Much Training Is Needed?,” on page 24 and Section 1.8, “What

Training Is Available?,” on page 26.

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

 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.

, WebAccess, etc.

Frequently Asked Questions 15

Page 16

Customer Tip

 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 SP2: Lab Guide for Linux 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 SP2 is easy and relatively painless.

Start your upgrade in a lab environment first and play with the product.

 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.

novdocx (en) 7 January 2010

 The Novell management Interfaces look the same. iPrint, iManager, etc.—all of the benefits of

NetWare are available on OES 2 SP2.

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.6 What Are the Differences Between NetWare and OES 2?

 Section 1.6.1, “System and Administrative User and Group Differences,” on page 17

 Section 1.6.2, “Comparing Services Between NetWare and OES 2 SP2,” on page 17

 Section 1.6.3, “Services Not Included in OES 2 SP2,” on page 24

16 OES 2 SP2: Upgrading to OES—Planning and Implementation Guide

Page 17

1.6.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, such as Novell AFP and Novell CIFS require proxy users to retrieve service-related information, such as user passwords 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 SP2” and “Administrative Users in OES 2 SP2” in the OES 2 SP2: Planning and Implementation Guide.

1.6.2 Comparing Services Between NetWare and OES 2 SP2

Table 1-3 Service Comparison Between NetWare 6.5 SP8 and OES 2 SP2 Linux

Service NetWare 6.5 SP8 OES 2 Platform Differences / Migration Issues

Access Control Lists Yes Yes In combination with NCPTM Server, Linux

supports the Novell® trustee model for file access on NSS volumes and NCP volumes on Linux.

novdocx (en) 7 January 2010

AFP (Apple* File Protocol)

Apache Web Server Yes - NetWare

Archive and Version Services (Novell)

Backup (SMS)

Yes - NFAP Yes - Novell

port of open source product

Yes Yes Setup varies slightly, but there are no

Yes Yes SMS provides backup applications with a

 SMS

 NSS-Xattr

AFP

Yes - Standard Linux

AFP services on NetWare and OES are proprietary and tightly integrated with eDirectory (NSS).

Administration Instance vs. Public Instance on NetWare (http://www.novell.com/ documentation/oes2/web_apache_nw/data/ aipcu6x.html#aipcu6x).

What’s Different about Apache on NetWare (http://www.novell.com/documentation/ oes2/web_apache_nw/data/ail8hvj.html) .

functional differences.

framework to develop complete backup and restore solutions. For information, see the

OES 2 SP2: Storage Management Services Administration Guide.

NSS provides extended attribute handling options for NSS on Linux. For information, see “Using Extended Attributes (xAttr)

Commands (Linux)” in the OES 2 SP2: NSS

File System Administration Guide.

and Novell Storage Services

Frequently Asked Questions 17

Page 18

Service NetWare 6.5 SP8 OES 2 Platform Differences / Migration Issues

novdocx (en) 7 January 2010

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 SP2:

Planning and Implementation Guide.)

Clustering Yes Yes “Product Features” in the OES 2 SP2:

Novell Cluster Services 1.8.7 for Linux Administration Guide.

“Product Features” in the NW6.5 SP8:

Novell Cluster Services 1.8.5 Administration Guide.

DFS (Novell Distributed File Services)

Yes 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 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 SP2: Planning and

Implementation Guide.

To plan your DHCP implementations, see “Planning a DHCP Strategy” in the OES 2

SP2: Novell DNS/DHCP Administration Guide for Linux and “Planning a DHCP Strategy” in the NW 6.5 SP8: Novell DNS/ DHCP Services Administration Guide.

18 OES 2 SP2: Upgrading to OES—Planning and Implementation Guide

Page 19

Service NetWare 6.5 SP8 OES 2 Platform Differences / Migration Issues

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 SP2: Planning and

Implementation Guide.

See “Planning a DNS Strategy” in the OES

2 SP2: Novell DNS/DHCP Administration Guide for Linux and “Planning a DNS Strategy” in the NW 6.5 SP8: Novell DNS/ DHCP Services Administration Guide.

novdocx (en) 7 January 2010

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. DST also supports NCP volumes as shadow pairs and Linux POSIX* volumes as shadow pairs.

eDirectory 8.8 Yes Yes No functional differences.

eDirectory Certificate

Yes Yes No functional differences.

Server

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

Yes Yes The Health Monitoring Server, which was

Services

Identity Manager 3.6.1

No Yes IDM 3.6.1 is not available on NetWare.

Bundle Edition

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 SP2:

Planning and Implementation Guide.

Frequently Asked Questions 19

Page 20

Service NetWare 6.5 SP8 OES 2 Platform Differences / Migration Issues

iPrint Yes Yes See “Overview” in the OES 2 SP2: iPrint for

Linux Administration Guide, and “Overview”

in the NW 6.5 SP8: iPrint Administration

Guide.

novdocx (en) 7 January 2010

IPXTM (Internetwork Packet Exchange

Yes No Novell has no plans to port IPX to OES.

)

from Novell

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

Yes Yes No functional differences.

eDirectory

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 Linux

See MySQL.com on the Web (http://

www.mysql.com).

See “Overview: MySQL” in the NW 6.5 SP8:

Novell MySQL Administration Guide.

NCP Volumes No Yes 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 SP2: 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

SP2: NCP Server for Linux Administration Guide.

20 OES 2 SP2: Upgrading to OES—Planning and Implementation Guide

Page 21

Service NetWare 6.5 SP8 OES 2 Platform Differences / Migration Issues

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

SP2: Planning and Implementation Guide.

novdocx (en) 7 January 2010

NetWare Traditional File System

NetWare Traditional

Yes No Novell has no plans to port the NetWare

Traditional File System to Linux.

Yes N /A

Vol um es

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

Yes Yes No functional differences. International Cryptography Infrastructure)

NMAS

(Novell

Yes Yes No functional differences. Modular Authentication Services)

Novell Audit Yes 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).

Novell Client Windows and Linux

for

Yes Yes Novell Client connectivity to OES 2 requires

that the NCP Server be installed.

support

Novell Cluster Services

Novell iFolder

2.x Yes No For migration information, see “Migrating

Yes Yes See “Product Features” in the OES 2 SP2:

Novell iFolder 3.8 No Yes OES 2 SP2 includes Linux, Macintosh*, and

Novell Licensing

Yes No See “OES 2 Doesn’t Support NLS” in the Services

Novell Cluster Services 1.8.7 for Linux Administration Guide.

See “Product Features” in the NW6.5 SP8:

Novell Cluster Services 1.8.5 Administration Guide.

iFolder 2.x” in the OES 2 SP2: Migration Tool Administration Guide

Windows clients.

OES 2 SP2: Planning and Implementation Guide.

Frequently Asked Questions 21

Page 22

Service NetWare 6.5 SP8 OES 2 Platform Differences / Migration Issues

novdocx (en) 7 January 2010

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 SP2: NSS File

System Administration Guide.

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://www.pervasive.com/ support/technical/online_manuals.asp).

PKI (Public Key

Yes Yes No functional differences.

Infrastructure)

Printing Yes Yes See “iPrint” in the OES 2 SP2: Planning and

Implementation Guide.

QuickFinder

Yes Ye s

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 OES 2 SP2: Samba Administration

Guide.

22 OES 2 SP2: Upgrading to OES—Planning and Implementation Guide

Page 23

Service NetWare 6.5 SP8 OES 2 Platform Differences / Migration Issues

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: Novell QuickFinder Server 5.0 Administration Guide.

novdocx (en) 7 January 2010

SLP Yes - Novell

SLP

Software RAIDS (NSS volumes)

Storage Management

Services

(SMS)

Yes (0, 1, 5, 10,

15)

Yes Yes No functional differences, except that the

Yes - OpenSLP

For OES 2, see “SLP Services in the

Network” (http://www.novell.com/ documentation/sles10/sles_admin/data/ cha_slp.html) in the SLES 10 SP3: Installation and Administration Guide (http:// www.novell.com/documentation/sles10/ sles_admin/data/sles_admin.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.

Yes (0, 1, 5) See “Understanding Software RAID

Devices” in the OES 2 SP2: NSS File

System Administration Guide.

SBCON backup engine is not supported on Linux.

TCP/IP Yes Yes No functional differences.

Timesync NLM

Yes No Timesync will not be ported to 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.

However, NTPv3 is available on both Linux and NetWare.

See “Time Services” in the OES 2 SP2:

Planning and Implementation Guide.

Frequently Asked Questions 23

Page 24

Service NetWare 6.5 SP8 OES 2 Platform Differences / Migration Issues

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/oes2/ web_tomcat_nw/data/ ahdyran.html#ahdyran)

novdocx (en) 7 January 2010

Virtual Office (Collaboration)

WAN Traffic Manager Yes No

Xen Virtualization Guest

Xen Virtualization Host Server

Yes No 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).

Yes Yes 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.

N/A Yes

1.6.3 Services Not Included in OES 2 SP2

See “eGuide, IFolder 2, and Virtual Office Are Still Available on Netware” in the NW 6.5 SP8:

Planning and Implementation Guide.

1.7 How Much Training Is Needed?

 Section 1.7.1, “What Our Customers Tell Us,” on page 24

 Section 1.7.2, “Conduct a Training Assessment,” on page 25

1.7.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 SP2. Many administrators are pleasantly surprised when they see that their knowledge and skills apply very well to managing Novell services on OES 2 SP2.

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.

24 OES 2 SP2: Upgrading to OES—Planning and Implementation Guide

Page 25

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 SP2

 Differences between NetWare and OES: services, features, and interoperability

 Troubleshooting

1.7.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 Qualities of Potential Candidates

novdocx (en) 7 January 2010

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.

Linux Administrator Novell recommends SUSE Linux-

specific 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.

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.

 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.

 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.

Linux Support Staff Support staff need to be

knowledgeable about how specific network services (eDirectory, edge services, iPrint, etc.) work on Linux.

Novell offers service-specific courses for most major services.

 Support current file, print, and

other network systems.

 Will need to move to more Linux

support, but system focus will remain the same.

Frequently Asked Questions 25

Page 26

1.8 What Training Is Available?

Here are some of the avenues you can use to get the training you need:

 Section 1.8.1, “Novell Training Services,” on page 26

 Section 1.8.2, “Complimentary Free Training,” on page 26

 Section 1.8.3, “Product Documentation,” on page 26

1.8.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 s i te 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

technicaltraining@novell.com (mailto:technicaltraining@novell.com)

 To subscribe to the Technical Training Newsletter, see http://www.novell.com/info/list (http://

www.novell.com/company/subscribe/)

novdocx (en) 7 January 2010

1.8.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.8.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 SP2: 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).

26 OES 2 SP2: Upgrading to OES—Planning and Implementation Guide

Page 27

1.9 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-NovellOpen-Enterprise-Server-on-SUSE-Linux-Enterprise/154405544072?ref=ts) as well.

novdocx (en) 7 January 2010

Frequently Asked Questions 27

Page 28

novdocx (en) 7 January 2010

28 OES 2 SP2: Upgrading to OES—Planning and Implementation Guide

Page 29

Getting Started

TIP: You can move storage devices directly from NetWare to OES 2.

“Moving Non-Clustered Devices From NetWare Servers to OES 2 Linux Servers” in the OES 2

SP2: NSS File System Administration Guide includes information on moving NSS volumes cross-

platform between servers in the same Novell eDirectory tree. See also “Cross-Platform Issues for

NSS”.

You can ensure a successful upgrade by

 Section 2.1, “Assessing Your Current Network,” on page 29

 Section 2.2, “Identifying Needed Improvements,” on page 31

2.1 Assessing Your Current Network

novdocx (en) 7 January 2010

 Section 2.1.1, “Running Novell Support Advisor,” on page 29

 Section 2.1.2, “Recording Your Current Network Information,” on page 29

2.1.1 Running Novell Support Advisor

To ensure you are equipped with the latest pre-upgrade information and are aware of known issues, we recommend that 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

Page 30

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

novdocx (en) 7 January 2010

Site Location

Southwest Office

# of NetWare Servers

62-NW4.11

NetWare Versio ns

1-NW5.1 3-NW6.5

Server Notes

All NetWare are being retired. Users will be moved to OES 2 SP2 servers

# of Clients

30 4–Win98

Client Breakdown

6-W2K 20-WinXP

Client Notes

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

/eDirectoryTM 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 NCPTM (Novell ClientTM), then list the servers that provide them and the contexts of the users that use them.

30 OES 2 SP2: Upgrading to OES—Planning and Implementation Guide

Page 31

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 SP2.

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 SP2 and whether they are Novell YES Approved.

Specify which applications will be ported to OES 2 SP2 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.

novdocx (en) 7 January 2010

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 32

 Section 2.2.2, “Consolidation Considerations,” on page 33

 Section 2.2.3, “Virtualization Considerations,” on page 33

 Section 2.2.4, “File System Considerations,” on page 34

 Section 2.2.5, “Method Considerations,” on page 34

 Section 2.2.6, “Network Considerations,” on page 34

 Section 2.2.7, “eDirectory/LDAP Considerations,” on page 34

 Section 2.2.8, “Time Synchronization,” on page 35

 Section 2.2.9, “Cluster Considerations,” on page 35

 Section 2.2.10, “Application Compatibility Considerations,” on page 35

 Section 2.2.11, “LAN/WAN Connection Considerations,” on page 36

Getting Started 31

Page 32

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 SP2 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.

Tabl e 2-3 outlines both “minimum” and “recommended” requirements for running OES 2 SP2.

NOTE: The RAM and disk space amounts shown in Table 2-3 are for system components only. The OES 2 SP2 components you install might require additional RAM and disk space.

novdocx (en) 7 January 2010

Table 2-3 Minimum and Recommended Hardware Requirements

System Component

Computer Server-class computer

Memory 1 GB of RAM 2 GB of RAM

Free Disk Space

CD-ROM Drive

Network Board

Storage Adapter

Minimum Recommended

Server-class computer that has been certified by the hardware with Intel Pentium* II or AMD * K7 450 MHz processor

10 GB of available, unpartitioned disk space.

4X CD-ROM or DVD drive if installing from physical media

Ethernet 100 Mbps

N/A When determining what hardware bus adapters (HBAs) to use for

vendor for SLES 10 SP1.

Pentium III, Pentium III Xeon *, Pentium 4, Intel * Xeon 700 MHz,

AMD K8 CPUs (Athlon* 64 and Opteron*), Intel EM64T or higher

processor.

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.

48X CD-ROM drive or DVD drive if installing from physical media.

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.

32 OES 2 SP2: Upgrading to OES—Planning and Implementation Guide

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.

Page 33

novdocx (en) 7 January 2010

System Component

IP Address  One IP address on

Minimum Recommended

Internet connectivity from the server in order to complete

a subnet

registration and configure patches

 Subnet mask

 Default gateway

Mouse N/A USB or PS/2

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.

2.2.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 SP2, 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 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 SP2? 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 SP2:

Installation Guide. For information about installing OES 2 SP2 as a guest operating system,

“Installing, Upgrading, or Updating OES on a Xen-based VM” in the OES 2 SP2: Installation

Guide.

software can be accommodated this way until suitable

Getting Started 33

Page 34

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

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: Cases can also be made for using ext3 or ReiserFS. ReiserFS is optimized for small files and performance. In fact, both Novell IS&T and the GroupWise engineering team recommend using ReiserFS for GroupWise servers, primarily because of performance increases and the fact that GroupWise doesn't utilize the advanced features of NSS. The performance levels for ext3 are similar to those of ReiserFS.

(NSS) volumes on NetWare?

novdocx (en) 7 January 2010

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?

34 OES 2 SP2: Upgrading to OES—Planning and Implementation Guide

Page 35

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.

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 SP2: Planning and Implementation Guide.

novdocx (en) 7 January 2010

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 SP2: Novell

Cluster Services 1.8.7 for Linux Administration Guide 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 SP2 or SLES 10?

Getting Started 35

Page 36

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.

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.

novdocx (en) 7 January 2010

36 OES 2 SP2: Upgrading to OES—Planning and Implementation Guide

Page 37

Upgrading eDirectory to OES

This section discusses upgrading eDirectoryTM to OES 2 and includes the following sections:

 Section 3.1, “About eDirectory in OES 2 SP2,” on page 37

 Section 3.2, “Planning Your eDirectory Upgrade,” on page 40

 Section 3.3, “Upgrading eDirectory,” on page 44

 Section 3.4, “Post-Upgrade Checks,” on page 46

 Section 3.5, “About Domain Services for Windows,” on page 46

 Section 3.6, “Additional eDirectory Resources,” on page 49

3.1 About eDirectory in OES 2 SP2

 Section 3.1.1, “The Role of eDirectory in OES 2,” on page 37

 Section 3.1.2, “eDirectory Version Considerations,” on page 38

 Section 3.1.3, “About eDirectory Management Tools in OES 2,” on page 39

novdocx (en) 7 January 2010

3.1.1 The Role of eDirectory in OES 2

 “eDirectory Is Essential to OES 2 Services” on page 37

 “About Installing eDirectory and OES Services” on page 37

 “The First Server Is Critical” on page 38

 “eDirectory Provides Additional Security for the Server” on page 38

eDirectory Is Essential to OES 2 Services

eDirectory is an integral component of the services that make up OES 2 SP2. 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.

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.

Upgrading eDirectory to OES

Page 38

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 SP2: Planning and

Implementation Guide.

novdocx (en) 7 January 2010

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.4” on page 38

 “eDirectory 8.7.3” on page 38

 “Migrating Earlier DS Versions” on page 39

eDirectory 8.8.4

OES 2 SP2 includes eDirectory 8.8.4. Where possible, you should upgrade existing servers to eDirectory 8.8.4 before or during the process of introducing OES 2 SP2 into the environment. Novell anticipates releasing eDirectory 8.8.5 through the patch channel in the near future and recommends applying the patch when it becomes available.

For complete information, refer to the Novell eDirectory 8.8 Whats New Guide available at

www.novell.com/documentation/edir88 (http://www.novell.com/documentation/edir88/).

eDirectory 8.7.3

Novell supports eDirectory 8.7.3.9 or later on NetWare to facilitate the transition from NetWare to OES 2 SP2. 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 full support is NetWare 6.5.

eDirectory 8.8.4 also runs on NetWare 6.5.

38 OES 2 SP2: Upgrading to OES—Planning and Implementation Guide

Page 39

Migrating Earlier DS Versions

Earlier versions of DS/eDirectory should be migrated to eDirectory 8.7.3.7 as outlined in Tab le 1-1,

“Upgrade Paths from Earlier Versions of NetWare,” on page 14.

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.3 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 SP2: Novell Remote Manager for Linux

Administration Guide.

 Novell Import Conversion Export Utility (ICE): You use ICE to:

novdocx (en) 7 January 2010

 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.

 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: Lets you configure the LDAP Server and LDAP Group Objects. For usage information, enter

man ldapconfig

at the terminal prompt.

Upgrading eDirectory to OES 39

Page 40

nmasinst: Lets you configure Novell Modular Authentication Service (NMASTM) 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.

novdocx (en) 7 January 2010

 ConsoleOne: This utility is not supported to perform administration tasks on OES 2 SP2

server. However, if you have a service that requires ConsoleOne

GroupWise

, it is supported for administration of those applications.

, such as Novell

3.2 Planning Your eDirectory Upgrade

Installing eDirectory on OES 2 SP2 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 40

 Section 3.2.2, “Checking eDirectory Health,” on page 41

 Section 3.2.3, “For More Information,” on page 43

3.2.1 Deciding Whether to Redesign Your Tree

Upgrading to OES 2 SP2 provides an excellent opportunity to evaluate whether changes are necessary to better accommodate your current and future needs.

 “Questions to Ask” on page 40

 “Deciding Whether to Move Services” on page 41

 “For File and Print, Design around Your WAN” on page 41

 “Verify Your Redesign in a Lab First” on page 41

Questions to Ask

 Type of Tr ee: 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?

 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?

40 OES 2 SP2: Upgrading to OES—Planning and Implementation Guide

Page 41

 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

novdocx (en) 7 January 2010

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 SP2 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.

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 SP2 and eDirectory 8.8 into an existing tree or for transferring eDirectory from NetWare to OES.

 “What to Check For” on page 42

 “Health Check Tools To Use” on page 43

Upgrading eDirectory to OES 41

Page 42

 “Check Requirements, Prerequisites, and Compatibility” on page 43

 “Check Application Compatibility” on page 43

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.

novdocx (en) 7 January 2010

 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.

 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.

42 OES 2 SP2: Upgrading to OES—Planning and Implementation Guide

Page 43

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.

novdocx (en) 7 January 2010

You can run the diagnostic tools (

ndscheck

on OES 2 SP2;

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 web-

based 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.

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.

Upgrading eDirectory to OES 43

Page 44

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 SP2,” on

page 44

 Section 3.3.2, “Choosing an Upgrade Strategy,” on page 44

 Section 3.3.3, “Moving, Creating, or Importing eDirectory Users,” on page 45

3.3.1 Do Not Install or Upgrade to eDirectory 8.8 Separately from OES 2 SP2

Because OES services are tightly integrated with eDirectory, both the services and eDirectory must be upgraded at the same time. The OES 2 SP2 install is not designed to handle a separate installation or upgrade of eDirectory 8.8.

3.3.2 Choosing an Upgrade Strategy

novdocx (en) 7 January 2010

There are several basic strategies for setting up eDirectory on OES 2 SP2 or upgrading to the OES 2 SP2 platform:

 “Transferring eDirectory to a New Server” on page 44

 “Starting Fresh with OES 2 SP2” on page 44

 “Adding a branch to an existing tree” on page 45

 “Manual Upgrade Using Replicas” on page 45

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 SP2 server.

Use the OES 2 SP2 Migration Tool for this purpose, specifically the Identity Transfer functionality. For more information, see “Transfer ID Migration” in the OES 2 SP2: Migration Tool

Administration Guide.

Starting Fresh with OES 2 SP2

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 SP2 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 SP2.

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.

44 OES 2 SP2: Upgrading to OES—Planning and Implementation Guide

Page 45

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 SP2 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 SP2 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 SP2 server, without the OES server assuming the NetWare server's identity, you can move objects to a new OES 2 SP2 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 re-created.

1 Create a new OES 2 SP2 server with a new eDirectory 8.8 tree.

novdocx (en) 7 January 2010

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 non-destructive 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 SP2 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 45

 “Creating and Importing an LDIF file” on page 46

 “Using the OES 2 SP2 Migration Tool” on page 46

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 45

Page 46

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 SP2 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.

novdocx (en) 7 January 2010

3.5 About Domain Services for Windows

NOTE: The following overview of DSfW is copied from the OES 2 SP2: 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 Samba-enabled storage on OES servers.

46 OES 2 SP2: Upgrading to OES—Planning and Implementation Guide

Page 47

Figure 3-1 DSfW File Access Overview

Could be on a

separate OES 2 server

in or out of the domain

Could be on a separate

Windows server

eDirectory

DSfW server

eDirectory

User

Windows Explorer

Internet Explorer

Access Methods Authentication

File Storage Services

AD Windows

server

AD User

Windows Explorer

Internet Explorer

Cross-Forest

Trust

novdocx (en) 7 January 2010

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.

Unlike Windows workgroup or Novell Samba, the user doesn’t need to have a matching username and password on the local workstation.

Although not shown, Novell Client users can also access files through a normal

connection.

NCP

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.

For AD users, file service access is controlled by authentication through the AD server.

On OES 2 servers, file storage services are provided by Samba to NSS or traditional Linux file systems.

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 47

Page 48

Figure 3-2 DSfW User Management Overview

DSfW

Administrators

Novell iManager

Management Tools Users

AD server

Microsoft Management

Console

DSfW

eDirectory server

novdocx (en) 7 January 2010

The following table explains the information illustrated in Figure 3-2.

Management Tools Users

iManager manages DSfW users exactly like other eDirectory users.

MMC manages both AD users and DSfW users as though they were AD users.

DSfW users must have the Default Domain Password policy assigned and a valid Universal Password.

DSfW users are automatically enabled for Samba and LUM.

48 OES 2 SP2: Upgrading to OES—Planning and Implementation Guide

Page 49

Figure 3-3 DSfW Storage Management Overview

Network

Administrators

Management Tools Storage

Windows servers

OES 2 servers

OES

Storage Management

Tools

Windows

Storage Management

Tools

novdocx (en) 7 January 2010

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

Storage devices on OES 2 servers can be either NSS or traditional Linux volumes. Samba management standards

apply to both volume types. devices on OES and Windows servers, respectively.

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 SP2: Domain Services for Windows Administration Guide.

For implementation information, see the OES 2 SP2: 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 49

Page 50

 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)

novdocx (en) 7 January 2010

50 OES 2 SP2: Upgrading to OES—Planning and Implementation Guide

Page 51

Upgrading NSS and Data Storage

novdocx (en) 7 January 2010

to OES

 Section 4.1, “About NSS in OES 2,” on page 51

 Section 4.2, “Platform Differences in NSS,” on page 52

 Section 4.3, “Moving Data from NetWare to OES 2,” on page 52

 Section 4.4, “Planning to Upgrade NSS,” on page 53

 Section 4.5, “Post-Upgrade Procedures,” on page 55

 Section 4.6, “Upgrading Distributed File Services (DFS) to OES,” on page 56

4.1 About NSS in OES 2

Novell® Storage ServicesTM is available with NetWare® 5.0 and later. The NSS kernel has been open sourced and is included in Novell SUSE OES 2 SP2. The tools to manage NSS are available only in OES.

 Section 4.1.1, “NSS Is Designed for the Enterprise,” on page 51

 Section 4.1.2, “More Reasons to Consider NSS,” on page 51

4.1.1 NSS Is Designed for the Enterprise

SLES 9 SP1 Linux distribution and later and with Novell

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 SP2.

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 SP2 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

Page 52

 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 SP2:

 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

novdocx (en) 7 January 2010

4.2 Platform Differences in NSS

Most NSS features that have been available on NetWare are now also available on OES 2 SP2.

For the most up-to-date feature comparison, see “Comparison of NSS on NetWare and NSS on

Linux” in the OES 2 SP2: NSS File System Administration Guide.

4.3 Moving Data from NetWare to OES 2

 Section 4.3.1, “Moving Devices from NetWare to OES 2,” on page 52

 Section 4.3.2, “Moving Data from NSS on NetWare to NSS on OES 2 SP2,” on page 53

 Section 4.3.3, “Moving Data from NSS to Other Volume Types,” on page 53

4.3.1 Moving Devices from NetWare to OES 2

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 SP2 servers.

“Moving Non-Clustered Devices From NetWare Servers to OES 2 Linux Servers” in the OES 2

SP2: NSS File System Administration Guide includes information on moving NSS volumes cross-

platform between servers in the same Novell eDirectory tree. See also “Cross-Platform Issues for

NSS”.

52 OES 2 SP2: Upgrading to OES—Planning and Implementation Guide

Page 53

4.3.2 Moving Data from NSS on NetWare to NSS on OES 2 SP2

The OES 2 SP2 Migration Tool supports transferring data from a source NSS volume on NetWare to a target NSS volume on OES 2 SP2. 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 SP2

Linux” in the OES 2 SP2: Migration Tool Administration Guide.

4.3.3 Moving Data from NSS to Other Volume Types

The OES 2 SP2 Migration Tool also supports moving data from an NSS volume on NetWare to a Linux POSIX volume on OES 2 SP2.

 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.

novdocx (en) 7 January 2010

If you are unsure about the implications briefly stated above, you should read the following sections in the OES 2 documentation:

 OES 2 SP2: 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 SP2: File Systems Management Guide

 “Understanding File System Access Control Using Trustees”

 “Coexistence and Migration Issues”

4.4 Planning to Upgrade NSS

As you plan your NSS implementation, the following file system guidelines should be noted:

 Section 4.4.1, “Identify NSS Coexistence and Migration Issues,” on page 53

 Section 4.4.2, “Limitations,” on page 54

4.4.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 SP2:

NSS File System Administration Guide:

 “Cross-Platform Issues for NSS”

Discusses pool snapshots, NSS volumes and features, file access, and management tools

Upgrading NSS and Data Storage to OES 53

Page 54

 “Migrating NSS Devices from NetWare to OES 2 Linux”

Includes guidelines for moving NSS pools and volumes between NetWare and OES 2 SP2 servers and instructions for moving both clustered and non-clustered devices from previous versions of NetWare and OES 1.

4.4.2 Limitations

 “Traditional NetWare File System Is Not Supported” on page 54

 “Installing NSS on the System Disk” on page 54

 “Samba Access Requires LUM” on page 54

 “The Linux OS Can’t Be Installed on NSS” on page 54

 “Moving Volumes Cross-Platform Has Limitations” on page 54

 “Pool Snapshots Cannot Be Moved” on page 55

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 tie-ins, and therefore, has little utility.

novdocx (en) 7 January 2010

NWFS is not supported on OES 2 SP2 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 SP2: 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 SP2: Planning and Implementation Guide. For

information specific to NSS, see “Planning NSS Storage Solutions” in the OES 2 SP2: NSS File

System Administration Guide.

The Linux OS Can’t Be Installed on NSS

You cannot install the Linux operating system on an NSS volume. OES 2 SP2 requires a Linux traditional file system volume for the operating system, such as Ext3 or ReiserFS.

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.

54 OES 2 SP2: Upgrading to OES—Planning and Implementation Guide

Page 55

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.

You can move storage devices containing NSS volumes between NetWare servers and OES 2 SP2 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.

novdocx (en) 7 January 2010

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

User files, such as

Shared directory for a team (where the group is used for access.)

Shared team files (where the group is used for access.)

/home/userid/myfile rw- r-- ---

/home/userid rwx --- ---

rwx rwx ---

rw- rw- ---

700

740

760

660

Upgrading NSS and Data Storage to OES 55

Page 56

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.

novdocx (en) 7 January 2010

For information and instructions, see “Migrating DFS from NetWare to OES 2 SP2 Linux.” in the

OES 2 SP2: Novell Distributed File Services Administration Guide.

For additional instructions for moving NSS devices cross-platform, see “Migrating NSS Devices

from NetWare to OES 2 Linux” in the OES 2 SP2: NSS File System Administration Guide.

56 OES 2 SP2: Upgrading to OES—Planning and Implementation Guide

Page 57

eDirectory

LDAP server

OES 2 Linux

server

Access Points Authentication AFP Services

MAC

AFP server

processes

AFP

Upgrading File Services to OES

 Section 5.1, “Upgrading AFP File Services to OES,” on page 57

 Section 5.2, “Upgrading CIFS File Services to OES,” on page 61

 Section 5.3, “Upgrading Novell FTP to OES,” on page 65

 Section 5.4, “Upgrading iFolder to OES,” on page 66

 Section 5.5, “Upgrading NetWare Core Protocol (NCP) File Services,” on page 70

 Section 5.6, “Upgrading NetStorage,” on page 73

5.1 Upgrading AFP File Services to OES

 Section 5.1.1, “About AFP File Services in OES 2,” on page 57

 Section 5.1.2, “Platform Differences in AFP File Services,” on page 58

 Section 5.1.3, “Planning to Transfer AFP Services,” on page 59

novdocx (en) 7 January 2010

 Section 5.1.4, “Upgrading AFP,” on page 60

 Section 5.1.5, “Post-Upgrade Checks,” on page 60

5.1.1 About AFP File Services in OES 2

Starting with OES 2 SP2, 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 SP2 servers with NSS volumes without installing any additional software, such as the Novell Client (see Figure 5-1).

Figure 5-1 How Novell AFP Works

Upgrading File Services to OES

Page 58

The following table explains the information illustrated in Figure 5-1.

Access Points Authentication AFP File Services

novdocx (en) 7 January 2010

eDirectoryTM 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.

Although shown separately, eDirectory could be installed on the OES 2 server.

Of course, the same files can also be accessed through other OES file services (such as NetStorage) that connect to Linux volumes.

5.1.2 Platform Differences in AFP File Services

The differences in AFP services on NetWare and OES 2 SP2 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 server.

See “Enabling and Disabling

AFP” in the NW 6.5 SP8: AFP,

CIFS, and NFS (NFAP) Administration Guide

Ability to configure AFP server parameters through iManager.

See “Administering the AFP

Server” in the OES 2 SP2: Novell

AFP For Linux Administration Guide.

Filenames and Paths

sys:\etc\ctxs.cfg

sys:\etc\afpvol.cfg

sys:\etc\afptcp.log

/etc/opt/novell/afptcpd/ afpdircxt.conf

/etc/opt/novell/afptcpd/ afpvols.conf

/etc/opt/novell/afptcpd/ afptcpd.conf

/var/log/afptcpd/ afptcp.log

Installation Customized installation during

installation of NetWare 6.5.

See, “Installing Novell Native File

Access Protocols on a NetWare

6.5 Server” in the NW 6.5 SP8:

AFP, CIFS, and NFS (NFAP) Administration Guide

Simple Password support Yes No

Universal Password Yes. Limited to 8 characters. Yes. Over 8 characters.

Installation through YaST along with associated dependencies.

See “Installing and Setting Up

AFP” in the OES 2 SP2: Novell

AFP For Linux Administration Guide.

58 OES 2 SP2: Upgrading to OES—Planning and Implementation Guide

Page 59

Feature Description AFP for NetWare AFP for OES

Upgrade/migration support Not Applicable Support to upgrade AFP from

NetWare to OES.

See “Migrating AFP from

NetWare to OES 2 SP2 Linux” in

the OES 2 SP2: Novell AFP For

Linux Administration Guide.

novdocx (en) 7 January 2010

Mac versions supported Classic Mac, Mac OS* 10.3, 10.4

and 10.5

Cross-protocol locking Supported among AFP, CIFS,

and NCP

Authentication methods Clear text Clear text

Dynamic detection of volumes Yes Yes, but the AFP server needs to

Choosing volumes to be exported Yes No. Exports all the volumes.

Support for 64-bit architecture No Yes

Mac OS 10.3, 10.4 and 10.5

Supported among AFP, CIFS, and NCP.

Two-Way Random Key Exchange

Random Exchange

Diffie-Hellman Exchange

be reloaded.

5.1.3 Planning to Transfer AFP Services

The OES 2 SP2 Migration Tool supports transferring AFP file services from NetWare to OES 2 SP2. 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 59

 “Limitations” on page 60

 “Universal Password” on page 60

Requirements

Table 5-2 AFP Source and Target Server Requirements

Source Server Target Server

NetWare 5.1 or later OES 2 SP2

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.

Upgrading File Services to OES 59

Page 60

Limitations

The OES 2 SP2 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 SP2 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 SP2: Migration Tool

Administration Guide and “Installing and Setting Up AFP” in the OES 2 SP2: 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 58.

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. The process also configures the AFP proxy user to read the passwords.

novdocx (en) 7 January 2010

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 SP2:

 Consolidate: If you are transferring just the AFP service and associated data to an OES 2 SP2

server, you should perform a consolidation migration. For more information, see Section A.1.1,

“Consolidating Selected Data or Services,” on page 105.

 Transfer ID: If you are transferring an entire NetWare server, including the AFP service and

associated data, to an OES 2 SP2 server, you should transfer the entire server configuration. For more information, see Section A.1.2, “Transferring an Entire NetWare Server,” on page 106.

To transfer Novell AFP from NetWare to OES 2 SP2, follow the instructions in “Migrating AFP

from NetWare to OES 2 SP2 Linux ” in the OES 2 SP2: Migration Tool Administration Guide.

5.1.5 Post-Upgrade Checks

 “Verify Upgrade Success” on page 60

 “Preparing for the First Login” on page 61

Verify Upgrade Success

After the process is complete, be sure to complete the instructions in “Verifying the Migration

Process” in the OES 2 SP2: Migration Tool Administration Guide.

60 OES 2 SP2: Upgrading to OES—Planning and Implementation Guide

Page 61

Preparing for the First Login

You must do two things to ensure that users can authenticate seamlessly to the transferred AFP service:

novdocx (en) 7 January 2010

1. Restart eDirectory with the environment variable

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 SP2: Migration Tool

Administration Guide.

NDS_TRY_NDSLOGIN_FIRST

set to

TRUE

5.2 Upgrading CIFS File Services to OES

 Section 5.2.1, “About CIFS File Services in OES 2,” on page 61

 Section 5.2.2, “Platform Differences in CIFS File Services,” on page 62

 Section 5.2.3, “Planning to Upgrade CIFS Services,” on page 63

 Section 5.2.4, “Upgrading CIFS,” on page 65

 Section 5.2.5, “Post-Upgrade Checks,” on page 65

5.2.1 About CIFS File Services in OES 2

Starting with OES 2 SP2, 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 SP2 servers with NSS volumes without installing any additional software, such as the Novell Client (see

Figure 5-2).

Upgrading File Services to OES 61

Page 62

Figure 5-2 How Novell CIFS Works

eDirectory

LDAP server

eDirectory users have automatic access to Novell CIFS file services.

Any CIFS/SMB Client

(such as Windows Explorer)

CIFS server

processes

Web Folders

(Windows Explorer or

Internet Explorer browser)

Access Methods Authentication

File Storage Services

OES Linux

server

WebDAV

CIFS

novdocx (en) 7 January 2010

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.

 CIFS Client Access: Windows

Explorer users can access and modify files on the OES 2 SP2 server just as they would on any workgroup server share.

 Web Folder: Users can create Web

Folders in Windows Explorer or Internet Explorer.

Files on the OES 2 SP2 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 SP2 are summarized in the following table.

Although it is shown separately, eDirectory could be installed on the OES 2 server.

Of course, the same files can also be accessed through other OES file services (such as NetStorage) that connect to NSS volumes.

62 OES 2 SP2: Upgrading to OES—Planning and Implementation Guide

Page 63

Table 5-3 CIFS services on NetWare and OES 2 SP2

Service NetWare OES 2 SP2

64-Bit Support No Yes

novdocx (en) 7 January 2010

Distributed File Services for NSS Vol um es

OpLocks Yes Yes

Cross Protocol Locking Yes Future

NSS Support Yes Yes

CIFS-enabled shared NSS pool/ volume in a NetWare-to-NetWare or OES-to-OES cluster

CIFS-enabled shared NSS pool/ volume in a mixed NetWare-toOES cluster

iManager Support and Administration tool

File and Record Locking Yes Yes

Domain Emulation Yes Future

Monitoring No Future

Xen Virtualized Host Server Environment

Xen Virtualized Guest Server Environment

Yes Future

Yes Yes

No No

Yes Yes

NA No

Yes Yes

Multi-processor/Multicore Server Support

Multi-File System Support No Future

NTLMv2/Kerberos No Future

No Yes

5.2.3 Planning to Upgrade CIFS Services

The OES 2 SP2 Migration Tool supports transferring CIFS file services from NetWare to OES 2 SP2. The upgrade process is quite straightforward, but there are, of course, some planning steps that you must take to ensure success.

 “Requirements” on page 64

 “Limitations” on page 64

 “Universal Password” on page 64

Upgrading File Services to OES 63

Page 64

Requirements

Table 5-4 CIFS Source and Target Server Requirements

Source Server Target Server

NetWare 5.1 or later OES 2 SP2.

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 64

 “Server Configuration Information Not Transferred with Consolidation” on page 64

 “Upgrading Novell Samba Not Supported” on page 64

novdocx (en) 7 January 2010

Cross-Tree Migration Not Supported

The OES 2 SP2 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 SP2 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 SP2: Migration Tool

Administration Guide and “Installing and Setting Up AFP” in the OES 2 SP2: 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 SP2 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.

64 OES 2 SP2: Upgrading to OES—Planning and Implementation Guide

Page 65

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 SP2:

 Consolidate: If you want to move just the CIFS shares and associated data to an OES 2 SP2

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 105.

 Transfer ID: If you are transferring an entire NetWare server, including the CIFS service and

associated data, to an OES 2 SP2 server, then you should perform a Transfer ID migration. For more information, see Section A.1.2, “Transferring an Entire NetWare Server,” on page 106.

To upgrade Novell CIFS from NetWare to OES 2 SP2, follow the instructions in “Migrating CIFS

from NetWare to OES 2 SP2 Linux” in the OES 2 SP2: Migration Tool Administration Guide.

5.2.5 Post-Upgrade Checks

 “Restarting CIFS” on page 65

novdocx (en) 7 January 2010

 “Verifying Success” on page 65

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 SP2: Migration Tool

Administration Guide.

5.3 Upgrading Novell FTP to OES

 Section 5.3.1, “About FTP File Services,” on page 65

 Section 5.3.2, “Platform Differences in FTP File Services,” on page 65

 Section 5.3.3, “Planning,” on page 66

 Section 5.3.4, “Transferring FTP Services to OES,” on page 66

 Section 5.3.5, “Post-Upgrade Checks,” on page 66

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 SP2 or OES NetWare volumes.

5.3.2 Platform Differences in FTP File Services

Upgrading File Services to OES 65

Page 66

5.3.3 Planning

 “Requirements” on page 66

 “Limitations” on page 66

Requirements

Table 5-5 FTP Source and Target Server Requirements

Source Server Target Server

NetWare 5.1 or later OES 2 SP2 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.

novdocx (en) 7 January 2010

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 SP2:

 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 105.

 Transfer ID: If you are transferring an entire NetWare server, including the FTP service and

associated data, to an OES 2 SP2 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 106.

To transfer Novell FTP from NetWare to OES 2 SP2, follow the instructions in “Migrating FTP

from NetWare to OES 2 Linux” in the OES 2 SP2: 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 SP2: 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 SP2,” on page 67

 Section 5.4.2, “Platform Differences in iFolder File Services,” on page 68

 Section 5.4.3, “Planning,” on page 68

66 OES 2 SP2: Upgrading to OES—Planning and Implementation Guide

Page 67

 Section 5.4.4, “Upgrading iFolder,” on page 69

iFolder 3.7

Web Access Server

Can run on an

iFolder 3.7 Enterprise server

or a different OES 2 server

eDirectory

LDAP server

iFolder Client for SLED 10

iFolder Client for Windows

Access Methods

Authentication/File Encryption

iFolder 3.7 Services

iFolder Client for Macintosh

iFolder 3.7

Enterprise servers

iFolder 3.7 Web Access via a Web browser

HTTP(S

)

Sync

Upload or Download

HTTP(S

)

HTTP(S

)

HTTP(S

)

eDirectory LDAP

server on the

same or different

OES 2 server

Master server

provides

access

Slave servers

provide

scalability

HTTP(S

)

 Section 5.4.5, “Post-Upgrade Checks,” on page 69

5.4.1 About iFolder on OES 2 SP2

NetWare runs only iFolder 2.x while OES 2 SP2 runs iFolder 3.8, and as the version numbers imply, iFolder on OES 2 SP2 is much more robust and flexible.

Figure 5-3 How Novell iFolder 3.8 Works

novdocx (en) 7 January 2010

The following table explains the information illustrated in Figure 5-3.

Upgrading File Services to OES 67

Page 68

Access Methods Authentication/File Encryption Novell iFolder 3.8 Services

novdocx (en) 7 January 2010

Linux and Windows workstation users who have the Novell iFolder installed can access and modify their files in one or more workstation folders. Changes are automatically synchronized with the iFolder 3.8 Enterprise servers.

A Macintosh client for iFolder 3.8 is under development and expected to be released with OES 2 SP2.

A Web interface lets users access their files from any computer with an active network or Internet connection.

Client

All file service access is controlled by LDAP- based authentication through the eDirectory LDAP server.

Although it is shown separately, eDirectory could be installed on the OES 2 server.

Files can be encrypted for transport using SSL connections (HTTPS).

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 3.7 and Later

Ve r si o n s” in the Novell iFolder 3.8 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 Administration Guide.

5.4.3 Planning

 “Requirements” on page 68

 “Limitations” on page 69

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 SP2 servers installed.

The iFolder 3.8 service pattern is installed on each server but not configured.

68 OES 2 SP2: Upgrading to OES—Planning and Implementation Guide

Page 69

Source Server Target Server

All iFolder 3.8 servers, the iFolder 3.8 Web Access server, and eDirectory are up and running.

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 SP2: Migration Tool Administration

Guide.

Limitations

 “Moving Encrypted iFolders” on page 69

 “iFolder 2.x User Policies Not Transferred” on page 69

novdocx (en) 7 January 2010

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.7 and

later Versions” in the Novell iFolder 3.8 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 SP2:

 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 105.

 Transfer ID: If you are transferring an entire NetWare server, including the iFolder service

and associated data to an OES 2 SP2 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 106.

To upgrade Novell iFolder on NetWare to OES 2 SP2, follow the instructions in “Migrating iFolder

2.x” in the OES 2 SP2: Migration Tool Administration Guide.

5.4.5 Post-Upgrade Checks

As mentioned in “iFolder 2.x User Policies Not Transferred” on page 69, you must set a policy for each user after the upgrade is finished.

Upgrading File Services to OES 69

Page 70

5.5 Upgrading NetWare Core Protocol (NCP) File Services

The NetWare Core Protocol (NCP) Server provides the same file services on OES 2 SP2 that are available on NetWare.

 Section 5.5.1, “About NCP File Services in OES 2,” on page 70

 Section 5.5.2, “Planning to Upgrade NCP File Services,” on page 72

 Section 5.5.3, “Only Data Transfers Are Required,” on page 72

5.5.1 About NCP File Services in OES 2

 “What NCP Server Provides” on page 70

 “What NCP Server Alone Doesn’t Provide” on page 71

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 SP2 servers just as they do on NetWare servers, unless they need NSS file attributes (see “What NCP Server Alone Doesn’t Provide” on page 71).

novdocx (en) 7 January 2010

Novell NCP Server for OES enables support for login scripts, mapping drives to OES 2 SP2 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 SP2.

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.

70 OES 2 SP2: Upgrading to OES—Planning and Implementation Guide

Page 71

Figure 5-4 NCP Services for OES and NetWare

eDirectory

server

OES 2 NetWare

server

Access Points Authentication NCP Server

Novell Client

on SUSE Linux

Enterprise Desktop

and Windows

OES 2 Linux

server

NCP

novdocx (en) 7 January 2010

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.

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.

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.

Upgrading File Services to OES 71

Page 72

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 72

 “Deciding Between a Linux POSIX File System and NSS” on page 72

 “The Novell Client Is Required” on page 72

Requirements

Table 5-7 NCP Source and Target Server Requirements

Source Server Target Server

NetWare 5.1 or later OES 2 SP2

novdocx (en) 7 January 2010

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 SP2, or mount existing NSS volumes on the OES 2 SP2 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 SP2 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 SP2 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.

72 OES 2 SP2: Upgrading to OES—Planning and Implementation Guide

Page 73

5.6 Upgrading NetStorage

Windows

Explorer

Browser

PDA

Access Methods Authentication NetStorage Server

eDirectory/LDAP

(OES server)

NetStorage

OES 2 Linux

NSS

volume

NCP

volume

NetWare

Traditional

volume

CIFS share

(NFAP)

CIFS share

Linux

traditional

volume

Windows

servers

Target Servers

NCP

WebDAV

HTTP

SSH

CIFS

to manage

 Section 5.6.1, “About NetStorage,” on page 73

 Section 5.6.2, “Platform Differences in NetStorage File Services,” on page 74

 Section 5.6.3, “NetStorage Is Not Transferred,” on page 75

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 SP2

novdocx (en) 7 January 2010

The following table explains the information illustrated in Figure 5-5.

Upgrading File Services to OES 73

Page 74

Access Methods Authentication NetStorage Server Target Servers

novdocx (en) 7 January 2010

Users have read and write access to files from

 Windows Explorer: Is

enabled by the HTTP protocol with WebDAV extensions.

 Browsers: Users can

access files directly by connecting to the NetStorage server.

 PDAs: PDA users with

network connections can also access their files.

Access is granted through login script drive mapping (NCP server required) or through Storage Location Objects.

File service access is controlled by LDAPbased authentication through the eDirectory LDAP server.

Although it is shown separately, eDirectory could be running on the OES 2 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:

 The same targets as

NetWare if the NCP server is running

 Windows workgroup

shares (CIFS or Samba shares)

 Linux POSIX

volumes through an SSH connection.

Linux volumes can also be made available as NCP volumes.

Management of NSS volumes on OES 2 SP2 through NetStorage requires SSH access to the server. See “When Is

SSH Access Required?”

in the OES 2 SP2:

Planning and Implementation Guide.

5.6.2 Platform Differences in NetStorage File Services

Although NetStorage provides the same basic services on NetWare and OES 2 SP2, 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 SP2

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 relies heavily on NCP login scripts to provision user access to the storage locations it points to.

NetStorage provides automatic Web access for iFolder 2.x when that service is installed on the same server as NetStorage.

NetStorage is well integrated with eDirectory and OES.

NetStorage uses Storage Location Objects to provision storage locations that users access based on their rights.

An integration with iFolder 3.8 is not needed because the iFolder 3.8 Web Server provides Web access for iFolder users.

74 OES 2 SP2: Upgrading to OES—Planning and Implementation Guide

Page 75

Despite these differences, NetStorage on OES 2 SP2 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 SP2. 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

novdocx (en) 7 January 2010

 “NetStorage Implementation and Maintenance” in the OES 2 SP2: Planning and

Implementation Guide

 OES 2 SP2: NetStorage for Linux Administration Guide.

Upgrading File Services to OES 75

Page 76

novdocx (en) 7 January 2010

76 OES 2 SP2: Upgrading to OES—Planning and Implementation Guide

Page 77

Upgrading Print Services to OES

 Section 6.1, “About iPrint,” on page 77

 Section 6.2, “Platform Differences in iPrint,” on page 77

 Section 6.3, “Planning to Upgrade iPrint to OES,” on page 77

 Section 6.4, “Upgrading iPrint to OES,” on page 78

 Section 6.5, “Additional Information,” on page 79

TIP: If any printers in your environment have IPXTM 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:

novdocx (en) 7 January 2010

 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 SP2, neither of which should impact your upgrade plans:

 The back end infrastructures are different

 iPrint on OES does not support NDPS/NCP

Both OES and NetWare support the same iPrint workstation agent.

client-based printing

6.3 Planning to Upgrade iPrint to OES

 Section 6.3.1, “Requirements and Recommendations,” on page 77

 Section 6.3.2, “Limitations,” on page 78

6.3.1 Requirements and Recommendations

 “Platforms” on page 78

 “Prepare the Workstations First” on page 78

 “Use DNS Names Rather than IP Addresses” on page 78

Upgrading Print Services to OES

Page 78

Platforms

Table 6-1 iPrint Source and Target Server Requirements

Source Server Target Server

NetWare 5.1 or later OES 2 SP2 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 SP2. 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.

novdocx (en) 7 January 2010

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.

6.4 Upgrading iPrint to OES

iPrint can be installed and configured on OES 2 SP2 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 SP2 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.

78 OES 2 SP2: Upgrading to OES—Planning and Implementation Guide

Page 79

 Set up iPrint on OES 2 SP2.

 Deploy iPrint agents to workstations.

Novell's Server Consolidation and Migration Tool or the OES 2 SP2 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 to OES 2 Linux” in the OES 2 SP2: Migration Tool

Administration Guide.

novdocx (en) 7 January 2010

Upgrading Print Services to OES 79

Page 80

novdocx (en) 7 January 2010

80 OES 2 SP2: Upgrading to OES—Planning and Implementation Guide

Page 81

Upgrading QuickFinder to OES

This section provides information about upgrading QuickFinderTM from NetWare® to OES. For complete information, refer to the OES 2: Novell QuickFinder Server 5.0 Administration Guide.

 Section 7.1, “About QuickFinder in OES 2,” on page 81

 Section 7.2, “Platform Differences in QuickFinder,” on page 81

 Section 7.3, “Planning to Upgrade QuickFinder,” on page 81

 Section 7.4, “Upgrading QuickFinder to OES,” on page 82

 Section 7.5, “Post-Upgrade Considerations,” on page 82

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.

novdocx (en) 7 January 2010

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 SP2.

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 SP2.

2. Install QuickFinder on the OES 2 SP2 server, using the Novell QuickFinder service pattern.

Upgrading QuickFinder to OES

Page 82

7.4 Upgrading QuickFinder to OES

Complete the instructions in “Migrating QuickFinder Server from NetWare to OES 2 Linux” in the

OES 2: Novell QuickFinder Server 5.0 Administration Guide.

7.5 Post-Upgrade Considerations

Complete the instructions in “Post-Migration Considerations” in the OES 2: Novell QuickFinder

Server 5.0 Administration Guide.

novdocx (en) 7 January 2010

82 OES 2 SP2: Upgrading to OES—Planning and Implementation Guide

Page 83

Upgrading Backup Services to

novdocx (en) 7 January 2010

OES

 Section 8.1, “Upgrading Novell Archive and Versioning Services to OES,” on page 83

 Section 8.2, “About Upgrading Storage Management Services (SMS),” on page 84

8.1 Upgrading Novell Archive and Versioning Services to OES

 Section 8.1.1, “About Archive and Versioning Services in OES 2,” on page 83

 Section 8.1.2, “Platform Differences in Archive and Versioning Services,” on page 83

 Section 8.1.3, “Planning to Upgrade Archive and Versioning Services,” on page 83

 Section 8.1.4, “Upgrading Archive and Versioning Services,” on page 84

 Section 8.1.5, “Post-Upgrade Procedures,” on page 84

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 SP2, but there are no functional differences.

8.1.3 Planning to Upgrade Archive and Versioning Services

 “Requirements” on page 83

 “Limitations” on page 84

Requirements

Before upgrading, make sure to do the following:

1. Install an NSS volume on the OES 2 SP2 server.

2. Make sure the Archive server and the Primary volume reside in the same eDirectory

3. Make sure the Archive server, PostgreSQL database, and Archive volume are installed on the same machine.

tree.

Upgrading Backup Services to OES

Page 84

Table 8-1 Archive and Versioning Source and Target Server Requirements

Source Server Target Server

NetWare 6.5 SPX OES 2 SP2.

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 SP2:

novdocx (en) 7 January 2010

 Consolidate: Only consolidation on the same tree is supported. For more information, see

Section A.1.1, “Consolidating Selected Data or Services,” on page 105.

 Transfer ID: You can transfer an entire NetWare server, including Novell Archive and

Versioning Services, to an OES 2 SP2 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 106.

To upgrade Novell Archive and Versioning Services from NetWare to OES 2 SP2, follow the instructions in “Migrating Novell Archive and Version Services to OES 2 SP2 Linux” in the OES 2

SP2: 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 SP2: Migration Tool Administration Guide.

8.2 About Upgrading Storage Management Services (SMS)

The Novell Storage Management ServicesTM (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 for off-site storage. It provides a single consistent interface for all file systems and applications across NetWare and SLES.

Linux Enterprise Server (SLES), to removable tape media or other media

The upgrade path for SMS is to install it on the OES 2 SP2 server.

84 OES 2 SP2: Upgrading to OES—Planning and Implementation Guide

Page 85

Upgrading Network Services to

novdocx (en) 7 January 2010

OES

Network services are critical to event coordination and service discovery.

 Section 9.1, “Upgrading DNS Services to OES,” on page 85

 Section 9.2, “Upgrading DHCP Services to OES,” on page 86

 Section 9.3, “Time Synchronization,” on page 87

 Section 9.4, “Service Location Protocol (SLP),” on page 89

9.1 Upgrading DNS Services to OES

With OES 2, DNS has been integrated with eDirectoryTM. This means you can transition your existing DNS infrastructure from NetWare you do on NetWare.

 Section 9.1.1, “About Novell DNS in OES 2,” on page 85

 Section 9.1.2, “Platform Differences in Novell DNS,” on page 85

 Section 9.1.3, “Planning to Upgrade Novell DNS,” on page 85

 Section 9.1.4, “Upgrading DNS,” on page 86

to OES, as well as centrally administer it the same way

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 SP2: Planning and Implementation Guide.

9.1.3 Planning to Upgrade Novell DNS

 “Requirements” on page 86

 “Limitations” on page 86

Upgrading Network Services to OES

Page 86

Requirements

Table 9-1 DNS Source and Target Server Requirements

Source Server Target Server

novdocx (en) 7 January 2010

NetWare 5.1 SP8

NetWare 6.0 SP5 or later

NetWare 6.5 SP5 or later

OES 2 SP2.

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 DNS-DHCP 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 SP2 Migration Tool doesn’t support DNS migrations.

For instructions, see “Migrating DNS from NetWare to OES 2 SP2 Linux” in the OES 2 SP2:

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 86

 Section 9.2.2, “Platform Differences in Novell DHCP,” on page 87

 Section 9.2.3, “Planning to Upgrade Novell DHCP,” on page 87

 Section 9.2.4, “Upgrading DHCP,” on page 87

9.2.1 About Novell DHCP in OES 2

The DHCP services in OES 2 SP2 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.

86 OES 2 SP2: Upgrading to OES—Planning and Implementation Guide

Page 87

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 SP2: Planning and Implementation Guide.

9.2.3 Planning to Upgrade Novell DHCP

 “Requirements” on page 87

 “Limitations” on page 87

Requirements

Table 9-2 DHCP Source and Target Server Requirements

Source Server Target Server

NetWare 5.1 or later OES 2 SP2.

novdocx (en) 7 January 2010

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 SP2, follow the instructions in “Migrating DHCP from NetWare to OES 2 SP2 Linux” in the OES 2 SP2: 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 87

 Section 9.3.2, “Planning to Upgrade Time Synchronization Services,” on page 88

 Section 9.3.3, “Transferring Time Synchronization Services,” on page 89

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 87

Page 88

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.

novdocx (en) 7 January 2010

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 SP2: 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.

88 OES 2 SP2: Upgrading to OES—Planning and Implementation Guide

Page 89

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.

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 SP2:

 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 105.

 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 106.

To transfer time synchronization services from NetWare to OES 2 SP2, follow the instructions in “Migrating Timesync/NTP from NetWare to NTP on OES 2 Linux” in the OES 2 SP2: Migration

Tool Administration Guide.

novdocx (en) 7 January 2010

9.4 Service Location Protocol (SLP)

SLP is not a migratable service, however, it is a critical component of OES 2 SP2 and must be planned as part of your upgrade strategy.

 Section 9.4.1, “About SLP in OES 2,” on page 89

 Section 9.4.2, “Platform Differences in SLP Services,” on page 89

 Section 9.4.3, “Setting Up SLP on OES 2 SP2,” on page 90

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 89

 “SLP on OES 2 SP2” on page 90

 “Caveats” on page 90

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.

Upgrading Network Services to OES 89

Page 90

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 SP2. If you decide to use OpenSLP, NetWare servers can also be configured to use OpenSLP.

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 SP2

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.

novdocx (en) 7 January 2010

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 SP2.

 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 SP2

 “Enabling Multicasting” on page 90

 “Installing and Configuring OpenSLP” on page 91

 “Additional Information” on page 91

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.

90 OES 2 SP2: Upgrading to OES—Planning and Implementation Guide

Page 91

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

(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.

novdocx (en) 7 January 2010

OpenSLP installs like any other RPM by using the in the

/usr/sbin

directory on the server.

rpm -i

After it is installed, you can configure the slpd daemon by editing the

 To configure the daemon to run every time the server is booted, use the following command:

chkconfig slpd 345

 To configure an OES 2 SP2 server as a DA, edit the “Static Scope and DA Configuration”

command. The slpd daemon is installed

/etc/slp.conf

file.

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 SP2: Planning and Implementation Guide.

Additional Information

 Novell eDirectory 8.8 Administration Guide, “Configuring OpenSLP for eDirectory”

Upgrading Network Services to OES 91

Page 92

novdocx (en) 7 January 2010

92 OES 2 SP2: Upgrading to OES—Planning and Implementation Guide

Page 93

Upgrading Novell Cluster Services

novdocx (en) 7 January 2010

to OES

Novell® Cluster ServicesTM 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 load balancing of individually managed cluster resources including data, applications, and services.

 Section 10.1, “Overview,” on page 93

 Section 10.2, “Planning to Upgrade Novell Cluster Services,” on page 94

 Section 10.3, “Prerequisites,” on page 95

 Section 10.4, “Caveats,” on page 96

 Section 10.5, “Rolling Cluster Conversions,” on page 96

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.

and supports failover, failback, and

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 here.

Linux via a rolling conversion is one of the easier methods and is documented

Upgrading Novell Cluster Services to OES

Page 94

10.2 Planning to Upgrade Novell Cluster Services

 Section 10.2.1, “Reviewing the Current Cluster,” on page 94

 Section 10.2.2, “Upgrading Novell Cluster Services to OES 2 SP2,” on page 94

 Section 10.2.3, “Additional Information,” on page 95

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.

novdocx (en) 7 January 2010

 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 SP2 nodes as required

 Reconfigure the SAN to host DST shadow volumes

10.2.2 Upgrading Novell Cluster Services to OES 2 SP2

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 SP2

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 SP2 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.

94 OES 2 SP2: Upgrading to OES—Planning and Implementation Guide

Page 95

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.

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 SP2: Novell Cluster Services

1.8.7 for Linux Administration Guide.

10.2.3 Additional Information

Refer to the following sections in the OES 2 SP2: Novell Cluster Services 1.8.7 for Linux

Administration Guide 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”

novdocx (en) 7 January 2010

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.

Upgrading Novell Cluster Services to OES 95

Page 96

 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.

 Novell Cluster Services software must be running on the OES server (SLES 10 and OES must

be installed on every OES 2 SP2 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 SP2: Novell Cluster

Services 1.8.7 for Linux Administration Guide."

10.4 Caveats

There are several caveats that you need to be aware of:

novdocx (en) 7 January 2010

 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 Cluster Nodes to OES 2 Linux (Rolling Cluster Conversion)” in the

OES 2 SP2: Novell Cluster Services 1.8.7 for Linux Administration Guide for instructions on

performing a rolling cluster upgrade.

96 OES 2 SP2: Upgrading to OES—Planning and Implementation Guide

Page 97

Upgrading Other Novell Products

novdocx (en) 7 January 2010

to OES

The information in this section was contributed by the GroupWise® and ZENworks® teams.

 Section 11.1, “GroupWise 7 and GroupWise 8,” on page 97

 Section 11.2, “Identity Manager,” on page 100

 Section 11.3, “ZENworks,” on page 101

11.1 GroupWise 7 and GroupWise 8

 Section 11.1.1, “Source Platform Requirements,” on page 97

 Section 11.1.2, “Target Platform Requirements,” on page 97

 Section 11.1.3, “Preparing to Migrate,” on page 98

 Section 11.1.4, “Caveats,” on page 98

 Section 11.1.5, “Tool Options,” on page 98

 Section 11.1.6, “Migration Instructions,” on page 99

 Section 11.1.7, “Migrating GroupWise as Part of a Transfer ID Migration,” on page 99

 Section 11.1.8, “Additional Information,” on page 100

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 SP2.

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

Page 98

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 SP2.

 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.

novdocx (en) 7 January 2010

11.1.5 Tool Options

You have two options for migrating GroupWise from NetWare to OES 2 SP2:

 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 SP2 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 SP2.

98 OES 2 SP2: Upgrading to OES—Planning and Implementation Guide

Page 99

11.1.6 Migration Instructions

 “Manual Method” on page 99

 “Automated Method” on page 99

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)

novdocx (en) 7 January 2010

Automated Method

Table 11-2 Instructions for an Automatic GroupWise Migration

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)

11.1.7 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 99

 “Verifying that the GroupWise Migration Succeeded” on page 100

 “Transferring the NetWare Server’s Identity” on page 100

Migrating GroupWise

If your NetWare server is currently running GroupWise, you must run the GroupWise Server Migration Utility before performing the Transfer ID migration.

Upgrading Other Novell Products to OES 99

Page 100

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

novdocx (en) 7 January 2010

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/)

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).

100 OES 2 SP2: Upgrading to OES—Planning and Implementation Guide

Novell OPEN ENTERPRISE SERVER 2.0 SP2 Implementation Manual

Specifications and Main Features

Frequently Asked Questions

User Manual