OES2 SP2 Migration Utility – ID Transfer
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.
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.
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.
Voila, the volume is created and mounted.
Proceed for each volume you need to migrate.
We do NOT migrate SYS Volumes!!!!!!
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).
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 #