After you have exhausted all the usual things (e.g. making sure it's not a firewall issue, making sure it's not a SQL login permission issue, etc.) but are still stumped, check the Forefront Identity Manager Management Agent event log (i.e. EventLog --> Applications and Service Logs --> Forefront Identity Manager Management Agent) and see if you are getting an error like the one below:

System: System.UriFormatException: Invalid URI: The format of the URI could not be determined.     
   at System.Uri.CreateThis(String uri, Boolean dontEscape, UriKind uriKind)      
   at MIIS.ManagementAgent.RavenMA.InitializeConnection(XmlNode connectionInformationNode, XmlNode encryptedAttributeNode, Boolean runInitialization)      
   at MIIS.ManagementAgent.RavenMA.UIInitialize(String pszInitString, Int32& pfValid, String& ppszResult)

If you are, then the answer is quite simple -- you can actually see it in the screen shot above if you aren't too distracted by the error message. If you can't see it, let me point it out to you in the screenshot below:

What you have done is neglected to put the FIM Service base address value in the http://<SPN>:5725 notation. Adjusting the value as depicted below will correct your mistake and allow you to proceed:

A groan-worthy, forehead slapping, bonehead mistake? Absolutely, but also a simple and easy one to make if you aren't paying attention, which is why I am putting this debugging tip up for others.

To make this easy, what I do is simply add a tab to the Configuration for User Editing RCDC. The following is the XML that I tend to just paste into it right after the ContactInfo tab and customize as necessary: 

 <my:Grouping my:Name="ServiceCenter" my:Caption="Service Center" my:Enabled="true" my:Visible="true">
 <my:Help my:HelpText="%SYMBOL_ContactInfoTabHelpText_END%" my:Link="01796fb1-c1ab-417c-abe3-41d1907e299a.htm#bkmk_grouping_ContactInfo"/>
 <my:Control my:Name="ResourceCurrentSetPicker1" my:TypeName="UocIdentityPicker" my:Caption="Locked Out Authentication Processes" my:Description="This is a list of the authentication processes out of which the user is locked out (e.g. self-service password reset)" my:RightsLevel="{Binding Source=rights, Path=AuthNWFLockedOut}">
 <my:Properties>
 <my:Property my:Name="Mode" my:Value="MultipleResult"/>
 <my:Property my:Name="ObjectTypes" my:Value="WorkflowDefinition"/>
 <my:Property my:Name="ColumnsToDisplay" my:Value="DisplayName"/>
 <my:Property my:Name="AttributesToSearch" my:Value="DisplayName"/>
 <my:Property my:Name="Value" my:Value="{Binding Source=object, Path=AuthNWFLockedOut, Mode=TwoWay}"/>
 <my:Property my:Name="Filter" my:Value="/Set"/>
 <my:Property my:Name="UsageKeywords" my:Value="ServiceCenterUI"/>
 <my:Property my:Name="ResultObjectType" my:Value="AuthNWFLockedOut"/>
 <my:Property my:Name="SearchOnLoad" my:Value="true"/>
 </my:Properties>
 </my:Control>
 <my:Control my:Name="ResourceCurrentSetPicker2" my:TypeName="UocIdentityPicker" my:Caption="Registered Authentication Processes" my:Description="This is a list of the authentication processes for which the user is registered (e.g. self-service password reset)" my:RightsLevel="{Binding Source=rights, Path=AuthNWFRegistered}">
 <my:Properties>
 <my:Property my:Name="Mode" my:Value="MultipleResult"/>
 <my:Property my:Name="ObjectTypes" my:Value="WorkflowDefinition"/>
 <my:Property my:Name="ColumnsToDisplay" my:Value="DisplayName"/>
 <my:Property my:Name="AttributesToSearch" my:Value="DisplayName"/>
 <my:Property my:Name="Value" my:Value="{Binding Source=object, Path=AuthNWFRegistered, Mode=TwoWay}"/>
 <my:Property my:Name="Filter" my:Value="/Set"/>
 <my:Property my:Name="UsageKeywords" my:Value="ServiceCenterUI"/>
 <my:Property my:Name="ResultObjectType" my:Value="AuthNWFRegistered"/>
 <my:Property my:Name="SearchOnLoad" my:Value="true"/>
 </my:Properties>
 </my:Control>
 </my:Grouping>

Below is what is looks like after you post the updated RCDC

As you can see, this will allow a help / service desk member the ablity to clear self-service password reset registrations and to clear any that have been locked.

Couple of notes:

Regarding the highlighted text, if you have a UsageKeyword that you associated with Help / Service Desk UI resources (and you should organize your UI resources like that), those highlighted values are what you would replace with the UsageKeyword you've created.


