What are usual steps that admins and user should perform to initiate and successfully complete the ODJ (Offline Domain Join) process? This article presumes that all necessary configurations and preparations were done in ODMAD, in environments, and on the machine (like device agent installed, domain trust established, ODMAD Cached Credentials populated, etc).
The usual situation for the the remote user is like this:
The first step in the ODJ process, is when migration admin is initiating a ReACL, then Cached Credentials jobs for user's machine. This will create a popup on user's machine, asking for the target domain user's credentials. For majority of migrations, password sync was established in the Dirsync area and target user's password is the same as in the source.
Important: VPN solution/firewalls must not block ICMP protocol (ping) as it's required by the ODJ process to verify that target DC IP is reachable.
When user is populating target domain credentials, they're validated against the target DC. If successful, these credentials will be stored in the secured part of the registry.
The next step is when migration admin is initiating the ODJ process. This will perform DJOIN process to the target domain, using previously prepared DJOIN file. It'll also ReACL user's profile. Machine will go to reboot.
After the reboot, user should be able to perform login using target domain credentials, while target domain network is not available. This will validate that captured cached credentials are working.
Once logged in, user can use a VPN client to connect to the target network. This could be a different VPN solution so migration admins should take care that user is having all necessary tools to connect prior to starting the ODJ process.
Note 1: ODJ process should never be mixed with the usual Cutover. Doing so may leave machine unusable.
Note 2: There are "pre-logon" VPN solutions that establish network connectivity upon OS boot. These solutions are usually certificate-based. Please make sure that VPN certificate is stored in the Local Machine certificate store and not within the user's personal cert store. User's personal certificate store's certificates will not be available after profile conversion from the source to the target.
The reason is that personal certificate store is encrypted using user's SID. Profile conversion is effectively changing the source SID to the target SID, and Windows can no longer decrypt certificates after such conversion.
If there are important personal certificates, that should be preserved during the migration, please export them to files, then import them back after the migration.
