0
Fixed
When running ConfigureEventBrokerChangesActivity.ps1 the display looks like a string.Format is not being applied
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
Customer support service by UserEcho
Attached screen shot
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?
Yes. See screen shot.
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:
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.