Cool Solutions

OES2 SP2 Migration Guide for Transfer ID Scenarios


July 16, 2010 12:50 pm





OES2 SP2 Migration Utility – ID Transfer


  1. Overview
  2. Configure NSS
  3. GroupWise 8.x – Installation
  4. Configure iPrint
  5. Migration Phase – MigGUI
  6. File System Consolidation
  7. DHCP Migration
  8. iPrint Migration (Standalone server only)
  9. Identity Transfer
  10. Post-Migration Steps-iPrint


Migration Scenario:

Transfer all data and services from NetWare server to OES2 SP2 server. This includes the Identity transfer. We broke out the File System as a separate Migration Project (Consolidate) due to the massive amount of data we had to migrate. We then created a second project for Transfer ID that did the remaining services.


OES2 SP2 server must be installed with a temporary name into the same eDirectory context as the source server. It must also be installed with the pattern option of: Pre-Migration Server. Lastly, you must install the services on the OES2 SP2 server that you wish to transfer. In other words, if the source NetWare server has iManager, NSS, iPrint, and DHCP on it, you must install iManager, NSS, iPrint, and DHCP onto the OES2 SP2 server as well. Failure to do this will mean that you cannot migrate those services over. Please note that services only refers to what ships with NetWare/OES2 itself. It does not mean services such as ZENworks, GroupWise, McAfee, IDM, etc. Those are items that are installed independently and AFTER you finish the migration.

Once the OES2 SP2 server is installed and up and running (this includes patching), we must do some more preparation work.

  1. Ensure that time is in sync
  2. You must install and partially configure the services on OES2 SP2. Each service will be documented. iManager is configured by the very fact that it was installed. Only additional items to configure would be DHCP and NSS.
  3. Edit the /etc/nam.conf file for the: preferred-server=IP to point to a server with all replicas (this is also in the installation guide in case you missed it). This should avoid any issues with LUM repair during ID Transfer migration scenarios.

Configure NSS

Most of this is already covered in the installation guide, but for ID Transfers you have to ensure some additional steps are followed. To configure NSS, you must add devices to the physical server first. This means carving out LUNs. On a standalone server, we currently have one LUN for all volumes (NetWare). On the Cluster servers, each volume is a LUN. On the Xiotech SAN, one LUN should be made for each volume because we can easily expand the LUN.

Just make sure on the standalone servers to create a boot LUN, and one or more LUNs for NSS. (HP Proliant servers call these: “Logical Drives”)

Use the appropriate utility for creating the LUN. It is strongly recommended that you do not create multiple LUNs of the same size because it makes it difficult to figure out which LUN is to be used for what. If you do need identical LUNs, create the LUN one at a time, then create the NSS volume/pool on it, and then create the second LUN, etc. That way there’s no confusion.

Do not partition the LUN. Ensure that the OES2 server sees the LUN. You can verify by running the Yast -> Partitioner.

Once you’ve verified that the system can see the LUN (may require a reboot), you can then use iManager to create the NSS pools/partitions in preparation for migration.

We are going to create pools with the SAME NAME and equal or greater size for migration.

Login to iManager for the OES2 SP2 server you are going to migrate to.

Access the Storage menu on the left-hand side

Select Devices, and then use the magnifying glass to select the OES2 server you are working on and wait for it to retrieve the system information.

Select the appropriate device from the list (in this case, I am selecting “sdb”). You’ll notice that the Initialize button is now selectable. Double-check the Capacity to make sure you have selected the proper LUN. Please use this with caution. If you initialize the wrong disk, you will permanently erase all the data on it.

Now click Initialize Disk.

Heed the warning and click OK if you’re sure it’s the right one.

After a few seconds you should see that other items have changed:

Now, access the Volumes menu on the left-hand side.

Click New

Enter the name. Remember to make the name EXACTLY the same as the old volume.

Click New Pool.

Name the pool the same name as the volume and click Next.

Now you can check the box to assign the volume to the pool you just created. Note, that in this case, we are letting the volume grow to the size of the pool. The Pool, by default, will be the same size as the LUN itself. Check the box.

Notice that it automatically fills in the space to equal the free space. This is ok. Now click Finish

Check the box for the pool and click Next (this is assigning the volume to the pool) A quota of zero means that it can use all the space.

This is important. The rule for attributes is as follows:

