Chapter 4. Basic Configuration

If you have followed this book, you will now have a freshly installed FIM 2010 R2 environment. In this chapter, we will discuss some of the basic configurations we need to look at, no matter how our environment looks or how we plan to use FIM 2010 R2.

If you have an environment already set up, I hope that this chapter can act as a guide for you to verify that you have not missed any important steps causing your FIM environment to not work properly.

In this chapter we will focus on the initial configuration of FIM Synchronization Service and FIM Service. Specifically, we will cover the following topics:

• Creating Management Agents

• Schema management

• FIM Service MA

• Initial load versus scheduled runs

• Moving configuration from development to production

Note

All the configurations are made on the FIM-Dev system, and as you will see at the end of this chapter, we will move that configuration from the development to the production servers.

Creating Management Agents

Before we even start to use our FIM implementation to manage identities, we need to decide where the information about the identities will come from and where the information will go.

It is also very important that we start off with the essential connections and then add other connections after verifying that the basics are working.

A very typical scenario is the one we have—The Company has an HR (Human Resource) system that will, for the most part, work as the source of identity information. Then it has Active Directory, which is the primary system to receive identity information.

The basic flow will be HR - FIM - AD.

But that is only the basic flow, and as you will see later in this book, there are other sources of information and also other targets.

Active Directory

Almost 100 percent of the FIM implementations have at least one Management Agent connected to an Active Directory.

There are a few things to consider before creating this Management Agent. I suggest you...

Schema management

Very early on in our FIM deployment, we ran into discussions regarding the need for schema changes in FIM.

The default schema is, in almost every case, not sufficient and needs to be modified.

I will only give a short overview in this chapter about this, and will try to explain more in the coming chapters, as we look into the details of FIM implementation at The Company.

FIM Sync versus FIM Service schema

One of the problems with the FIM Synchronization/FIM Service system is that it holds two schemas. We have one schema for the FIM Synchronization Service database and one for the FIM Service database.

Depending on our needs, we change one or both of these schemas. Whether the attributes or objects are required within FIM Service depends on whether or not they are managed using FIM Portal, or used in some policy. If not, we do not need them in the FIM Service schema.

On the other hand, if an attribute or object type is used in a policy within FIM Service, but is never supposed...

FIM Service MA

The AD and HR (SQL Server) MA only give the synchronization engine the possibility of talking to these data sources. But in order for FIM to apply its logic to the data flow, we need to have the very special MA connecting FIM Synchronization Service to FIM Service.

Even if you implement it like almost any other MA, you will soon find out that this is not a typical MA. In most cases, this will be the first MA we create.

Creating the FIM Service MA

I will walk you through the steps for creating the FIM Service MA, which are as follows:

1. Start FIM Synchronization Service Manager.

2. Select the Management Agents tool, and click Create in the Actions pane.

3. Select the FIM Service Management Agent option in the Management agent for: drop-down list:

   

4. Give the MA a descriptive name; at The Company we simply call it FIM Service:

   

5. As we are using SQL Aliases, we will use the alias server name dbFIMService:

   

   The FIM Service MA will not only connect to the FIM Service Database, but also make calls to...

Initial load versus scheduled runs

When we first start to import information into Synchronization Engine it is likely that information already exists in many or all of the connected systems.

We might need to create special synchronization rules just for the initial load, which are not used again unless we need to rebuild the data.

Let me give you an example. At The Company, the basic idea is that users should be imported from the HR system and created in AD. But when we start, there might be existing users in AD and we would need to connect them using a Join rather than provisioning (creating) them in AD. During the initial load we would therefore turn off Provision in FIM, import users from both systems, project them into the MV, and join the users existing in both the systems.

Initial load is usually done manually; that is, we manually start the required run profiles for each MA.

If the environment is large, the initial load might take many hours due to the fact that, when we export our objects...

Moving configuration from development to production

So far, I have done all the changes on the FIM-Dev server, which is my test/pilot/dev environment. We now need to transfer the information from development to production.

The steps to move the configuration vary a little depending on what kind of changes you have made. But basically we have two major areas, FIM Synchronization Service and FIM Service. We move changes to each in different ways.

If I have made any changes to the FIM Synchronization Service schema or any MA, I need to move this configuration as well. Otherwise, I will settle with only moving the FIM Service configuration.

The tool we use to move the FIM Service configuration is PowerShell. When working with FIM, you will realize that PowerShell will be something you will have to learn.

The main steps are as follows:

1. Export the FIM Service schema, FIM Service Policy configuration, and FIM Synchronization Service configuration on both development and production systems.

2. Compare the...

Summary

In this chapter, we have seen how The Company configured their first Management Agents and prepared the FIM environment for further configuration.

In my experience, the most common source of errors in the FIM environment is the lack of well-documented processes to make sure the development/test and production environments look the same. Learning and documenting how to move your configuration from development/test to production is vital as the configuration gets more complex.

If you take your time to make sure your basic configuration setup is satisfactory, it will save you many hours of troubleshooting later on. If you feel confident that your basic configuration is correct, moving on and making more complex configuration settings will be easier.

We are now ready to actually do something with our FIM environment. In the next chapter, we will start off by looking at how to configure FIM for user management.