Live@edu ilm2007

Live@EDU Escalation Engineer
Training
Module 6: Identity Lifecycle Manager

DRAFT V1.1 Released: July 12, 2010

Conditions and Terms of Use
Microsoft Confidential - For Internal Use Only
This training package content is proprietary and confidential, and is intended only for users
described in the training materials. This content and information is provided to you under a Non-
Disclosure Agreement and cannot be distributed. Copying or disclosing all or any portion of the
content and/or information included in this package is strictly prohibited.
THE CONTENTS OF THIS PACKAGE ARE FOR INFORMATIONAL AND TRAINING PURPOSES ONLY AND ARE PROVIDED "AS
IS" WITHOUT WARRANTY OF ANY KIND, WHETHER EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE
IMPLIED WARRANTIES OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE, AND NON-INFRINGEMENT.

Training package content, including URL and other Internet Web site references, is subject to
change without notice. Because Microsoft must respond to changing market conditions, the
content should not be interpreted to be a commitment on the part of Microsoft, and Microsoft
cannot guarantee the accuracy of any information presented after the date of publication. Unless
otherwise noted, the companies, organizations, products, domain names, e-mail addresses, logos,
people, places, and events depicted herein are fictitious, and no association with any real company,
organization, product, domain name, e-mail address, logo, person, place, or event is intended or
should be inferred.

Copyright and Trademarks
© 2010 Microsoft Corporation. All rights reserved.
Microsoft may have patents, patent applications, trademarks, copyrights, or other intellectual
property rights covering subject matter in this document. Except as expressly provided in written
license agreement from Microsoft, the furnishing of this document does not give you any license to
these patents, trademarks, copyrights, or other intellectual property.
Complying with all applicable copyright laws is the responsibility of the user. Without limiting the
rights under copyright, no part of this document may be reproduced, stored in or introduced into a
retrieval system, or transmitted in any form or by any means (electronic, mechanical,
photocopying, recording, or otherwise), or for any purpose, without the express written
permission of Microsoft Corporation.
For more information, see Use of Microsoft Copyrighted Content at
http://www.microsoft.com/about/legal/permissions/.
Microsoft®, Internet Explorer, and Windows® are either registered trademarks or trademarks of
Microsoft Corporation in the United States and/or other countries. Microsoft products mentioned
herein may be either registered trademarks or trademarks of Microsoft Corporation in the United
States and/or other countries. All other trademarks are property of their respective owners.

Table of Contents
About This Course .................................................................................... Error! Bookmark not defined.
Course Contents .................................................................................................. Error! Bookmark not defined.
Document Conventions ....................................................................................... Error! Bookmark not defined.
Technical Terms, Commands, and Program Code ........................................... Error! Bookmark not defined.
Notes ............................................................................................................... Error! Bookmark not defined.
Tables and Figures ........................................................................................... Error! Bookmark not defined.
Course Document and Slide Numbering ......................................................... Error! Bookmark not defined.
Using the Keyboard and Mouse in a Virtual Machine ......................................... Error! Bookmark not defined.
Module 1: Introducing <product or technology> .................................... Error! Bookmark not defined.
Lesson 1.1: Title ....................................................................................... Error! Bookmark not defined.
Topic H2 ............................................................................................................... Error! Bookmark not defined.
Subtopic H3 ..................................................................................................... Error! Bookmark not defined.
Lesson Review ..................................................................................................... Error! Bookmark not defined.

Lab 1: Title ................................................................................................ Error! Bookmark not defined.
Module Review ........................................................................................ Error! Bookmark not defined.
Module 2: Installing and Configuring <product or technology> .............. Error! Bookmark not defined.

Lab 2: Title ................................................................................................ Error! Bookmark not defined.
Module 3: Managing and Maintaining <product or technology>............ Error! Bookmark not defined.

Topic H2............................................................................................................... Error! Bookmark not defined.
Lab 3: Title ............................................................................................... Error! Bookmark not defined.
Module 4: Troubleshooting <product or technology> ............................ Error! Bookmark not defined.


Lab 4: Title ............................................................................................... Error! Bookmark not defined.
Additional Resources ............................................................................... Error! Bookmark not defined.
Course Review ......................................................................................... Error! Bookmark not defined.
Course Assessment.................................................................................. Error! Bookmark not defined.
Appendix *: Title...................................................................................... Error! Bookmark not defined.
Overview Topic H3 .......................................................................................... Error! Bookmark not defined.
Appendix Topic H3 .......................................................................................... Error! Bookmark not defined.

DRAFT V1.1 Live@EDU Escalation Engineer Training

Module 6: ILM and Live@Edu
This is the final module in the Live@Edu class. It covers ILM and our different
management agents.

Before You Begin
Before starting this module, you should:
 Have a working understanding of Live@Edu under both Hotmail and Exchange
 Done all the previous Live@Edu modules

What You Will Learn
After completing this module, you will be able to:
 Understand ILM and its complexities
 Configure and Install all three editions of the @EDU Management Agents.
 Troubleshoot common configuration issues with all three versions.

Global Technical Readiness
Microsoft Confidential - For Internal Use Only 1

Module 6: Identity Lifecycle Manager DRAFT V1.1
Lesson 1: Identity Lifecycle Manager

This lesson goes into depth about ILM and its configuration. Note that the vast majority
of this documentation came from existing Admin Guides and online documentation that is
available.