For regular non-SYS volumes, we choose Backup, Compression, Directory Quotas, Salvage. Make sure to check the box “Allow Mount Point to be Renamed”.

Change: We are not going to enable Compression on any volumes. NetBackup doesn’t work with it (it will decompress them anyway). If your backup software DOES use the TSA/SMS code, then feel free to use Compression if you so desire.

For GroupWise volumes, choose: Backup only. Do NOT choose Salvage or Compression. Also make sure to check the “Allow Mount Point to be Renamed” box.

Then click Finish.

And wait

Voila, the volume is created and mounted.

Proceed for each volume you need to migrate.

We do NOT migrate SYS Volumes!!!!!!

GroupWise 8.x – Installation

This one is a little different. IF you are planning on migrating GroupWise with an ID Transfer, here’s the steps that we took to do this. The most important item to remember is that you must not have ANYONE logged into your OES2 server at the time you install the GroupWise Agents. This is because the installer routine will detect NSS/NCP access and perform an automated restart of ndsd (eDirectory) without asking you and if you restart eDirectory while users are logged in, they’ll get pop ups about the server being down and it’ll whack their NCP connection to the server.

I have created a separate document for GroupWise Migrations. The key item IF you are doing an ID Transfer is that you have to make sure you have all the data migrated over BEFORE you start the ID Transfer section of the Migration Utility (because it removes eDir from the source server and you have to power the source server off, so then you cannot get to your data anymore unless you want to mess with tape backups/restores).

Configure iPrint

According to the product documentation, iPrint must be installed and setup on the Target server, and a Driver Store configured. (Page 198 of the OES2 SP2 Migration Tool Admin Guide).

Login to iManager and create a driver store. The name should not be a TEMPORARY name, but a new permanent one.

As per TID #7004109, we now suggest putting your new iPrint stuff (OES2) into a DIFFERENT eDirectory container than where your SOURCE iPrint items are located at. For example, if your NetWare server and existing iPrint objects are in: .NYC.CO.ABC, we created a new subcontainer called: iPrint in the .NYC.CO.ABC container and put the NEW iPrint (OES2 stuff) into there.

Click OK

Click OK again.

Now we need to create a new Manager.

Use iManager to create a print manager. Again, the name is a new, permanent name. MUST USE DNS NAME!!!!

Again, put this into a new/different container than where the CURRENT NetWare iPrint stuff is at. Will prevent issues with renaming in eDir during the ID Transfer.

Click OK.

Click OK.

Check the box “Allow the hostname . . .” and then click OK.

You will be taken back to the original Create Print Manager screen as shown:

Click OK once more.

Migration Phase – MigGUI

  • If you do not have your DNS entries ahead of time, then edit the /etc/hosts files on both NetWare and OES2 SP2 to include the entries for each other. In other words, the NetWare server needs to have an entry pointing to the OES2 server and the OES2 server needs to have an entry pointing to the NetWare server.
  • Ensure that time is in sync and that directory synchronization is current with no errors.
  • Run a pkidiag and ensure the SSL certs are all working on the SOURCE.
  • Lastly, stop/unload all services on NetWare (ie, stop GroupWise if you’re migrating a groupwise volume, etc.) DO NOT UNLOAD iPrint! DO NOT UNLOAD TSAFS.
  • Make sure to stop/unload any and all AV scanners as well as Backup software!!!!—but not the TSAFS.NLM
  • Make sure you have a valid backup image or do a: “disrepair –RC” that’s been safely copied somewhere.
  • Verify smdr and tsafs loaded okay. /opt/novell/sms/bin/smsconfig –t (to list if tsa is running) and /etc/init.d/novell-smdrd status (to see if sms is running)
  • If Migrating GroupWise make sure you finish all your data transfers/dbcopy before proceeding to the final ID Transfer phase. (See Migration Guide)
  • Make sure you have run the GroupWise agent installation before starting the MigGui utility. The reason for this is that the GW installation routine will restart eDirectory and that can interrupt your MigGui authentication.
  • You may have problems authenticating if the userid has a password with large number of character and/or “special” characters.

Start the Migration Utility:

Computer -> More Applications -> Novell Migration Tools

Click New Project. I change the name to match the server (ie: test01). And click OK

Click Yes (note the location of the file as I think the logs are put there too).

Click the Source server icon:

