1

Resolved

Using Export-FimConfig or Import-FimConfig: This operation is not supported for a relative URI

description

When using the FIM configuration migration cmdlets inside the PowerShell Activity it fails with :
{"The type initializer for 'Microsoft.ResourceManagement.WebServices.Client.ResourceManagementClient' threw an exception."}
and
{"This operation is not supported for a relative URI."}
Stack Trace:
at System.Uri.get_Fragment()
at System.UriBuilder.Init(Uri uri)
at Microsoft.ResourceManagement.WebServices.Client.ResourceManagementClient..cctor()
 
Details of this issue are well captured in this FIM TechNet Forum post:
http://social.technet.microsoft.com/Forums/en-HK/ilm2/thread/295fc491-ffc8-4e02-b923-43af1c3aef1d
 
the workaround right now is to use Remote PowerShell (not sure why this works, but I don't like having to do it).
 
So this fails in the ActionWF:
Add-PSSnapin FimAutomation;Export-FIMConfig -CustomConfig "/Person"
 
But this works in the ActionWF:
Invoke-Command -ComputerName localhost {Add-PSSnapin FimAutomation;Export-FIMConfig -CustomConfig "/Person"}
 
Digging deeper to find a solution, but the workaround works for now.

file attachments

comments

CraigMartin wrote May 11, 2011 at 6:33 AM

A smart developer at Microsoft figured this out for me. Turns out this was just a FIM configuration issue, phew!
To resolve the issue (and remove the need to use PowerShell remoting) simply make this change to the FIM service configuration file:
Change:
<resourceManagementClient resourceManagementServiceBaseAddress="localhost" />
To
<resourceManagementClient resourceManagementServiceBaseAddress="http://localhost:5725" />

wrote Dec 14, 2011 at 2:33 PM

Remivandemir wrote Dec 14, 2011 at 2:33 PM

This did not help me with the problem. :/

Im running the following script from the WF: See attached file

But my Event log just says this:
GetCurrentUserFromSecurityIdentifier: No such user FIMLAB\srv-fimws, OBJECTSID

Requestor: Internal Service
Microsoft.ResourceManagement.Service: Microsoft.ResourceManagement.WebServices.Exceptions.UnwillingToPerformException: Exception of type 'Microsoft.ResourceManagement.WebServices.Exceptions.UnwillingToPerformException' was thrown.
at Microsoft.ResourceManagement.WebServices.ResourceManagementService.GetCurrentUserFromSecurityIdentifier()
at Microsoft.ResourceManagement.WebServices.ResourceManagementService.GetCurrentUser()
at Microsoft.ResourceManagement.WebServices.ResourceManagementService.Put(Message request)

Remivandemir wrote Dec 14, 2011 at 3:45 PM

Okei. I fixed this by adding the SRV-FIMWS user to the portal and putting it in the Administrators SET.
But now. When im run the powershell wf. This appears: PowerShell activity failed with the following error:
The term 'Import-FIMConfig' is not recognized as the name of a cmdlet, function, script file, or operable program. Check the spelling of the name, or if a path was included, verify that the path is correct and try again.

wrote Feb 14, 2013 at 7:14 PM

wrote May 16, 2013 at 9:30 AM

wrote May 16, 2013 at 9:30 AM

wrote Jun 14, 2013 at 7:11 AM

panfinsen wrote Apr 8, 2014 at 9:49 PM

CraigMartin's suggestion worked for me. This was necessary even though I was explicitly specifying the -URI parameter on the Export-FIMConfig cmdlet call. Prior to this change, I had the bare server name (not 'localhost'), as we have a two server Portal configuration. Thanks, Craig! You da man!

CraigMartin wrote Apr 9, 2014 at 4:57 PM

Weird error, eh? Glad you found the solution!

MikeCrowley wrote Aug 5, 2014 at 2:25 AM

Anyone (Remivandemir?) figure out why we need to wrap the script in invoke-command to load the fimautomation snapin? I'm encountering the same problem, and while this workaround does work, I'd obviously rather avoid the complexity. I'm using Windows 2012 R2, FIM 2010 R2 SP1 (4.1.3510.0)

MikeCrowley wrote Aug 5, 2014 at 3:44 AM

Including $host | out-file c:\hostCheck.txt revealed this is running as PS 2.0. I didn't realize this, and that explains my problem.

I was checking for the presence of the fimautomation module by throwing an error when:
((Get-PSSnapin 'FimAutomation').Count -ne '1')
But as we can see, .count works differently in PS 3.0+:
Image

Doh!!

This does work:
((Get-PSSnapin 'FimAutomation' | measure).Count -ne '1')

CraigMartin wrote Aug 11, 2014 at 3:43 PM

Yup, the FIM Service runs an older version of .NET (ugh, showing its age) so we lose some of the PowerShell awesomeness. A clunky workaround is to use WinRM to fire up a fresh PowerShell runspace outside of the FIM Service process. It is expensive, so I wouldn't do it for a WF that is going to run frequently.

mattcplx wrote Feb 20, 2015 at 12:24 AM

Ok - this took me about 3 days to figure out. Same issue. Null returns on Export-FIMConfig. No matter what URI I specified. Really annoying and tedious to troubleshoot.

If you were like me, maybe you are updating the wrong field in the config file. I just did a quick search for 5725, and didn't look closely.

I was updating this:
  <service name="Microsoft.ResourceManagement.WebServices.ResourceManagementService">
    <host>
      <baseAddresses>
        <add baseAddress="http://localhost:5725" />
      </baseAddresses>
    </host>
  </service>
That's WRONG. Well, for the purposes of solving this FIM Automation issue... That's not the value we need to update regarding the FIMAutomation CLIENT

If you look carefully, everyone is mentioning updating a different field:
 <resourceManagementClient resourceManagementServiceBaseAddress="http://localhost:5725" />

Search for "resourceManagementServiceBaseAddress" - that's what you want to update. Mine didn't have "localhost" in there, so I was just skipping over it and giving myself headaches. The value I had in there was an alias that that our portal sort of goes by. It wasn't in a web server form, and it was exactly what was breaking. I did a reboot after making this change.

Once I changed the resourceManagementServiceBaseAddress to the above value it worked flawlessly.

That was my issue anyway. Solved and ready to get back to powershell workflow awesomeness.