What You Will Learn
After completing this lesson, you will be able to:
 Describe how ILM Functions.
 Understand concepts like the Meta Verse.

2 © 2010 Microsoft Corporation. All rights reserved.


Identity Lifecycle Manager
What is ILM
ILM 2007 is a metadirectory product that has a variety of uses for data synchronization
and identity management. In the case of the Live@edu program, it will be used to
facilitate the management of accounts by synchronizing data from the data source for
student information and Windows Live. To further understand the role of ILM 2007 as it
relates to Live@edu it is important to understand the fundamentals of this type of
product.
The ILM 2007 application runs on Windows 2003 or 2008 Enterprise Edition. It relies
upon Microsoft SQL Server as the application data store to retain all of the settings for
ILM 2007 as well as the identity data that is synchronized through it.

Metadirectory
A metadirectory collects information from different data sources throughout an
institution and then combines all or part of that information into an integrated unified
view. This unified view presents all the information about an object such as a student or
network resource that is contained throughout the institution. An Identity Management
system may have a metadirectory at its heart and ILM 2007 is such a system. A
metadirectory performs the following functions:
 Connects to a variety of data sources, importing a desired subset of data from each one
 Combines all the information about each student or resource into a single entry
 Presents to the institution the unified view of all known information about each student
or resource
 Enforces rules as to which sources are authoritative for a given attribute and what
precedence applies where more than one source is authoritative

Microsoft currently distributes two separate versions of ILM 2007. The Live@edu version
allows an institution to connect to one data source for account imports and to Windows
Live for account creation. The full version of Microsoft Identity Lifecycle Manager 2007 is
needed to connect to more than two data sources. The following table lists the supported
management agents for the full version of Microsoft Identity Lifecycle Manager 2007.
This table illustrates the capabilities of the full version of ILM 2007 to communicate with
some of the types of data sources that ILM 2007 includes out of the box.
System Management Agent

Network Operating Systems Microsoft Active Directory Windows Server 2003 R2, 2003, and 2000
and Directory Services Microsoft Active Directory Application Mode Windows Server 2003
R2 and 2003
Microsoft Windows NT 4.0



IBM Tivoli Directory Server
Novell eDirectory 8.6.2, 8.7, and 8.7.x
Sun Directory Server (Netscape/iPlanet/SunONE) 4.x and 5.x
Mainframe IBM Resource Access Control Facility
Computer Associates eTrust ACF2
Computer Associates eTrust Top Secret
E-mail and Messaging Microsoft Exchange 2007, 2003, 2000, and 5.5
Lotus Notes 6.x, 5.0, and 4.6
Applications SAP 5.0 and 4.7
Telephone switches
XML-based systems
DSML-based systems
Databases Microsoft SQL Server 2005, 2000, and 7
IBM DB2
Oracle 10g, 9i, and 8i
File-Based Attribute value Pairs
CSV
Delimited
Fixed Width
Directory Services Markup Language (DSML) 2.0
LDAP Interchange Format (LDIF)
All Other Extensible Management Agent for connectivity to all other systems

If the previous table does not include your student data source, you have several options.
The first is to get the data out of your data source and into a format that ILM 2007 can
recognize, such as an LDIF file or delimited flat-file. Flat-files can often be the lowest
common denominator between integrating two systems. You also have the possibility to
build your own extensible management agent to connect to the data source.

Data Aggregation
In most institutions, student information exists in many different data repositories
resulting in duplication of student information; there is no single, reliable place to go for
this information about a student or faculty. Directories that hold identity information are
often incompatible. These incompatibilities include different naming conventions,
different directory schemas, different communication protocols and different data
formats. The number of places in which organizations must manage identity information
increases with the addition of new systems. To solve the issues that result from identity
data residing in multiple repositories you can use a metadirectory to:
 Combine the data for a specific person or resource in the metadirectory, thereby
creating a single entry that contains some or all of the identity information from each
directory.
 Present a single unified view that contains some or all of the attributes from the
different directories regardless of whether the directories are compatible.



 Provide a platform that can become the basis of an Identity Management (IdM) system –
it contains the authoritative identity information for objects.

Data Synchronization
Because an institution‘s student information is often contained in different data
repositories, a change made to data in one repository is not automatically made in any of
the other repositories. Making the change throughout the organization requires the
administrator(s) to make the change in each directory manually. Therefore, updating data
in each directory is costly, unreliable and may even present a security risk. Unmanaged
identity information quickly becomes disorganized which results in identity information
that is not synchronized throughout the organization. To manage changes to identity
information you can use a metadirectory to:
 Identify changes to identity information from many sources.
 Propagate those changes automatically to other directories as appropriate (i.e. as
defined by rules which have been configured to support company procedures).
 These changes can be modifications to attributes or to whole objects. This change
detection infrastructure keeps the directories synchronized.

Data Enforcement
Data ownership issues often prevent effective coordination of an institution‘s identity
information even though it may be technically possible. Certain departments maintain a
strong ownership of their data. Although ownership of data is not an issue when
directories remain separate, retaining ownership when data is synchronized among
multiple directories becomes more challenging. To address data ownership issues you
can use a metadirectory system to:
 Enable administrators to define and enforce ownership relationships at the attribute
level.
 Allow, block, or reverse changes made to identity information. If a change to data is
consistent with the ownership rules it is allowed; otherwise, it is blocked (allowing local
control) or reversed.
 Ensure that the departments that own the identity information in a specific directory
