Netware

IDM Server Hardware Migration

idm
Today's project was to do a hardware migration of my IDM server to new hardware, you could use this process for any server but I'm focussing on the IDM stuff.

This is how I accomplished it, and some of the problems/resolutions I found during the process are listed at the end. I'm not going to list a blow-by-blow account of the Server Consolidation Migration Utility as it's very straight forward. However, if you'd like some info let me know and I can give you the step-by-step process. I may even include this in a separate blog entry.

If you've read any of my other Novell Blog entries you'll know that my IDM system runs on NetWare... let me hear you say YEAH!!!

Because I'm still running Netware, migrating to other hardware is quite easy. Novell has provided a neat little utility called the Server Consolidation and Migration Utility and it's a good time saver. Download this free product before you begin and I highly recommend you run this process through your test environment.

A few notes before we start.

I don't recommend trying to migrate to a higher DS level than the one your source server is on. ie, don't migrate from 8.7.3 to 8.8. If you wish to upgrade your DS version, do it after the migration has settled.

I do recommend using the latest patches and version of Netware as your destination server.

Side note: because my source server was a NW65SP7 server that was updated from SP6, I am still running eDir 8.7.3.9 and this is by choice. If you've installed a new Netware server from the SP7 overlay DVD you'll notice the default version of DS is 8.8sp2. So to get around this I install the pre-migration server with the SP6 overlay CD's and then apply the downloaded SP7.

Let the games begin.

1. Take note of the products/services your original server is running. You're going to re-install these on the new server so it helps to know what the old one did. Go make yourself a coffee and get comfortable.

2. Build the migration server ensuring all hardware is functioning correctly.
Use the Pre-migration server installation option in the Netware install. This installs a bare-bones Netware server with no additional products.

Note at this point: to cut down on editing in the comparison step later on, I recommend your temporary eDirectory has the same containment structure of your original tree. Create the same structure down to the server location. The following is what I typically used:

TREE Name: TEMPTREE
Server Name: OLDSERVERNAME1
Server context: Same structure as original server in production tree.
Server IP: something in the same network as the original server

