How does export work anyway? Perhaps this diagram will shed some light:

The Export cmdlet is essentially a web service client that can read resources from the FIM service. The resulting output of such reads is known as an ExportObject. ExportObjects store the various attributes associated with FIM resources.

Notice that the Export cmdlet has a number of switches. They dictate what and how to download from the web service. Let’s go over the switches:

Switches for the cmdlet environment:

-uri This allows you to point the Export cmdlet at an external server. By default, we are exporting from localhost.

-messageSize This allows you to increase the web service message size to accommodate large objects. By default, the message size is

-credential This allows you to define the credentials of the caller to web service. By default, we are using the current powershell user credentials when talking to the web service.

Switches for determining what to export:

-policyConfig Exports the objects that controls FIM policy

-portalConfig Exports the objects that control how the portal works

-schemaConfig Exports the objects that control objects and attributes in FIM

-customConfig Exports the objects that matches the XPATH you define

-allLocales Instructs the cmdlet to get all localized copies of objects you export

-onlyBaseResources Instructs the cmdlet to only export objects that match our switches. Do not export “placeholders”

So let me spend some time to explain what exporting means. I’ll explain –customConfig exclusively since the other “Configs” are an amalgamation of multiple customConfigs. In customConfig, you can instruct the Export cmdlet to export objects based on a custom XPATH. Let me illustrate a few diagrams to further elaborate. Suppose we have the following objects and associations:

If we specified –customConfig “/ManagementPolicyRule”, we get the following result:

You’ll notice that we will export the MPRs you’ve asked for in the Xpath. Our primary objects are MPRs. However, you will also find that we’re exporting the dependent objects of our primary objects. These dependent objects not defined in our initial filter are known as “Placeholders”. Why are we doing this? Well, we pick up on extra layer of objects so we can join up dependencies between two systems later on in the migration process. Think of them as stubs that need to get filled in later on.

Let me provide another example: -customConfig “/*[ObjectID=’1’]”:

Notice that our primary object is the MPR with ObjectID 1. We pick up the primary object’s dependents as placeholders.

So what if we don’t want to pick up these dependent objects? I want to use the tool for reporting! Well, we have a switch just for that reason: -onlyBaseResources. Suppose I want to export only Sets since I want to find out what filters I’m using and which explicit members are in my sets: -customConfig “/Set” –onlyBaseResources. Let’s see what happens:

With the –onlyBaseResources switch, the Export cmdlet will only export primary objects defined in the filter. This switch is especially useful for scenarios that you just want the data and won’t be using it for import purposes.

Since Powershell is one of the many extensibility points of FIM 2010, I’d like to create this blog to highlight the capabilities of this tool beyond what is documented in the upcoming SDK.  While the configuration migration is primarily geared towards moving configuration from one system to another, we’ve made changes to the tool over the course of several release candidates to accommodate extensibility scenarios.

I will post at the rate of 1 to 2 posts per week. If there is a specific scenario you would like me to talk about, please contact me via the email link.

I’ll be covering the topics in the following order:

1)      An explanation of how each cmdlet works

a.       Export-FIMConfig

b.      Join-FIMConfig

c.       Compare-FIMConfig

d.      Import-FIMConfig

2)      Overview of the FIMAutomation object model

a.       ExportObject

b.      MatchObject

c.       ImportObject

3)      Using FIMAutomation as a client

a.       …in Powershell

b.      …in managed code

4)      Reporting

5)      Troubleshooting errors

6)      Advanced topics

a.       Parallelized import

b.      Reuse old join criteria

c.       Creating new users without sync

d.      Group migration

e.      Batch enabling scenarios

A couple of caveats before I begin:

1)      All posts here on this blog are provided “as is”. This means these posts are not the official voice of the product team and hence unsupported. I will try my best address your questions but there’s no guarantee that the content posted here will be applicable to your deployments.

2)      This is not a conduit for support. For product issues, please use the Connect site or contact your Microsoft representative.

3)      The official product documentation is fully authoritative. If there’s a conflict between the posts and the official documentation, you should follow the official documentation. Do let me know if there are conflicts.

4)      Lastly, we do not endorse any linked content on this blog. We are not responsible for the content contained in those links.