Hey Bob, Not sure what script you are referring to. But I've got the "FIM Object Visualizer" here and what I do is start an elevated prompt and execute the script by using this command: C:\Windows\System32\mshta.exe "C:\FIM\FIM Object Visualizer\FIM Object Visualizer.hta" Then I click "get all objects". And then I wait. I must say that some of the steps seem to time out, but I'd say just be (very) patient. I can view the madata just fine here... Or are you referring to an other visualizer tool? Regards, Thomashttp://setspn.blogspot.com

Thomas - thanks for getting back. Firstly I tried the "get all objects" idea, but got tired of waiting for something to happen once it hit the management agent config scripts (the others all worked steadily through each object set returned, but not this one ... it never even got past 0%). So what I tried was to isolate what it was that was taking so much time, and by altering a copy of the offending PS1 script to accept a single MA name parameter, I found that all my MAs ran through fine ... EXCEPT for the (2) AD MAs. Each of the MAs took only seconds to run, but the AD MAs didn't complete no matter how I tried, and after about an hour (the longest I waited) with nothing coming back, I figured it was never going to. Interestingly the CPU remained busy the whole time, so it wasn't like it wasn't doing SOMETHING ... just nothing particularly useful. So then I simplified the script as much as possible and still got no other result. I figured maybe something was wrong with my MA configuration, so I downloaded the old MIIS Toolkit 2.0 and ran the MA Configuration Viewer - worked no problem. So something in the export-fimconfig step is having incredible difficulty with the ma-data for the AD MA, but I can't imagine what it could be. What to try next do you think?Bob Bradley (FIMBob!) ... now using Event Broker 3.0 @ http://www.unifysolutions.net/ourSolutions.cfm?solution=event for just-in-time delivery of FIM 2010 policy via the sync engine