will maintain that ownership even when that directory is synchronized with other
directories in the organization.

Data Source
A data source for the Live@edu solution is any place where you have student information
– a directory, database, or other data repository that contains data to be integrated within
ILM 2007. Data sources can be enterprise directories (Active Directory, Novell, ADAM,
etc), databases (Oracle, SQL, etc), or even data in flat files, such as LDIF, DSML or
delimited text.



Management Agent
A management agent is a component of ILM that manages the data associated with a
specific data source and connectivity to the data source. The management agent not only
connects to the data source, but is responsible for managing the flow of data (inbound
and outbound). There is at least one management agent for each data source. For many
management agents, ILM 2007 communicates directly with the data source – these are
call-based and examples of such directories are LDAP and Active Directory. For others,
where a direct call is not possible, an intermediary file is used such as AVP, LDIF or fixed
width – these are file-based management agents. In some cases, the situation may be
more complex: there may be no management agent specifically for the data source or the
data source may, for example, support a mixture of file-based and call-based activities so
that a simple file-based management agent is insufficiently feature-rich. In such a case,
the extensible management agent allows a developer to create code which instructs the
management agent how to communicate with the data source.
Management agents are primarily configured by setting their properties within the
wizard-like interface in the Identity Manager, the application that manages and
configures ILM 2007. There are occasions when more complex operations are desired
than those possible through the user interface (for example, combining the contents of
FirstName and LastName to make a displayName); in this case, a management agent can
be augmented by .dll extensions produced using Visual Basic.NET or C# or, indeed, any
language making use of the .NET Common Language Runtime (CLR). It is not necessary to
write code in most basic implementations of Live@edu, however remember that the
capability is there if needed.

Metaverse
The Metaverse is a set of tables within ILM 2007 that contain the integrated identity
information from multiple data sources. All identity information about a specific student
or object, which is stored in multiple data sources, is synthesized into a single entry in the
metaverse. Your students will most likely have a single unique object in the metaverse
representing each student.

Connector Space
The connector space is a storage area and a staging area. It stores the different states that
are used to decide whether information in a data source has changed, or needs to be
changed. It is also, where changes are staged on their way into or out of ILM 2007. Each
data source has its own logical area in the connector space, which is managed by its
corresponding management agent. The connector space is essentially a mirror of the
related data source, with each object in the data source having a corresponding entry in
the connector space. The connector space does not contain the data source object itself,
but a subset of the object‘s attributes, as defined by the management agent.



Provisioning
When we think of objects in data sources, they will often be accounts, such as an Active
Directory® service account. The term account is often used even for groups, resources,
and so on. Provisioning is the creation of accounts in data sources (such as LDAP
directories, databases, and e-mail systems). Once provisioned, the account attributes can
be managed as those of any existing object. The manual creation (and removal or
disabling) of accounts in several systems is administratively burdensome, prone to errors
and inconsistency, and leaves potential security gaps. For Live@edu, the act of
provisioning refers to the creation of a Windows Live ID account. You can use ILM 2007
to:
 Automatically create accounts (objects) in directories, based on their addition in one
(authoritative) directory.
 Continue to manage those accounts, including removal (de-provisioning) and
disablement.

Provisioning will occur within ILM 2007 to create the Windows Live IDs in the Windows
Live environment. The Windows Live Management Agent is entrusted to handle this task
on behalf of ILM 2007. This management agent will take the e-mail address of the student
to be provisioned from the data source, connect to the Windows Live server, create the
account and then return the confirmation to ILM 2007. Similarly, should the user who has
an account need to have the account evicted (deleted) from the school namespace, the
management agent will again connect to the Windows Live server to evict the account.

In a simple to management agent System like the ones that are most commonly used for
Live@Edu the flow looks like.

In this example, data is being taken from a connected MA, Say ADMA, brought into the
connector space where Projection or Join rules are applied. From there the provisioning



rules trigger a creation into another connector space, any management agent. Finally, that
management uses an Export operation to push the data from ILM into its systems.
For systems that are more complicated it can look like:

In this example, there are multiple management agents and connector spaces. Here we
have a single data source that projects data into the metaverse. Another management
agent joins to the recently projected entry. This could be an example where you want
your HR/billing system to initiate the create of accounts however you may have an
existing account in a SQL or other data source. There are also 2 MAs that are triggered off
the provisioning code which would create a user. This logic is configurable where it could
create multiple different types of users. For instance a HR system create could trigger
admin accounts in a website or just a single user. The provisioning rules would calculate
that. Note that a single MA isn’t limited to just project or join to the metaverse. As you
can see there are 2 basic types of operations into the metaverse and 1 out. Based on
scenarios you may want to attempt a Join before you do a project. You could also
introduce a join when you have a projection rule. ( into : join & project ; output :
provisioning )
This is the core foundation of ILM and allows for a near infinite of flexibility and
configuration. The design is versatile enough to allow for any number of identity
management scenarios. The scenarios for Live@Edu are really only touching a small
fraction of what ILM can actually do.



Running a Synchronization
During development, a management agent is executed by means of the user interface. In
production systems, it is desirable to run management agents in sequence without user
intervention, both on a scheduled basis, and occasionally in response to specific events
(for example, the submission of a new student registration). Such automated execution of
management agents is achieved using the WMI functions of ILM 2007 in conjunction with
a scheduling agent (described in detail later).

