What can Export-FIMConfig do for me?

As many of you may know from the Powershell documentation, the Export cmdlet is the FIM 2010 of getting configuration out of a system into our powershell object model. However, it may be unclear why our tool performs in a certain manner. Today, I will explain how our Export cmdlet works and elaborate on what each knob does.

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.