Forefront identity management 2010 Installation

Some of you might have struggled trying to install FIM 2010, I must admit it’s a little tough at first the software having so many requirements.

Here is a quick guide that should help you deploy that solution in one shot and be done with it. I’ve skipped the obvious part or this would have taken me forever so here we go.
I will assume that you have a windows domain with Microsoft Exchange and an SQL server installed so I will skip these step and go on to the part that’s important in the FIM installation process.
1- Account Creation
You will need to create multiple standard domain accounts each of which will be used for a different purpose, (try not to use the domain admin account even though it works):
· Create an e-mail-enabled domain service account to run the FIM Service

· Create a domain service account to run the FIM Synchronization Service

· Create a domain FIM Service management agent account

· Create a SharePoint Server management account.

· Create an SQL Server admin account.

2- Account configuration
Next step is to configure those accounts:
· Allow Logon locally on the FIM server to the FIM MA account

· Grant the « log on as a service » right to the FIM Service Account

3- SharePoint Installation and configuration
We can now install SharePoint services (WSS 3.0) on your FIM server (standard standalone install):

Once the installation is complete, launch the central administration website open the site actions and select “Create”.

Select « Create or extend Web application »

And configure the new web application as follows:

Once the application created you should be able to browse the localhost website and get the page below:

Navigate back to the central administration website and choose to create a basic web page:

4- Securing the SharePoint Website :
Start by issuing a webserver certificate for the FIM Server

Then in IIS, bind the SharePoint website in HTTPS using the certificate created previously.

Then get back to the central administration website and go to operations/alternate access mappings


Edit the http://fimserver url into https://fimserver

5- FIM Installation
Start by installing the synchronization service


Select the machine you’d like to install the service on and the sql server instance to use,

This step will create the local groups you will need to administer FIM, leave as is and continue then finish.

Next step is the manager service and portal installation:

Skipping the obvious parts, select the features you’d like to install

Select the database server and database name you’dd like to use to store the FIM data

Enter the mail server Address and the features you’d like enabled:
For exchange 2007 and 2010, the three checkboxes should be selected.

Select the Generate a new self-issued certificate option even if you have a pki installed on your domain.

Enter the service account created in the first step of this document:

As well as the synchronization server and the management account:

Enter the FIM server Address

Then enter the SharePoint site URL you created earlier (localhost if the site is on the server):

Finally choose to open the ports on the local firewall and to grant authenticated users read access to the FIM portal and password reset site.

Users that wish to administer the solution must be members of the local FIMSyncAdmins group

Make sure that the fim services are started

You can now finally begin using FIM

Top 10 new features in Exchange Server 2010

Microsoft recently released Exchange Server 2010, and it's chock-full of new features. This article will introduce you to a few of my personal favourites.

1: Legal hold
Over the last several years, it has become increasingly more common for an organisation's email messages to be subpoenaed as part of the litigation process. The problem is that email is dynamic in nature. Messages are constantly being sent, received and deleted. Likewise, messages in the archives are often set to expire after a specific length of time. All of these factors have made it difficult to comply with litigation-related message retention requirements.

Exchange 2010 offers a new legal hold feature. This feature allows you to preserve the contents of an Exchange mailbox. Users can still use their mailbox in the usual manner, but copies of all items are retained, even if they delete them or if archived content would otherwise have expired.

2: Multi mailbox search
A complementary feature to legal hold is the new multi mailbox search feature. This feature makes it a lot easier for organisations to perform e-discovery. As the name implies, multi mailbox search allows a designated person to perform organisation-level searches across users' mailboxes. The search interface is designed to allow administrators to search for multiple keywords or phrases simultaneously.

3: Exchange Control Panel
The Exchange Control Panel is a new management tool built into Exchange 2010. While the Exchange Control Panel isn't designed to take the place of the Exchange Management Console or the Exchange Management Shell, it is definitely a welcome addition.

The Exchange Control Panel is integrated into OWA. It allows users to perform a few basic self-service tasks, such as changing their contact information. For administrators, the Exchange Control Panel provides a way of performing some of the more common management tasks remotely using a web interface.