3. On the source server comment out all unnecessary load lines in the AUTOEXEC.NCF. Backup clients and anything else that is not immediately required (which should be nothing as you're working inside a maintenance window or scheduled outage.. right??)

4. Stop all drivers running on the server and set them to manual start. Unload any backup clients or other applications to ensure files are not in use.

5. Export all driver configurations.

6. Start the Server Consolidation Migration utility and create a new project for your server. I usually just name the project after the server name being migrated followed by the date. Eg: SERVER1_220408

7. If your server is not a file server (ie doesn't have any volumes other than SYS) you can "next" your way through to the data copy. You can run this stage of the migration days ahead if you like. Then do a final update copy for any files that have changed at the time of the migration. This is a HUGE time-saver. This step simply backs up the trustees on the server and copies the entire contents of the SYS volume to the SYS:\SYS.MIG directory on the destination server.

Note at this point: take a bit of time to clean up your source server, delete any old patches etc that might be lingering around. The data copy stage will copy EVERYTHING, even stuff you don't necessarily need.

8. Complete the Migration process. I usually just accept the defaults given (unless you've done a pre-copy). Read each screen carefully and ensure you follow any additional steps that are suggested. Pay particular attention to the configuration file comparisons. You'll get a second warning about the Server name and IP address. Make sure these are correct.

9. At this point, your original server should be down and turned off, and your new server has now taken on the identity of the original. It's now time to install all the goodies again, but take a moment to yank the network and power cables from the old box.

10. Insert the SP7 overlay DVD and start installing the additional products. My server also ran DNS so I installed it at this point along with the following:

General:
Tomcat 4 and 5
Apache2
iManager 2.7
Novell Modular Authentication Services
reboot server.

Products required for IDM 3.5.1
Security Services 2.0.5
NMAS updates
CIMOM updates
reboot server.

11. Reinstall IDM 3.5.1 engine/utilities and any drivers. I have a blog entry on upgrading from 3.0.1 to 3.5.1 and I just followed these steps.

12. Load DSTRACE using the following:

load dstrace
load dstrace screen on
load dstrace +dvrs dxml

13. Start iManager and fire up the drivers one at a time. Watch the trace screen in step 12 for any errors. Once you've confirmed all is running, edit the driver configurations and set the drivers to auto-start.

14. Pat yourself on the back for a job well done.

Problems encountered:

The above process is exactly how it all went... in test.

In production, however, things were slightly more "interesting".

My hardware migration went perfectly and the new server became the old one as expected. I then went and started installing all the Netware products and patches. Still all good at this point.

I then installed IDM on the server and for good measure, rebooted.

When I attempted to start the first driver, the process failed with a -783 error. This TID pointed in the right direction but didn't help me. DIRXML was loading but was not functioning.

I investigated the logger screen and saw an error loading DXLDAP.NLM and followed this TID. However, unloading DIRXML or DS simply locked the console screen and after 20 minutes still wouldn't unload the nlm's. I could see from the DSTRACE screen the drivers were caching any changes so updates weren't going to be lost.

At this point I figured something hadn't installed correctly. DS was working perfectly but DIRXML was being a precious petal. To prevent DIRXML from loading I renamed the dirxml.nlm to dirxml.old and rebooted.

After the reboot I reinstalled IDM and rebooted, but had the same problem. Did the rename dirxml.nlm thing again, rebooted. This time I uninstalled IDM and did the following:

1. Ran the Product install again and re-installed all the products and update in step 10 above.
2. Ran the IDM install again
3. Added the server back to the driver set as it was removed because of the -783 error above.
4. Enabled the drivers but didn't automatically synchronize (drivers are disabled if the server is removed from the set)
5. Started the drivers, this time all went well.

Post investigation seems to point to the NMAS installation, but I haven't confirmed this.

All is working perfectly now and the pointy-haird boss is blissfully unaware of my numerous missed heartbeats this morning.

|

Novell IDM upgrade ~ 3.0.1 to 3.5.1

idm
So it's time to upgrade to the latest Novell Identity Manager code. This is a rather straight-forward process but still one you'll want to run through a test environment.

I came across a few hiccups in test that I didn't hit in production, but this only helps in the preparation.

I have two eDirectory Trees to contend with. Tree 1 has eDir, MAD, Delimited Text drivers. Tree 2 has eDir, GroupWise, and UserApplication drivers. All IDM servers are OES2 Netware with the exception of the UserApplication server. This is required to be linux.

The really good news is all these drivers will work together at different version levels, allowing you to take your time in the completing the process.

Here is my take on the process of getting to the latest and greatest.

Approach

Prepare for the upgrade
Test roll-back plan
Upgrade the Meta-directory engine in Tree 1
Upgrade the drivers in Tree 1
Upgrade the MAD remote loader and PassSync.
Upgrade the Meta-directory engine in Tree 2
Upgrade the drivers in Tree 2
Install new UserApplication

I have chosen to create a new install of the UserApplication as currently it's only used for password self-service. The original server is a SLES9 box and the new one I want to be an SLES 10.1 box.

Prepare for the upgrade

1. Upgrade IDM servers in both Trees to NW65SP7
2. Upgrade Security Services to 2.0.5
3. Upgrade NMAS to 3.2.0.1
4. Export current driver sets
5. Export each individual driver in both sets
6. Refresh documentation of current settings noting passwords etc
7. Rename sys:\ni\update directory on both IDM servers
8. All software including previous versions of IDM to hand.
9. Set trace level on all drivers to 3

Roll-back plan

1. Ensure there is a current backup of the SYS volume
2. Export of all drivers

Should the installation fail with no ability to continue:

1. remove the new software if possible
2. Install previous version of software

Should the upgrade of the drivers fail with no ability to continue:

1. Delete drivers in driver set and re-import or;
2. Delete driver set and re-import.

Update Process

Schema update

Schema updates are done as part of the Installation of the IDM 3.5.1 Metadirectory engine. This is done once per tree.

TREE 1 (1hr 30mins)
1. Set all drivers to manual start and apply.
2. Stop all drivers
3. Install Metadirectory Server, Web components and utilities to server
4. Deselect all drivers and select

Delimited Text
eDirectory

5. Select Application components
6. Complete install and restart the server
7. Load DSTRACE and set DSTRACE to DXML and DVRS
8. Start all drivers and confirm no errors on trace
9. Apply authorization to Directory set
10. restart all drivers to check for authorization
11. Upgrade eDirectory driver and restart
12. Upgrade Delimited Text driver and restart
13. Upgrade Active Directory driver and restart


AD remote loader
(30mins)
1. Stop AD remote loader on Domain Controller.
2. Edit settings and set trace level to 3
3. Copy the remote loader config file C:\Novell\RemoteLoader\ADRemoteLoader-Config.txt to ADRemoteLoader-Config.backup
4. Install new remote loader and start

TREE 2 (1hr 30mins)
1. Set all drivers to manual start and apply.
2. Stop all drivers
3. Export individual drivers and driver set
4. Install Metadirectory Server, Web components and utilities to server
5. Deselect all drivers and select

GroupWise
eDirectory

6. Select Application components
7. Complete install and restart the server
8. Load DSTRACE and set DSTRACE to DXML and DVRS
9. Start all drivers and confirm no errors on trace
10. Apply authorization to Directory set
11. Restart all drivers to check for authorization
12. Upgrade eDirectory driver and restart
13. Upgrade GroupWise driver and restart
14. Upgrade UserApplication driver and restart


UserApplication Install
(Yet to be completed)
1. Install new SLES 10.1 server
2. Install additional software including development tools
3. Create a new instance of the IDM UserApplication using different port number to the original
4. Duplicate settings between UserApp drivers but leave the new one stopped
5. Install and configure UserApplication on new server


Problems encountered

Problem: Error updating NMAS methods during IDM install on server.
Solution: Rename sys:\ni\update directory

Problem: Error on eDir driver start using certificates
Solution: Re-issue certificates using the NDS-to-NDS certificate wizard

Problem: Unable to deploy new UserApplication driver from Designer
Solution: Run Project Checker in Designer and redeploy


And there you have it, an upgraded IDM system.

|

Rebuild Netware 6.5 DOS partition

So your NetWare server has been running flawlessly for years, and you've just restarted it to find it wont boot.

Boot loader not found...

or

No operating system found...

You know the error, I'm sure you've seen it all before.

You could go through and boot from a utility disk and try and repair the partition, or you can recreate it with the NetWare install CD. How you proceed will depend on your comfort level, how/if you've done it before, and how many pointy-haired bosses you have yelling at you at the time. I'll take you through using the NetWare install CD.

Things you'll need to know are:
a) Your current OS version and patch level.
b) Any new driver updates you may have applied and modifications to the STARTUP.NCF file.
Get these ready, tell your pointy-haired boss to back-off before you insert the CD up his ...

...and focus.

1. Insert your NetWare CD with the latest patch overlaid (you can download this from Novell).

2. Start the install and select "Manual" so you get to choose all the options.

3. At the screen that asks you for the Boot Partition you'll see the current FAT16 partition. Delete this taking note of the size.

4. Create a new boot partition of the same size and continue with the install.

5. At the screen that asks for the SYS: partition DO NOTHING. You only have two options... recreate the partition or format the existing one. YOU DON'T WANT TO DO EITHER.

6. Switch to the Console screen (Alt+Esc and screen 1)

7. Down the server by typing "Down" and pressing enter.

8. Power cycle the server.

9. When the server comes back up it will be sitting at a DOS prompt. This is because the AUTOEXEC.BAT file is not created till later in the install. Edit the AUTOEXEC.BAT file and add the following:

@echo off
CD NWSERVER
SERVER -nl

(the -nl just turns off the splash screen so you can see any errors that may occur)

10. If you did NOT use an overlay CD at the same patch level as your server, you will need to copy the files from the patch CD. You will need the updated SERVER.EXE and any other updates. You can browse the patch CD for these files.

11. If you have a backup copy of your STARTUP.NCF file simply copy it back into C:\NWSERVER. You may be able to recreate it based on another server if you have another of similar hardware. If not, don't despair. Leave it alone and go to the next step.

12. Type AUTOEXEC and press enter to start the server. If you don't have a copy of your STARTUP.NCF file, once the server has started and is sitting at the console, type HWDETECT and press enter. Your NetWare box will go through and scan for new hardware and load the necessary drivers, or prompt you for them.

13. Once all the hardware is taken care of, reboot and you should be right to go.

As simple as that.
There are multiple ways of rebuilding your DOS partition and I think I've tried most of them. I didn't have any time constraints this time around so I thought I'd test out this method. It works a treat.

Last step.
Because you've had problems with your DOS partition, you should run a Pool verify over the NSS pools after you get the server back up. Regardless of the pressure you're under, don't put this off.

NSS /poolverify

|

IDM Driver movements

In preperation for using the Entitlements driver in our IDM solution I had to restrict our driverset to a single server (version 3.5 of IDM overcomes this restriction but I was also trying to streamline). This meant moving the GroupWise driver from one server to another. There are a number of ways to do this but ultimately they involve, exporting the driver, deleting the driver, importing the driver specifying another server and then deleting the superfluous server from the driverset. You can do this with Designer, but I've not taken a liking to it yet and prefer to use iManager. Before doing any work with the driver, install the GW components on the new recipient server.

To export the driver with iManager do the following:

1. Browse to the driver set and click on the driver in question

2. Select export and follow the prompts, exporting to an xml file on your PC

3. Once exported, delete the driver from the driverset

Import the Driver back into the driverset

1. Now that it's gone, we need to import it back in. Import the driver back into the same driverset selecting the other server and following the prompts

2. Because in my case the GW driver is not on a server other than the primary domain database, we have to specify a user account with RWCEMFs rights to the Domain DB. We also need to specify the IP address of the GW server and the path to the Domain DB.

3. Start the driver

NB: if you're running the IDM drivers on a Netware server, make sure you add a search path for the GW driver components before starting the driver. I add the following line up high in the AUTOEXEC.NCF file.

SEARCH ADD SYS:\SYSTEM\GWDRIVER

Once added to the AUTOEXEC.NCF file, type the same line at the console and press ENTER.

Because we didn't change the name of the driver in the driverset all associations remain current.. so no need for the driver to go off madly reassociating objects.

The final step is to delete the old server from the driver set.

1. Click on the IDM overview in iManager and then select the red X next to the server list.

2. Select the server about to be removed from the driverset and click apply.

3. Done. Go grab yourself a coffee.

FINAL NOTE: Run this process through your test environment. iManager crashed on me during test which cause a few skipped heartbeats. Plus I forgot to add the search line on the recipient server which accounted for a couple more.
|

Moving your GroupWise PostOffice to a new server

So for one reason or another you need to move your GroupWise post-office to a new server. I have used the following process with GW7 but there should be no reason you can't use it with version 5.x and 6.x. The key is to do it in a test environment first, in case things turn pear-shaped. If your GroupWise system is using UNC paths for access links between the agents, I recommend you change this now to TCP links. The GroupWise documentation covers this.

You're going to need to bring down the MTA and POA to do this so pick a time when people aren't needing the system urgently.
We work in I.T. We're used to doing the late shift... aren't we?

First things first. Know a little about your GW system. Are your POA's, MTA's etc configured for TCP links or UNC paths? Also know where your log files are currently going and where to change this information.

1. Shutdown the MTA and POA. If you have more than 1 post office in your domain, shut the others down also.

2. Copy the PO data to the new location.
You can use whatever you like. I'm lucky, my PO resides on a SAN LUN so it can be easily pointed at any server with a HBA. But you can use XCOPY, DBCOPY, even the Server Migration Utility. While the copy is occurring carry on with the next steps.

3. Edit the post-office object in ConsoleOne and change the UNC path to reflect the new location.

4. Edit the post-office agent in ConsoleOne and change the network address to reflect the new server. You can also change the port if required. Check the log file UNC path to ensure it's still valid and change if necessary. I like to keep logs local to the post-office so I change this to reflect a path on the local server.

5. Select the Domain MTA and edit the Link configuration of the post-office in ConsoleOne to reflect the network address and port of the new server. Save this.

6. Edit the links for your Web Access Gateway if you use it, to reflect the new server network address. Save this.

7. Edit the links for your GWIA to reflect the new server network address. Save this.

8. If your NGWNameserver DNS entry points to the old server, make sure you update this information if required.

9. Load the MTA for the domain if the data copy has completed.

10. Rename and rebuild all post-offices in the domain and reload the agents on their respective servers.
(I have two post-offices in the domain and until I had rebuilt the second post-office it wouldn't redirect clients to the moved post-office)

11. From the MTA Agent screen press F10 and view the configuration information. Ensure it reflects the changed network address/port of the new server for the PO in question.

12. Test.

As mentioned previously I assume the use of TCP links rather than UNC between the different agents. If you use UNC paths the process is the same except you will need to ensure the /USER-userid has the required filesystem rights to the new post-office location.

LINUX. If you're running your GW system on Linux the process is the same. But rather than use the MTA agent screens that appear on NetWare, you will need to use the web consoles for your agents.

I highly recommend you run up a test environment and test your proposed course of action.
|

Extending a User with LDAP

While this doesn't apply specifically to Novell, it's what I've been playing with.

Thanks to Eddie for being a ready-reference, you're a LEGEND!

I had to extend our eDirectory schema at work with an auxiliary class for the Users. Easily done. However actually extending all the user objects with the new class information was a little more challenging...only slightly. Yes it can be done in C1 and iManager but I needed to do this to 21,000 users at once as well as apply some attribute values.

LDAP to the rescue.

Using a text editor and C1 you can easily manipulate values in a Directory using the power of LDAP. This doesn't just apply to eDirectory, you can do similar things with MAD or any LDAP directory. This is how I did it.

1. Backup your Directory

2. You need a list of accounts to modify. Using C1 do an export of objectclass=inetOrgPerson and select Entry names only.
This gives you a nice list of distinguished usernames. Perfect.

3. Now you'll need a good editor. TextWrangler is my choice but anything that can search and replace including special characters like CR... so Notepad is out, and so is Wordpad. I'm not sure about Word but you could give it a shot. If you have a MAC, use TextWrangler, it's hard to beat. Excel can be used initially also.

For each user record you need the following in your LDIF file:

dn: ‹username›
changetype: modify
add: objectClass
objectClass: ‹name of your aux class›
-
add: ‹attribute name›
‹attribute name›: ‹attribute value›
-
add: ‹attribute name›
‹attribute name›: ‹attribute value›


Continue on for all additional attributes leaving a space or two between useraccounts. Some creative search and replacing will do it.

3. Import using the wizard in C1 and 5mins later all 21,000 accounts have been updated. It helps if you tell C1 not to stop on errors, if you've done the above correctly you shouldn't get any but you don't want to walk away from the PC only to find the import stopped on record 55 of 21,000.

Deleting is just as easy. Simply change your LDIF file to something like this:

To delete the attribute:

dn: ‹username›
changetype: modify
delete: ‹attribute name›


To delete the class extension (essentially deleting all auxiliary attributes that were part of the auxiliary class we extended the user with, and removing the extension from the object. Be very careful with this!!!!!):

dn: ‹username›
changetype: modify
add: objectClass
objectClass: ‹name of your aux class›

Note: ensure you are not still using the attribute data before deleting it. You might want to consider doing an LDAP export of all data before making any deletes, in case you need to put it all back in a hurry.
Note: Step 1
|