This one is really confusing, as the intended behaviour and config is really simple... In one one; an expression for an export attribute flow is not always flowing the expected data. We've got a system, that has an attribute called userPrincipleName (not to be confused with the familiar, AD one), which is flowed out using an expression: "DOMAIN/" + accountName So, a value like "DOMAIN/joebloggs" is expected. For some users, this is true, but we're seeing cases where values like this joebloggs@DOMAIN.LOCAL are being exported. I have no idea where this value could be coming from. There's no classic attribute flows on the MA, and accountName always contains a simple account name, like "joegbloggs". When I do a preview on such an object, I see the following: We're running RTM, but I don't see anything in the Update1, or hot-fix notes, that suggest this would be fixed by any FIM updates. Does anyone have any ideas? It seems that FIM is just getting it wrong. I'll have to open a pss ticket if not, or create a rules extension :-/

The joebloggs@domain.local smells very AD-ish. You don't happen to have an AD MA with an inbound attribute flow configured from userPrincipalName -> userPrincipalName? If this AD MA would have a higher attribute precedence then your target MA, that would explain why your is sometimes not working as expected; if no value was contributed by the AD MA: rule works as expected if a value was contributed by the AD MA: AD MA wins and exports joebloggs@domain.local If I need to explain further... Gl!http://setspn.blogspot.com

Thanks Thomas, I've since worked it out, but it's still odd: This is to an XMA, not AD. The data in traditional upn format we see, is actually what's in that connected system, i.e. on full import, it comes back as joebloggs@domain.local, but there is actually a restriction in what the system can receive on export, i.e. it must be in DOMAIN/joebloggs. This is clearly idiosyncratic. So, an investigation, and discussion will now take place here, to find out why there's this disconnect between import and export values. BUT! I must be missing something in terms of attribute precedence.. By my understanding, the export sync rule, and its expression cannot have attribute precedence applied to it, so I would expect its value to always be sent to the connected system, but it's not, the original connector-space value is left unaltered. Why?

BUT! I must be missing something in terms of attribute precedence.. By my understanding, the export sync rule, and its expression cannot have attribute precedence applied to it, so I would expect its value to always be sent to the connected system, but it's not, the original connector-space value is left unaltered. Why? Attribute flow precedence is also applied on the outbound side. The MV can't flow a an attribute value that was contributed with a lower precedence out to a CS with a higher precedence. This is by design. Cheers, MarkusMarkus Vilcinskas, Knowledge Engineer, Microsoft Corporation