hello Everyone, i'm having a small issue with my FIM i'm importing data from an SQL DB to my FIM portal and then exporting them to my Active Directory i started by importing my AD already existing objects to my fim portal since the SQL is Precedent i then changed the precedence rules to have it first once my first Active Directory import was done i then exported the SQL data to my FIM portal (the join condition was such that i only had updates to do). the export was flawless i then did a delta import to confirm my export and got a million exported change not reimported errors does anyone have any idea one how to solve this ? thanks Hitch Bardawil

If you click on one of the errors you should get a window that will give you information about which attribute change was not reimported. Check that the value you expect to be there is really there in the destination object. Be aware that sometimes case-sensistivity is an issue. I've seen errors reported sometimes with "Value" and "value" not equating to the same thing. Also, if the values are both empty, make sure one of them doesn't contain a space and the other doesn't or something like that. The purpose of the confirming import is to ensure that the destination object got all the changes FIM expects, so somewhere that isn't happening and once you figure out which attribute is throwing the error, you can trace your logic to find that. (Also: do you have logging enabled on any of the configuration run profiles? If so, I've seen instances when that means the changes don't actually get exported and therefore you get all the exported-change-not-reimported errors.) Hope that helps. Good luck! Sami

Further to Sami's post, the most common problem where AD is concerned is case sensitivity of the DN. Assuming you have a sync rule EAF that constructs a DN from a series of strings and inserted tokens, check that the string constants you are using match EXACTLY with the way distinguished names appear in AD (e.g. CN=xxx,DC=ccc,DC=com vs. cn=xxx,dc=ccc,dc=com)Bob Bradley (FIMBob @ http://thefimteam.com/) ... now using Event Broker 3.0 @ http://www.fimeventbroker.com/ for just-in-time delivery of FIM 2010 policy via the sync engine

Along with case-sensitivity, the thing that usually causes that for me where SQL is concerned is datetime data. The ILM/FIM metaverse doesn't have a datetime attribute type, so it's just a string and that's fairly free-form. SQL has a specific datetime column type, and it converts to/from a very specific string format. If datetime is the problem, on the import side in those errors you should be able to see the format that you need to write your datetime values in on the export side so that SQL doesn't have to "transform" them in any way and FIM doesn't see a change. One other note...the FIM portal does have a datetime attribute format, but it imports to the metaverse in a string format that doesn't exactly match what SQL will send to the metaverse.

thanks for your replys everyone, the attributes i see when i click the error in fim ma are attributes suck as the address, officelocation, country postalcode which are strings! does it mean i should disregard the possiblity of having problems with my dn and date time data ? is the fim error explicit like that ? Hitch Bardawil

Hi Hitch, What values does it show in the "old value" and "new value" columns? You need to check the datasource the MA throwing the errors is connected to and check the value that is in there. Compare that to the value expected by FIM. The error should be on the attributes of address, country, postalcode, etc. (Are any of the attributes making it to the target datasource?) (As a tip: you can highlight the row in the error that has the attribute and value columns and copy and paste it to Notepad. Sometimes that is easier to read.) Thanks, Sami

In the case of string data the kinds of problems I indicated with datetime are probably not relevant. As Sami suggests, you should look to see what is actually in the datasource. Also, when you get one of those errors, in the pane that shows the errors you should be able to click on the connector link or the error link and drill into the details of the error to see what values FIM exported and what it imported. Just to clarify, is it the FIM MA that is throwing the errors? If so, you might want to check to make sure you don't have some kind of workflow running to alter ("clean up") the data and that the synchronization account is granted permission to write those attributes in an MPR. Also, if you were being literal in saying that you had a "million" errors then I have to suspect that you have applied the latest hotfix and configured the portal for a speedier export/load, and I would wonder if the FIM Service is still chewing on all the data you just sent it while you're trying to import it. Check the portal for failed requests, and for requests that are stuck in processing somehow. Find one of the accounts with an error and search for requests related to that account.

it is indeed the FIMMA that's throwing the errors for almost all my users (i have around 5000 of them) for most of my errors if i go into the error's detail i see that the old value and new value are empty here is an example of an error: and the source attributes correspond to the values you see in the imported value field! in the portal i have 0 errors ! all requests complete successfully Hitch Bardawil

