Azure IAM Maps MIM PowerShell Management Agents To SailPoint Connectors

Azure IAM, LLC explains what replaces a custom Microsoft Identity Manager PowerShell management agent in SailPoint IdentityIQ: which connector takes over for each kind of target, where the PowerShell survives, and what the migration tooling converts versus what needs a scoping decision.

Las Cruces, United States, October 13, 2026 /NewsNetwork/ -- Teams planning a Microsoft Identity Manager (MIM) to SailPoint IdentityIQ migration tend to hit the same wall when they inventory their management agents: at least one of them is a PowerShell agent that somebody wrote years ago to reach a system no packaged connector covered. The question that follows is what replaces a custom MIM PowerShell management agent in SailPoint. Azure IAM, LLC, an independent identity consulting firm, says the answer starts with a reframe. The PowerShell agent was never the integration. It was a shim in front of one, and the scripts behind it tell the migration team exactly which IdentityIQ connector should take over. The firm documents its MIM to SailPoint method at https://azureiam.com/mim-to-sailpoint.

MIM offers two ways to build a PowerShell agent. Microsoft's own Windows PowerShell Connector, built on the ECMA2 framework, stores its schema, import, export, and password scripts inside the Synchronization Service configuration. The community Granfeldt PowerShell Management Agent, open sourced on GitHub, points at Schema, Import, Export, and Password script files on the sync server. In both cases the scripts do four jobs: declare the object types and attributes, read accounts from the target, write pending exports to the target, and optionally set passwords. Everything else, attribute flows, join rules, and run profiles, is ordinary MIM configuration.

That split matters for migration. IdentityIQ has no PowerShell management agent type and does not need one. It needs an Application object with a schema, a correlation configuration, and a connector that can aggregate and provision against the real target. Azure IAM sorts PowerShell agents by what their scripts talk to, which usually lands in one of five places.

The target already has a packaged connector. Many PowerShell agents predate a vendor connector or the license for it: Entra ID, Exchange Online, ServiceNow, Workday, Salesforce, Google Workspace. IdentityIQ ships connectors for these, so the PowerShell layer is retired and the Application points at the packaged connector.

The target is a REST or SOAP API. The IdentityIQ Web Services connector handles account and group aggregation with pagination, plus create, update, enable, disable, delete, and password operations, each defined as an HTTP operation with response mapping and optional BeanShell before and after operation rules. Most Invoke-RestMethod scripts translate here.

The target is a database. Scripts that read and write tables map to the JDBC connector, with a BeanShell provisioning rule for writes that need more than a single statement.

The target is a file drop. Import-only CSV agents become a Delimited File application for aggregation. If the agent also wrote a file for another system to pick up, that export is a provisioning decision, not a connector setting.

The target is Windows itself. Scripts that create mailboxes, home folders, or run Exchange cmdlets after an Active Directory account exists survive as PowerShell. IdentityIQ runs them on the IQService host through the Active Directory connector's native rules, such as ConnectorAfterCreate and ConnectorBeforeModify, so the script is relocated rather than rewritten.

When none of the five fit, the remaining option is a custom connector built with the IdentityIQ connector SDK in Java. Azure IAM treats that as the last resort and scopes it as new build.

Azure IAM's conversion starts from a MIM Configuration Documenter report. Every management agent in that report becomes an IdentityIQ Application, with the schema derived from the agent's object types and attributes, correlation derived from its join rules, and credentials replaced by placeholder tokens. For a PowerShell agent, the application shell, schema, and correlation come from the agent definition. The connector type behind it is chosen in scoping, from the scripts, because script bodies are code rather than synchronization configuration and the conversion refuses to guess what code does. Attribute flows that referenced the agent still convert to identity attribute sources and provisioning templates.

Equivalence is proven in a parallel run. MIM remains the only system provisioning to the target. IdentityIQ aggregates from the same target through its new connector and computes the provisioning it would send, and the two are compared until accounts, attribute values, and planned changes match. For an agent that only imports, aggregation parity is the whole test. For one that exports, the computed provisioning plans are checked against what MIM's pending exports would have done.

Microsoft's extended support for MIM 2016 SP2 runs through January 10, 2029. Organizations that host the MIM Portal on SharePoint Server 2019 face an earlier constraint, because SharePoint Server 2019 reached end of support on July 14, 2026.

Organizations still running custom PowerShell management agents can book a scoping call with Azure IAM at https://azureiam.com/contact. The call inventories every custom agent, names the IdentityIQ connector that replaces each one, and leads to a fixed fee migration quote.

Contact Info:
Name: Robin Lilly
Email: Send Email
Organization: Azure IAM, LLC
Address: 2521 North Main Unit 1-276, Las Cruces, New Mexico 88001, United States
Website: https://azureiam.com

Source: NewsNetwork

Release ID: 89205974

If there are any deficiencies, problems, or concerns regarding the information presented in this press release that require attention or if you need assistance with a press release takedown, we encourage you to notify us without delay at [email protected] (it is important to note that this email is the authorized channel for such matters, sending multiple emails to multiple addresses does not necessarily help expedite your request). Our diligent team is committed to promptly addressing your concerns within 8 hours and taking necessary actions to rectify any identified issues or facilitate the removal process. Providing accurate and trustworthy information is of utmost importance.