FIM 2010: Eliminating equal precedence

Intro

Precedence can be tricky in certain scenarios. Imagine you want to make FIM master for a given attribute, but you need an initial flow from another data source. A good example is the LDAP distinguished name. If you have a rule that builds the DN automatically based on a base DN and one or more attribute values, the object is provisioned with the correct DN on export. But when you want to visualize this DN in the FIM portal, you need to be able to flow it back. If FIM is master over the distinguished name attribute, this flow will be skipped "Not precedent".

So you have to consider the option of using equal precedence, since manual precedence is not possible in combination with the FIM MA. But equal precedence is dependent on the synchronization cycle order: "the last one to write the attribute wins". Therefore it is not an option if FIM needs to be the absolute master of the DN attribute and you want to make sure that it always has the value you expect it to have.

FIM on Azure

While deploying your Forefront Identity Manager labs in your own local virtual environment is convenient, it does consume a lot of your precious disk drive space and there is no questioning the impact of hardware failure. So why not move your virtualization layer to the cloud and let Azure take care of the storage, networking and compute infrastructure for you? This post will go over the steps we took in order to successfully automate the deployment of our FIM lab environments on the Microsoft Azure platform.

Azure infrastructure fundamentals

In order to create domain joined environments in Azure, there are four components we need:

1. An affinity group

Having our resources deployed in the same region (data center) is a fair option, but there is no certainty these resources are also located in the same cluster within that data center. Using affinity groups, we can define a container in which all our virtual machines are physically placed close together. This improves latency, performance and thereby cost.

2. A cloud service

This component is responsible for hosting our virtual machines. It gets assigned a public IP address, making it possible for you to connect to your environment from any location using your own defined endpoints.

3. A virtual network

In a domain joined setup it is necessary your machines can talk to each other. Using a VPN, we make sure VM's are deployed in the same IP range. These VM's can be assigned a static internal IP address which makes it possible to define your domain controller as the DNS server for the virtual network.

4. A storage container

Each deployment gets its own container to host their virtual hard disks (VHD's) under a storage account which is linked to the subscription of the deployment's cloud service.