So let me give you an example of how I was able to put this to use in my environment.

As I was troubleshooting some provisioning issues in a lab environment today, I determined that I need to delete the objects from Active Directory so the provisioning code could be executed again.  From a PowerShell perspective all I really needed was the DN of the user object to pipe to the Remove-ADUser cmdlet.  Since all of the information is available in the error data, you just need to have a method for getting to it (this is where CSExport comes in).

CSExport will allow you to get to all of this data and dump it to an XML where you can then consume it with PowerShell in a pretty quick fashion!

For more info on the usage for the utility see the link below.

https://technet.microsoft.com/en-us/library/jj590346(v=ws.10).aspx

In my case, I had all of the export errors and just need to dump the data to an XML.  So I started by opening a command prompt (or PowerShell prompt) and navigating to the C:\Program Files\Microsoft Forefront Identity Manager\2010\Synchronization\Bin folder and launching the CSExport utility.

To dump the data I used the command below.

.\CSExport.exe "ADMA" errorList.xml /fe

This actually gives an output XML file with all of the connector space information needed to feed to the AD cmdlet.

From here I was able to read the content of the file in using the following PowerShell command.

[xml]$CSErrorObjects = get-content .\errorList.xml

Now I have all of the information I need to work with, the next step is to select the XML nodes for consumption by PowerShell.

$csObjects = $CSErrorObjects.SelectNodes("/cs-objects/cs-object")

At this point all I need to do is loop through the collection and execute the command!

$csObjects | foreach-object {remove-aduser $_.'cs-dn' -confirm:$false}

As you can see this simple utility gives a great deal of flexibility for pulling information out of the connector spaces to take action on especially if you are running into errors that can be remediate in bulk.

Enjoy!

The product group at Microsoft released 3 new connectors for FIM, I would definitely recommend taking a look.

Windows Azure Active Directory
Connector can be used in scenarios not supported by DirSync, for example multi-forest or non-AD. We still recommend to use DirSync as the primary solution to synchronize AD to AAD and use it whenever possible. The Connector comes with sample code and configuration for a resource/account-forest scenario. For more information, please refer to the TechNet documentation: https://go.microsoft.com/fwlink/?LinkID=330371.

Generic LDAP
Connector will allow you to connect to an LDAPv3 compliant directory. It currently supports the same LDAP directories (IBM, Novell, and Oracle) we ship with FIM2010R2 and will over time replace the built-in LDAP Management Agents. For more information, please refer to the TechNet documentation: https://go.microsoft.com/fwlink/?LinkID=270179.

SharePoint User Profile Store
Connector will connect to the SharePoint User Profile Store and can be used as a replacement for the built-in synchronization engine which comes with SharePoint, for example in mulit-forest or non-AD scenarios. For more information, please refer to the TechNet documentation: https://go.microsoft.com/fwlink/?LinkID=331344.

The challenge in my case was allowing users which are required to login using SmartCards to register for SSPR. The benefit of SSPR in this case is not really the ability to reset a password, but the ability to unlock an account that has been locked out.  In addition, I also had to allow users which did not require SmartCards to register and use SSPR to reset their forgotten password.

At a quick glance you wouldn't really think of this as a problem but it is.  This is because of the way that AD handles setting the Smart card is required for interactive logon flag. When the flag is set, a random password is generated (that the user doesn't know) and the password is flagged to never expire. This prevents a user who must use a smart card for interactive logon from completing the first password challenge gate during registration. While the challenge gate can be removed, it's there for a reason and that's security.  As an example an end user walks away from his or her desk and leaves their computer unlocked.  Without a password gate, a malicious user could easily register new challenge/answers then reset the password somewhere else.  At this point they could have access to a whole trove of information they should not.

As you can see, it's a catch either way that requires a bit of customization to make both scenarios work.

So the first part of this dilemma is being able to identify the users in FIM via a set. Declarative sync rules really make this a very simple task since it can be done with a custom expression on the inbound flow from userAccountControl.

To start with, a few custom attributes and bindings are required. First create a new attribute in FIMService (SmartCardRequired) and bind it to the person object.  Second a new metaverse attribute will be required to move the data from AD into fim (smartCardRequired).

Once the attributes have been created; the custom expression below will give a Boolean value that can be used for the sets. Keep in mind this also must be exported back to the FIMMA to make it available to the FIMService.

CustomExpression(IIF(Eq(BitAnd(262144,userAccountControl),262144),"true","false")) --> smartCardRequired (MV attribute).

