Managing proxyAddresses in MIM with MIMWAL: A No-Code Approach

The Business Challenge

If you were to search for “MIM” and “proxyAddresses” in your favorite search engine, you would be inundated with pages of links. Manipulating contact object proxyAddresses with MIM is a  very common challenge. Solutions vary, but many are based on custom rules extension. Conversely, Most client prefer to implement a simpler infrastructure that does not rely on custom code.

In fact, a recent multi-national client came to us to replace a legacy identity management and mail transfer agent (MTA) solution heavily dependent on custom code for transformation and routing rules. The client required a method to manually alter and update proxyAddresses values for destination contact objects while still retaining the original source proxyAddresses attribute values without code.  

The client also required a method provided by their legacy MTA to transform mail addresses and route mail to the appropriate business unit where the end users’ mailbox actually resided.  Again, without code.

For example: Bob Jones of Company A has a primary SMTP address of Bob.Jones@CompanyA.Com. But the legacy MTA may also recognize him as BJones@CompanyB.com or even x500:/O=ExchangeOrgName/OU=NY/cn=Recipients/cn=JonesB. Any user may have from zero to six alternate mail addresses that are not captured as values in the source directory proxyAddresses attribute.

Unleash the Potential of Power Platform With a Center of Excellence

Business innovation often comes from within. Discover how to empower innovation from non-traditional developers with the Microsoft Power Platform.

Learn More

The client needed a method to take the business logic of these legacy systems and translated that solution in a simple, easy-to-understand infrastructure. I was able to meet these business objectives with Microsoft Identity Manager (MIM) and  the MIM Workflow Activity Library (MIMWAL).

Major Data sources of proxyAddresses data

Solution Elements

In short, the implemented solution needed to accomplish the following major objectives.

• Allow admins to manipulate proxyAddresses for destination contact objects while still retaining the original proxyAddresses values at the source.
• Import alternate addresses from the legacy MTA as proxyAddresses values.
• Accomplish both requirements without writing any PowerShell or custom rules extension.

So how do you take up to six new proxyAddresses values and add it to the existing source proxyAddresses multi-value attribute without iterating through these values one-by-one in a custom rules extension?   How do you allow admins to ingest additional values into proxyAddresses?

The solution was surprisingly simple and elegant; requiring no rules extension at all.

• Expanded the schema to introduce two new multi-value attributes: proxyAddressesExtension and ProxyAddressesConcatenated.  
  • ProxyAddressesExtension will be used to import the MTA transformation rules as a file-based MA.  It will also be used in the web portal by admins to ad hoc create alternate proxyAddresses values.
  • ProxyAddressesConcatenated will be used to concatenate both the file-based MA and the AD MA values while still retaining the source AD MA data within the Metaverse.
• Introduce a file-based MA to take the legacy MTA alternate addresses and join on the source mail attribute to the new attribute ProxyAddressesExtension.
• Expose ProxyAddressesExtension in the MIM portal via an RCDC change.
• Using MIMWAL InsertValues and RemoveDpulicates functions, flow a clean ProxyAddressesExtension and ProxyAddressesCollection to the newly created ProxyAddressesConcatenated attribute.
• flow ProxyAddressesConcatenated to the destination contact objects via Outbound Sync Rules.

If this simple solution does not sound all that simple, relax. I will break down each step in detail in the coming weeks.

Watch out for the next chapter: Adding alternate proxyAddresses attributes to the MIM Schema