Also, be sure you grant those Help/Service Desk users (i.e. set members) the right to read and modify the AuthNWFRegistered and AuthNWFLockedOut attributes of the Password Reset Users set. Otherwise, this won't work.

Good luck!

You've done the usual to verify that everything as it is supposed to be:

1. You verified that the user accounts in the portal have the following attributes populated and are valid:
• Display Name
• Account Name
• Domain
• Object SID
2. You verified that the following MPRs are enabled
• General: Users can read non-administrative configuration resources
• User management: Users can read attributes of their own

But still no luck? Try this. You might have forgotten to check that stupid little checkbox while installing the MIM Portal and Service entitled "Grant authenticated users access to the MIM Portal site"

Under the hood, all that checkbox is doing is ensuring that NT Authority\authenticated users is granted Read permissions to your MIM Portal.

How can you check to see if this is the case? Open up PowerShell and do the run the following:

# Load the SharePoint PowerShell Snap-IN
Add-PSSnapin Microsoft.SharePoint.PowerShell

# Set a reference to the MIM portal website
$MIM = Get-SPWeb -Identity http://[MIM_PORTAL_NAME]/IdentityManagement

# Display the list of users
$MIM.Users

If you don't see NT AUTHORITY\authenticated users in the list that returns, you know that is the issue. Authenticated users have not been given read permission to the MIM portal, which is of course a requirement for them to log into it..

Here is how to fix it

# Load the SharePoint PowerShell Snap-IN
Add-PSSnapin Microsoft.SharePoint.PowerShell

# Set a reference to the MIM portal website
$MIM = Get-SPWeb -Identity http://[MIM_PORTAL_NAME]/IdentityManagement

# Set a reference to the authenticated users
$account = $MIM.EnsureUser("NT AUTHORITY\authenticated users")

# Set a reference to the Read (only) role definition
$role = $MIM.RoleDefinitions["Read"]

# Instantiate a new role assignment object for the authenticated users
$assignment = New-Object Microsoft.SharePoint.SPRoleAssignment($account)
 
# Bind the role to the new role definition
$assignment.RoleDefinitionBindings.Add($role)

# Add the role assignment to the web site.
$MIM.RoleAssignments.Add($assignment)

# Release the reference to the web site for garbage disposal
$MIM.Dispose()

How that helps!

For instance, say that you wanted that whenever an owner of a group was deleted from AD that it would be replaced with a default value (i.e. say for self-service sake).

One could create a Transition-In MPR that whenever a resource enters that set (e.g. an ownerless group), that would trigger an action workflow, that would contain a custom activity that you could write -- or calls an UpdateResource activity from the Workflow Activity Library (WAL) that Microsoft Consultant Services provided you -- but wouldn't it be nice if you could just use the out-of-the-box Function Evaluator? Well, I figured out how you can.