Extensible Management Agents
Management agents allow ILM 2007 to connect to a wide variety of different data sources
to manipulate data from them. While most of the management agents allow for
connectivity to a specific connected data source the extensible management agent has
expanded the ILM 2007 connectivity options by allowing developers to build any
connection they want by simply creating code within the confines of a management agent.
Information is provided in the ILM 2007 developer reference help files and on MSDN.

State Based System
ILM 2007 is a state-based system. There are advantages to this (particularly robustness)
as well as potential disadvantages (extra processing and storage) but the actual result is a
very effective and flexible compromise. ILM 2007 stores a hologram for each external
object of which it is aware; this hologram represents the current view of the data stored
in each data source. During a subsequent import of the data from the data source, the
imported object data is compared with the hologram. If any differences are detected
between the two (for example, the values for the Student Type attribute do not match, or
a new or missing object is detected), a change is inferred and the change is passed to the
ILM 2007 Sync Engine to be propagated through the metadirectory. In a deployed system,
management agent runs are invoked by scheduled scripts, which are run either on a
scheduled basis or in response to external events (perhaps a web portal could invoke a
run to ensure that accounts created through the portal are created). ILM 2007 then asks
for data -- it is a pull system, which avoids the need for a push agent on each data source.
However, ILM 2007 can work with Delta Import (i.e. imports of only those objects that
have changed; as it happens, Exports are always delta in nature). Some data sources
support this already, others may be able to with some modification, yet others simply
cannot support this feature. Where deltas can be used, there are considerable savings in
processing time (traffic and state comparisons). Depending on how many students are
being processed by the system and the frequency of the processing, designing the data
source to provide ILM 2007 with delta updates may be extremely important. ILM 2007
can work entirely with Full Imports, minimizing the intrusion on data sources;
additionally, it is sometimes necessary to use a Full Import (for example on initial import
or when recovering from a data source failure).



Lesson Review
Topics covered in this lesson include the following:
 How ILM operates
 The Concept of the Metaverse
 ILM being a State based system
Answer the following questions to confirm your understanding of lesson topics.
1. How does ILM work?

ILM operates through a series of connected MAs import and export data. Based on
provisioning rules action is taken on the various objects and data is synchronized across. It
has the ability to connect to multiple directory sources and is extensible enough to handle
new ones.

2. Question

Answer



Lesson 2: Live@Edu Specific Management
Agents
This lesson will explain more of the specifics of ILM with regards to Live@Edu. As you
read above ILM depends on connected Management Agents to enable data access
between the various components.

What You Will Learn
After completing this lesson, you will be able to:
 Understand our MAv2 Offering
 Understand our MAv3 Offering
 Understand OLSync


Lesson 2: Live@Edu Specific Management Agents

Management Agent V2 for Windows Live
Originally, Live@Edu's management agent was developed by an MCS consultant as a
means to integrate MIIS 2003, ILM 2007's predecessor, to Windows Live. The original
version, MAv1, was truly a first release product and functioned well. It did what it was in
scope to do.
Sortly after MAv1 was released it became apparent that the onboarding process for
Live@Edu needs to change drastically. We used to only be able to configure schools once
per quarter and depended on several other teams at Microsoft for provisioning. We
wanted to allow schools to onboard more quickly and shorten the pipeline.
MAv2 was the way to accomplish it. During the upgrade process from V1 to V2 we
changed a number of things dramatically.
 V2 required the use of certificates instead of Username/Password authentication
 V2 required network ACLs be put in place to allow for SCS offers to be provisioned
With these changes we were able to more agile deploy customers and speed up the
onboarding process to once per Quarter to a month deployment cycle.

How does MAv2 actually work?
MAv2 makes direct calls to SCS, LiveID, and Hotmail to handle account provisioning. As
we learned in Module 2 this can use a Certificate and SiteID. SCS is a unique platform and
only accepts certificate authentication. This requirement drove the change from V1 to V2
to use certificates. The same certificate that was uploaded to IDSAPI is the same one
configured in SSAPI, SCS's API. The relationships look like:



Inner workings
MAv2 creates accounts differently than the sequence diagram that was presented earlier.
You can see the updated flow below:

Here we see that MAv2 communicates directly with each service. Note that it has built in
error handling to overcome communication glitches like a timeout to LiveID on create
credential where it actually succeeded but we didn't get the data in time. In that instance
we automatically use another call in LiveID, GetNetIDFromSigninName, to get the NetID
for the account.
After the Credential and Profile or Passport are created then we initiate a call to Hotmail
to login to the mailbox. This is to set any specific language/region code on the mailbox
that the administrator might have defined.
Finally, we call SCG to stamp the mailbox with the Live@Edu specific offers. This enabled
them to have features like No Ads, Pop3 access, and higher levels of sending capabilities.
If the Hotmail mailbox doesn't exist then this call will automatically create the mailbox
with the data it has. If the customer has specified timezone or language it will not be


Lesson 2: Live@Edu Specific Management Agents

configured on the mailbox by default. This was a problem previously as MAv2 would not
"wait" for a call but would call Hotmail and SCG at the time. Hotmail would normally win
but there were instances where SCG would win causing problems on the mailboxes.
Note that MAv2 is a one directional MA in that it only pushes information to the various
services. It does not have an Import capability.

