Installing and configuring the Outlook Live Management Agent with Forefront Identity Manager 2010.   9 comments

Hi folks,

As much as it surprises me, I still receive the odd question about the Outlook Live Management Agent when used in conjunction with Forefront Identity Manager 2010. It’s with that in mind that I’m providing the following brief write-up on how to manually install the OLMA, and although there’s not a lot of value in covering the attribute flow in depth, I’ll at least provide a guideline on how to configure the management agent to work with Live@EDU.

Please pay attention to the fact I mentioned this relates to a manual installation of the agent and subsequent configuration. We do not use the Self Service Portal component form FIM 2010 as Sharepoint is not our university’s standard for collaboration. As such, we only use the Synchronisation Service Manager along with writing the code ourselves.

Part 1: Installing the Outlook Live Management Agent.

  1. Download the “OLSync R4 Download Package.zip” file from connect.microsoft.com – you’ll need to use your Live@EDU registered admin account to do this;
  2. Extract the contents of the .zip file;
  3. Run the Galsync_R4_v2.msi installer:
    1. Welcome screen = Next;
    2. License agreement page = I agree & Next;
    3. Installation option = Extract files for manual installation & Next;
    4. Extract files = choose a directory & Extract;
    5. Finish.
  4. Using Explorer, navigate to the location where you extracted the files to from step 3 above where you should see the following three sub-directories:
    1. Extensions;
    2. SourceCode;
    3. UIShell
  5. Copy all of the contents of each directory as follows (I’m just using the default installation directory for FIM as the destination):
    1. Extensions -> C:\Program Files\Microsoft Forefront Identity Manager\2010\Synchronization Service\Extensions
    2. SourceCode -> C:\Program Files\Microsoft Forefront Identity Manager\2010\Synchronization Service\SourceCode
    3. UIShell\XMLs\PackagedMAs -> C:\Program Files\Microsoft Forefront Identity Manager\2010\Synchronization Service\UIShell\XMLs\PackagedMAs
  6. You have now completed a manual installation of the Outlook Live Management Agent.

Part 2: Configuring the Outlook Live Management Agent.

  1. Start the Forefront Synchronisation Manager;
  2. Select the “Management Agents” tab;
  3. Choose the Create action either from the side menu, or the context-sensitive menu;
  4. Choose “Outlook Live Management Agent” from the drop-down list named “Management agent for”;
  5. Give it whatever name you feel suits the purpose;
  6. Next;
  7. Set “Connect to” equal to “https://ps.outlook.com/powershell;”
  8. Set “User” equal to the account you created as your service account, which by default will look something like “olsync@university.edu.au”;
  9. Set “Password” equal to whatever you set the password to be;
  10. Next;
  11. Click the New button:
    1. Set “Parameter Name” equal to “ProvisioningDomain”;
    2. Set “Value” equal to your Live@EDU domain name, for example “university.edu.au”;
    3. For a list of this and other parameters you can set, have a read of this outlook.com help page.
  12. OK;
  13. Next;
  14. Next (skipping “Configure Attributes”);
  15. Next (skipping “Map Object Types”);
  16. Next (skipping “Define Object Types”);
  17. Next (skipping “Configure Connector Filter” – though you may want to come back to this depending on your requirements);
  18. Configuring the “Join and Projection Rules” section depends on your current FIM topology and could take a light year to discuss. If you’ve work with ILM/FIM before, just do what you do best here. If you have absolutely no idea, then you can use the following as a simplistic example for creating mailboxes. We use the metaverse attribute “accountName” as our primary key, meaning our configuration for this screen is as follows:
    1. Highlight “Mailbox”;
    2. Click “New Join Rule”;
    3. On the left side (“Data source”) choose “Alias”;
    4. On the right side (metaverse) choose “accountName”;
    5. Click the “Add Condition” button, and if you’re prompted about the attribute being non-indexed, just accept that and move on;
    6. OK;
  19. Next;
  20. Okay, with this screen you’re largely on your own – sorry. There’s just too much scope for variance here between organisations/institutions, and it’s extremely likely you’re also going to be dealing with writing your own rule extensions here, too. Still, just so you have some point of reference, here’s the attributes we populate with what they’re based on in brackets:
    1. UserPrincipalName (custom e-mail address attribute);
    2. Name (accountName metaverse attribute);
    3. DisplayName (displayName metaverse attribute);
    4. Alias (accountName metaverse attribute);
    5. WindowsLiveID (custom e-mail address attribute – same as UserPrincipalName);
    6. FirstName (firstName metaverse attribute);
    7. LastName (lastName metaverse attribute);
    8. EmailAddresses (rule extension as there are multiple addresses added to accounts, and we also have to be able to handle name changes – as I suspect you will, too);
  21. Next;
  22. Next (skipping “Deprovisioning” – again, it’s up to you as to how you handle this – if at all);
  23. If you have enabled PCNS – or intend to, then you can use this final screen (“Configure Extensions”) to enable password management, and if you have written one, to include the “Rules extension name” (a .DLL file – which is beyond the scope of this article).
  24. You have now finished defining the structure of your Outlook Live Management Agent.