Now that the attributes are available the next step is to build the appropriate sets. In this step we are essentially replacing the built-in "password reset users set" with our two custom sets.  The first set will define users that require SmartCards for interactive logon, and the second set will define standard users authenticating with a username and password.

As the next step I chose to define two new custom Password Reset AuthN workflows.  One that included the challenge for password gate (regular users) and another that did not include the password challenge (smart card users). However, both workflows included the same Q/A gates to provide some standardization between the two.

Since sets and workflows have now been defined the new MPR's can be created. These can be mirrored after the existing policy "anonymous users can reset passwords". The difference here is that each policy will need to have the appropriate AuthN workflow assigned (with or without password gate) and the target set must specify the appropriate set (smartcard required or not). Finally, the Password Reset Action workflow should also be attached to both policies.

The last piece that needs to happen to tie everything together is to have all of the items that were created added to the Password Reset Objects Set. This includes both new sets, both new workflows, and both new policies. After this is done, I am ready for multi-path SSPR! As a final clean up action, if the existing policy "anonymous users can reset their password" is enabled it must be disabled so FIM will know which workflow to call.

I hope this rather lengthy post might be of help to someone else out there. 

Happy FIM'ing!

In short, I was running a change install on the FIMService/Portal as we needed to add reporting. The installer would make it to the piece where it was deploying management packs, and would then perform a rollback.

In order to do this, I had to run msiexec with the appropriate switches and provide a location for the logfile.

msiexec /I "Service and Portal.msi" /l*v InstallLog.log (this creates a log in the same directory as the installer).

The log files can get very large (especially for FIMService and with a verbose switch usually run around 2MB).  2MB worth of text is a tremendous amount and can be very tedious to wade through.  What I've found with FIM is that searching for "InstallFinalize" is a good way get started looking for the failure

The log file eventually led to the error below:

CustomAction ImportRequestHistoryReportManagementPackBundle returned actual error code 1603 (note this may not be 100% accurate if translation happened inside sandbox).

Essentially, the failure was occurring due to a timeout when trying to import the Management Packs to the SCSM 2012 server.

The solution in this case was to manually import the management packs and re-run the install change. 

I won't go into the details on how to import management packs in this article.  A reference is available at https://technet.microsoft.com/en-us/library/hh524269.aspx.

One piece that I needed was the location of the management pack bundles.  These can be found in the FIM installation media in the following directory Portal and Service/Program Files/Forefront Identity Manager/2010/Reporting/Reports. The management pack bundles will have a .MPB extension which can be loaded manually into Service Manager.

In my specific case, I found this bypassed the timeout error in the installation and allowed me to successfully install reporting.

Hopefully it can help someone else too!

This issue centered around Exchange provisioning via FIM and occurred with both 2007 and 2010. The short of the problem is that I was able to run completely through a synchronization cycle (DI,DS,EX) on both FIMMA and ADMA with provisioning turned off.  When Exchange provisioning was turned on the first export was run against the ADMA the Sync UI became totally unresponsive and locked up.  The only way to remedy the situation was to kill the miisserver.exe process and try again.

My first thought was to upgrade to the latest and greatest 4.1.3451.0. The latest hotfix also included a cumulative update introduced in 4.1.3441.0 which allowed the sync server to continue in the event of an Exchange provisioning failure. After patching all of the components in the lab up to the new version I found the issue was still present.

The really unusual part was that there were no failures in the event log of the sync server. Additionally, after looking at the log on the Exchange CAS server I was finding the command was executing without any failures!

While staring at add/remove programs contemplating rolling everything back to a previous version I noticed the WMF 3.0 framework (beta) and a light bulb went off. I immediately uninstalled WMF 3.0 beta and rebooted the server, as soon as it came back up provisioning was working.

Since I am huge fan of the new PowerShell 3.0 ISE, I had to go immediately download the WMF 3.0 RTM which did not cause any problems with Exchange provisioning.

As I have found many times, issues often jump out at you when you look somewhere completely different!

https://support.microsoft.com/kb/2849119

A very good way to get back some time is to enable FIM portal tracing.  This will allow you to get exactly to the error and give you an idea of what needs to happen in order to resolve the issue.

You can find instructions on how to enable this at https://social.technet.microsoft.com/wiki/contents/articles/how-to-configure-fim-portal-tracing.aspx.

In short, you just need to edit the SharePoint web.config and add the system.diagnostics node (followed by an IISRESET of course).