Configuration Files
The MAv2 management consumes 3 different configuration files for various tasks. First
there is the PassportMA_GlobalConfig.xml. This file contains the primary set of
information that the MA uses to connect to LiveID, SCG, and Hotmail. This file contains
certificate identification in the form of the Subject Key Identifier or SKI of the certificate,
the SiteID, and endpoints for both Hotmail and SCG. During the labs you will have an
opportunity to configure these files.
Next there is the PassportMAProvisioningConfig.xml. ILM out of the box cannot provision
accounts on its own. It requires Provisioning Code to instruct it to create connectors. We
use a baseline provisioning code that reads from this XML. Specifically we look for a
couple things like the Name of the MAv2 MA, the Object inside ILM you are using, and the
email address attribute you have configured. This config file takes any metaverse
projection and creates a new connector in the MAv2 MA. This new connector ultimately
becomes a new LiveID and mailbox.
Finally we have the PassportMADomainRules.xml. This config file allows users to set
domain level attributes for their users. For instance if you use ILM to create both Student
and Alumni domains then you may want to provision offers on the student domain but
not on the Alumni. Additionally if you are multistate or multinational school you may
want to set a unique time zone for the various domains with different language codes.
This config file allows these per domain configurations. Note that any attribute flows
created for these values will overwrite what is configured in this file.