Fill in the information. You should really use the IP address of the source server. Make sure you use cn=admin,o=abc. The root password is the root password of the OES2 server you’re migrating the data to. You can uncheck the “use SSL” box if you so desire. Click OK.

Click the Target Server icon and fill out the information. Again, make sure you use: cn=admin,o=dec Enter the appropriate passwords and click OK. You can optionally disable the “Use SSL” checkbox.

Notice how both servers are green.

You have two choices here. You can choose C onsolidate first, and then choose Transfer ID later. In our case, we chose Consolidate and ONLY migrated the File Systems. Why? Because we had about 300 GB of data we had to migrate from NetWare to OES2 across a Gigabit LAN link. Since we did not want to do this over a weekend or spend late hours at night, we did the File System transfer during the DAY. Yes, it skipped files that were open. The reason we chose this was that the bulk of the data was NOT being used. Then, we saved the migration project, and on the final day of the migration, we kicked all the users off the system and opened that project and did a SYNC to get any data that changed or was missed the first time (it went a lot faster).

THEN we created a NEW project and chose Transfer ID

Click the Add button

The list of services that displays varies depending upon what was installed on the SOURCE server and what’s installed on the TARGET server. For example, if you forgot to install iPrint on the Target server, then you would not see that as a service. Further, there may be services on the NetWare side that you don’t wish to migrate, such as Novell FTP or Novell NTP.

In this case, we’re going to CONSOLIDATE the File System and TRANSFER ID along with Novell iPrint, and DHCP. There’s really no need to migrate Novell NTP because the server should already be setup for NTP. For regional servers, we would migrate DHCP as well (now that the bugs have been fixed).

So our Migration project will be TWO projects. One for the file system (Consolidate) so that we can save ourselves some time, and then a second project with the TRANSFER ID that also migrates iPrint and DHCP.

Click ONE service (in this case, File System) and click OK.

Click Add again and select the next service and click OK. Keep repeating until all the services you wish to migrate are selected.

We have two services selected now, but they are Not Configured. Click One (File System) and then you can click the Configure button. Each service MUST be configured in order to migrate it.

When you’re migrating the file system, if you have to migrate from a COMPRESSED NetWare volume to a NON-COMPRESSED OES2 NSS volume, make sure of two things:

  1. You compensate for extra space on the OES2 volume (we did a volume inventory on NetWare, found the “compressed” space, doubled that, and then added that number to the total volume data and added another 20% for good measure).
  2. You CLEAR ALL directory quotas. If you don’t do this, you run the risk of the data decompressing, exceeding the directory quota and then your migration will take forever (it’ll try like 3 times for each file) AND your data won’t copy over either because it can’t write it because the quota is there.

File System Consolidation

You’re presented with a screen similar to the SCMT. Left-hand side shows the NetWare volumes available. Right-hand side shows where you can transfer the data to. Remember, we are NOT migrating SYS volumes. In this case, I will transfer the APPS1 to APPS1. We will use the GroupWise docs for migrating the GW data via dbcopy.

I dragged the APPS1 from the left-hand side to the NSS volumes -> Apps1 on the right-hand side. The menu comes up and asks what I wish to do. I wish to use the first option. Click OK.

Remember, in our case, we did not enable compression on the OES2 volumes (due to limitations with our backup software). This required that we ensure additional drive space on OES2, AND that we disabled all quotas on the “source” NetWare server and renabled/re-adjusted them later on the OES2 volume. Obviously if you are using Compression on both source/destination you don’t need to worry about that.

I do the same thing for each volume I wish to migrate (I’m just using a volume named GW for this example, but if you’re really moving a dedicated GroupWise data volume that only contains Domain/PO files, please use the dbcopy steps instead). Click OK.

On an initial migration, I don’t bother to change the File Options.

Click OK again.

Notice that File System has gone to the Ready State.

DHCP Migration

From this point on, we created a new project in the migration utility and chose TransferID and added the DHCP and iPrint services. This assumes you are using OES2 SP2 with the latest patches (we found a series of bugs with the dhcp migration scripts that caused all sorts of issues, but they have been fixed in SP2 now).

After you add the DHCP server to migration and you click Configure on it, you should see:

Select Server level.

(we chose server level since this is for a migration of a server with ID Transfer).
Click the Browse button

Browse for the NETWARE DHCP object (be careful which one you’re picking/choosing here).

