Known Behaviors & Considerations

Opsole Migrate performs an in-place device and user transition from Active Directory or Hybrid environments to Microsoft Entra ID. This includes device join, user identity transition, and preservation of the existing Windows user profile.

Due to Windows platform design, identity boundaries, and management transition, certain behaviors are expected during and after migration. These are inherent characteristics of the operating system and environment.

Supported Device States

Before migration, devices must be in one of the following supported states:

Hybrid Microsoft Entra joined
Active Directory joined with Microsoft Entra registration
Microsoft Entra joined (applicable for tenant-to-tenant migration scenarios only)

The following scenarios are not supported:

Active Directory–joined devices where the user does not have a corresponding Microsoft Entra ID account
Devices using only local (workgroup) accounts

Opsole Migrate is designed for environments where user identities are synchronized from Active Directory to Microsoft Entra ID.

Multi-Factor Authentication (MFA) Requirements

Automated Microsoft Entra ID device join relies on non-interactive authentication during the provisioning process.

To ensure successful execution:

The "Require Multi-Factor Authentication to register or join devices" setting in Microsoft Entra ID must be set to No.
Any Conditional Access policies enforcing MFA for device registration or join must exclude the account used for provisioning (for example, bulk enrollment or migration account).

If MFA is enforced for these operations, the device join process may fail because user interaction is not available during execution.

Intune Enrollment & Configuration

Microsoft Intune enrollment must be correctly configured to allow automatic device enrollment after Microsoft Entra ID join.

To ensure successful enrollment:

Automatic MDM enrollment must be set to All users or include the group containing the target users.
Windows Information Protection (WIP) must be set to None in the MDM user scope configuration.

Devices with existing or previously applied WIP policies may experience enrollment or migration failures due to conflicts with the enrollment process.

Ensure that the device is in one of the following supported states:

Fully managed by Microsoft Intune
Not enrolled in Intune

Devices configured with WIP are not supported for this migration scenario.

Conditional Access & Network Restrictions

Conditional Access policies can impact device registration and join operations during migration.

To ensure successful execution:

Policies that restrict device registration or join based on network location (for example, public IP conditions) must allow traffic from the device's current network.
The account used for automated provisioning (bulk enrollment or migration account) must remain unchanged throughout the migration process.

Changes to this account (such as credential updates, policy assignment changes, or removal from exclusions) may result in device join or enrollment failures.

Testing and Proof of Concept (Recommended)

It is recommended to perform a Proof of Concept (PoC) prior to large-scale deployment.

PoC testing should be conducted on a representative set of devices and user profiles, including:

Business-critical applications
Third-party applications
In-house or custom-developed software

This helps identify:

Application compatibility considerations
Background services or processes that may interfere with profile or identity transition
Environment-specific behaviors that may require configuration adjustments before rollout

User Profile Migration (Known Considerations)

Profile in Use

The user profile must be fully unloaded during migration. If the profile is in use, Windows prevents changes to the profile configuration.

When a profile is loaded, Windows maintains active locks on:

The user registry hive (NTUSER.DAT)
User profile data files

As a result, profile updates cannot be completed while the profile is in use.

Migration skips profiles that are detected as loaded.

This condition can occur when:

Services run under the user account
Scheduled tasks execute using the user account
Background applications (e.g., backup services or security agents) may access the profile after sign-out

If a profile is detected as loaded during migration, the underlying cause must be identified and resolved prior to reattempting the migration.

Resolution of such conditions is dependent on the device configuration and environment-specific processes within the customer

Operational Considerations

Profile processing time and reliability may vary depending on device state and environment conditions.

Large user profiles (high file count or size) may increase processing time.
Background processes or applications accessing the profile may delay profile updates.
Endpoint security tools (EDR/AV) may monitor or intercept file system operations during processing.
Devices with high disk usage or limited system resources may experience longer execution times.
In some cases, profile updates may require additional time during system startup before user sign-in.

Resolution of such conditions is dependent on the device configuration and environment-specific processes within the customer environment.

The user profile folder name (e.g., C:\Users\username) remains unchanged after migration

If the Microsoft Entra UPN differs from the on-premises SAM account name, the profile folder continues to reflect the original on-premises username

Changing the profile folder name is not supported as part of in-place migration and requires device reset or reprovisioning

Protected Data and Credentials

Certain user data is protected by Windows security mechanisms and is bound to the user identity.

After identity transition, the following may not be accessible:

Credentials stored in Windows Credential Manager
Saved passwords for network resources
Application-stored secrets and tokens
Certificates with user-bound private keys
Files encrypted using Windows Encrypting File System (EFS)

On devices using Trusted Platform Module (TPM) or software TPM, hardware-protected credentials (for example, Windows Hello and passwordless authentication) may also require reconfiguration.

For scenarios where credential continuity is required, credentials and certificates should be backed up prior to migration and restored afterward. Recovery or restoration of such data depends on the availability of user-specific keys, credentials, or backups within the customer environment.

Applications & User Experience (Known Behavior)

Application behavior after migration depends on the migration scenario.

Hybrid AD / AD -> Microsoft Entra ID

Some applications may prompt for reauthentication due to changes in device trust and user context.

Tenant-to-Tenant Migration

Microsoft 365 applications may require reauthentication.
Outlook profile may require recreation in some cases.
OneDrive may require reconfiguration and resync.
Browser sign-in may be required.
Application licensing may require reactivation.

General Behavior

Default applications (file associations) may revert to system defaults.
Some modern (Store/UWP) applications may require reinitialization.
Application preferences (for example, recent files and pinned items) may not be retained.

Application behavior and required reconfiguration may vary depending on application design and environment-specific configuration.

Policy and Management Transition

After migration, the device transitions from Active Directory-based management to Microsoft Entra ID and Intune.

Active Directory Group Policy (GPO) no longer applies.
Existing registry-based settings remain in place.
New configurations are applied through Intune policies.
Mapped drives configured through Group Policy or logon scripts are not recreated automatically.
Printers deployed through Group Policy are not retained.
Folder Redirection configured through Group Policy no longer applies.
Active Directory-based logon and logoff scripts do not execute.
Applications deployed through device management (for example, Intune required apps) may be reinstalled or temporarily unavailable during transition.

Existing policy configurations and cached settings from Active Directory may continue to influence device behavior until they are replaced or overridden by Microsoft Intune policies.

Replacement of legacy configurations depends on the organization's device management and policy design.

Not Supported Scenarios

The following configurations are not supported:

Roaming user profiles (network-based profiles)
Mandatory profiles (NTUSER.MAN)
Profile container technologies (for example, FSLogix, Citrix profile management, and VDI environments)
Temporary or corrupted user profiles

Provisioning Package Requirements

Installation of the provisioning package must not be restricted by Intune policies, Group Policy, or endpoint security controls.
The provisioning package must remain valid for the duration of the migration window.

Active Directory Object Cleanup

After successful migration, the corresponding Active Directory device object should be removed to avoid conflicts with the Microsoft Entra-joined device.

Third-Party MDM Considerations

Direct migration from third-party MDM platforms is not supported.

Devices managed by non-Microsoft MDM solutions require assessment and planning prior to migration.

Migration from third-party MDM platforms requires assessment and planning based on the customer's environment and management configuration.