Lab 1: Configure your own MAv2 domain
1. Create and configure an ILM Service Account
a. Assign it to the Local Admin Security Group.
2. Create and Configure a SQL service account
3. Install SQL with a default instance and use the SQL Service Account
a. Select SQL Server Database Services
b. Select the Default instance
c. Configure it for Windows Authentication
4. Install ILM using the ILM Service Account
a. Install from: DesktopILm 2k7Disk 1MIISSetupMicrosoft Identity
Integration Server
b. Backup the Encryption Key for the DB on the Desktop.
5. Create a Delimited Text File MA
a. Open Identity Manager
b. Click Management Agents
c. Under Actions Click Create
d. Select Delimited Text File and use StudentMA as the name
e. For Input Text File use the template at DesktopFilesUsers.csv
f. Click “Use First Row for Header Names” and set Comma as the delimiter.
g. Set the EmailAddress as the Anchor Attribute
h. Under Join and Projection Rules click New Projection Rule to Person. (Just click
“New Projection Rule” and click OK
i. For Attribute Flow put the Email Address in the Mail Attribute and make it an
Import flow. Put the password in comment and name in display name.
j. Create a Full Import and Full Synchronization run profile on the MA.
i. At Identity Manager under Management Agents Click Configure Run
profiles on the new MA
ii. Click New Profile
1. For the name use FIFS
2. Under the type select Full Import and Full Sync.
3. For the Input file name copy the template file we used earlier to
Program FilesMicrosoft Identity Integration ServerMA
DataStudentMA then select that file.
6. Create the Windows LiveID Management Agent
a. Install the Management Agent from DesktopFilesMAv2. Run Setup from an
elevated command prompt.
b. Set the type to Windows LiveID and name it LiveIDMA
c. Leave Configure Connection Information Blank
d. Go to Configure Attribute Flow
i. Create an export flow for Mail -> Signin Name
ii. Comment -> TempPassword
e. Click through and complete.



7. Copy over the new PassportMA_Globalconfig.xml from DesktopFilesMAv2MA to
c:program filesMicrosoft Identity Integration ServerExtensions.
8. Install the Certificate by Double Clicking on “WindowsLiveIDExtensibleMA.msi”
selecting Install Certificate Only. Use the Certificate in DesktopFilesMAv2MA.
9. Configure the PassportMAProvisioningConfig.xml with the Name of the WindowsLiveID
MA and the mail Attribute. It’s located at c:program filesMicrosoft Identity Integration
ServerExtensions.
10. Restart the MIIServer.exe process.
11. Create a new User
a. Add a user to the Text File
b. Full a FIFS on the StudentMA
i. You should see a pending Export
c. Run an Export
i. Did the Account create properly
12. Login to that account at http://mail.live.com

Estimated time to complete the exercise(s): 60 minutes



Management Agent V3
The Management Agent V3 is the final evolution of the Hotmail based management agents
for ILM. It allows a much more convent interface for account provisioning and
maintenance. This management agent is titled MAv3 for convince but really it is called the
Windows Live Custom Domains Management Agent or WLCD MA. This is because it was
written by an engineering team at Microsoft called SyndC. The original name for their
project was Windows Live Custom Domains before it was renamed to Windows Live
Admin Center.

How does it work?
The account provisioning stack for MAv3 looks like:

Here we see that MAv3 calls SyndC to do most of the work. This is the primary difference
between MAv2 and MAv3. Because MAv3 leverages the SyndC platform, Admin Center,
we were able to significantly speed up the onboarding time. Infact you went through that
same onboarding process when you enrolled your Hotmail domain. The process that used
to take weeks to be configured reduced to minutes.
The other advantage about using SyndC was this brought a significant improvement to
the account provisioning process. With it as the intermediary we no longer had to worry
about transient network issues that would disrupt account provisioning. SyndC was
always intended to be a consumer API whereas LiveID was primarily built for internals.
This new found resilency eliminated a significant number of support calls.
MAv3 also ended the sole dependence on certificates. With the SCG calls now done by
SyndC we were able to offer users the choice on how they wanted to authenticate. They



could use a certificate or they could use Username/Password. It was up to how they
wanted to implement their service.

Inner Workings
MAv3 follows the same account provisioning sequence diagram that was shown earlier in
Module 2. Here it is again for reference.

As we can see the calls between MAv2 and MAv3 are very similar. The biggest change is
that SyndC operates as an intermediary and has some business logic built in. This takes
care of some privacy concerns around Hotmail and mailboxes. For instance in MAv2 if
you deleted an account and recreated it immediately the new account would have access
to the previous accounts mailbox.



Config Files
MAv3 like Mav2 relies heavily on config files. Here the first file is the
WLCDGlobalConfig.xml. This file is effectively a merger between the
PassportMA_GlobalConfig.xml and the PassportMADomainRules.xml files. Here users can
configure a certificate for authentication and various domain settings like mentioned
above.
The second config file is the WLCDProvisioningConfig.xml. This file is virtually identical to
the one for MAv2. Its sole job is to take in configuration data for the provisioning rules
inside of ILM. It has the same required attributes as MAv2.


Lab 2: Configuring MAv3

1. Create and configure an ILM Service Account
a. Assign it to the Local Admin Security Group.
2. Create and Configure a SQL service account
3. Install SQL with a default instance and use the SQL Service Account
a. Select SQL Server Database Services
b. Select the Default instance
c. Configure it for Windows Authentication
4. Install ILM using the ILM Service Account
a. Install from: DesktopILM 2k7Disk 1MIISSetupMicrosoft Identity
Integration Server
b. Backup the Encryption Key for the DB on the Desktop.
5. Create a Delimited Text File MA
a. Open Identity Manager
b. Click Management Agents
c. Under Actions Click Create
d. Select Delimited Text File and use StudentMA as the name
e. For Input Text File use the template at DesktopFilesUsers.csv
f. Click “Use First Row for Header Names” and set Comma as the delimiter.
g. Set the EmailAddress as the Anchor Attribute
h. Under Join and Projection Rules click New Projection Rule to Person. (Just click
“New Projection Rule” and click OK
i. For Attribute Flow put the Email Address in the Mail Attribute and make it an
Import flow. Put the password in comment and name in display name.
j. Create a Full Import and Full Synchronization run profile on the MA.
i. At Identity Manager under Management Agents Click Configure Run
profiles on the new MA
ii. Click New Profile
1. For the name use FIFS
2. Under the type select Full Import and Full Sync.
3. For the Input file name copy the template file we used earlier to
Program FilesMicrosoft Identity Integration ServerMA
DataStudentMA then select that file.
6. Create the Windows Live Custom Domains MA
a. Enter Connection Information for your domain admin. (Just Username and
Password)
b. Configure the Attribute Flows for name, Email Address, and Password just like
MAv2.
7. Configure the WLCD MA
a. Configure the WLCDProvisioningConfig.xml with the name of the Custom
Domains MA and set the email address to Mail.
b. Add any values you want to the WLCDGlobalConfig.xml.



c. Restart the MIIServer.exe in the Services MMC snapin.
8. Create a new User
a. Add a user to the Text File
b. Full a FIFS – See a pending Export?
c. Run an Export
9. Run the FIFS run profile you created
10. You should see Pending Exports
11. Run Export on the Windows Live Custom Domains MA.

Estimated time to complete the exercise(s): 45 minutes



Outlook Live Directory Sync
Outlook Live directory Sync or OLSync is an end to end provisioning solution developed
by the Exchange Team. The key difference between OLSync and MAv2/3 is that it includes
and configures the source ma for you. There are also a predefined set of logic used to
determine how accounts are to be created and what objects should be created.
One of the big challenges with OLSync is the various kind of objects it can provision. In
several situations OLSync can create Mail users, Mailboxes, or Mail Contacts. The default
rules created by the Exchange Team govern these scenarios and business logic.

How Does OLSync Work?
Because OLSync is an end to end solution it normally would be more complicated to
configure. The Exchange Team invested a lot and developed a simple way to install and
configure the MA. A fully automated installer detects and configures itself for the
environment it is going into. We have different configurations for:
 Active Directory only system
 Exchange 2003
 Exchange 2007
 Exchange 2010
These configurations are detected by the schema in AD. The AD Only profile is the most
basic implementation and does not provision to multiple object types inside Outlook Live.

Inner Workings
The most complex scenarios in OLSync first come from the default filtering it has enabled.
For the Exchange versions it doesn't just create accounts at will. Before they are
processed by ILM they must made it by the filter rules:
1. Recipient objects that don't have required attributes ILM reads the following
recipient objects. If any of the required attributes are empty (null), the recipient object
is filtered out.

Recipient object type Required attributes

Mailbox-enabled user mail, legacyExchangeDN,
proxyAddresses

Mail-enabled user mail, targetAddress



User (AD DS or Active Directory only; no mail
Microsoft Exchange installed)

Mail-enabled contact mail, targetAddress

Distribution group, dynamic distribution mail, proxyAddresses,
group, or security group mailNickName

2. Recipient objects where the adminCount attribute is set to 1 The adminCount
attribute is used to identify users in protected administrator groups, such as the
Domain Admins and Administrators. If the adminCount attribute is set to 1 on any
recipient object, it is filtered out.
3. Mailbox-enabled user objects that are specified as mailbox plans, discovery
mailboxes, or arbitration mailboxes The msExchRecipientTypeDetails attribute
is used to identify mailboxes that are specified as mailbox plans, discovery mailboxes,
or arbitration mailboxes. These mailbox-enabled users are filtered out.
4. The mail attribute on an AD DS or Active Directory-only user that doesn't match
the provisioning domain In an on-premises environment where Microsoft Exchange
hasn't been installed, OLSync filters out all user objects where the mail attribute
doesn't contain an SMTP address that matches the provisioning domain.
5. The attribute used to generate the Windows Live ID doesn't match any of the
accepted domains The final pass filters out recipient objects that are configured for
auto-provisioning but don't have an accepted domain match in the attribute that is
used to generate the Windows Live ID.
The attribute used to generate the Windows Live ID must contain a domain name that
matches one of the accepted domains that you have configured in Outlook Live. As
described in step 4, by default, OLSync looks to the user principal name (UPN) for a
match unless you have set the MVWindowsLiveIdAttributeName parameter to use a
different attribute. In this case, OLSync matches the SMTP address that is stored in the
attribute that you have specified in the MVWindowsLiveIdAttributeName parameter. In
any case, if OLSync can't find a match to an accepted domain, the recipient object is
filtered out.
Once they get past the filtering rules then they make it into the provisioning rules. They
can best be described by the scenarios below.



Beyond the provisioning scenarios there are a number of parameters that are configured
inside OLSync. Note these parameters themselves are stored in an XML file but that XML
file is not the authoritative source. OLSync automatically populates that XML file during
each Sync so that it can be used by other processes like PCNS.

Parameter name Default Description Recommendatio



paramete n
r?

ProvisioningDom Yes. The Do not remove
ain ProvisioningDom domain entries
If you
ain parameter is from the
configured
required. It must ProvisioningDom
OLSync
include at least ain parameter
with a
one accepted after you have
OLSync
domain in run a
service
Outlook Live. synchronization
account,
cycle. To change
the The
a provisioning
Provisioni ProvisioningDom
domain, add a
ngDomain ain parameter is
new domain
parameter used as a trigger
name to this
is set to to auto-provision
parameter.
the mailboxes in
domain Outlook Live. After users are
that you Only an accepted provisioned,
specified domain can be a changing the
in the provisioning value of the
Windows domain. ProvisioningDom
Live ID for ain parameter
You can add
that doesn't remove
multiple domains
account. those user
to this parameter
accounts.
If you separated by
Accounts that
configured semicolons, for
have been
OLSync to example,
created in
use contoso.edu;
Outlook Live will
certificate- fabrikam.edu.
remain and are
based
represented in
authentica
ILM by a GUID in
tion
the metaverse.
instead of
Therefore, the
a service
user accounts
account th
will continue to
e
be updated
Provisioni
according to the
ngDomain
changes on the
parameter
source object in
will be
the on-premises
empty and



you have Active Directory
to set it. Domain Services
(AD DS) or Active
Note Cert
Directory
ificate
directory service
authentica
as long as the
tion is no
object exists in
longer
the ILM
supported
metaverse.
for new
installatio
ns of
OLSync.

ResetPasswordOn Yes. Setting this This parameter
NextLogon parameter to doesn't apply if
Default is
True will force you are running
True.
users to reset the Outlook Live in a
password on Connected
their new Federation
Windows Live deployment.
account when Connected
they sign in for Federation
the first time. passwords are
This is the default managed by the
behavior. on-premises AD
DS or Active
Directory. As a
security best
practice, you
shouldn't set this
parameter to
False.

MVWindowsLiveI Yes. The In an
dAttributeName MVWindowsLiveI environment
Default is
dAttributeName where Microsoft
UserPrinci
parameter Exchange isn't
palName
defines how installed on-
OLSync provision premises, if the
s the Windows MVWindowsLiveI
Live account dAttributeName
names in Outlook parameter is set



Live. to null,
OLSync uses the
By default,
mail attribute to
OLSync names
name the
new Windows
Windows Live
Live accounts
IDs for the
according to the
Outlook Live
userPrincipalNa
mailboxes that
me (UPN)
are provisioned.
attribute on the
on-premises In an
recipient object. environment
Therefore, when where Microsoft
OLSync Exchange is
provisions new installed on-
accounts in premises, and if
Outlook Live, the the
new Windows MVWindowsLiveI
Live ID matches dAttributeName
the on-premises parameter is set
UPN for the to null,
corresponding OLSync uses the
account. primary SMTP
Address in the
The
proxyAddresses
MVWindowsLiveI
attribute on-
dAttributeName
premises to name
parameter takes
the Windows
any attribute
Live IDs for the
name. For
Outlook Live
example, you can
mailboxes that
enter
are provisioned.
customAttribute
1 if you are
flowing a custom
attribute from
the on-premises
extensionAttrib
ute1 attribute.
You must only
enter attributes
that hold a single
SMTP address



value. For this
reason, don't
enter the
proxyAddresses
attribute for this
parameter. If you
want to flow the
primary SMTP
address from the
on-premises
mail-enabled
users or mailbox-
enabled users,
leave the
MVWindowsLiveI
dAttributeName
parameter
empty. The video
demonstration at
the end of this
topic shows how
to configure the
primary SMTP
address as the
provisioning
SMTP address.
Do not remove
the
MVWindowsLiveI
dAttributeName
parameter from
the Additional
Parameters page.
If the
MVWindowsLiveI
dAttributeName
parameter is
removed, OLSync
uses the UPN
value.

DisableWindowsL Yes. Set the Although the



iveId Default is DisableWindowsL default behavior
False. iveId parameter is False, the
to True to disable recommended
Windows Live setting for the
accounts when DisableWindowsL
the on-premises iveId parameter
source account is is True. When it
removed. When is set to True,
the Windows after a mailbox is
Live account is deleted, the
disabled, it is owner of the
removed and the Windows Live ID
owner of the associated with
Windows Live ID that mailbox can
loses all use the Windows
Windows Live Live ID for other
services. services by
renaming the
If you leave the
Windows Live ID
DisableWindowsL
the next time
iveId parameter
they sign in. If
set to False,
this parameter is
Windows Live
set to False, after
accounts whose
the mailbox is
corresponding
deleted, the
on-premises
Windows Live ID
source account is
can't be used
removed are still
again except for
able to access
association with
Windows Live
a new mailbox.
services.
However, the
corresponding
Outlook Live
mailbox or mail-
enabled user
object is deleted.
Important Be
careful when you
move on-
premises objects
between
organizational



units in AD DS or
Active Directory.
For example, if
you move objects
that are
provisioned as
mailboxes in
Outlook Live to
an on-premises
organizational
unit that isn't
configured to be
synchronized
with OLSync, the
corresponding
mailboxes in
Outlook Live will
be deleted.

PasswordFile Yes. Specify the name Initial passwords
and location of for each Outlook
Default is
the password file, Live mailbox or
reportpa
for example, Windows Live
ssword.x
D:adminpwd.x ID-enabled
ml
ml. synchronized
user are stored
If a file name is
cumulatively in
provided, the
the password file.
default path is
<system You must
drive>:Program distribute the
FilesMicrosoft initial passwords
Identity to your users. By
Integration default, the
ServerMaData ResetPasswordOn
Hosted. NextLogon
parameter is set
When OLSync
to True, so users
provisions a new
are forced to
Windows Live
change the
account in
password when
Outlook Live, the
they sign in for
password for the
the first time.
new Outlook Live



account is We recommend
written to the file you specify a
that is specified secured directory
in this parameter. for the password
file.

SyncProxyAddress No By default, Set the
Protocol OLSync SyncProxyAddress
synchronizes SM Protocol
TP and X500 parameter only if
addresses in the an additional
ProxyAddresses protocol is
attribute from required by your
the on-premises Outlook Live
recipient object feature set.
to the
corresponding
Outlook Live
object. Set the
SyncProxyAddress
Protocol
parameter to
synchronize
other protocol
address types.
For example, you
can synchronize
additional
protocol address
types such as SIP
by setting the
SyncProxyAddress
Protocol
parameter to SIP.
You can add
multiple protocol
address types to
this parameter
separated by
semicolons, for
example, EUM;



SIP.
Valid values for
this parameter
are determined
by the protocol
address types
that you have
stored on the
ProxyAddresses
attribute on
recipient objects
in your on-
premises Active
Directory.
If you remove an
additional
protocol address
type from this
parameter after
you run a full
synchronization,
OLSync removes
the addresses on
the
corresponding
Outlook Live
recipient object
during the next
full
synchronization.

EvictLiveIdOnCre No An e-mail as sign Set the
ate in ID (EASI ID) is EvictLiveIdOnCre
a Windows Live ate parameter to
ID that was True if you want
created in a all provisioned
domain accounts in your
namespace Outlook Live
before Outlook domain to match
Live was the
deployed in the corresponding
same domain on-premises



namespace. accounts.
For example, a Setting the
student at EvictLiveIdOnCre
Contoso ate parameter is
University may recommended
have created a for organizations
Windows Live ID, that are running
KwekuA@contos in a Connected
o.edu, before Federation
Contoso environment.
University
If your
enrolled in
organization isn't
Outlook Live.
running in a
After Contoso
Connected
University
Federation
establishes a
environment, you
contoso.edu
should consider
Outlook Live
importing
domain, the
existing
Windows Live ID,
Windows Live
KwekuA@contos
accounts for
o.edu, is an
users in your
unmanaged EASI
organization that
ID in the Outlook
already have a
Live contoso.edu
Windows Live ID
domain.
in your domain.
By default, when For more
OLSync tries to information, see
create a mail- Import or Evict
enabled user or a Existing
mailbox-enabled Windows Live
user in Outlook IDs.
Live where a
matching EASI ID
already exists, an
error is logged
and a recipient
object in Outlook
Live isn't created.
You can change
this behavior by



setting the
EvictLiveIdOnCre
ate parameter to
True. When you
set the
EvictLiveIdOnCre
ate parameter to
True, the EASI ID
is evicted from
the domain and
new recipient
objects are
created in the
Outlook Live
domain
according to their
corresponding
on-premises
names.
When a Windows
Live account
status is set to
"evict," the
account is in a
state that forces
the user to
rename the
Windows Live ID
the next time the
user signs in.
After the user
renames the
Windows Live ID
to an unmanaged
domain name,
the account is
fully functional
again.

Inside OLsync we include a script that users can run called StartSync. This script will
automatically run the various run profiles for users in the correct orders. Users are not



required to manually create run profiles like they had to for the other management
agents.


Additional Resources

Additional Resources
Implement Outlook Live Directory sync
http://help.outlook.com/en-us/140/dd575560.aspx


Live@edu ilm2007

Recommandé

Recommandé

Contenu connexe

Tendances

Tendances (18)

En vedette

En vedette (9)

Similaire à Live@edu ilm2007

Similaire à Live@edu ilm2007 (20)

Dernier

Dernier (20)

Live@edu ilm2007