FIM R2 and BHOLD Suite Service Pack 1

Just a quick update on my entry about the bug in BHOLD Suite concerning permission deprovisioning. I mentioned that Service Pack 1 would contain a fix for this issue. Yesterday, Andreas Kjellman announced that Service Pack 1 is released. This is however a so-called ‘soft release’, which means that the update is only available on MSDN and that there isn’t much documentation available yet. It also means that you are not allowed to apply the update to your production environment just yet.

I’ll try to install this new version on my sandbox environment and let you know if the issue is resolved. Of course, I’m also curious about any other changes. Dave Nesbit already mentioned on his blog that the BFPC and BFSS services are replaced by the new ‘Access Management Connector’, so I’ll see if I can bring any news on that as well.

I’ll keep you posted on any progress!

Posted in Uncategorized | Tagged | 1 Comment

Interesting bug in Microsoft BHOLD Suite concerning permission deprovisioning

While working on a BHOLD implementation, I found an interesting bug:

If you’re getting to know BHOLD, you’ll soon find out that it consists out of (among others) these object types:

  • User; An employee in your organization, mostly imported to BHOLD by the FIM Synchronization engine through the ‘FIMEmployees’ table.
  • Org.Unit; An organizational unit. Your BHOLD environment will probably contain an entire tree structure of org.units. An Employee should have a reference to an Org.Unit object.
  • Role; A role that can be assigned to an employee. It can be assigned to an employee based on his/her position in the Org.Unit structure, or based on an attribute of the user (basically, the assignment of roles is one of the main features of BHOLD).
  • Permission; A role consists out of 1 or more permissions. Linked to Active Directory, this would be the same as a ‘Group’. Other applications might have different names for this.

Basically, through his/her role membership, an employee is entitled to a set of permissions. To export these permissions to your target system, you will need to synchronize them using the FIM Synchronization service. FIM Sync imports the permissions and memberships through the ‘tblObjects’ and ‘tblReferences’ tables, where ‘tblObjects’ contains the users and permission objects and ‘tblReferences’ contains the link between the two objects.

That’s it for the technical explanation, let’s continue to the details of the bug: The tblReferences table is filled by a BHOLD service (the ‘BFPC’) once a user is entitled to a certain permission, which works as intented. Apparently, it doesn’t do a good job of deleting a record once the user is not entitled to a permission anymore.

I’ve contacted someone from BHOLD, who says this is a known bug. He tells me there is a patch available to fix this issue, but this patch is not generally available. You can however request the patch by creating a service call at Microsoft. Service Pack 1 of the BHOLD suite will contain a fix for the issue, but this service pack is not yet released for production environments.

If you’re experiencing the issue, or if you want to know more technical details about it, let me know. Hang in there: a production-suitable fix is on the way!!

Posted in Uncategorized | Tagged | Leave a comment

Microsoft BHOLD Suite Logging

For the last couple of weeks, I started to work with Microsoft BHOLD suite. If you’re new to the product, you’ll soon find out that the logging of the BFSS and BFPC services is a good starting point in trying to solve issues. Here’s some information on the logging configuration of these services.

By default, all information is logged to the files ‘BFSS.log’ and ‘BFPC.log’ in the ‘C:\temp\’ folder. To change the directory in which these files are stored, create a registry key in ‘HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\bhold\b1Core\LogfileDir‘, containing the directory (without the filename) where you want the logfiles to be stored.

You can also add the ‘BFSSLogLevel’ and ‘BFPCLogLevel’ keys. This suggests that it is possible to control the amount of messages logged, but it doesn’t. If the value is set to ‘verbose’, all available information is logged. Any other value (like ‘none’ or ‘warning’ / ‘error’) stops all logging for the BFSS and limits the logging for BFPC to things like ‘BFPC Initialising’ and ‘BFPC Ended’.

To summarize: there aren’t much possibilities to configure logging, it’s basically all or nothing. The information above could prove value in changing the default log location and disabling logging in your production environment. This is most recommended because if verbose logging is enabled (which it is by default), this will result in gigabytes of logdata per day!

Posted in Uncategorized | Tagged | Leave a comment

Exceptions to throw in FIM Synchronization Engine

When writing assemblies for the FIM Synchronization Engine, you might run into a situation where you want to throw an exception. Just as a reference: here’s a link to the FIM exceptions you can use in the Microsoft.MetaDirectoryServices namespace:

Posted in Uncategorized | Leave a comment

Forefront Identity Manager 2010 R2 Now Available

Forefront Identity Manager (FIM) 2010 R2 is now generally available!  FIM 2010 R2 adds many new capabilities to help organizations handle the growing complexity of managing identity and permissions across heterogeneous systems.  We feel that 2010 R2 is the best FIM release yet – and wanted to review just a few of the new capabilities you’ll find inside.

Read more…

Posted in Uncategorized | Leave a comment

FIM 2010 R2 and BHOLD Suite available on MSDN!

FIM 2010 R2 and the BHOLD Suite are now available on MSDN. This means that you can download this software and use it in your development environment. 

Here’s a link to the RSS-feed of new downloads on MSDN, which contains the download link!

Posted in Uncategorized | Leave a comment

Office365 and Dirsync. When to use?

Many companies that use Office365 struggle with the same problem: “how can I automate the synchronization between my on-premise Active Directory users and Office365”? To solve this problem, Microsoft provides ‘Dirsync’. Dirsync is a downsized version of the Forefront Identity Manager 2010 (FIM2010) sync server.

When you start using Dirsync, you have to be very aware of the advantages and disadvantages of this solution. A summary:


  • It’s free.
  • The solution is out-of-the-box. There are no difficult configurations to make, so the system can be operational in a short time span.

The disadvantages:

  • An Office365 account is created for ALL Active Directory users of a particular OU. There are few possibilities to create an account for users with a particular role, or members of a particular AD group
  • There is little control over the user object. The necessary ‘IsLicensed’ attribute is not set to true. This means that there is still an action necessary to allow the user to work. This can be done by means of a powershell-command, or via Office365 itself.

If these disadvantages are not applicable to your organization, Dirsync might do the trick for you. If they do apply, you should consider using the full FIM 2010 Sync server and an Office365 management agent based on powershell.

Want more advice on this topic? Do not hesitate to contact me at any time!

Posted in Uncategorized | Leave a comment