Are you running the latest FIM build? Trailing/leading spaces and case-change-only changes were always a cause of the dreaded exported-change-not-reimported warning, until a fim build earlier this year which fixed this.Bob Bradley (FIMBob @ http://thefimteam.com/) ... now using Event Broker 3.0 @ http://www.fimeventbroker.com/ for just-in-time delivery of FIM 2010 policy via the sync engine

version 4.0.3531.2 is that it ?Hitch Bardawil

Check out http://social.technet.microsoft.com/wiki/contents/articles/fim-2010-build-overview.aspx?wa=wsignin1.0 ... this is way too old. You want 4.0.3576.2 The specifics of the changes I'm talking about aren't listed here, but you need to look at the linked pages themselves. Here you go ... search for the string "case" on this link: http://support.microsoft.com/kb/2417774 Bob Bradley (FIMBob @ http://thefimteam.com/) ... now using Event Broker 3.0 @ http://www.fimeventbroker.com/ or just-in-time delivery of FIM 2010 policy via the sync engine

hello Bob, sadly the hotfix did not fix anything i still have the same 5000 exported-change-not-reimported messages however now, it's a warning and not an error anymore and the delta import seem to have completed, what can i do ?Hitch Bardawil

Hitch - I think you might be misinterpreting your results. If the delta import has been obsoleted as you say, then that is the result you are looking for. My expectation is that is the last you will see of the problem ... the warning is just a legacy of the old pending import hologram which shouldn't get regenerated next export/delta-import/sync cycle.Bob Bradley (FIMBob @ http://thefimteam.com/) ... now using Event Broker 3.0 @ http://www.fimeventbroker.com/ for just-in-time delivery of FIM 2010 policy via the sync engine

yes you're right ! it's all gone now :) thanks a lot for the help guyz ! cheers HichamHitch Bardawil

hello Bob, sadly the wrning reappeared for two attributes that i'm exporting to AD whenever i delta import from my FIM MA to confirm changes 2 attributes: office location that i'm exporting to the st active directory attribute and address that i'm exporting to the postaladress attribute recieve the error! the error details show me empty values in the source and destination .... what could cause that ?Hitch Bardawil

hello guyz, sorry to pop up again in this post but the update didn't change anything ! the error dissapeared for a while then i had to start over by deleting my user base and starting over my imports however just now i got the error all over again for all my user base and for so much more attributes! check out the snapshot ! what's weird is that it was working two minutes ago but just for 433 users ! any ideas that could help ?? Hitch Bardawil

Hi Hitch, Looking at the attributes in the screenshot: are there trailing spaced on the postal code? Also, if you change your source data for the DisplayName and the FirstName fields for this user so that the case matches--does that resolve the issue? (You can just try it for this one user. Just as a way to see if the issue is the case sensitivity/non-trimming that the update was supposed to fix.) Also, please be sure you don't have logging enabled for any of the configuration runs. That can put things into a debug state and changes don't get committed. Thanks, Sami

hey sami, well the thing is it was working like 5 minutes before i got these warnings! and i don't have any logging in place ! maybe i missed a run profile ?Hitch Bardawil

