Dear Community, when exporting to FIM it seems that CRLF are changed somehow so that kind of ping-pong effect might occur between MV and FIM. Any suggestions to this? I already thought about either getting rid of all them in the external systems or write custom sync rules to filter them on the way to MV (but I would have to enable that for all string attributes...) Thanks, Rainer

This is a known issue and a fix to it is in the process of being developed. Cheers, MarkusMarkus Vilcinskas, Knowledge Engineer, Microsoft Corporation

Hi Markus, Is there any update on this issue? Is there a hotfix from PSS available? Thanks, Curt

Yes, you can get it from PSS. Cheers, MarkusMarkus Vilcinskas, Knowledge Engineer, Microsoft Corporation

Any idea of the KB number for this hotfix? Is it included in the update to 4.0.3573.2 (http://support.microsoft.com/kb/2417774)? Keith

Yep. Cheers, MarkusMarkus Vilcinskas, Knowledge Engineer, Microsoft Corporation

Hmm, I am at 4.0.3573.2 and I still get the issue when exporting to the portal. In my case I am concatenating two address values and sending it to street in the metaverse (no issues), and then exporting street from the MV to Street in the portal. address1+CRLF()+address2->streetKeith

Hey guys, I also have installed the last KB (4.0.3573.2) but still get the exported-change-not-reimported error on any export I run (I tried with FIMMA and ADLS MA)... It seems to occur only when i try to confirm the export of an empty string. Is this supposed to be fixed by this KB ?? Thanks ! Laurent

I was having the same issue after 3576 so we did this using the quest powershell for AD snap-in: $user = Get-QADUser -SizeLimit 0 ForEach ($note in $User) { if ($note.Notes -ne $null) { $usernote = Get-QADuser -Identity $note.DN $usernote.Notes $newnotes = [regex]::Replace($usernote.Notes, "`n", " / ", "Singleline") $newnotes = [regex]::Replace($newnotes, "`r", "", "Singleline") Write-host "NewNotes: " $note.Email $newnotes Set-QADUser -Identity $note.DN -Notes $newnotes } }

Interesting workaround. It would be better if the issue were actually resolved though.Keith

True. We cannot wait that long! :)

Hi guys, I'm getting the exact same issue because the streetAddress attribute because it contains CRLF.. Have update KB (4.0.3573.2) installed as well... Any ideas if Microsoft is going to really fix this?

Hello everyone - After wrestling with this for for a few days, I found a solution that works for me. My issue was that in the AD field "info" we've got a bunch of data to be displayed on a groups form - not to be edited, just displayed. Same issue, the sync from AD -> MV -> FIM Portal works, but the verification between FIM -> MV gets the dreaded "export-change-not-reimported", as some of the data has CRLF in it. My ADMA is a Sync Rule, and the field in both AD and the MV is called "info". I created a CustomExpression on the import for that field that looks like this: CustomExpression(ReplaceString(info,CRLF()," | ")) => info which pulls single and double CRLF characters from my data and replaces it with a " | " string. This works just fine because I'm displaying the data on a form, and this is rather human-readable. But most of all, I don't get the reimport error when syncing as the CRLF characters have been stripped out. It was driving me batty. regards, Ken

Nice. This got me thinking, if you had the double CRLFs coming back (which is what i seem to have), could you replace them both with "|" and then replace "||" with a single CRLF on the import flow? So something like this: CustomExpression(ReplaceString(ReplaceString(info,CRLF(),"|"),"||",CRLF())) => infoKeith

This is still not fixed in 4.0.3576.2...

Ran into this error. My workaround was to replace the Windows newline (CRLF) with just LF. A bit hacky but it seems to make the error go away. It's all these little issues that remain unresolved that really makes this product so frustrating. if (csentry["info"].IsPresent) mventry["notes"].Value = csentry["info"].Value.Trim().Replace("\r\n", "\n"); else mventry["notes"].Values.Clear();

This is still an issue in 4.0.3594.2. Markus, do you know why this is still around? Cheers!Paul N Smith