Part 3: Rules extensions.

This is an exceptionally important part of the process, but beyond the scope of this article. Essentially, if you’re not already familiar with ILM/FIM then you’re possibly not aware that you will need to create at least one rule extension which handles the provisioning of new objects into the Live@EDU connector space.

If you deployment requires it, you may also need to write another rules extension that handles the customised calculation of values to flow back out from the metaverse to the connector space for the OLMA. To give you a simple example, the code might do something as simple as combine a student’s given and surnames to produce a display name. You can’t do this with the “Direct” flow (in the attribute flow screen of the MA). It needs to be an “Advanced” export flow, for which you specify the rule name and write the code to go along with it.

At this point you have done enough to get the OLMA talking to Live@EDU – so long as there no other peripheral issues such as ports being blocked by firewalls and whatnot. You can proceed to run a Full Import and Full Synchronise cycle(s) to populate the connector space and metaverse respectively, though before you can provision accounts into Live@EDU, you’ll have to write your own code to handle the provisioning of the object within the Provision() function.

Cheers,
Lain

9 responses to “Installing and configuring the Outlook Live Management Agent with Forefront Identity Manager 2010.

Subscribe to comments with RSS.

  1. Hi, very useful information thank you, but I am confused somewhat by step 20 part 1 where you have the userprincipalname mapped to a custom email address attribute. I can’t see any such beast in the “Configure Attribute Row” wizard. The Metaverse attributes are clear to see, but I can’t see any method to add custom attributes. Could you expand on this a little, please?

    • Hi Andrew,

      Because it’s a custom attribute, you won’t see it by default. The basic process for creating a custom attribute is:

      1. Select the Metaverse Designed tab within Synchronisation Service Manager;
      2. Select the class you wish to extend (such as person);
      3. Choose the “Add Attribute”.

      We added two custom attributes to avoid any future divergence between our current standards:

      1. For the WindowsLiveID;
      2. For the mailbox GUID, which we import back in as confirmation of a successful creation.

  2. Hello Lain, I had almost the exact comment as Chapman… Thank you so much for the post. I have been put in charge of FIM (I have not used it before this week) and LIVE@ EDU (two weeks ago) for the 25k+ students in our district….. I have been reading and researching everything I could find on this and there is not much out there. Which leeds me to the question I have…. Would you know where to get more information on the “rule extension” in the last line?

    • Hi Travis,

      This is a hard one to answer in a concise manner – it’s pretty much worth a new blog entry. Still, I’ll try and give you some quick pointers.

      First, this provisioning business revolves around two Visual Studio projects:
      1. Handles the provisioning of objects (and deprovisioning if that’s in scope);
      2. Handles the wonderous things known as extension rules – which are really just glorified case/switch statements.

      To create the object provisioning project:
      1. Open Synchronisation Service Manager
      2. Tools menu -> Options
      3. “Create Rules Extension Project..” button
      4. Choose your project’s name, location and development language while making sure Project type is Rules Extension.

      You can then copy this bunch of files to your workstation from which you can use them in Visual Studio.

      To create the rules provisioning project:
      1. Open Synchronisation Service Manager
      2. Actions menu -> “Create Extension Projects…”
      3. Choose your preferred development language, name and location while making sure the Project Type is Rules Extension

      As with the object provisioning project, you can now also copy this bunch of files to a separate subdirectory on your workstation and use these in Visual Studio.

      Both these projects are created as Vistual Studio 2008 projects, and you’ll also have to redefine the OutPath, as compiling will throw up some path errors otherwise. These projects are also safe to convert over to Visual Studio 2010 projects, in case you were wondering.

      Within the provisioning project, you want to focus on the Provision() method. Here’s something you can look at as a reference for this:
      http://msdn.microsoft.com/en-us/library/ms698375(VS.85).aspx

      Within the extension rule project, you’ll want to focus on the MapAttributesForExport() method. Again, here’s a reference you take dig into:
      http://msdn.microsoft.com/en-us/library/ms695345(v=VS.85).aspx

      To give you something of an example of an extension rule, I have what we refer to as a flow that converts the single letter campus initial into the full name. Looking at things backwards again, with the code first, this is part of the MapAttributesForExport() method:

      Case “exportADStudent_Campus”
      If (mventry(“officeLocation”).IsPresent) Then
      Select Case mventry(“officeLocation”).Value.ToUpper
      Case “B”
      csentry(“physicalDeliveryOfficeName”).Value = “Broome”
      Case “F”
      csentry(“physicalDeliveryOfficeName”).Value = “Fremantle”
      Case “M”
      csentry(“physicalDeliveryOfficeName”).Value = “Melbourne”
      Case “S”
      csentry(“physicalDeliveryOfficeName”).Value = “Sydney”
      Case Else
      csentry(“physicalDeliveryOfficeName”).Value = “Undefined”
      End Select
      End If

      The “exportADStudent_Campus” is precisely the same name as what I labelled the advanced mapping type within the “Configure Attribute Flow” section within Synchronisation Service Manager. The end result of this case statement is that I’m setting the connector space (in this case it’s Active Directory) attribute of physicalDeliveryOfficeName to the full name of the campus.

      Again, this is a very expansive topic, but hopefully something in here might help you get started with it all.

      Cheers,
      Lain

    • Travis, are you running Exchange? If so this link may help (it certainly helped me): http://blogs.technet.com/b/kristinw/archive/2011/02/23/installing-galsync-4-2-on-forefront-identity-manager-fim.aspx. The part where you select your version of Exchange from the installation folders configures your extensions.

      • Thanks for the update, Andrew.

        The two things you will need to consider about the linked article in your planning stage are:
        1. If you’re running an existing installation of FIM, then importing the server configuration will wipe your existing configuration (ie any existing management agents). Though if Live@EDU is the only reason you’re running FIM, this won’t be an issue.
        2. You’re stuck with the pre-compiled object provisioning and rule extension DLLs. If you need to make any customisations to your provisioning process, you’re going to be back to the above process.

        The obvious positive of using the import server option is that the OLMA is configured for you to working defaults – you do not need to step through the manual process I’ve outlined above. If you also only ever expect to work with Direct flows (or none at all if you’ll never touch the attribute flows), then it’s an infinitely better option.

        Cheers,
        Lain

  3. Hi,

    Thanks for the comprehensive guide but i’m still confused as to how to build the DN to pass to Outlook Live….
    We have MA extension code that sucessfully creates the accounts in AD from the HR system but to acheive that we manually define the DN of the object and the connector knows that there are provisioning tasks for that MA and connector space.

    As i understand it the DN of the Live@ user will be a guid generated by the Outlook live platform or should i just generate my own guids and pass them up that way.

    Jason

    • Hi Jason,

      The process for the Live agent is rather similar to what you’ve already done – in fact, you can copy and paste that provisioning section and with some minor adjustments it’ll work with Live just fine. Here’s an example from our Provision() function:

      cMA = mventry.ConnectedMAs("Students - Live")

      If (cMA.Connectors.Count < 1) And _
      (mventry("objectSID").IsPresent) Then

      oDN = cMA.EscapeDNComponent("CN=" & mventry("accountName").Value)

      csEntry = cMA.Connectors.StartNewConnector("Mailbox")
      csEntry.DN = oDN

      csEntry("export_password").Values.Add(dob)
      csEntry.CommitNewConnector()
      End If

      For reference, our metaverse accountName is effectively just the sAMAccountName. We actually get that from our HR system (which is really just an SQL Server-based product) and flick that out to AD, two AD LDS instances and Live@EDU. We also make sure the Active Directory attribute objectSid has been flowed back into the metaverse first via the “(mventry(“objectSID”).IsPresent)” check, as we don’t want an account in Live@EDU that wasn’t first successfully created in AD, but you can remove this part of the “If” statement if that’s not a concern for you.

      You’re correct with your final statement on how the DN is handled by Live@EDU. While you specify this value as your original DN, it is in turn modified by Live@EDU to be a GUID. Knowing this is important when it comes to defining the join and projection and attribute flow section within the Live@EDU MA. As you can see from the code above, we just use the accountName (which again is identical to the sAMAccountName from AD) to get the object up there and let Live@EDU take care of the GUID generation.

      Rather than linking the Live@EDU attribute “DistinguishedName” to the metaverse “accountName”, I actually create the join on Live.Alias = MV.accountName, since we also flow accountName outbound to the Alias attribute on creation. Since Alias has to be unique anyway, this works perfectly for us.

      For posterity, we do actually flow the Live@EDU DistinguishedName back into the metaverse into a custom attribute we defined, but that’s just because we have other processes in place that aren’t meant to run until an object’s been successfully provisioned into Live@EDU, so we only do this as a way of confirming that everything worked in terms of provisioning the account.

      Cheers,
      Lain

  4. In case it is relevant for anyone reading: It is possible to open a ticket with Live@Edu support to get the Olsync MSI that is compatible with FIM. I had to do this because I was having some serious issues with the initial configuration of the GALSync Management agents extracted using the process talked about in this thread.

Leave a reply to Lain Robertson Cancel reply