First a comment, although Microsoft seems to have a much better DNS system than on Netware 6.5, their DHCP implementation leaves a lot to be desired.

On Novell I could create a scope, reservations and options and it is stored in eDirectory. I could then have multiple DHCP servers with different IP ranges to offer. I could use the java console (sometime slow) to add a reservation and it would sync to both servers.

On Windows Server 2003 and 2008 I need to separate create scopes, allocation ranges and reservations on each server. Their is no synchronisation or communication between these servers. This means to migrate my reservations from my current Netware DHCP servers to the target Windows servers the reservations need to be added to each server, as well as adding any future reservations to both servers.

Migration Process

First use the Novell DNS/DHCP console and export the DHCP scope / database you are migrating.

I have written the following Perl code to read in the DHCP3TAB file generated and output a netsh file that will add all your reservations to any number of Windows DHCP servers.

You will need to modify the DHCP servers list to your AD servers and change the scopeName to the correct IP settings.

After running your DHCP3TAB through the perl script, copy output to your server and run netsh exec outputFile.txt to add it to your servers.

#!C:\Perl\bin\perl.exe

# Designed to read in Rservations from a Novell DHCP Tab file and output a NetSH script file
# From http://technet.microsoft.com/en-us/library/cc787375.aspx
# On the destination server, the exec command is used to load and execute the converted reservations:
#  netsh exec AdReservations.txt
# After you use the exec command to load the file, you must reconcile all scopes.
# Use net stop dhcpserver to stop the DHCP Server service and net start dhcpserver to restart it. Once the service is restarted, DHCP database changes take effect.

use strict; use warnings;

my $dhcptabName = "DHCP3TAB.txt";
my $outFile = "AdReservations.txt";
my @dhcpServers = ('\\\\DHCPServer1.win.us.schools.nsw.edu.au',
    '\\\\DHCPServer2.win.us.schools.nsw.edu.au');
my $scopeName = "10.10.11.0";

open F, "< $dhcptabName" or die "Can't open $dhcptabName : $!";
open O, "> $outFile" or die "Can't open $outFile : $!";

# File parsing
my $ip;
my $host;
my $mac;
my $type;
my $comment="";