4: Database availability groups
Exchange 2007 provided several high availability features, such as Cluster Continuous Replication. Exchange 2010 takes things a step further with database availability groups. Database availability groups allow you to designate multiple servers to host copies of individual databases. In the event of a failure, Exchange can automatically recover. Databases are no longer server specific, so you are free to mix and match the database replicas that are hosted on each mailbox server.

5: Database-level failover
In previous Exchange Server cluster implementations, a failure required an entire cluster node to fail over. This meant that if a server was hosting multiple databases, and the disks associated with a single database were to fail, the entire server would have to fail over — which would be disruptive to users whose mailboxes weren't even stored on the failed disks.

In contrast, Exchange 2010 supports database-level fail over. That way, if a failure affects only a single database, that database can fail over without disrupting the other databases on the server.

6: Voice mail transcription
In Exchange 2007, the unified messaging feature caused voice mail messages to be saved as email message attachments. While that seemed to work out fine most of the time, it did sometimes make life difficult for road warriors who didn't always have the ability to play the message.

Exchange 2010 uses a speech recognition engine to automatically transcribe voice mail messages. Users still receive the voice message as an email attachment, but the email message also contains a written transcript of the voice message. Users can check their voice messages even when they don't have access to a sound card. More important, the transcription feature allows the contents of voice messages to be indexed along with traditional email messages.

7: Call answering rules
In Exchange 2007, the auto attendant provides voice prompt menus for the organisation's primary phone number. For example, an auto attendant might be used to ask callers to press 1 for English or 2 for Spanish and then route calls accordingly. In Exchange 2007, the auto attendant is an organisation level feature.

In Exchange 2010, though, each user has his or her own personal auto attendant, which Microsoft refers to as the Call Answering Rules feature. Call answering rules allow users to create their own call routing options. So, for instance, an important call might be forwarded to a user's mobile phone, while a less important call might go straight to voice mail.

8: Personal archive
In Exchange 2010, each user can now have two mailboxes — a primary mailbox and an archive mailbox. By using an archive mailbox, users can keep their primary mailboxes uncluttered. They're free to browse their archive mailbox at will, and items can be automatically moved from their primary mailbox to their archive mailbox using retention policies.

9: Retention policies
Retention policies allow messages to be tagged in a way that reflects their useful lifespan and what should happen when they expire. For example, you could specify that items in one folder should be deleted after 30 days, while items in another folder should be moved to the archives after five years. Users can also apply retention policies to individual messages that are separate from folder-level policies.

10: Role-based access control
Exchange 2010 uses a new access control model called role-based access control. Now, administrators can perform delegation based on the role that the delegate will be performing. This means that rather than guessing which permissions the delegate will need, the administrator can simply tell Exchange which tasks the delegate will be performing.

Exchange 2007: Understanding the Routing Group Connector between an Exchange 2003 and Exchange 2007 Messaging Environment

In a previous Blog entry I outlined the steps necessary to install the first Exchange 2007 Server into an existing Exchange 2003 Messaging Environment.  This process, which Microsoft terms a 'Transition Strategy' is well defined and well documented.  As part of a deeper look into the Routing Group Connector I thought I would offer some details using both the Exchange Management Shell (Powershell) and the Exchange Management Console to detail settings.  Additionally, I show how to use the Message Tracking Application from the Exchange 2007 Manager Console.
Here are the reference URLs to prior Blog entries of interest on this topic:

Installation Steps - Installing the first Exchange 2007 Server into an Existing Exchange 2003 Organization

Moving from Exchange 2003 to Exchange 2007 using a Transition Strategy

Transition Steps - Moving a Mailbox from an Exchange 2003 Organization to an Exchange 2007 Organization using the Move Mailbox Wizard

In this Blog entry I will analyze mailflow across the Routing Group Connector to provide a clearer picture of what occurs while Organizations are Transitioning from Exchange 2003 to Exchange 2007.

 

1.  Let's begin by examining the 2 Servers that comprise the Exchange 2003 Site titled 'First Administrative Group', and, the 2 Servers in the Exchange 2007 Site titled 'Exchange Administrative Group'.  We see 4 Servers total:
Exchange 2003

1. S01-EX00
2. S01-EX00-1

