0
Fixed

When running ConfigureEventBrokerChangesActivity.ps1 the display looks like a string.Format is not being applied

Shane Day (Chief Technology Officer) 8 years ago • updated by anonymous 3 years ago 11

When running ConfigureEventBrokerChangesActivity.ps1 the green bar across the top of the PowerShell script window says:

Importing change {0}
Importing change 1

eb357 screen shot.png
Importing Change.png
Importing Change 2.png

I have investigated this issue with different scripts and different parameters, and it seems to be an issue with the Import-FIMConfig commandlet that is built in to the FIM Service/Portal. Using both this script and some other scripting approaches (such as the commandlet set found here that uses this commandlet on users), with different numbers and types of objects, the "Importing Change

{0}

" line seems to come up whenever this commandlet is used.

Bob, if you would be able to comment on this issue as to whether or not you've seen this occur before when importing Activity Information Configurations or other objects using this approach, that would be a big help. It would seem there is nothing that can be done about this as it seems to be occurring inside the commandlet itself, and no parameters or switches seem to affect it.

Matt - will observe what happens later this week when I'm working with powershell @ DEEWR. I have a hunch that this is indeed nothing to do with your script, but I will confirm. I will be working with variations on these scripts here: http://technet.microsoft.com/en-us/library/ff400264(WS.10).aspx ... and if these exhibit the same behaviour that will be fairly conclusive.

I can confirm that the "Importing change

{0}

" prompt is displayed initially, and then is OVERWRITTEN with "Importing change 1" etc. Is your experience that the text is displayed in separate lines?

I'm going to have to resolve this as there seems to be nothing we can do about this. I have tried the following, with the issue still persisting:

  • Updating FIM to Update 1
  • Importing an array of changes rather than just one at a time
  • Calling the commandlet multiple times - for each time the commandlet is called, the issue appears (see screenshot)
  • Adding a value to the "State" variable for import objects, specifically setting it to "Create"
  • As in an earlier check, attempting to import user profiles as opposed to Activity Information Configurations
  • Running the commandlet in the PowerShell command prompt

Hence I can say with confidence the issue is not with the Event Broker script, but rather with the FIM commandlet. As such, we cannot do anything about this

After discussion - issue is closed as the only work-around could prevent future versions of FIM working with the PowerShell script. To be reopened if there is ever an opportunity to fix.

Behaviour seen again at DET in a similar script (not for Event Broker or sourced by UNIFY) where the commandlet is used.

In that first screenshot those errors about policy prohibiting something or other: I've seen that before and I think it's caused by the powershell script being run as a user that doesn't exist in the portal. To modify or read attributes in the portal the user doing it must have the rights granted by an MPR. Try running the script as the same service account/user that the FIM MA is using.

To further illustrate this, you could open up FIM Portal as administrator and go to requests and search all requests. You should see that the calls to FIM that the powershell script is doing will be logged and denied.

spoke to matt - the policy prohibiting part wasn't the real issue anyway.