while (my $line = <F>){
  if ($line =~ /^\[IP Address Configuration /i) {
  # New entry, clear values
    $ip="", $host="", $mac="", $type="", $comment="";

    while ((my $entry = <F>) !~ /^$/){
    # Parse and fill in values
      if ($entry =~ /IP Address Number = ([\d.]+)/i){
        $ip=$1;
      }
      elsif ($entry =~ /Assignment Type = (\d+)/i){
        $type=$1;
      }
      elsif ($entry =~ /Host Name = ([\w\-_]+)/i){
        $host=$1;
      }
      elsif ($entry =~ /MAC Address = 1 (.+)/i){
        $mac=$1;
        $mac=~ s/\s+//g;
      }
      elsif ($entry =~ /Comment = (.+)/i){
        $comment=$1;
      }
    }

    # Following determines which type of entries to convert. Default is only reservation.
    # You can comment it out and uncomment the second line to include reservations and allocated IPs.
    # If  type != 8 (reservation) discard
    next unless ($type == 8); 

    # If  type != 8 (reservation) or  != 2 (Allocated) discard
    # next unless  ($type  == 8 or $type  == 2);

    next if ($mac eq "" or $ip eq "" or $host eq "");
    foreach my $server (@dhcpServers){
      print O "Dhcp Server $server Scope $scopeName Add reservedip $ip $mac \"$host\" \"$comment\" \"BOTH\"\n";
    }
  }
}

close F;
close O;

As part of this rename we needed to change their Novell eDirectory account and home directory. We also needed to ensure linked systems such as an LDAP authenticated Moodle site and an IDM linked Active Directory (AD) domain were properly updated.

To perform the user account and folder rename we used Mass User from HBWare. This is a great program we already used for creating and managing home directories and quotas. There was a small bug in the rename area, but it was quickly fixed when brought to Hans’ attention.
Note: Before beginning you need to have a list of the old usernames and the new usernames. A simple two column Excel or CSV file would be fine.

Novell

Create Mapping File: The mapping file is used by Mass User to know what to rename the existing username to.

Use NDS Report ( http://www.novell.com/coolsolutions/tools/13908.html ) to create a list of all the accounts. You only want the DN and CN fields. Save this as an Excel or CSV file.

NDS Report: Select Student OU

NDS Report: Choose only CN

Create a new MS Access file and import the account list
Import the text / excel file that lists the old and new account names.
You now need to create a query that maps the cn to the old account name, and then use this to generate a list of the full old dn and the new account name.

Access: Mapping Query

Access: Query Results

You can then export this as a text file.

Access: Export as text file

Access: Export Delimited

You will need to set the field separate as ‘=’ and set the test qualifier to none.

Access: = as Delimiter and no Text Qualifier

You should end up with each line having format:
OLDNAME.OU.C=NEWNAME
Once the mapping file is generated you can apply it either to individual OUs (e.g. year groups), or to the entire Users container. I would recommend applying to small containers initially to allow checking for errors. After verifying all renames were performed correctly you can then apply the rename to your entire users’ container.

Mass User: Rename

IDM 3.0 – Active Directory

Before doing the mass rename we did some simple tests of renaming eDirectory accounts to see how they replicated to Active Directory. We determined that the individual renames were successfully propagated through IDM to automatically change the pre-2000 and logon name fields to match the new eDirectory account.
When performing the mass rename of accounts, AD was checked after doing each OU to check propagation was successful. We experienced no problems with IDM and all accounts were successfully synchronised with Active Directory.

Moodle

For Moodle we wished for users to retain their own accounts including all their settings and course information. To do this the username stored in the Moodle Database (DB) would need to be changed to the new username.
Before making changes to Moodle I recommend putting the site in admin mode and temporarily disabling your LDAP authentication. I only put the site in Admin mode and then had problems during migration as some students had attempted to logon after I had renamed the eDirectory accounts, but before migrating Moodle accounts. This created new user accounts in Moodle that prevented the update queries running due to duplicate key name problems (ie the old account would not rename to new one if one has already been created with the new name)
First you need to import your list of old and new account names into the database. If you already have it in a separate DB on your Moodle server you can use that, otherwise it is best to just to create a new table in the Moodle DB.
I used this query to check the mapping fields. You will need to adjust the fields and collation types for your own setup.
I use the IDNumber field to store the full DN, if you use a different field you will need to adjust this.

Validation:

# Shows the current username, the new username and the new IDNumber field for validation check.
SELECT mdl.`username` , ern.`StudentId` , replace( `idnumber` , mdl.`username` , ern.`StudentId`
COLLATE latin1_swedish_ci )
FROM moodle.`mdl_user` mdl, sbhsdata.`oasisStudentIdMap` ern
WHERE mdl.`username`
COLLATE latin1_general_ci = ern.`OldStudentId`

Update:

# Replaces the IDNumber field with the new username.
UPDATE moodle.`mdl_user` mdl, sbhsdata.`oasisStudentIdMap` ern
SET `idnumber` = replace( `idnumber` , mdl.`username` , ern.`StudentId` COLLATE latin1_swedish_ci )
WHERE mdl.`username`
COLLATE latin1_general_ci = ern.`OldStudentId`

# Replaces the mdl_user field with the new username.
UPDATE `mdl_user` mdl, `rename` ren
SET mdl.`username` = ren.`newname`
WHERE mdl.`username`= ren.`oldname`
Note: As can be seen by the queries, during the migration I did two separate updates, one to update the IDNumber field and another to update the mdl_user field. When I had completed migration I realised I had only needed to update the mdl_user field as Moodle would automatically update the value in IDNumber at next log on.

Round Up

The migration to the new accounts went well with no problems from student passwords or accounts, although we had a few instances of students using the old username instead of the new one.

Since performing the change we have also implemented a Papercut system which would have required the additional step of renaming all of its accounts to ensure student balances were carried across.