A colleague forwarded this onto me and I think it’s worth sharing – since leaving Microsoft, Andreas Kjellman has been writing up some of the ‘undocumented’ aspects of the ECMA2 and it’s absolute gold.
The site is here:
http://www.theundocumentedsyncengine.com/content/home.html
And let’s hope that there’s more information like this still to come!
Or when FIM Filters go bad…
I’m currently taking a new project into production for the first time, and was a bit confused when the Sets being uploaded started failing with the FIPS error above – especially as I don’t quite understand how FIPS was being invoked for anything to do with this solution.
Fortunately this turns out to be the message thrown by MIM when a set that doesn’t meet the allowed filter criteria is uploaded – in development I’d disabled the MPRs that enforce the filter checks and it looks like when I’ve been performing the configuration upload that these sets were encountered before the updated MPR was.
Panic over as at least it’s possible to pre-emptively update (disable) the ‘General workflow: filter attribute validation for administrator’ and ‘non-administrator’ MPR and a re-import went in smoothly.
I’ve recently rebuilt a development environment – replacing my older Windows 2008 FIM R2 rig with a Windows 2012 MIM and hit an odd problem when trying to trigger the just in time debugger from within my code.
Normally to debug one of my tools, I just set a label at run time and the debugger is automatically triggered using System.Diagnostics.Debugger.Launch(); – however in the new environment the debugger never appears and in the event log I see an error message warning me that “Just-In-Time debugging this exception failed with the following error: The operation attempted is not supported.”
After doing some digging about, it appears that this is actually a security feature introduced after Windows 2008 – fortunately though, it can be turned off by updating the registry and I’ve found that setting HKEY_CLASSES_ROOT\AppID\{E62A7A31-6025-408E-87F6-81AEB0DC9347}\AppIDFlags to a value of 0x08 seems to do the trick and debugging is restored.
more background to why the feature was introduced here: http://stackoverflow.com/questions/11940378/vsjitdebugger-operation-attempted-is-not-supported-on-windows-8-windows-server
I have an established MIM server that I’m currently developing on that started to throw ‘Unable to process your request’ errors whenever I attempted to move away from the initial landing tab of any RCDC – including the “System” ones such as those for MPR and Sets.
Looking into the event log on the Portal server it looked like there was a clear issue as:
It turns out that I’d managed to fill the transaction log for the MIM Service database and this was causing the whole service to misbehave – working through the suggestions here: https://msdn.microsoft.com/en-ie/library/ms175495.aspx
I was able to reduce the size of the transaction log and free space allowing MIM to breath – or at least start to behave itself again and normal MIM operation resuming once SQL had enough space to work again.
Update – A copy of this session is available on YouTube – https://www.youtube.com/watch?v=-TaTvfbgBJQ
The FIM Team have organized a briefing and Demo about MIMWAL for Februarys session – should make for an interesting demo and discussion.
From – https://www.thefimteam.com/fim-team-user-group/
Date:
10th February 2016, 20:00 UTC
See when this is in your timezone
Presenter:
Jef Kazimer (Microsoft)
Topic:
Demonstration of the MIM/FIM Workflow Activity Library (WAL) which has now been made availbel, by Microsoft, as open source project on GitHub.
The MIMWAL is a powerful solution accelerator for MIM / FIM that provides foundational activities which can be combined to create complex workflows to implement business processes within a MIM / FIM solution simply by configuration instead of coding. Microsoft Consoluting Services have been using this library for years and now the latest version has been made available for anyone to use.
Microsoft have released their FIMWAL / MIMWAL “Workflow Activity Library” for building advanced workflows within FIM / FIM.
Code and more details can be located here:
http://microsoft.github.io/MIMWAL/
If you’re at all interested in creating advanced workflows however it’s going to be worth a look.
I’m currently debugging some custom workflow activities and updating the logging code so it produces more useful information (apparently my ‘development’ error codes aren’t human readable enough!) and noticed that I was getting lots of ‘KeyNotFound’ exceptions in the event log.
Microsoft.ResourceManagement.WebServices.Exceptions.UnwillingToPerformException: Other —> System.Collections.Generic.KeyNotFoundException: The given key was not present in the dictionary.
After much digging through my code I spotted that this was actually being generated whenever I read from FIM in the Portal and while it was a relief to know that my workflow code was off the hook I didn’t really want to leave this in place and cluttering up the eventlog.
It looks like this was introduced during one of the hotfix releases (4.1.3496 is mentioned in the article I’ve linked to below) when additional Portal configuration was introduced to allow the Advanced Search option to be turned off – this means that my local FIM installation was actually attempting to locate an attribute on the Portal Configuration that I didn’t have in my schema which was the cause of the KeyNotFound exceptions I was finding.
The steps to fix is are fairly simple as follows (Steps taken from the referenced documents – not my own work – see below for links)
To enable the configuration and remove the Advanced Search link, follow these steps:
Once I had this implemented and FIM restarted the errors were removed and I was left with the exceptions of my own making again – yay I think!
Links for the above are to:
KB Article –https://support.microsoft.com/en-us/kb/2906832/en-us
Sometimes FIM strikes me as being way to clever for its own (and usually my) good – and I’ve been looking into a problem for a client that ticks this box big time.
They have a number of email notifications that they need to generate that instruct various parties within the organization about people joining, moving and leaving so that the processes that they can’t or don’t want to automate can be initiated based on the data held by FIM – in this scenario, a leavers email is sent to HR letting them know when a contractor has reached their leaving date.
This works fairly well for six months out of every year – during the daylight savings months, the email is issued the day before its supposed to go out, and the HR department being highly efficient are carrying out the required action when they see the email leading to all sorts of downstream mayhem trying to clean up after the event.
Naturally, focus fell on a custom workflow that is used to generate these emails and after spending an amount of time pulling apart the code it occurred to me that nothing in the workflow could actually be causing this and it was the user account transitioning into the temporal set that was executing a day early (obvious in hindsight 
) – seeing as I had visual studio hooked up to the workflow, I moved a few more users about and it turned out that even though their leaving date was set correctly – e..g 03/06/2015 – FIM was transposing this in the background and storing it as 02/06/2015 23:00.
What it appears is that when FIM is presented with a date, it’s transposing it into UTC for internal storage and as during June GMT (the configured time zone for the solution) is +1 hour compared to UTC, it’s removing the hour and bringing the user’s leaving date forward into the previous day – allowing it to trigger the removal notification effectively 24 hours early.
Fortunately as FIM is using its configured time zone to work this out, it’s a fairly simple case (in this instance!) to create a new UTC TimeZone object and then configure FIM to use this instead of the previous GMT one although this probably isn’t going to be a fix in all instances!
I’m currently working on some tools to upload portal elements and have been struggling with uploaded Homepage Configuration items – they upload, but they don’t display.
Turns out that the IsConfigurationType flag needs to be set otherwise the Homepage item doesn’t display – simple when you know… (as usual)
Note – IsConfigurationType doesn’t appear on the standard RCDC, you need to go into advanced view to be able to see / update it (doesn’t really help if you’re troubleshooting and can’t see an obvious difference between one Homepage item that displays and another that doesn’t!)
Note – looks like there’s similar behaviour on Navigation Bar Items as well – at least it’s consistent!
