Hi all, This does not relate to the portal functionality, as we are only running the synchronisation engine. I'm running into some dramas that I suspect (but don't know) come from FIM possibly not caring about the case of a string when comparing a submitted change via a MA custom export rule (if appearances count for anything). In Exchange, the primary SMTP address within the proxyAddresses attribute is denoted with a SMTP: prefix, while the remaining addresses are prefixed with the lowercase version of smtp:. When I endeavour to change this value in the CS through the advanced attribute flow code, the value slated for export is simply not acknowledged by the synchronisation process. The case of the SMTP component of the string is exactly as it was prior to the code running - meaning that there is nothing to export, though I have verified the correct case version is being applied to the multi-valued string list. To resolve this, should I look at removing this attribute before re-adding it as a multi-valued binary type, or should I just resort to not bothering to use FIM to maintain the proxyAddresses field at all and use code to modify AD directly? Cheers, Lain

Hi Lain, I did exactly that. I just used a for next loop to do it... For Each proxyAddress In csentry("proxyAddresses").Values.ToStringArray If proxyAddress.StartsWith("SMTP") Then newProxyAddresses.Remove(proxyAddress) newProxyAddresses.Add(proxyAddress.ToLower) End If Next Anyway, hope this is helpful as it works for my requirements... but the add and remove is present in the code as you suggested... Thanks B

Hi Blain, Thanks for the reply. I'll post my code below, but what is interesting is we're approaching it in a similar fashion. The only real difference is that I've decided not to completely reconstruct the proxyAddresses field, instead choosing to pull just the current primary address and potential replacement and add those back in with the correct SMTP prefix. The alternative to what I've got below is that I stop working with the proxyAddresses in FIM altogether and edit the Active Directory account directly, which although it's an easy option to exploit, I'd prefer to keep as much in FIM as possible. Anyway, here's the code (below). Cheers, Lain Case "exportAdStaff_legacyMail" If mventry("msExchRecipientTypeDetails").IsPresent And _ mventry("ldapMail").IsPresent And _ mventry("proxyAddresses").IsPresent And mventry("email").IsPresent Then If (mventry("msExchRecipientTypeDetails").IntegerValue = 1) And (Not mventry("proxyAddresses").Values.Contains(mventry("ldapMail").Value.ToLower)) Then csentry("proxyAddresses").Values.Add("smtp:" & mventry("ldapMail").Value.ToLower) End If For Each mailAddress In mventry("proxyAddresses").Values If mailAddress.ToString.Substring(0, 5) = "SMTP:" Then csentry("proxyAddresses").Values.Remove(mailAddress.ToString) csentry("proxyAddresses").Values.Remove("smtp:" & mventry("email").Value) csentry("proxyAddresses").Values.Add("SMTP:" & mventry("email").Value) If mailAddress.ToString.Substring(5).ToLower <> mventry("email").Value.ToLower Then csentry("proxyAddresses").Values.Add(mailAddress.ToString.ToLower) End If Exit For End If Next End If

Note that if set email addresses with attribute flow you can end up with duplicate email addresses if you are not careful. (More then one person has the same SMTP address.) If this occurs you will not get an error and inbound mail to that address will silently fail. Last time I had to do this, I ended up using PowerShell commands from a custom MA to maintain SMTP addresses. If you use the PowerShell interface to Exchange, you will get duplicate smtp address detection and you can catch the errors as they happen. For more details check out this thread: http://social.technet.microsoft.com/Forums/en/ilm2/thread/2e28be9b-e617-4b1e-b86a-d3614cc03277

Thanks Rex. At the moment the constraint checking for e-mail address uniqueness is handled prior to the data being presented to FIM, but I take your point. I'll certainly handle that should the scenario become a possibility. At the moment I'm trying a slightly different version of the same routine I had above that involves clearing the csentry("proxyAddresses") with the Clear method and rebuilding it based on the mventry values for proxyAddress and email. Technically, it shouldn't make any difference as the end result is the same, but I'm hoping that the problem is in the implementation and that using a different method pays off. I'm just playing the waiting game now while I wait for an existing user to be renamed. Cheers, Lain