Friday, April 18, 2014

Mailbag: Learning FIM, SQL and IIS

Recently, a reader reached out to me for advice on learning FIM, SQL and IIS. As well as guidance on setting up a lab (more advice on that part in a later post).

First think for a moment about your best learning styles for technology. Do you need to read the concepts and architecture first and then do it? Do you need to watch a video and then read, and then do it? Do you need to try it and then go back and read? Do you need an instructor? Sometimes you have to learn through experimentation. In the early days of ILM 2 Beta there wasn't much info so we had to experiment. Brad Turner and I spent many days in a lab configuring and trying things out to see what was the best practice.

Fortunately there are a fair amount of videos, articles, virtual labs and classes about all three subjects. In general I find the virtual labs to be a great way to get in and get some quick hands on lab knowledge without having to labor endlessly to setup your own lab. Not that you won't get something out of that experience. But sometimes you need to pickup tidbits or try something out before deciding you need to setup a more permanent lab to experiment with.

FIM, SQL and IIS rely on Windows Server, Active Directory and Networking. It is surprising how many issues get resolved through knowledge of basic networking and its troubleshooting tools. Understand how client applications use DNS to find what they are looking for and SPNs to authenticate through Kerberos.  If you are shaky or want a refresher I encourage people to start with those topics.

For FIM I would start with the Ramp Up training. It provides you with video, lab manuals and the virtual labs. Of course I also recommend my book. There is also another FIM book by Kent Nordstrom. Beyond that here is a great list of resources:

SQL: this is more in the context of what you need to know about SQL to support FIM. Start with a presentation I gave a few years ago at The Experts Conference on Care and Feeding of the databases
 as this gives you some perspective on what you need to SQL to support FIM. Configuring overall memory for SQL, TempDB configuration, Index management, Backups, Transaction Logs, Recovery Models. The last chapter of FIM Best Practices Volume 1 covers how to intelligently automate your SQL maintenance.

If you want to start learning SQL queries try  or take the Microsoft course

IIS: Again this is in the context of what you need to know about IIS to support FIM.
Overview of IIS 8 (Windows 8 and Windows Server 2012)

Overview of IIS 7

Great post comparing how IIS 6 through 8 deal with SSL.

Intro to IIS 8 virtual lab

Thursday, April 17, 2014

New name for FIM?

Did you know that if you subscribe to Azure AD Premium you also get licenses for FIM? Well if that isn't a hand tipper I don't know what is. I think we can safely assume the next version of FIM will have Azure in the name. Safe or not I am going speculate that it will.

Azure Identity Manager (AIM) -- I would be ok with this
Azure Role Based Access Manager (ARBAM) -- Explosive sounding name
Azure Provisioning Engine (APE) -- Please no!!
Azure Identity Technology (AIT) -- pronounced 8 or aight. Nah.
Azure Identity Sync Lifecycle Engine (AISLE) -- Certainly when people walk down the aisle they have an identity changing event.
Azure Identity Lifecycle Management Engine Next Technology (AILMENT). I really hope not we want to cure ailments not install one for you.

My Official guess -- Azure Identity Enhancements (AIE)

Unless we have already seen the new product name -- Azure Active Directory Premium (AADP).
Maybe the on-premise version will have a slightly different name
Azure Active Directory Premium On Premises Edition (AAD POPE)

The above has been pure speculation. I have no inside knowledge on the name.

Hints of FIM's Future: Azure Active Directory (AAD) Sync

For years I have been trying to predict the future of Identity Management, but every time I look in my crystal ball it is just too cloudy to see anything. In fact anytime I look in my crystal ball on just about any technology topic the only thing it shows me are clouds! I was beginning to think it was broken.

But then, yesterday, I watched Andreas Kjellman present at the FIM user group
Andreas unveiled the AADSync, the Azure Active Directory Sync that will replace DirSync to sync from your Active Directory to the cloud. I finally got it! My crystal ball wasn't broken!

AADSync is built on the next generation of the Sync Engine. 80% of the scenarios for syncing with Azure (Office365) will be handled with a wizard, including Multi-Forest. For more advanced scenarios you will be able to use a significantly upgraded function library to do "declarative provisioning" with sync rules. In fact no code for rules extensions will be permitted.

What does this mean for FIM?

I speculate that eventually FIM will follow this path. Since this next version seems to support the same connector framework, I think we will continue to see connector development as well as continued cloud capabilities ala Azure Access Enhancements and Azure AD Premium.

Thanks to the user group sponsor --  the FIM team, hosted by Carol Wapshere for putting it together and eventually providing the recording found here:

AADSync is available now in Preview.

Wednesday, April 16, 2014

Good RID(ance, I mean issuance)