Exchange 2007

1. S01-EX01
2. S01-Ex02

 

2.  The Exchange 2007 Servers have been introduced into the Exchange 2003 Organization named 'ITPS Lab Exchange Organization'.  When this occurred, a Bi-Directional Routing Group Connector was generated as part of the installation process.  We see here the Routing Group Connector titled 'ITPS Lab Interop RGC' (actually, this is a hand-generated Routing Group Connector I created 'after the fact').  In this example, the Exchange 2007 Installation Process generated the RGC, then I generated an additional RGC and finally, deleted the RGC created automatically by the Exchange 2007 Installation Process.  In a typical environment, we would generate (with the Exchange 2007 Installation Process) and maintain a single Routing Group Connector (RGC).  Unless of course multiple Exchange 2007 Hub Transport Role Servers are required.

3.  Let's examine the Properties of the Exchange 2003 Routing Group Connector.

4.  Here we see the Exchange 2003 Server (titled S01-EX00) is the Default Server used for Routing Messages over the Routing Group Connector to the Exchange 2007 Remote Bridghead Servers.

5.  The Exchange 2007 Server that is the Remote Bridgehead Server for this Exchange 2003 Routing Group Connector is titled 'S01-EX01'.  It is an Exchange 2007 Hub Transport Role Server running Exchange 2007.

6.  Now, let's examine the Routing Group Connector Properties for the Exchange 2007 Routing Group.  Remember, Exchange 2007 only uses Routing Group Connectors for interoperability 'backwards' to Exchange 2003 Organizations.

 

7. Again, we see reciprocity! The Exchange 2007 Hub Transport Role Server (titled 'S01-EX001') 'connects' over this Routing Group Connector to the Exchange 2003 Server (titled in the next caption as 'S01-EX00').

8.  The Remote Bridgehead Server for the Exchange 2003 Routing Group is identified as 'S01-EX00'.

9.  Next I move to the Exchange 2007 Hub Transport Role Server titled 'S01-EX01'.  As you can see, through the Exchange Management Console there is no Graphical Interface for Administering a Routing Group Connector (RGC).  We will instead use the Exchange Management Shell to invoke the 'Get-RoutingGroupConnector' Commandlet.

10.  Initially, when I offer the Exchange Management Shell Commandlet 'Get-RoutingGroupConnector' we see data listed in a Table from the default feedback.  Here's the Exchange Management Shell Commandlet:

get-routinggroupconnector

11.  Next, to see the full detail for this EMS Commandlet I issue the following Commandlet using the 'Pipeline Parameter' (|) followed by 'Format List' (fl):

get-routinggroupconnector | fl

12.  The second half of the EMS window appears here.  Notice we have rich granularity in the Attributes available.

13.  So, what do we have here?  This is another variation of the EMS Commandlet denoting additionall Attributes be displayed.  Here we can see both 'Source Transport Server' and 'Target Transport Server' by using the followng EMS Commandlet variation:

get-routinggroupconnector |fl targetroutinggroup,targettransportservers,sourcetransportservers

14.  Next I add the 'Cost' Attribute to display in this EMS Commandlet.  Here's the Commandlet syntax:

get-routinggroupconnector |fl targetroutinggroup,targettransportservers,sourcetransportservers,cost

15.  Finally, I personally favor the following EMS Commandlet Syntax for this Commandlet.  It allows me to keep track of versional changes.

get-routinggroupconnector |fl targetroutinggroup,targettransportservers,sourcetransportservers,cost,whencreated,whenchanged

16.  Okay, so where are we?  We just spent time using the Exchange Management Shell (EMS) to analyze the output of the Routing Group Connector that links the Legacy Exchange 2003 Organization to the initial Exchange 2007 Hub Transport Role Server in our Messaging Environment.  We are reviewing these configuration details to understand how and where SMTP Messages 'Route' in a Transitional Strategy that involves Exchange 2003 and Exchange 2007.

17.  Next, I would like to review the 'Routing Log Viewer' available from within the Exchange Management Console in Exchange 2007.  You will find it on the 'Tools' leaf of the Exchange 2007 Management Console.

 

