Unpopulated sync rule “External System Resource Type” drop-down for FIM/MIM Generic LDAP MA

Learnings, MIM Service, Portal

In order to populate the External System Resource Type drop-down on the Create/Edit Synchronization Rule form of the MIM Portal, the client retrieves the ma-data object from the MIM Service using a WCF call. In certain cases (e.g. for General LDAP MAs connected to extensive back-end data sources like Oracle Identity Directories (OIDs)) the object returned can be very large – and if it is in excess of the maximum allowed size of an WCF call (14MB by default) then the call will fail and the External System Resource Type drop-down will be left blank/empty/not populated.

The solution to this is to edit the Portal’s web.config file and increase the limit to something larger (eg. 50MB).

To find the web.config file (usually something like C:\inetpub\wwwroot\wss\VirtualDirectories\80\web.config) run IIS Manager and right-click “Expore” from the MIM Portal site:

Near the end of the file (usually) add maxReceivedmessageSizeInBytes=”52428800″ to the resourceManagementClient element:

An web site or IIS restart is probably be required to active this change!

More info?
https://docs.microsoft.com/en-us/previous-versions/mim/ff800821(v=ws.10)
https://identityunderground.wordpress.com/2014/11/26/new-hotfix-rollup-released-for-fim2010-r2-now-build-4-1-3613-0/

Sharepoint and MIM

Bad, How To, MIM Service, Portal, Sync Service

Installing MIM and all its bits (especially Sharepoint) is SOOO easy… if you get *every* *single* *thing* *right*.  But make even one tiny mistake and you’ll be debugging it for hours.

Here are my self-reminder notes, covering the strange things I’ve found, and the things I seem to get wrong every time:

  • The prerequisites can be installed by a domain admin if that works out easier.
  • Pre-requisite problems?
    • Add-WindowsFeature NET-HTTP-Activation,NET-Non-HTTP-Activ,NET-WCF-Pipe-Activation45,NET-WCF-HTTP-Activation45,Web-Server,Web-WebServer,Web-Common-Http,Web-Static-Content,Web-Default-Doc,Web-Dir-Browsing,Web-Http-Errors,Web-App-Dev,Web-Asp-Net,Web-Asp-Net45,Web-Net-Ext,Web-Net-Ext45,Web-ISAPI-Ext,Web-ISAPI-Filter,Web-Health,Web-Http-Logging,Web-Log-Libraries,Web-Request-Monitor,Web-Http-Tracing,Web-Security,Web-Basic-Auth,Web-Windows-Auth,Web-Filtering,Web-Digest-Auth,Web-Performance,Web-Stat-Compression,Web-Dyn-Compression,Web-Mgmt-Tools,Web-Mgmt-Console,Web-Mgmt-Compat,Web-Metabase,WAS,WAS-Process-Model,WAS-NET-Environment,WAS-Config-APIs,Web-Lgcy-Scripting,Windows-Identity-Foundation,Xps-Viewer -verbose
    • Turn on .NET 3.5 feature
  • Install Sharepoint (and create the farm and CA) as the MIMAdmin user, even if it has to be temporarily made a local admin in order to do so.
  • Get the installers from https://my.visualstudio.com/Downloads
  • Get the license key for testbed installs from https://my.visualstudio.com/ProductKeys
  • MIMAdmin needs sysadmin rights in SQL.
  • When building a single node testbed with ADDS on the same server, remember that “local” group memberships are configured in the Builtin container in AD.
  • Make sure that the MIMSharepoint user has “login as a service” rights.  Then make sure it doesn’t have “DENY login as a service” rights.
  • Always do the post-installation configuration (Farm and Central Admin creation) using a powershell ISE window that is Run As Administrator.
  • Once the permissions and rights issues have all been solved, usually the farm still can’t be created due to persistent rubbish.  Remove Sharepoint altogether, delete the databases, reboot and reinstall it from scratch.
  • After a failed attempt to install the MIM Service + Portal, it’s often necessary to delete and recreate the whole Sharepoint WebApp before trying again.  I’ve even had to resort to uninstalling and reinstalling Sharepoint entirely!
  • This is certainly a weird one – when installing MIM on a domain controller it looks like the MIM Service account needs to have local admin privileges, otherwise MIM Sync cannot impersonate it when connecting to the FIMService database during setup of the MIM Service MA.  It just reports “The credentials provided for accessing Forefront Identity Manager are invalid” in the Forefront Identitity Manager Management Agent event log otherwise.

And here are my helpful scripts for the Sharepoint configuration steps:

Create-SPFarm-example.ps1

Create-MIMPortalSPWebApp-example.ps1

*** This Is A Work In Progress ***

Criteria-based sets and “prior to today” evaluation in the Portal vs the MIM Service

Learnings, Lithnet, MIM Service, Portal, Ugly

So… maybe you have a set like this:

You might wonder exactly what “prior to today” actually means.  Especially when it comes to timezone handling.  And if you’re not wondering that, well you probably should be 🙂

First of all, remember that all your time DateTimes are (or at least should be) stored in UTC inside the MIM Service database.  That’s the sensible approach, and the Portal will format your DateTimes correctly based on the configured timezone if you do.

Anyway, back in the Portal and you’re clicking the “View Member” button.  It’s not hard to work out that “prior to today” seems to actually mean “prior to now” there.  Specifically, the UTC time in your attribute needs to be before the current UTC time.  I’m not specifically sure if that’s the web browser’s UTC time or the server’s UTC time, but in any sensible environment they’ll be the same anyway.

Here’s a quick look at the underlying Filter attribute to get a better understanding of that:

So it’s all about fn:current-dateTime().  Cool.

So far so sensible.  Now we know that temporal sets like this only get re-evaluated when the FIM_MaintainSetsJob runs on the SQL server.  And here’s where the pain sets in – a user with accessExtensionExpiryDate prior to the current time appeared as a member just fine in the Portal, but when I ran the SQL agent job to recalculate my set membership the user object didn’t get added to the set.

After quite a bit of trial and error it appears that the SQL Agent job’s definition of “prior to now” is “before 1AM today in the local server time”.  I can sort-of understand a decision to do the evaluation in local time – at some time someone decided that the job should just do the sensible thing, since “prior to today” inherently needs to know what “today” means, and using local server time is probably what MIM developers want, rather than “today” in the UTC sense.  But the 1am threshold?  That makes basically no sense to me.  I can only guess it’s because FIM_MaintainSetsJob is configured to run at 1am by default.  If that’s the case then hard-coding the definition of “today” to the time when a SQL job runs by default isn’t my idea of sensible programming 🙁

No wonder temporal sets cause headaches!

Addendum: if you really want to see what’s in your Set, LithnetRMA is your friend:

(Search-Resources -XPath "/Set[DisplayName='My Lovely Set']" -AttributesToGet @("ComputedMember")).ComputedMember