Click OK

Now click the Other Options tab.

Click the Browse buttons for the three items. You want to browse for the:

Container of the server you’re migrating (for the Base DN)

The other two items (Locator and Group DN), you want to choose the items in the O=ABC container. This assumes that during the install you placed your items “high” in your tree (ie, the O level). In this example, we are doing an ID Transfer for a single server in one of our regional offices (so the server is in its own eDirectory container).

The two items in the Locator and Group DN fields are the OES2 DHCP items.

Click OK.

iPrint Migration (Standalone server only)

We have found that TID #7004109 to be immensely helpful. There is also a sister TID (if you are NOT doing ID Transfers): 7004455.

Novell suggests that you use name resolution for your printers BEFORE you migrate.

Assuming you have done this ahead of time, you must then temporarily point the DNS name to the primary IP of the NetWare server.

Then edit the sys:\etc\hosts file and add a line so that the name of the manager resolves to the PRIMARY IP of the NetWare server.

Restart the server

Failure to do these steps, will result in an error message from the migration utility that “An Active Manager is not found”.

Select the Source and Target Print Managers.

Click the “browse” icon next to the Source Printer Manager:

Browse to where the SOURCE print manager is, and select it and click OK.

You can now click the browse button for the Target Print Manager.

I’ve not yet updated the above screenshot to show the fact that my “target” print Manager is in a DIFFERENT container than the SOURCE is.

Now click Get Printers

By default, it will show all the printers that are on the SOURCE Manager.

Now check the Select All (if you wish to migrate all the printers). Otherwise, check the ones you want to migrate.

CHANGE the Target Context to your newly created iPrint container (or somewhere different than where the SOURCE ones are at). This is as per TID #7004109.

Click the Options tab

Select the TARGET Driver Store (this is what it’s called now, instead of the Broker)

We will overwrite the drivers and profiles on the TARGET (there shouldn’t be any profiles on the target anyway).

Click OK

Notice that the services show Ready now.

We can now click the Start button on the top of the screen.

You will be prompted to save the project. Click Yes

Click Yes

For iPrint, you’ll get a “Precheck” status that may take a few minutes. Then it will progress to a “psminfo.xml build phase”.

If you wait long enough and then click the line that says: File System,– then you’ll get more feedback:

Notce that it will show it’s actually migrating. But you still don’t get info as to what file it’s on, etc. This may take a while

The file system migration uses the TSAFS to migrate from server to server.

After a while you’ll get some sort of idea where the progress is:

During this migration phase you can switch over to the GroupWise Migration guide and start your first run dbcopy if you so desire.

For iPrint only, you would hopefully see this:

After completion we had some errors. For the FILE SYSTEM, the errors were due to the NDPSM.DAT files being open (this is normal). However, it’s strongly suggested to review the logs to see which files exactly did not migrate over.

You can click the View Logs button to see the log files

You can see the lines that say “ERROR” and see which files/items failed to migrate and why.

If you need to re-migrate files you can select the File System line and then click the Sync button). If it’s just a few files, you can also manually copy them over (remember you may lose trustees if you do so). Unload the NDPSM and BROKER from the SOURCE NetWare Server

In our case, everything went over okay (that we needed/wanted). So we will proceed with the Identity Transfer

Identity Transfer

This is the most crucial and critical phase. It is very important that you follow the steps correctly. MAKE SURE YOU HAVE FINISHED YOUR FINAL dbcopy for GroupWise before you start this section!!!!

  1. Ensure that time is in sync. From the DS Master server, (if it’s NetWare), do a DSREPAIR –A and run a timesync check. You should get all “Yes” responses. Do not proceed if you do not get all “Yes”.
  2. Ensure that eDirectory is synchronized. From the same DSREPAIR screen (again, if NetWare), run a Check Synchronization status. You should get ZERO errors. Do not proceed if you get errors
  3. On the SOURCE NetWare Server, ensure that the SSL Certificates are correct and good. Load PKIDIAG and login as
  4. Choose option 4 (press the “4” key, so that it toggles the setting). Then choose (press) the “0” key to run the repair. Ensure you get 0 problems found:

  5. 5.Ensure you have a valid backup of the DS file (DSREPAIR –RC). Copy it to your PC.
  6. 6.Ensure that the hosts file on both SOURCE and TARGET servers point to each other.
  7. 7.Start the Identity Transfer:

Heed the warning and click Yes.

(if you followed the Installation Guide you should be able to avoid the LUM repair issue by adjusting the /etc/nam.conf file to put an LDAP server that contains R/W or Master Replicas of everything).

Click Next (the dots on the left-hand side will turn colors depending on what stage it’s at and whether it’s successful or not ).

The Log Messages window will populate. Notice the checkbox on the left-hand side. DO NOT proceed unless you have a GREEN checkbox.

Click Next

The Preparation can take a few minutes. It will have a blinking light until it’s finished.

We have success, so click Next.

This informs you that yet another backup of the DS Database is taken and WHERE it’s located at. Remember this. Click OK.

WAIT. It can take a little while to transfer the DS Databases over. Usually less than 5 minutes.

The scrollbar for the Log Messages can be scrolled to see where the process is at. When it’s finished, it will auto-scroll to the end.

We finished successfully with the DIB Copy, so click Next.

You must DOWN the SOURCE NetWare server (it has to be at the DOS Prompt or shut off entirely). DO NOT CLICK OK until you have done that.

At this point, you will NOT be able to boot the SOURCE Server and have it reachable. DS has been transferred and locked on the SOURCE Server.

Once the server is shutdown and/or powered off, click OK.

The Migration Utility will now ping the SOURCE Server IP address and if it gets no response, you will be allowed to continue. If you forgot to shut it down, it will give you an error.

Now click Next. This will restore the transferred DS Database to the TARGET OES2 server.

Wait. It can take some time (again, usually less than 5 minutes).

Finished successfully. Click Next

No, we are NOT doing any of the upgrades via SSH. We will either physically be at the server, or via ILO. Neither of which are SSH. So you can click OK. IF you are doing this via SSH/VNC there is a step in the documentation that explains how you can get past this issue (you basically restart the server and re-run the migration project and it should pick up where it left off). But try to avoid this at all costs (I’ve only run into this if running OES2 on a Citrix XENserver because Citrix only allows VNC/SSH via the “dummy” video card driver).

The sub-checkboxes will slowly all be checked green, at which point, the “master” item will become a green checkbox. (hopefully).

All done. Click Next

The hostname changes goes really fast. Now click Next.

The next step can take a few minutes as well. (less than 5 minutes).

Click Next

The next step can take a few minutes again.

Wait for it to go through and finish all the sub-services.

Each step may take several minutes (usually eDir and Certificate take the longest).

When finished, the last item – Restart Server will not be green. The Cancel button will change to “Close”. You must click Close and save the project. Exit the Migration Utility.

For iPrint, modify the: /etc/opt/novell/iprint/conf/ipsmd.conf file
Change the PSMHostAddress line so that it is the DNS name of the OES2 iPrint Manager.


Then you must MANUALLY restart the OES2 server.

At this point the Migration Utility and ID Transfer are complete, but you may have more work to do depending on what you migrated.

Post-Migration Steps-iPrint

For iPrint, there may be some post-migration steps.

1) Printers not coming up after Transfer ID migration

Explanation: You migrate printers by using Transfer ID option, but printers are not coming up.

Possible Cause: Printers are not being asociated with the Drivers after an ID swap (Transfer ID).

Action: Use the following procedure:

  1. Run the /opt/novell/bin/iprintman psm –xml-import /tmp/psmimport_idswap.xml -s <Server IP Address> -u admin -f –accept-cert command on the OES 2 Linux console.
  2. Enter the admin password.

Where the <Server IP Address> is equal to what the OES2 SP2 Linux server CURRENTLY has, after the migration.

2) Edit the /etc/opt/novell/iprint/conf/ipsmd.conf file again (the script changes it to be the old NetWare name). Change the PSMHostAddress line so that it’s the DNS name of the OES2 SP2 iPrint Manager entry.

0 votes, average: 0.00 out of 50 votes, average: 0.00 out of 50 votes, average: 0.00 out of 50 votes, average: 0.00 out of 50 votes, average: 0.00 out of 5 (0 votes, average: 0.00 out of 5)
You need to be a registered member to rate this post.

Categories: Uncategorized


Disclaimer: This content is not supported by Micro Focus. It was contributed by a community member and is published "as is." It seems to have worked for at least one person, and might work for you. But please be sure to test it thoroughly before using it in a production environment.