As we know a SID is 12 Bytes long or 96 bits long and is composed of several components, among them the domain identifier and the relative identifier or RID of a particular object. The RID is 30 bits long which means you have approximately 1 billion RIDs. So while you think it is unlikely that you will run out of RIDs, according to you can encountering this if you have accidentally used scripts or provisioning tools (like FIM) to shoot your self in the foot and create gobs and gobs of users, you let some end-user go out of control creating waaaay too many groups, you increased the RID pool size to be too big, did lots of DC demotion and promotion, cleanups, forest recoveries or invalidated RID pools.

In short most of you would be more likely to encounter this in a test or dev environment where you destroy and create many many users as part of your testing with FIM.

So Windows Server 2012 to the rescue.
1) It adds a bit so now you can unlock that bit and have 31 bits for the RID or 2 billion RIDs.
2) You get warnings in the event log whenever you consume 10% of the space left since your last warning.
3) Now there is a safety mechanism, you can't increase the RID Block size to higher than 15,000. Previously there was no limit and you could have allocated the entire RID space in one transaction to one domain controller.
4) There are also brakes. When you are within 1 percent of only have 10% of your global RID space left you get warned and there is also an artificial ceiling so that you can fix whatever is chewing up your RIDs before you are out.

In short good RID(ance I mean issuance).

Wednesday, November 13, 2013

FIM Deprecated Features FIM TEAM user group meeting

So in 1 hr and 20 min I will present on

November 13, 2013 21:00 UTC
See when this is in your timezone
David Lundell
Impact of deprecated features.This session will go over various deprecated features that the FIM product group have announced are to be eliminated in future releases, such as XMA v1 (ECMA v1), transaction properties, multi-mastery and equal precedence, with advice on planning for and working around their future absence.

Friday, October 4, 2013

DirSync w/ domain if NetBios and FQDN don't match

If one of your AD domains has a NetBios domain name that doesn't match the leftmost part of your FQDN you need to have the Replicating Directory Changes permission given to your AD MA account. This is documented in a few places including my book. However, DirSync misses this step. Normally, Dirsync does a very good job of installing and configuring everything which you need without needing you to be an expert in FIM, but this is one thing it misses.

For Example if the FQDN is Exchange.loc but the netbios name of the domain was Snappy then you would use this command to solve the issue

DSACLS "CN=Configuration,dc=exchange,dc=loc" /G "exchange\Grp_DirChanges:CA;Replicating Directory Changes;"

Declarative or Bust!

Michael Pearn from down under wrote about his experience trying to use just Declarative Sync Rules

His experience -- especially the religious debates are similar to my own. It made me recall my presentation at TEC 2012 the FIM 2010 R2 Showdown: Classic vs. Declarative

The vast majority of old hands at the presentation declared for Classic both before and after the presentation. During the presentation I attempted to view anything you could do without code as declarative whether it came from a sync rule or not, especially if it was a new feature. But the crowd wouldn't let me claim anything configured in the sync engine as declarative. But in this post only classic code counts as not declarative.

Michael found that he needed classic code for Advance Join rules, doing anything with multi-valued attributes other than just flowing them and "Converting Binary values to ISO8601 Datetime." In his example he could have modified his SQL query that gets the data from HR and avoided the need for the Advanced Join rule.

In addition to Michael's list here are some other things that you may need classic code to do:

  • Advanced Filtering scenario to cause disconnections
  • Changing the Metaverse object type when a connector joins to it
  • Join Resolution Rules
  • Manual Precedence Import Flows
  • Provision objects with Auxiliary classes
  • Decide on a case by case basis whether to deprovision as a Disconnector, Explicit Disconnector or just delete the object.

But what does the FIM Sync engine bring us beyond what we had in ILM 2007 FP1?

  • A lot less need for MVDeletion rules extension since we can indicate that disconnection from any of a list of MA's should trigger MV Deletion or if it is disconnected from all MA's (but ignore this one and that one)
  • Many, many attribute transformations can be done with Sync Rules and don't need code
  • A way to do fairly sophisticated provisioning logic without code (Transition Sets, MPRs, Workflows, OutBound Sync Rules)
  • R2: A way to do some basic provisioning logic with filter based Outbound Sync rules that performs pretty decently and doesn't require a detour through the FIM Service
  • New ways to trigger deprovisioning (Transition Sets, MPRs, Workflows, OutBound Sync Rules)
  • OU creation w/o code (That sure is nice and no worried about the OU being a connector to the MV object that first needed it)
  • DN Rename w/o code (also very nice)

In my presentation I contrasted the new sync rules with the classic config and code:











Finally here were my recommendations that many disagreed with but it sounds like Michael would agree:


There are some high volume scenarios where sync rules are too slow and there are still some customers that get all they want out the classic sync engine and don't want to pay for CALs.