Very wild guess. perhaps you could add the "messagesize" parameter in the export-fimconfig ? Like this: $user = export-fimconfig -uri $URI ` –onlyBaseResources ` -customconfig $filter ` -MessageSize 9999999 That's an example of how I launch most my export-fimconfig commands. I think I've got that from the config migration guidelines.http://setspn.blogspot.com

Working with the current FIM build I am finding that processing never completes whenever the invoked Visualizer powershell scripts try to read the ma-data for either of my 2 AD management agents. There is no errror I can see in any of the various event logs, and the hang occurs in the export-fimconfig step. The same script runs fine when restricted to any of the non-AD management agents. Can anyone provide me with assistance as to why the AD MA would be any different to any other MA, and/or how to dig deeper into troubleshooting this part of the script? TIABob Bradley (FIMBob!) ... now using Event Broker 3.0 @ http://www.unifysolutions.net/ourSolutions.cfm?solution=event for just-in-time delivery of FIM 2010 policy via the sync engine

Thomas - thanks for the idea, but I still didn't get any joy. I think that there is a time-out happening which might have something to do with a few thousand run histories for this MA, so I've deleted all of them and was about to try again when I realized that the ma-data in the FIM portal didn't seem to have synced lately ... despite restarting both sync server and portal. Do you know how to force a sync of this object given that it bypasses the FIM MA? I am hoping that by getting a successful sync happening on this object it might start to play ball again ...Bob Bradley (FIMBob!) ... now using Event Broker 3.0 @ http://www.unifysolutions.net/ourSolutions.cfm?solution=event for just-in-time delivery of FIM 2010 policy via the sync engine

To force a sync of the ma/mv data there's two ways I think: Script: http://setspn.blogspot.com/2011/06/fim-config-migration-tips-for.html and http://msdn.microsoft.com/en-us/library/ms697764(VS.85).aspx (thanks to Craig Martin!) Double-click FIM MA, choose the DB config tab, fill in the PW of the FIM MA account, click OK, choose yes to refresh schema. This will take some minutes The second option is not the same as right clicking the FIM MA and choosing refresh schema! That will only do a refresh of the schema A MS Support Engineer showed me this way. Whatever option you choose you should see the MA/MVdata creation/deletion requests appear in the FIM Portal request historyhttp://setspn.blogspot.com

After discovering this thread, I am about to try the suggestion akin to re-applying update 1 (at the time of the post). I'm going to try a repair ... I'm on the latest FIM build for everything (4.0.3576.2) Bob Bradley (FIMBob!) ... now using Event Broker 3.0 @ http://www.unifysolutions.net/ourSolutions.cfm?solution=event for just-in-time delivery of FIM 2010 policy via the sync engine

Thanks again Thomas, but I had no joy after adopting the second of your above suggestions. I did, however, find that I was getting an Event 6331 exception in the Application Event log, exactly the same as posted here: http://social.technet.microsoft.com/Forums/pl-PL/ilm2/thread/cf991f2f-05ce-4b25-b0ed-86c3e884c234 http://idamd.blogspot.com/2010/06/ma-attributes-not-listed-in-fim-sync.html In both of the above cases there was no real resolution to the problem (i.e. the underlying cause remains unknown), and the only way of recovering was to either perform a full uninstall/reinstall, or recreate the MA configurations. Before I proceed with the second approach (delete/recreate my 2 AD MAs), I am concerned that this problem is occurring in the first place, and would prefer not to destroy the evidence before I have a better understanding of the cause ... and hopefully get some more help. Here's what I have done so far, with nothing making any difference to the problems experienced: Refreshed the FIM MA schema as suggested by Thomas in his second point above (FIM MA properties/re-enter creds) Tried deleting the 2 ma-data objects (got an Access Denied error) Tried exporting and updating the 2 AD MA configurations, and repeating step 1 Tried increasing the various FIM timeout settings, and repeating step 1 Tried refreshing the schema for the 2 AD MAs, and repeating step 1 When I inspect the FIM request history I can see that all activity appears with a "Completed" status, but interestingly when I refresh the ma-data I continually get the following: 4 out of my 6 MAs appear with a "Delete ma-data: 'xxx MA' Request" (the 2 that don't being the 2 offending AD MAs); but 6 out of my 6 MAs appear with a "Create ma-data: 'xxx MA' Request" The export-fimconfig commandlet continues to run indefinitely without returning any results. Any more ideas? Bob Bradley (FIMBob!) ... now using Event Broker 3.0 @ http://www.unifysolutions.net/ourSolutions.cfm?solution=event for just-in-time delivery of FIM 2010 policy via the sync engine

I currently have a case open with PSS for the event ID 6331 thingy. In my case it's referencing the "cleanup MA" operation for the "FIM MA". I've found a workaround to this error is to delete the FIM MA and re-import. I've done this 2 times. 3th time we logged a case with PSS. Hope to get an answer for this nasty error.http://setspn.blogspot.com

Thanks Thomas - any chance you could send me the PSS case number so I can add weight to this? I think we realized tonight that we are now at the point of having to open one of these ourselves, having completely uninstalled all FIM components, reinstalled (to brand new databases), and reimported schema, policy and sync config, then triggered the ma-data refresh and STILL got a 6331 :(Bob Bradley (FIMBob!) ... now using Event Broker 3.0 @ http://www.unifysolutions.net/ourSolutions.cfm?solution=event for just-in-time delivery of FIM 2010 policy via the sync engine

This sounds similar to an issue I had during a migration from a dev to test instance. When I imported the sync config, the ma-data for the MA's was missing, leading to an issue importing the policy since it couldn't find the portal ma-data entry for sync rules. After several re-loads of the MA's and nothing appearing, I ended up opening a PSS case. It was a known issue requiring a database update, so it's a procedure that PSS will only support with their assiatance, since the actual db fix varies depending on your configuration. -Frank

Thanks Frank - were you intending to reply to this thread, or my other one from today which I think is related? Either way, I think we're onto something here ... and a PSS ticket has now been raised.Bob Bradley (FIMBob!) ... now using Event Broker 3.0 @ http://www.unifysolutions.net/ourSolutions.cfm?solution=event for just-in-time delivery of FIM 2010 policy via the sync engine

Bob, got an email address where I can contact you? My case is currently on hold as I am on vacation. The conclusion for now is that it's harmless. However I think if I would be using this environment as a target for a configuration migration I'll be having troubles. So I'll go forward and see how the migration runs.http://setspn.blogspot.com

Thanks Thomas ... please use this one and just kill the .removeme bit :) CheersBob Bradley (FIMBob!) ... now using Event Broker 3.0 @ http://www.unifysolutions.net/ourSolutions.cfm?solution=event for just-in-time delivery of FIM 2010 policy via the sync engine

I am facing the same issue on a fresh installation of FIM, with the MAs coming from a configuration migration (following the official guide & using the provided scripts). In my case, the environment is a fresh install that was updated directly from RTM to KB2502631/build 4.0.3576.2, bypassing Update 1. Sync Engine & Service are at the same build. The theory I will test next is that I may be importing an unhealthy FIM MA from the "pilot" environment. As I have 3rd environment that works perfectly I will reinstall & migrate from the "good pilot".

The PSS call that was raised for this problem has now been closed ... the 6331 events have not stopped, but I am happy that in my case they can be ignored, and that the issues I have been facing (problems with the PS1 scripts extracting the ma-data for my AD MA) while still annoying are at least manageable. The Object Visualizer PS1 "Management Agents" scripts (and others which pull the same data) don't actually time out ... but in my case take over an hour to complete (I never waited that long originally!). Here's an extract from Steve Klem's report before the case was closed, in which he explains what actually happens when you re-enter your credentials for the FIM MA (and save): The synchronization service enumerates all of the ma-data objects in the FIMService. It then methodically deletes these objects. If the FIM Service MA ma-data object is deleted before any of the other ma-data objects, this will trigger a cascading delete of all other ma-data objects. When the sync engine cannot delete the ma-data objects it thinks should still exist, it fails because the objects do not exist. It then throws the error. Fortunately, this does not stop the ma-data objects from being created, so the error can be ignored as long as the ma-data objects are created successfully.Bob Bradley (FIMBob @ http://thefimteam.com/) ... now using Event Broker 3.0 @ http://www.unifysolutions.net/ourSolutions.cfm?solution=event for just-in-time delivery of FIM 2010 policy via the sync engine