Below is an example of the svc trace produced from the logging. As you can see, knowing exactly which line and position the error occurred is very useful and helps to save a ton of time. Instead of wading through 2000+ lines of XML, I go straight to line 2039 at character position 78. Voila, root cause found we can now fix it and move on.

 Just remember to reset the configuration file because a trace can consume a tremendous amount of disk space in a short time and it also has a performance cost associated with it as well.
   
  
  
  
  
  Happy troubleshooting!
  
  
  
  
  
  
 
 
 

• Server 2012
• SQL 2012
• SharePoint Foundation 2013
• System Center 2012

Full details can be found at https://technet.microsoft.com/en-us/library/jj863245(v=ws.10).aspx

The inclusion of System Center 2012 has been great, but there are certainly some "gotchas".

If you have upgraded and were previously using System Center 2010 things likely went very smooth until you try to install FIM reporting on System Center 2012 with SP1 (which was a large rev in itself).

Or if you are like me and are trying to implement on a clean install of System Center 2012 then you have no doubt run into issues. Have no fear, there are some workarounds out there that I will be sharing with you. Over a few implementations, I have noticed 2 very specific problems. The first is a bug in the Portal and Service.msi that will repeatedly tell you that you are missing a patch KB2561430, however, this is actually a hotfix that is only applicable to SCSM 2010. The second problem is a missing SQL function (that is present if you upgrade from SCSM 2010), hence why it possibly went smoothly for some folks above.

Continuous prompt for patch...

I've actually found two separate workarounds for this one.  My preference if you have the luxury of doing a clean install of Service Manager, is to install SM/DW 2012 (non-SP1), then install FIM reporting on top of it.  Once the Datawarehouse  has been registered (all the MP's have been deployed), you can run a change install on FIM to add reporting. Just make sure to read the next section before running the datawarehouse script install :)

Now if you have an existing SM 2012 installation that is already at SP1, it's not necessarily feasible to just wipe it out and start all over of course. In this case, you will need to do an unattended installation of FIM in order to deploy reporting. This also must be on an install and not a change, a fact I spent several hours learning today. The good part is that you will still be able to use an existing FIMService DB, that is neither here nor there if you do not have one to start with.

The following is an example of a command line to do just that, and more info on unattended installations are available here https://technet.microsoft.com/en-us/library/hh322863(v=WS.10).aspx

C:\Windows\SysWOW64\msiexec.exe /i "C:\FIM\Service and Portal\Service and Portal.msi" /quiet ACCEPT_EULA=1 ADDLOCAL=CommonServices,WebPortals,FIMReporting SQMOPTINSETTING=0 SQLSERVER_SERVER=FIMDBSQL SQLSERVER_DATABASE=FIMService EXISTINGDATABASE=1 MAIL_SERVER=exchange.yourdomain.com MAIL_SERVER_USE_SSL=1 MAIL_SERVER_IS_EXCHANGE=1 POLL_EXCHANGE_ENABLED=1 CERTIFICATE_NAME=ForefrontIdentityManager SERVICE_ACCOUNT_NAME=FIMServiceAccount SERVICE_ACCOUNT_PASSWORD=******* SERVICE_ACCOUNT_DOMAIN=yourdomain SERVICE_ACCOUNT_EMAIL=svc-fimservice@yourdoman.com SERVICE_MANAGER_SERVER=SMMGMTSRV SYNCHRONIZATION_SERVER=FIMSYNCSRV SYNCHRONIZATION_SERVER_ACCOUNT=Domain\fimma SERVICEADDRESS=FIMService.yourdomain.com REGISTRATION_PORTAL_URL=https://passwordregistration.yourdomain.com FIREWALL_CONF=1 SHAREPOINTUSERS_CONF=1 REQUIRE_REGISTRATION_INFO=1 REGISTRATION_ACCOUNT_NAME=fimSSPR REGISTRATION_ACCOUNT_DOMAIN=YOURDOMAIN REQUIRE_RESET_INFO=1 RESET_ACCOUNT_NAME=fimSSPR RESET_ACCOUNT_DOMAIN=YOURDOMAIN  /L*v "C:\FIM\Service and Portal\fimservicelog.txt"

Missing function...

The second issue I've run into is with the missing function this becomes a problem since two of the FIM Reporting SQL stored procedures have a dependency on it, and if it's not there you will continually see errors like the ones below.

Module name: TransformEntityRelatesToEntityFact

 Message: Cannot