In order to populate the reference attribute, create the workflow with a Function Evaluator activity that points to the desired reference attribute (e.g. [//Target/Owner]); then, for its value, add a String that simply contains the Resource ID of the desired resource (e..g e05d1f1c-3d5e-4014-baa6 -- without the single quotes!) and wallah. That is literally all there is to it.

If you are reading this, likely you are having this problem too and likely it is because in defining the schema of the custom resource type, you included a binding to the Domain attribute. Well, after conferring with the product group, it turns out that whenever you create or update a binding of a resource to a Domain attribute, you must also create a second binding for the DomainConfiguration attribute to that resource type as well. *Woof* Nice for them to make that obvious... 

Anyway, the short of it is: whenever you create (or update) a binding to the Domain attribute, you must also create a DomainConfiguration binding. After doing so, refresh the schema of the FIMMA in the sync engine, run a full import, sync, and export, and celebrate that this nut has been cracked... freeing you up for the next one.

Implementation Steps

1. Login a workstation or server that has Microsoft SQL Server Management Studio installed on it with an account that has administrative rights on the SQL server.
2. Launch SQL Server Management Studio.
3. From the SQL Servicer Management Studio’s Object Explorer tree view on the left, navigate Databases --> FIMService --> Storage --> Full Text Catalogs
4. Right-click on the ftCatalog node under Full Text Catalogs and select Properties. The Full-Text Catalog Properties window will appear.
5. On the Full-Text Catalog Properties window, select the Populate Schedule item from the menu on the left and then click the New button. The New Full-Text Indexing Catalog Schedule dialog will appear.
6. On the New Full-Text Indexing Catalog Schedule dialog, enter in the following values:
   • Name: Nightly Rebuild of Indexes
   • Enabled: checked
   • Schedule Type: Reoccuring
   • Frequency:
   • Occurs: Daily
   • Recurs every: 1 day
   • Daily frequency:
   • Occurs once at: 01:00 AM
   • Duration
   • Start date: (today’s date)
   • No end date: selected
7. On the New Full-Text Indexing Catalog Schedule dialog, click the OK button. The New Full-Text Indexing Catalog Schedule dialog will close.
8. On the Full-Text Catalog Properties window, click the OK button. The Full-Text Catalog Properties window will close.

• Part I - Instructions on how to set up the automate the clearing of the run history on the first of each month.
• Part II - The scheduled task XML file that you can simply import into yoru scheduled task library and turn on
• Part III - The PowerShell script that will the scheduled task will call to clear the logs.

BUT! Before we begin, a special thanks is due to one of the best FIM consultants with whom I have ever had the pleasure of working. His name is Oren Kwiatek and he is the author of the original script detailed in Part III of this post. He has since left Microsoft to form his own Washington DC based consulting firm specializing in FIM and IdM called Intellectix and he can be contacted at oren@intellectix.com

Part I - Instructions:

1. Save the XML document in Part II to a file called FIM Clear History Runs.xml
2. Save the PowerShell document in Part III to a file called FIMClearRuns.ps1
3. Login the FIM Synchronization server with an account that is a member of the Domain Admins security group.
4. Open Windows Explorer and create a new folder called Scripts under the following path: C:\Program Files\Microsoft Forefront Identity Manager\2010\Synchronization Service. (Note: Do not change the location of this folder without also updating the XML file in Part II)
5. Into the previously created folder, copy the following files from the deployment package:
   • FIMClearRuns.ps1
   • FIM Clear History Runs.xml
6. Open the Windows Task Scheduler by navigating, Start --> Administrator Tools --> Task Scheduler.
7. From the tree view on the left of the Task Scheduler, select and then right-click on the Task Scheduler Library entry and select New Folder. In the textbox on the modal dialog that appears, enter in the name FIM Automation and then click the OK button. The dialog will close and the folder will be created.
8. From the tree view on the left of the Task Scheduler, select and then right-click on the newly created FIM Automation folder and select Import Task. An Open File dialog will appear.
9. From the Open File dialog, navigate to the FIM Incremental Sync.xml file located in the following folder: C:\Program Files\Microsoft Forefront Identity Manager\2010\Synchronization Service\Scripts. The Create Task dialog will appear.
10. On the Create Task dialog, click the Change User button and update the service account that should be used to execute the PowerShell file. I recommend the user of the FIM Sync Service account.
11. On the Create Task dialog, click OK button. A dialog will appear to prompt you for the password for the service account specified to run this task. Enter the password for this account and click the OK button. Both dialogs will then close and the scheduled task ought to appear in the list under this folder.

Part II - FIM Clear History Runs.xml 

<?xml version="1.0" encoding="UTF-16"?>
<Task version="1.3" xmlns="http://schemas.microsoft.com/windows/2004/02/mit/task">
  <RegistrationInfo>
    <Date>2013-04-12T12:59:00.5037425</Date>
    <Author>NMIS\karcher_adm</Author>
  </RegistrationInfo>
  <Triggers>
    <CalendarTrigger>
      <StartBoundary>2011-02-28T01:00:00</StartBoundary>
      <Enabled>true</Enabled>
      <ScheduleByMonth>
        <DaysOfMonth>
          <Day>1</Day>
        </DaysOfMonth>
        <Months>
          <January />
          <February />
          <March />
          <April />
          <May />
          <June />
          <July />
          <August />
          <September />
          <October />
          <November />
          <December />
        </Months>
      </ScheduleByMonth>
    </CalendarTrigger>
  </Triggers>
  <Principals>
    <Principal id="Author">
      <UserId>DOMAIN\FIM-SYNC-ACCOUNT</UserId>
      <LogonType>Password</LogonType>
      <RunLevel>HighestAvailable</RunLevel>
    </Principal>
  </Principals>
  <Settings>
    <MultipleInstancesPolicy>IgnoreNew</MultipleInstancesPolicy>
    <DisallowStartIfOnBatteries>false</DisallowStartIfOnBatteries>
    <StopIfGoingOnBatteries>false</StopIfGoingOnBatteries>
    <AllowHardTerminate>true</AllowHardTerminate>
    <StartWhenAvailable>true</StartWhenAvailable>
    <RunOnlyIfNetworkAvailable>false</RunOnlyIfNetworkAvailable>
    <IdleSettings>
      <StopOnIdleEnd>true</StopOnIdleEnd>
      <RestartOnIdle>false</RestartOnIdle>
    </IdleSettings>
    <AllowStartOnDemand>true</AllowStartOnDemand>
    <Enabled>true</Enabled>
    <Hidden>false</Hidden>
    <RunOnlyIfIdle>false</RunOnlyIfIdle>
    <DisallowStartOnRemoteAppSession>false</DisallowStartOnRemoteAppSession>
    <UseUnifiedSchedulingEngine>false</UseUnifiedSchedulingEngine>
    <WakeToRun>false</WakeToRun>
    <ExecutionTimeLimit>PT4H</ExecutionTimeLimit>
    <Priority>7</Priority>
  </Settings>
  <Actions Context="Author">
    <Exec>
      <Command>powershell.exe</Command>
      <Arguments>-command "&amp; 'C:\Program Files\Microsoft Forefront Identity Manager\Scripts\FIMClearRuns.ps1'"</Arguments>
    </Exec>
  </Actions>
</Task>

Part III - FIMClearRuns.ps1

####################################################################################################
# Script Name: FIMClearRuns.ps1
# Author: Oren Kwiatek
# Company: Microsoft Corporation
# Date:  03/24/2011
# Description: Performs a backup of the FIM run history then clears the runs
####################################################################################################

# Define Variables

$filePath = "C:\Program Files\Microsoft Forefront Identity Manager\Logs\Run History"

# Script Logic

$today = Get-Date
[datetime]$clearRunsEndingBefore = $today.ToString("yyyy-MM-01")
$fileName = "Run History for " + $clearRunsEndingBefore.AddDays(-1).ToString("yyyy-MM") + ".log"

if ((Test-Path $filePath) -eq $false)
{
 New-Item $filePath -type Directory
}

New-Item -path $filePath -name $fileName -type File

$runs = Get-WmiObject -Class MIIS_RunHistory -Namespace root/MicrosoftIdentityIntegrationServer

$runs | ForEach-Object {
 $run = $_

 If ([datetime]$run.RunEndTime -lt $clearRunsEndingBefore)
 {
  Write-Host ('Exporting ' + $run.RunEndTime)

  $run.RunDetails().ReturnValue >> $filePath\$fileName
 }
}

$mc = Get-WmiObject MIIS_Server -Namespace 'ROOT\MicrosoftIdentityIntegrationServer'
$inParams = $mc.psbase.GetMethodParameters('ClearRuns')
$inParams.EndingBefore = $clearRunsEndingBefore
$mc.psbase.InvokeMethod('ClearRuns', $inParams, $null)

Import-Module ActiveDirectory

 $total = 1000
 for ($userIndex=0; $userIndex -lt $total; $userIndex++)
 {
  $userID = "{0:0000}" -f ($userIndex + 1)
  $userName = "test.user$userID"

  Write-Host "Creating user" ($userIndex + 1) "of" $total ":" $userName

  New-ADUser `
   -AccountPassword (ConvertTo-SecureString "AAaaAAaa11!!11" -AsPlainText -Force) `
   -City "City" `
   -Company "Company" `
   -Country "US" `
   -Department "Department" `
   -Description ("TEST ACCOUNT " + $userID + ": This user account does not represent a real user and is meant for test purposes only")`
   -DisplayName "Test User ($userID)" `
   -Division "Division" `
   -EmailAddress "$userName@karchworld.local" `
    -EmployeeNumber "$userID" `
   -EmployeeID "ISED$userID" `
   -Enabled $true `
   -Fax "703-555-$userID" `
   -GivenName "Test" `
   -HomePhone "703-556-$userID" `
   -Initials "TU$userID" `
   -MobilePhone "703-557-$userID" `
   -Name "Test User ($userID)" `
   -Office "Office: $userID"`
   -OfficePhone "703-558-$userID" `
   -Organization "Organization" `
   -Path "OU=Users,,DC=KARCHWORLD,DC=LOCAL" `
   -POBox "PO Box $userID"`
   -PostalCode $userID `
   -SamAccountName $userName `
   -State "VA - Virginia" `
   -StreetAddress "$userID Any Street" `
   -Surname "User ($userID)" `
   -Title "Title" `
   -UserPrincipalName "$userName@karchworld.local"
 }

FIM 2010 Kerberos Setup by Thomas Vuylsteke

...What a great piece of IP

This morning, while attempting to create a scheduled task to run my automation script (under the security context of a service account WITH a persisted password), this usually routine effort was thwarted with the following error message when I attempted to save it:

An error has occurred for task [NAME OF SCHEDULED TASK]. Error Message: The following error was reported: A specified logon session does not exist. It may already have been terminated.

What this jibber-jabber is saying is that there is a local policy preventing you from persisting (i.e. storing) the specified service account's password. 

To verify this:

1. Open up your Local Security Policies.
2. Navigate to Security Settings --> Local Policies --> Security Options
3. Open up the policy, Network access: Do not allow storage of passwords and credentials for network authentication
4. If that locally is enabled, you will need to disable it in order to persist the password for your service account.

As usual, if your ability to change it is grayed out otherwise unavailable, you either do not have rights to change the policy or the policy is controlled by GPO. Either way, you will need to disable this policy in order to get past this.

Good luck!