Possibly. Or could a data source have undergone an update somehow? (I think I've also seen this if the target data source becomes unavailable during the sync process for some reason. A re-sync usually clears that up.) If you run you syncs from the start, do you still get the errors? Thanks, Sami

yep still there, everytime an attribute has an emty value ! even though i specified to allow nullHitch Bardawil

Do you have any custom rules extensions that are setting the null value? If so, how are you doing that? (i.e. setting to null or going mventry["attribute"].Delete()? If that's not the case: when you do a preview, do you see anything like "Skipped: flow null not allowed". Another option: if you highlight one of the rows from your screenshot and copy and paste it to Notepad, you may see the value has extra spaces. ie: Country,string, ,France instead of Country,string,,France Any of those applicable?

this error gives me that: MobilePhone,string,,,add looks okay to me hmm however i do have custom workflows coded so that i reformat misformated phone numbers: case "cd.person:strMobileNumber->mv.person:mobilePhone" : string mblphn = csentry["strMobileNumber" ].Value; string mblphngood; mblphngood = FormaterText(mblphn); mventry[ "mobilePhone" ].Value = mblphngood; break ; Hitch Bardawil

If you do any kind of reformatting of data exported to the FIM portal before it gets imported again, you are going to get the error that spawned this thread when you import it back into the metaverse. Your choices are either to ignore the error, or avoid it (certainly my preference). It would be better to reformat your data on import from SQL so that it is in the correct format in the metaverse. That way, when you export it to the FIM Service and then re-import it, you don't get the errors. If data is entered in the portal directly and you need to transform it, that wouldn't be a problem because the FIM Sync Service will import it as data that originated from an external source and not have any preconceived notions about how it should look. Chris

well the thing is i did do the reformating in the sql import phase, as an import extention rule void IMASynchronization .MapAttributesForImport( and i'm only having the error when the phone number is empty could there be anything to put in the code to deal with the empty string ?Hitch Bardawil

Sorry, Hitch. I should have gone by what I saw in your code rather than your use of the term "workflow". In the case of empty data, I would either not flow data at all, or even better call the mventry("mobilePhone").Delete() method if it is authoritative for that attribute. That should eliminate the error you've been seeing related to empty values. If there is another potential source for that attribute, then you may want to "Throw New DeclineMappingException" instead. I think allowing the flowing of null would remove an existing value in the destination data source, but I'd want to test it before relying on it. If the FIM MA is also contributing to that value, especially if equal precedence is set on the metaverse attribute, I'd pay special attention in testing to what happened when data that was there was subsequently removed. I have some concerns or confusion regarding the Attribute Recall and Repopulation process where equal precedence is concerned and that could come into play there. (I have my own post about that which sadly hasn't generated any responses and I believe might actually be a bug.)

aha ! okay so i'll use the delete since my only source is my SQL DB! i didn't think it would matter though, i thought that if it's empty it'dd just flow the null value... i'll try that thanks !Hitch Bardawil

There are also options in the SQL MA for converting between empty string and null on import and export in the "Configure Columns" section of the MA properties. Since you're already using a Rules Extension, you can make your own decisions in the code about how to handle it. But if you were using direct flows on any other columns, you'd definitely want to take a look at that as well.

so here's another update on my situation ! i added the exception that deletes empty values from the metaverse, however the weird thing is before i even import things ftom my sql db i populate my portal from my active directory and then on the dela import i get like 30 exported change not reimported errors for any user that's missing a phone number ! in that case i'm not even touching my IAF and AD is authoritive on all attributes !Hitch Bardawil

if the error is coming from FIMMA when exporting values to portal, then it seems that the requests the FIMMA creates for updating the users are failing check the following MPR : Synchronization: Synchronization account controls users it synchronizes on the "target resources" tab, select all attributes in the resource attributes. It's never too late in life ... to start living

no it's when i do a delta import after a successful exportHitch Bardawil

This sounds incredibly weird ... which makes me think that the hotfix update you applied (which you observe hasn't worked for you) is still dealing with the legacy of the previous version bug. Have you tried (a) restarting the FIM box, (b) refreshing the FIM MA schema, and (c) re-entering the credentials of your FIM MA? The reason I say this is that I had this problem myself (as we all did really) and I haven't seen it again since the hotfix. The only other comment I have is more of an FYI ... that it sounds like you've got rules extensions configured (not custom workflows), in which case these will always override any portal-configured sync rules if they apply to the same attribute flows. I only ever use rules extensions now as a last resort, and at an attribute level always take an "all or nothing" approach with attributes involved in rules extensions, as I just figure it's cleaner that way and less likely to expose such issues as this.Bob Bradley (FIMBob @ http://thefimteam.com/) ... now using Event Broker 3.0 @ http://www.fimeventbroker.com/ for just-in-time delivery of FIM 2010 policy via the sync engine

it does! i did restart and refresh the schema and reseted everything i could ! i usually do the same but i'm in a scénario where i need to have a rule extension for a couple of my attributes because the portal did not let me do what i needed to them, having them both seems to work fine though except for those 30 smthng warnings, before the hotfix they were 5000 by the way, now i only have them for those 2 attributes Hitch Bardawil

beside the updating to the latest hotifx as Bob said, I'm kind of sure that the error must something else for the following but have you configured regular expression for these attributes in the portal, maybe it's rejecting the value you are trying to update ...It's never too late in life ... to start living