find either column "ETL" or the user-defined function or aggregate
"ETL.CanContinueExecution", or the name is ambiguous.

These errors manifest themselves during the transform phase of the ETL process and I have not seen SM recover on it's own even after adding the function. With that said, it's very important to make sure that all of the management packs are deployed to the DW and that the function is present before installing the DW scripts.

The SQL query below can be used to create the function ETL.CanExecutionContinue which will allow you to start enjoying the benefits of FIM reporting!

USE [DWRepository] 
 GO 
 
 SET ANSI_NULLS ON 
 GO 
 
 SET QUOTED_IDENTIFIER ON 
 GO 
 
 CREATE FUNCTION [etl].[CanContinueExecution] ( 
 @transformName VARCHAR(256), 
 @executionStartTime DATETIME 
 ) 
 RETURNS BIT 
 AS BEGIN 
 DECLARE @canContinue BIT = 1, 
 @executionTimeLimit INT = 30 -- minutes 
 
 -- do not continue if the time we have consumed is 
 -- more or equal to the amount of time that we are 
 -- allowed to take for this batch 
 IF(ABS(DATEDIFF(mi, @executionStartTime, GETUTCDATE())) >= @executionTimeLimit) 
 BEGIN 
 SET @canContinue = 0 
 END 
 
 RETURN @canContinue; 
 END 
 
 GO 
 

Over the past few years I have seen a variety of different issues related to FIM, however, this was the first time I have run into this specific error. When running a full import on the FIMService MA, the import would get to "completing obsoletion" then fail. Certainly frustrating to say the least since it would always fail at the end of a full import, a delta import would always run successfully though. After trying some of the standard things (deleting the connector space, deleting the MA and recreating) I found that the issue persisted and I couldn't seem to resolve it.

A very telling item in this case, was that the DB's (FIMService and FIMSync) had been moved from a virtual server to a physical host. Additionally, they had also been patched to the latest hotfix and I'm not sure what order that happened in since it was like that when I got here.  Anyone who has spent quality time with FIM knows that randomly upgrading and moving things around can be a recipe for disaster! As I dug in a little deeper, I found the stack trace below on the sync server which lead me to look into the DB role permissions.

As it turns out, during the DB moves execute and alter permissions had been removed from the roles which was the root cause of my errors.  After mirroring the permissions from a known good copy of the FIMService DB I was finally able to complete full imports.

 Planning is a step that cannot be overlooked or hurried through when dealing with FIM databases.

 __________________________________________________________________________________________________________________________________

Stack Trace:

___________________________________________________________________________________________________________________________________

Net SqlClient Data Provider: System.Data.SqlClient.SqlException (0x80131904): The EXECUTE permission was denied on the object 'AssertTransactionalContext',
database 'FIMService', schema 'fim'.

The SELECT permission was denied on the object 'RequestLog', database 'FIMService', schema 'fim'.

The SELECT permission was denied on the object 'RequestLog', database 'FIMService', schema 'fim'.

The SELECT permission was denied on the object 'RequestLog', database 'FIMService', schema 'fim'.

Cannot find the object "#truncateRequestLogBuffer" because it does not exist or you do not have permissions.

   at System.Data.SqlClient.SqlConnection.OnError(SqlException exception, Boolean breakConnection)

   at System.Data.SqlClient.TdsParser.ThrowExceptionAndWarning()

   at System.Data.SqlClient.TdsParser.Run(RunBehavior runBehavior, SqlCommand cmdHandler, SqlDataReader dataStream, BulkCopySimpleResultSet bulkCopyHandler,
TdsParserStateObject stateObj)

   at System.Data.SqlClient.SqlCommand.FinishExecuteReader(SqlDataReader ds, RunBehavior runBehavior, String resetOptionsString)

   at System.Data.SqlClient.SqlCommand.RunExecuteReaderTds(CommandBehavior cmdBehavior, RunBehavior runBehavior, Boolean returnStream, Boolean
async)

   at System.Data.SqlClient.SqlCommand.RunExecuteReader(CommandBehavior cmdBehavior, RunBehavior runBehavior, Boolean returnStream, String method,
DbAsyncResult result)

   at System.Data.SqlClient.SqlCommand.InternalExecuteNonQuery(DbAsyncResult result, String methodName, Boolean sendToPipe)

   at System.Data.SqlClient.SqlCommand.ExecuteNonQuery()

   at Microsoft.ResourceManagement.Data.Sync.TruncateRequestLog(Int64 requestLogTruncationKey