A couple of weeks ago I had to migrate about 5,000 clients from Novell OES eDirectory to an Active Directory domain.
None of the workstations were members of a NT- or AD-domain at that time.
But still ADMT was our tool of choice.
Initial situation – How to migrate clients from non-AD to AD
Our client is using netIQ IDM. The migration of users, OUs and groups with netIQ IDM worked really well.
Of course you can simply join the clients with the AD domain as well, but the user would then get a new profile.
Believe me, it is no fun to explain 5,000 people that their desktops and other settings have been cleaned up – meaning are just not there anymore.
The environment at our customers was a pure ‘Novell network’. All clients were installed without AD domain and all used the Novell DLU policy.
The DLU policy ensures that every user is dynamically set up on the client at Novell-login.
Our task was to replace every single user on any client with the respective user in the AD-domain.
Novell client migration – Tool choice
If checked the tools on the market and thought that we have 3 ways to encounter the problem:
- Profile migration tools
- PC migration tools
- A solution with standard AD-to-AD migration tools
There is a number of tools with which it is possible to migrate profiles.
But this method seemed to be too complex and susceptible to problems.
There are also several migration tools on the market which handle full PC migrations.
The problem here was, that they are very expensive and that they do much more than we needed.
All we wanted was a tool for the client migration only.
How to use ADMT for Novell to AD migration
In the field of “AD to AD”-migration, e.g. a domain-consolidation, we had frequently worked with the ADMT-tool by Microsoft. Originally, it is meant to be used for the migration of workstations from one AD-domain into another.
Essentially, those tools all do about the same:
SIDs of the old environment are swapped with the ones of the new environment (AD-domain) on the workstations. For an AD to AD-migration, I normally have a mapping file for the migration. In this special case though, I have an individual mapping file on each client, because every client is its own domain, so to say.
I decided to read out all local user-SIDs from the client, figure out the SID from the domain through the user name of the local user and feed the ADMT-service with the individual mapping-files for every workstation. I can give the ADMT-service the respective mapping-file for every workstation. The ‘reACLing’-process works as well or poorly as with every AD-migration.
Depending on the set up, I can log in to the workstation after the migration (joining and reACLing) with either the ‘old’ local user name (DLU-Novell) or with the new AD-user.
I can recommend a Novell client migration with ADMT to everyone who has a certain experience with migrations.
It works as stable as with costly migration tools.
Most problems that can occur are independent from the tool.
At firstattribute.com you can read more about challenges and planning of a Novell to AD migration.