Converting Active Directory Groups to Cloud-Only with ADGMS
If you find yourself creating and maintaining on-premises groups just so they will synchronize to your Azure tenant, it’s time to free yourself from this time-consuming and potentially risky outdated practice by converting them to cloud only. Converting your groups to cloud-only will eliminate your dependence on legacy Active Directory Domain Services environments and enable you to delegate their management without resorting to custom Active Directory permissions, outdated management interfaces and even VPN or remote access solutions if your administrators are a part of today’s remote workforce. Remember all those distribution groups that your users were able to manage before their mailboxes were migrated to Exchange Online? By converting those groups to cloud-only, your users can once again manage them themselves! This eliminates the need for custom group management tools or for your helpdesk to manage membership on their behalf. So now that we’ve agreed it makes sense to convert your synced groups to cloud-only, what are your options… There are a variety of methods available to convert your groups to cloud-only, however they vary in cost and complexity, ranging from manual re-creation, which can be time-consuming and prone to error, building your own Graph API or PowerShell scripts, which require a significant understanding of Microsoft Exchange, Active Directory, PowerShell as well as rigorous testing to ensure a functional solution, or, worst case, searching the internet and re-using scripts built by others with potentially harmful results. To help simplify and ensure the safety of this process, the IMS team offers a turn-key managed solution called Active Directory Group Modernization Service, or ADGMS. ADGMS is a cloud-based, automated solution that connects to and monitors your Entra tenant, automatically re-creating groups whenever they are moved out of scope of your Entra ID Connect or Entra Cloud Sync solution. ADGMS maintains each group’s membership, including any nesting, as well as it’s email addresses, send and receive restrictions, manager or owner and even extended attributes, and ADGMS uses all this data to instantly re-create the group as cloud-only. Additionally, ADGMS provides reports on all the nested groups in your tenant, helping to identify any cases where you have circular or self-nesting that might otherwise impact mail-flow and management. These reports are then used to create your group modernization strategy by ensuring you re-create your groups in the correct order. The beauty of ADGMS is that it’s 100% automatic and customer-driven. Once ADGMS is enabled, you control the quantity and speed of your group modernizations, and the ADGMS solution handles all the heavy lifting, and because ADGMS maintains all the email routing addresses, your users won’t even realize that the group has been converted to cloud-only. It is important to note, that while ADGMS can help radically change your cloud administration model, it does not support modernization of security groups by default. That said, based on the tens of thousands of groups already modernized with ADGMS, we have found that most legacy mail-enabled security groups primarily exist in Entra for the purposes of email routing and not securing cloud resources. In those cases, the group can be modernized into a cloud-only distribution group, and the on-premises group mail-disabled and left as a security-only group. How to take advantage of ADGMS If you are interested in reducing your administrative burden when it comes to on-premises groups currently synchronizing to Entra and leveraging a proven managed solution for migration of those groups to cloud-only resources, be sure to contact the IMS team for more information about ADGMS. Learn more about IMS and start hassle-free migrations and its capabilities today on our YouTube Channel Want to speak with an expert? Reach out to us at imssales@microsoft.com to connect with a sales representative.Seamless Transitions: Unlocking Workstation Migration with Identity Migration Service (IMS)
Workstation Migration with IMS IMS offers workstation migration as part of the solution for migrating user accounts across domains. This service includes joining the machine to the target domain and translating your user profile on the workstation to the target domain. Tool Leveraged for Migration: IMS uses WMT (Workstation Migration Tool) service for performing the workstation migrations across the domains. The Workstation Migration Tool (WMT) Service is specifically designed to perform privileged workstation migration operations. Prerequisites for a Workstation Migration For a workstation to qualify for migration, The WMT Service must be installed and active on the system. This ensures that all migration tasks are executed securely and efficiently. Computers objects must be pre-created by the synchronization service in order to migrate the user's computers. If they do not exist in the target, the migration will fail on the computer migration component. Scope Only enabled computers with a Windows client operating system, Windows 10 or greater, will be synchronized. All non-windows computers (such as Macs) and server computers will not be synchronized. IMS cannot be used to migrate servers and cannot migrate non-Windows clients. How WMT Migrates a Machine's User Profiles When one or more local User Profiles are in scope for migration from the source account ownership to the corresponding target account, they go through the following processing: User profile in scope: Typically, the initial ownership of a user profile (the NTUSER.DAT file) belongs to the user's source domain account. There is a specialization that can be configured to restrict migrating only those user profiles where their corresponding accounts are already migrated. There is a specialization that can be configured to allow a secondary (non-primary) source account to migrate its profile to the corresponding target account. User profile migration process: After rebooting, user account profile migrations are initiated. The size of the user profile will determine how much time is allocated to the user profile change ownership processing (which includes retries). The larger profiles will be allocated more time to process them. When a user profile ownership operation fails, it will not immediately retry; instead, the next profile on the list gets its chance to process first. The retries will be attempted in the subsequent processing cycle. Key Features WMT can track the per user profile translation and not translate the source account's user profile again if it's already translated. Migration Over VPN: By default, support for self-service migration under the VPN mode using the IMS Portal Click Once user interface is enabled. When a user is under VPN mode, only the self-service Portal migration is allowed since the logged in migrating user can be prompted to cache his/her target user account so that he/she can log back in after reboot and before the VPN connection is established. (surrogate Portal migration or the unattended Auto Migration App can't prompt the appropriate user to cache the target account which preventing the user from logging back in and therefore these two migration types should be blocked under VPN). Learn more about IMS Migration methods Migration Over VPN Without Target Domain Join: The WMT Package can be configured to skip joining the client machine to the target domain when migrating the machine over VPN. Under this mode, the target account is still validated and prompted to be cached so that after machine reboots the user can log back in with the migrated target account. WMT App Reregistration Processing and Progress UI: The WMT full-screen splash screen app is used for app reregistration progress UI and informing the user to log back in later due to the user profile change ownership task having not completed yet. The WMT Service has the option to run custom PowerShell external scripts at the following points in the WMT Service workflow. Pre-Workstation Migration (Local System Context) Post-Workstation Migration (Local System Context) After Reboot, After User Profile Migration (Local System Context) After Reboot, After Each User Login, After App Re-registration (Current User Context) IMPORTANT Note: The customer is responsible for maintaining the external script and monitor its logging. IMS only reports successful or unsuccessful execution. Benefits of Workstation Migration Tool: User Profile Tracking: WMT can track per user profile translation and ensure that the source account's user profile is not translated again if it's already translated. Migration Over VPN: The WMT package can be configured to migrate the machine over VPN and also can be configured to skip joining the client machine to the target domain when migrating over VPN, allowing for seamless migration with and without domain join. App Reregistration: The WMT full-screen splash screen app provides a progress UI for app reregistration and informs the user to log back in later due to the user profile change ownership task. Preventing Extra Profiles: A login GPO can use a script to prevent a migrated source account from logging onto a machine where its profile is already migrated to the target account, preventing extra blank profiles. Custom Scripting: The WMT Service allows for custom PowerShell external scripts to be run at various points in the WMT Service workflow, providing flexibility and customization. - Reference blog Custom Scripting Conclusion The Identity Migration Service (IMS) and its Workstation Migration Tool (WMT) offer a robust and efficient solution for migrating user profiles and workstations across domains. Overall, IMS and WMT provide a comprehensive approach to workstation migration, enhancing the digital presence and customer engagement for organizations. Learn more about IMS and explore its powerful migration capabilities today! Read our latest insights on the IMS blog Learn more about IMS and start hassle-free migrations and its capabilities today! On our YouTube Channel Want to speak with an expert? Reach out to us at imssales@microsoft.com to connect with a sales representative. Let’s power the future of digital collaboration — together.Exploring the Use Cases of ADMS Application Pipeline
A Comprehensive Overview: An Insight into Active Directory Migration Services Application Pipeline. Introduction ADMS, ADSS, and ADGMS are all cloud-based services that come within the ADxS services portfolio offered by Microsoft and designed to facilitate efficient and cost-effective migrations. For additional information around migration use cases, refer to this blog: https://techcommunity.microsoft.com/blog/microsoft-security-blog/exploring-the-use-cases-of-adxs-services/4373299?previewMessage=true . In this blog, we will examine the various use cases of ADMS application pipeline, highlighting its key features and advantages. ADMS or Active Directory Migration Service – is a service designed to facilitate the migration of users and workstations across domains and forests by offering diverse number of migration methods such as Self-Service Migration which is unique to the ADMS service and it comes with two types, Self-Service for corporate connect users, and Self-Service for Remote of VPN users, Admin automated Migrations, user only migration and Migration for workstations shared by more than one user. ADMS Queuing Framework The ADMS user migration is accomplished by several backend processes in addition to the ADMS Portal, which provides a self-service user interface, does pre-validation checking and ensures that the user is approved to migrate. The ADMS solution is scalable to support many concurrent user migrations submitted using the Self-service Portal and by the bulk account submission tool. An ADMS user migration spans across several processes in a workflow. These migration processes are tracked by several persisted work items across several queues. There are four primary types of queues in the ADMS solution for queuing up and serving work items. These work items are processed on a first-in-first-out (FIFO) basis where interactive migrations using the Self-service/Surrogate Portal have a higher priority than ones submitted in bulk with the Auto Migration app or the Bulk Account Submission tool. Each ADMS work item carries information to enable migration and application remediation features in our solution. This blog will focus on the application remediation (AR) work items. Each user account migrated through the ADMS Migration Portal will be submitted to the app remediation pipeline. When a task appears in the queue destined for that agent, the agent retrieves the task and performs the actions that the agent is configured to perform. This is done per user at migration run-time. ADMS approach for Application and/or Service Remediation during migration. The objective of this blog is to ensure you have a clear understanding of how ADMS delivery approaches application and/or service remediation during migrations. At a high level, we know that there are applications and services that will have some issue when a user migrates from one domain to another. We suggest identifying each application and service and then figuring out whether they will need to be remediated by performing configuration change, a code update, database update, or via an ADMS application remediation (AR) agent. The ADMS delivery team provides a sample application/service catalog where we suggest documenting application and service remediation details along your migration journey and continuing to do so as migrations complete. Migration teams utilize this sample that becomes a living document along the migration journey and a hands off to operational teams post migrations leads to long-term success. Application and service remediation philosophy during ADMS migrations are about coexistence. The user identities that migrate from source to target domain must maintain access across their migration journey and coexistence is key during the migration process focusing on lifting and shifting applications and services downstream allows more runway for operational teams. Coexistence allows primary focus to be on user and device identity management during migrations while allowing a foundation that will support pivoting to rationalizing and upgrading application and service operations downstream from migrations. The ADMS sync engine enables downstream ADMS features to consume identities based on logic provided by our customers early on in our process allowing a mapping for coexistence. Once ADMS sync engine is enabled and running, ADMS delivery team performs our smoke testing, where we validate if our solution meets our agreed upon blueprint for your solution. Once testing is completed, we hand over our solution to the customer migration teams to perform their own UAT. The key to customer migration success around applications and services remediations is getting started early testing with early adopters. We suggest our customers use identities that mirror their migration use cases prior to getting into production identities to validate remediation tasks during the migration journey. The next phase would be to ramp up into a larger pilot, where most customers use technology friendly business units to perform deeper dive remediation testing use cases. ADMS migration is non-destructive to the source user identity. We are not touching or altering any accounts in the source so customers can start with a pilot knowing that we have not done anything to unravel the source account, maintaining coexistence. Customers can migrate a test account forward and confidently know that the source account remains intact while you are testing with the migrated target domain identity. ADxS in Action: Practical Approaches to Application Remediation The ADMS delivery team suggest classifying applications and services into categories or “buckets” to help identify remediation types and timings during your migration journey. Let’s discuss those in more detail from a typical ADMS delivery: ADMS Runtime: This category would be where ADMS can help the most during migrations. There are per instance fees for each ADMS AR instance so typically limited to a few configuration items. As an example, a proprietary database update is needed at the time a user is migrating, ADMS updates the reference to the source and changes it to the target identity for that migration user or bulk or migration users. An example would be calling an existing stored procedure to update a custom application/service in the customer environment. Static Change: This category would be where customer migration teams need to make a one-time application or service change. These types of changes usually need a change control, scheduled change per application/service. An example of this use case would be an LDAP application only putting to the source domain/realm and needs an update to include the target domain/realm. Dual ID: As mentioned, we do not do anything destructive to the source account so you can pivot back to that identity and retain the existing access obtained while in the source domain. Out-of-Band: The last category would be applications and/or services that can be decoupled from user migration. Once we have user identities synced, we can work with customer migration teams to provide an identity mapping file that can assist in security translations to remediate the out-of-band processes where appropriate. The key objective from our perspective to building out an application/service catalog as it relates to coexisting during migration is putting these “buckets” in place. They help migration teams sort the entire application/service portfolio so as everyone goes through their test use cases and someone says “hey, this app/service doesn’t work”, your team can ask, “ok, WHY doesn’t it work?” and it typically falls into one of those categories or “buckets” listed above. They help migration teams to define what needs to be done to correct the issue and allow coexistence during your migration journey. The Ultimate ADxS Guide: Application Remediation for Modern Migrations The ADMS delivery team has seen these common types of application and service dependencies most frequently during ADMS migrations. Let’s discuss those in more detail from a typical ADMS delivery: AD Security Group Membership: As part of the ADMS sync engine, we have the ability to sync source groups to the target environment based on an agreed upon mapping of group objects. ADMS has a feature we can enable that will bring over SIDHistory for in scope groups that are part of the ADMS sync process. This resolves many of the AD-dependent application/service access scenarios where SIDHistory is honored by that application/service. AD Attributes: Exchange is an example of where we can pick up attributes in the source and flow them to the target. Some applications/services require an attribute for authorization and in those cases, you’ll want to identify requirements and include them in the ADMS sync engine configuration. Proprietary Database: Some applications/services have a proprietary database that needs to update when the user migrates to the target. SharePoint is a good example of this use case, where we must reach out to the database, and update that reference from the source identity to the target identity at user migration run-time. LDAP Application - Best case scenario, the LDAP application is capable of binding to multiple realms, meaning it can connect to multiple Active Directory domains that are in scope for user and device migrations. Customer teams can remediate the application by configuring the application to bind to the target domain, which is the landing zone for migration. If however, you have an application that is only single-realm bind capable there are a couple options: -- Migrate all users in scope for this single-realm bind use case in a single migration batch then change the application to point to the target domain post user migration. -- Another possibility is changing authentication to use local accounts during the migration, then point the application back to target domain authentication post user migration. -- A third option is to check with the application owner to determine if an update is available to the application to allow multi-realm bind use case. -- The last resort option would be to leave the source account enabled to allow existing access while your team works on a long-term solution. Cloud Identity - There are some applications and services that rely on a cloud Identity to allow access. Your source of authority that determines source vs target Identity will come into play for this use case. Customer may need to review and update their sync to cloud configuration to allow coexistence for this use case as the user and device migrates to the target domain. How can ADMS help? The ADMS delivery team can handle at run-time remediation in the ADMS AR pipeline. This is done per user at user migration run-time to allow coexistence, maintaining access for those pending migration, and updating access for those that have performed migration throught the ADMS Portal. Customer teams will need to identify any changes that need to be made within the organization to allow coexistence per application/service. A critical role during ADMS migration is the customer UAT role. During workshops, we enable this role to assist in building out the customer application/service catalog as well as the migration test plans. Migration success relies on this role in regards to customer application/service remediation. As migrations end, customers can use this catalog as a living document that is a key factor in long-term operational success. With this guide in hand, customers know what it takes to allow and disallow access to every application/service in the organization so their provisioning and deprovisioning process is better than it ever has been based on the efforts put in during their ADMS migrations. Conclusion ADMS AR pipeline offers endless extensibility options during user migrations by allowing customers to execute remediation at time of user migration. This feature has been priceless in recent migrations to allow customers to execute downstream workflow assisting their migration journey goals end to end. Learn more about IMS and explore its powerful migration capabilities today! Read our latest insights on the IMS blog Learn more about IMS and start hassle-free migrations and its capabilities today! On our YouTube Channel Want to speak with an expert? Reach out to us at imssales@microsoft.com to connect with a sales representative. Let’s power the future of digital collaboration — together.Exploring the Extensibility of Active Directory Migration Service (ADMS) Device Migration
Introduction Active directory migrations are a critical journey and a key success factor in your identity architecture for the future of your organization. Our portfolio offers services to assist your migration teams in various migration use cases, including acquisition, merger, divestiture, directory consolidation, and cloud enablement. Have you ever tried to migrate a device from one Active Directory environment to another? This is not an easy task especially when you try to scale your migration solution. Let us take you on our device migration journey. Overview of ADxS Services Active Directory Migration Service (ADMS), Active Directory Synchronization Service (ADSS), and Active Directory Group Modernization Service (ADGMS) are cloud-based services within the ADxS services portfolio offered by Microsoft. These services are designed to facilitate efficient and cost-effective migrations. In this article, we will examine the various extensibility options of ADMS WMT Service, highlighting its key features and advantages. Device Migration with ADMS Conventional tools require mapping of users to workstations so that the migration sequence can be structured and run by the migration team. ADMS offers a simple to use portal service so that self-service migrations can be offered with users now able to migrate when it's convenient for them. The ADMS device migration is accomplished by the Workstation Migration Tool (WMT), which uses a service for conducting workstation migration operations. The WMT Service is required for a workstation to be eligible for migration. If the WMT Service is not preinstalled before migration, the portal's WMT Service prerequisite check will fail, and the migration will not proceed any further. ADMS WMT service performs at device migration runtime when invoked by ADMS Portal or our auto migration app to perform our default migration operations as well as any additional features we agreed upon during our design discussions for your ADMS delivery. ADMS WMT service allows the extensibility to run custom external scripts at various execution points during the device migration sub steps, which has been a game changer for our ADMS customers. WMT Service running custom external scripts The WMT Service has the option to run custom PowerShell external scripts at the following points in the WMT Service workflow: Pre-Workstation Migration: This location of workflow executes prior to the device being domain join to the target domain. This is the first activity after the user mappings are obtained for WMT migration sub steps. Context is Local System. Post-Workstation Migration: This location of workflow executes after the device is domain join to the target domain but prior to the reboot of the device. This is the last activity before the device reboots post domain join. Context is Local System. After Reboot, After User Profile Ownership Change: This location of workflow executes after device domain join to the target domain, post reboot, and after all user profiles change their ownership from the source account to the target account. The goal of this script should be to complete it in a timely manner before any user logs back on to the device with their target account. Context is Local System. After Reboot, After Each User Login, After App Re-registration: This location of workflow executes after device domain join to the target domain, post reboot, and after the user’s app registration completes. This is performed for each user logging back in with their target account executing prior to their Windows desktop being available. Context is logged in user context. Partnership in device migration customization ADMS team can enable these WMT Service execution workflows very quickly after agreeing with customer migration teams on name and location of custom scripts that will reside on the devices during their migration journey. These custom scripts must be deployed by the ADMS customer in advance of the device migration and will execute from the agreed upon location during the agreed upon execution time. Customers have used this feature during device migration to perform many real-world case studies that can illustrate the impact of these custom external script. The most common as of late has been in partnership with our customers to assist in their Hybrid Azure Directory Join (HAADJ) migration use case. Stay tuned for future blogs that share some of those use cases during customer migration journeys. Conclusion ADMS WMT Service offers endless extensibility options during device migrations by allowing customers to execute custom code at time of device migration performed at various times and contexts. This feature has been priceless in recent migrations to allow customers to execute downstream workflow assisting their migration journey goals end to end. Learn more about IMS and explore its powerful migration capabilities today! Read our latest insights on the IMS blog Learn more about IMS and start hassle-free migrations and its capabilities today! On our YouTube Channel Want to speak with an expert? Reach out to us at imssales@microsoft.com to connect with a sales representative. Let’s power the future of digital collaboration — together.Exploring the Extensibility of Active Directory Migration Service (ADMS)
Active Directory Migration Service (ADMS), Active Directory Synchronization Service (ADSS), and Active Directory Group Modernization Service (ADGMS) are cloud-based services within the ADxS services portfolio offered by Microsoft. These services are designed to facilitate efficient and cost-effective migrations. In this article, we will examine the various extensibility options of ADMS, highlighting its key features and advantages.Meet the IMS team
In today’s fast-paced digital landscape, identity migration isn’t just a technical process—it’s a critical step in ensuring business continuity, security, and user satisfaction. That’s where our Identity Migration Service (IMS) comes in. A migration platform offering a seamless, IT-friendly, and end-user-focused experience. But what truly sets us apart? Our dedicated team of experts. These are the people who will guide you every step of the way, making your transition smooth, stress-free, and efficient. From initial configuration to the final migration, meet the specialists who ensure your success. So what's in it for you? When you choose IMS, you gain access to a team of highly skilled professionals who are committed to making your migration journey smooth and successful. They will help you set up the best solution for synchronization, user and workstation migration, application remediation, or group modernization whether for an on-prem AD or Entra ID in Azure. Most IT staff come across a migration project once in their career, for the members of the IMS team it’s their daily work. All that knowledge is put into the IMS migration platform so that the focus is on getting the best solution for your company, not on reinventing the wheel. IMS Identity Consultant Our identity consultant specializes in identity management and security. They work closely with your team to understand your current identity infrastructure and develop a customized synchronization and migration plan that addresses your unique needs. This is done through workshops and subsequent meetings. A few examples are: Do you want to modify any attribute when moving an object from source to target? How to handle users with multiple identities? IMS Portal Consultant The portal consultant focuses on the user self-service experience and underlying interfacing aspects of the migration methods. Just like the Identity consultant, they use workshops to determine your needs and translate those into technical implementations. A few examples are: What language support do you want? Is there a need to run external scripts at the time of migration? Are there any prerequisites you want checked before starting the migration? Any applications that require remediation before, during, or after the migration process? IMS Support Team We know that identity migration is a complex process, which is why we offer a support team that is available during local office hours on weekdays. There is an add-on available if you require support outside local office hours (e.g. If you’re operating globally) with a maximum of 24-hour support during weekdays. Once the Identity and Portal consultant finishes the configuration and you sign off on the acceptance tests, this team is ready to assist you with any issues or questions that may arise, ensuring minimal disruption to your operations. IMS Engineering Team Our engineering team is available to customize the IMS platform to match your specific needs. Whether it's integrating with existing systems or optimizing performance, our engineers can work closely with you to ensure that the IMS platform fits your organization's requirements. IMS Project Manager The project manager oversees the entire project on the IMS side, coordinating the efforts of the IMS team and ensuring that the project stays on track. They are your main point of contact and are connected to the project team on the customer side, providing regular updates and addressing any concerns there may be. Why Choose IMS? The skilled IMS team brings a wealth of experience and expertise to your migration project. By working with us, you can expect: Dedicated team: Staffing is included in the offering, the assigned team will be available to you for the duration of the migration project. Seamless Integration: Our team ensures that your identity migration is smooth and hassle-free, minimizing downtime and disruption to your business. Customized Solutions: We tailor our migration service to meet your specific needs, ensuring that your new identity infrastructure is optimized for your organization. Expert Support: With our skilled worldwide support team and the option to extend the support hours, you can rest assured that help is available when you need it. In conclusion, our Identity Migration Service is more than just a technical solution — it's a partnership with a team of dedicated professionals who are committed to your success. Learn more about IMS and its capabilities today on our YouTube channel or have a look at other articles on the IMS blog. Are you in need of more tailored information? Contact imssales@microsoft.com.ADSS TSync vs Entra Cross-Tenant Sync: A Comprehensive Comparison
When managing identities across multiple tenants, organizations often face a crucial decision: should they choose ADSS (Active Directory Synchronization Service) Tenant Sync or Entra Native Cross-Tenant Sync to enable collaboration across tenants? The ADSS Tenant Sync service for Tenant-to-Tenant Synchronization is designed to maintain a single unified global address list between tenants. It synchronizes and provisions users or contacts between tenants and provisions guest accounts for Azure B2B sharing of applications and resources. Cross-Tenant synchronization automates creating, updating, and deleting Microsoft Entra B2B collaboration users across tenants in an organization. It enables users to access applications and collaborate across tenants, while still allowing the organization to evolve. Both solutions aim to streamline identity management, but they differ significantly in terms of architecture, control, security, and overall functionality. Here’s a closer look at each solution, presented with relatable examples to help you make an informed decision based on your organization’s needs. Architecture and Core Functionality Imagine you are in charge of a large organization with multiple subsidiaries, each operating under its own Azure AD tenant. You need a solution to synchronize all these identities, but you're unsure where to start. ADSS Tenant Sync is a managed service provided by Microsoft Consulting - IMS team, utilizing a pull-push model. Here, synchronization rules are configured by Microsoft Consulting, and the ADSS server manages identity synchronization. This model is often preferred for larger, complex organizations, as it centralizes control and often includes expert support. It’s akin to outsourcing a specific task to a trusted third-party expert who sets up and manages the solution for you. Entra Cross-Tenant Sync, in contrast, is a native feature of Entra ID (formerly Azure AD) that follows a push-based model using SCIM (System for Cross-domain Identity Management). Synchronization happens directly from your source tenant, offering greater control and integration within your existing Microsoft ecosystem. It’s like managing your internal processes with a powerful tool that’s built into your existing system—no need for third-party involvement. Control, Authentication, and Security The level of control and the security measures between these solutions differ, particularly when it comes to permissions and access management. ADSS Tenant Sync requires permissions through Microsoft Graph and Exchange Online, demanding specific admin rights, like Exchange Recipient Admin rights and Write permissions for each object type you want to sync. This can feel like managing a series of security checkpoints where each part of the system requires specific access credentials to function properly. Entra Cross-Tenant Sync, on the other hand, simplifies authentication by allowing synchronization policies to be configured directly within both the source and target tenants. This reduces complexity and can be managed more easily, especially in organizations that prioritize ease of access and streamlined workflows. It’s more like having a universal access pass for various departments within a company, eliminating the need for multiple levels of clearance. Data Management, Synchronization, and Filtering When it comes to data handling, there are key differences in how each solution approaches storage and filtering. ADSS Tenant Sync utilizes a centralized identity store within Microsoft-owned Azure subscriptions before synchronizing data to target tenants. This approach allows for complex attribute filtering and customization, such as syncing users as guests or contacts with desired attribute flows and even supports distribution list synchronization as contacts. It’s like having a centralized warehouse where all the data is stored and categorized, allowing for flexibility when choosing what data to sync and how to manage it. In contrast, Entra Cross-Tenant Sync ensures that identities remain within their respective tenants, with no external storage of sensitive identity data. This model is beneficial for organizations concerned about data privacy, as the identities are kept within their home base. Additionally, Entra Cross-Tenant Sync supports syncing users as either external members or guests, depending on configuration. However, it does not support distribution list or contacts synchronization. It’s like keeping all documents in their respective departments to ensure that sensitive information stays within the correct boundaries. Both solutions support object filtering and attribute-based scoping, but ADSS offers more customization in terms of attribute management, making it more flexible for organizations with intricate requirements. Cost, API Support, and Suitable Use Cases Cost and extensibility are crucial factors when considering which solution to adopt. ADSS Tenant Sync operates as a third-party managed service through Microsoft, with a monthly fee attached. It’s ideal for businesses requiring extensive customization, external guest management, and broader synchronization capabilities. The use of Microsoft Graph and PowerShell APIs for extensibility also makes ADSS suitable for organizations that need advanced integrations and a highly tailored solution. Entra Cross-Tenant Sync, on the other hand, is natively integrated into the Microsoft ecosystem. It requires a P1 license for each synchronized user, but the overall cost can be lower compared to ADSS, especially for organizations that do not need extensive customization. The solution uses proprietary APIs managed by the Microsoft Entra Product team, offering a more straightforward, integrated experience. Entra Cross-Tenant Sync is typically more suitable for organizations that prefer an easy-to-manage, cost-effective synchronization solution, without requiring the advanced features of ADSS. Choosing the Right Solution Both ADSS Tenant Sync and Entra Native Cross-Tenant Sync have distinct advantages, and the decision between them depends on your organization’s specific needs. ADSS Tenant Sync is a solid choice for businesses that need advanced features, such as the ability to customize attributes, manage external guests, and support complex synchronization requirements, even if it comes with an additional cost. It’s more suitable for multi-tenant organizations or those working with business partners that require a more tailored solution. Entra Cross-Tenant Sync is a cost-effective, native option that seamlessly integrates into your existing Microsoft environment. It's ideal for enterprises looking for a simpler, more integrated way to manage multi-tenant synchronization without needing complex customization. This solution works well for organizations that prioritize streamlined workflows and less technical overhead. In conclusion, whether you choose ADSS Tenant Sync or Entra Native Cross-Tenant Sync depends on your organization’s goals, the level of customization required, and budget considerations. Both solutions offer effective ways to synchronize identities across tenants, and understanding these differences will help you select the one that aligns best with your infrastructure and long-term identity management goals. Learn more about IMS and explore its powerful migration capabilities today! Read our latest insights on the IMS blogs page Watch related videos on our YouTube channel for a seamless, hassle-free migration experience. If you would like to discuss in person, reach out to us at imssales@microsoft.com. Our team will connect with you.IMS Efficient Migration Methods
Efficient IMS Migration Methods The Active Directory Migration Service (ADMS), recently renamed Identity Migration Service (IMS), offers the migration of users and workstations across domains and forests. It offers a variety of migration methods that cater to different organizational needs, enhancing the efficiency and flexibility of the migration process. Here's an overview of the functionalities and usage modes of IMS: IMS provides various migration methods, including a unique self-service option with two types: one for corporate network users and another for remote or VPN users. Additionally, ADMS offers admin-automated migrations, user-only migrations, and migrations for workstations shared by multiple users. This blog post will explore the functionalities and usage modes of different migration methods IMS is offering by providing insights into how it streamlines the migration process. 1. Self-Service Migration Method Self-Service Portal Migration: Empowering Users and Streamlining IT Self-Service Portal Migration is an Active Directory Migration Service (ADMS) mode that allows users to initiate their own migration, minimizing the need for IT intervention. This empowers users, such as CFOs, to choose when they want to migrate, rather than having IT dictate the schedule. This method focuses on migrating a single user and their workstation, offering a streamlined and user-friendly experience The self-service approach is designed to be straightforward, granting users the autonomy to decide when to migrate, thereby minimizing potential disruptions if a user doesn't complete their migration within a specified timeframe. Benefits of Self-Service Reduced IT Dependency: One of the most significant advantages of the self-service method is that it reduces the burden on the IT department. Scalability: Customers have reported migrating up to 6,000 users in a week using this method, demonstrating its effectiveness for large-scale migrations. Profile Translation: During a self-service migration, profiles for other users on the same machine are also translated, even if those users haven't migrated yet. Improved Remote User Experience: Remote users often face a different set of challenges than those on the corporate network and ADMS has developed a unique solution to allow the user to migrate over VPN from any remote location. 2. User-Only Bulk Portal Method Streamlining User Migration with the User-Only Bulk Portal The next migration method ADMS offers is The User-Only Bulk Portal which offers a streamlined, admin-driven process for migrating users without their associated workstations. This method focuses solely on user data migration, omitting the local profile and workstation migration steps. It's particularly useful in virtual client scenarios where user profiles don't exist in a traditional sense. Key aspects of this process: Initiation: Admins add users to a designated security group in the source domain to mark them for migration. User Input: Users can be manually entered into the Bulk Portal browser window or uploaded via a text file. Migration Steps: The process involves migrating the user account, copying the SID history, migrating the password hash, and performing SharePoint and Exchange remediation if necessary. 3.Surrogate Method Admin-Driven Workstation and User Profile Migration via Click Once: In many organizations, migrating workstations and user profiles can be a complex undertaking, especially when dealing with multiple Active Directory (AD) accounts and users sharing a single workstation (many-to-one mapping). This method outlines an approach where IT staff members can efficiently perform these migrations using a Click Once application, streamlining the process and minimizing end-user disruption. Scenario: IT-Led Migration for Shared Workstations Imagine a scenario where an IT staff member needs to migrate a workstation and all associated user profiles (who are approved for migration). In this approach, the IT staff members are not migrating their own profile but acting on behalf of the users who share the workstation. They initiate the migration process directly from the workstation, utilizing a Click Once application that provides a user-friendly interface similar to a self-service portal. Benefits of Surrogate Method Simplified Migration: The Click Once application provides a user-friendly interface, simplifying the migration process for IT staff. Centralized Control: IT staff maintain control over the migration process, ensuring that it is performed consistently and according to organizational policies. Reduced End-User Disruption: The migration is performed by IT staff, minimizing disruption to end-users and ensuring a smooth transition to the new environment. Automated Updates: Click Once ensures that the migration tool is always up to date with the latest features and bug fixes. By leveraging admin-driven approach, organizations can streamline workstations and user profile migrations, especially in complex scenarios involving multiple AD accounts and shared workstations. This approach empowers IT staff to efficiently migrate users to new systems, ensuring minimal disruption and a seamless transition. 4. Auto-Migration Method Understanding Auto-Migration in ADMS: Active Directory Migration Services (ADMS) offers several modes of migration to suit different needs. Among these, Auto-Migration stands out as an administrator-initiated process that doesn't require user interaction. What is Auto-Migration? Auto-Migration is set up by an administrator and doesn't need users to do anything. It can be started with a login script, group policy, or software deployment tool, and it can be aimed at either the user, the computer, or both. Even though Auto-Migration is seen as a "push mode" or forced migration, it uses the same self-service migration engine as the other ADMS migration methods. The Four Usage Modes of Auto-Migration: Auto-Migration in ADMS comes with four distinct usage modes, each designed to cater to specific migration scenarios: All Users: This mode targets all users within a specified scope. It's useful when migrating an entire user base from one domain to another in a systematic way. Logged-On User: This mode focuses on the user who is currently logged into a system. It ensures that migration occurs for active users, minimizing disruption. Explicit User: In this mode, administrators can specify users for migration. This is helpful when dealing with specific accounts or when migrations need to be phased. Workstation Only: This mode targets only the workstation. This is helpful when you only want to migrate the computer and not the user profile. By understanding these different modes, administrators can tailor their migration strategy to meet the unique requirements of their Active Directory environment. Conclusion The Identity Migration Service (IMS), formerly known as ADMS, is expanding its functionality to include cloud services. A tenant-to-tenant migration will be released first, followed by functionality to migrate customers from on-premises Active Directory to the cloud. The self-service, opt-in model is currently leveraged in the ADMS product. Learn more about IMS and explore its powerful migration capabilities today! Read our latest insights on the IMS blog Watch related videos on our YouTube channel for a seamless, hassle-free migration experience. If you would like to discuss in person reach out to us at imssales@microsoft.com, Our team will connect with you.