18.  The 'Routing Log Viewer' in the Exchange 2007 Management Console (EMC) provide XML Files that 'record' the Routing Configuratin across all Routing Group Connectors, Send Connectors and Receive Connectors.  Foreign Connectors are not included in the Routing Log Viewer as Foreign Connectors simply 'pickup' SMTP Messages from the 'Pickup' Directory. 

19. I select the most recent XML File to examine the contents.

20.  Most Exchange System Engineer's have never seen, nor used the Routing Log Viewer.  Here we can see the Active Directory Site whereby the Exchange 2007 Servers are visible.  And, the Exchange 2003 Routing Group where the Exchange 2003 Servers are visible.

21.  Upon moving to the 'Servers' Tab in the Routing Log Viewer we see a more detailed breakdown of both Exchange 2003 and Exchange 2007 Servers.  Note the Exchange 2007 Servers use the Active Diretory Sites as their respective 'Routing Boundaries' (lower portion of capture) while the Exchange 2003 Servers use the Routing Group as their respective 'Routing Boundaries'.

22.  Next we observe the 'Send Connectors' Tab of the Routing Log Viewer.  Some of the details of the Routing Group Connector are present in this Graphical Interface. 

23.  As part of the endeavor to understand SMTP Message Routing across a Routing Group Connector I would like to 'follow' a message from an Exchange 2007 User Mailbox, across the Routing Group Connector to an Exchange 2003 User Mailbox.  We can use Message Tracking available in the Exchange 2003 System Manager (ESM) and in the Exchange 2007 Management Console (EMC).  Here I begin logging in as an Exchange 2007 Mailbox User fictitiously named 'Steve Railson' to send e-mail to an Exchange 2003 Mailbox User named 'Field1'.

24.  Logging in to prepare e-mail for an Exchange 2003 Target (from an Exchange 2007 Mailbox User).

25.  E-mail prepared and sent.  This message should 'travel across' the Exchange 2007 Hub Transport Role Server to the Routing Group Connector (RGC), ultimately to the Exchange 2003 Routing Group Server and finally to the destination Exchange 2003 User Mailbox Server.  Let's follow it's path!

26.  Confirmation of the 'CC' of this message from/to himself.

27.  I move to the Exchange 2003 Mailbox Server Role titled 'S01-EX00-1' to confirm an Exchange 2003 Mailbox User named 'Field1'.  Confirmation complete!  Our Mailbox is on this server!

28.  When I open the 'Messaging Tracking Center' in Exchange 2003 and input query parameters (like Exchange 2007 Mailbox User Name, Mailbox Server Name, etc.) the response is identification of the exact message sent.  Next, let's look a the Message Tracking in the Exchange 2007 Messaging Tracking to determine how this SMTP Message 'travelled' using which Connector (it should be our Routing Group Connector!).

29.  I move to the EMC on an Exchange 2007 Hub Transport Role Server.  Next, I open the Message Tracking Application.

30.  When I input a narrow time range (the exact 5 minute interval I know the message was sent) I receive a response with the exact message tracking detail.  Now, here is our point of confirmation - will the SMTP Message from the Exchange 2007 Mailbox User (srailson User ID) transmit over the Routing Group Connector as we expect?  Let's see.

31.  Yes!  Success!  A closer examination of the 'ConnectorID' Attribute and we see 'Intra-Organization SMTP Send Connector' indicated as the Connector used to transmit this SMTP Message from the Exchange 2007 Hub Transport Role to the Exchange 2003 Routing Group Server.  Thus providing 'mailflow' between a Legacy Exchange 2003 Organization and new Exchange 2007 Hub Transport Role Servers in the same Exchange Organization.

In this Blog entry I review many of the configuration parameters of an Exchange 2007 Routing Group Connector.  I use the many of the Exchange 2007 Applications for analysi, including the Exchange Management Shell Commandlet 'get-routinggroupconnector', the Exchange Management Console, the Routing Log Viewer and Message Tracking.  While, when working on the Exchange 2003 Server Role I use the Exchange System Manager and the Message Tracking Center.  All of these Tools prove useful when determining the SMTP Message Routing in a joint Exchange 2003 and Exchange 2007 Messaging Infrastructure!