Detection of changes in referenced MA guids
Bob Bradley 10 years ago • updated by anonymous 8 years ago • 10
Despite attempts to avoid this, MA Guids invariably have been known to vary between one environment to the next, and in this case any Event Broker operation references to these guids need to be deleted and recreated. To avoid this it would be good if the service were to detect the problem and alert the admin to the need to either replace this with the correct reference or delete the operation(s). An initial comparison against MA name could be used to propose a likely match for the user to confirm - akin to the "partition matching" that happens when you are deploying an AD MA where the AD partition guids are different.
Edit (Adam): The auto-config will also have to be looked at here.
Customer support service by UserEcho
I think the "partition matching" idea is a really good approach for addressing this problem.
This has become more important now that the auto-config also relies on the MA id's.
Please bump this priority up to critical since I've just discovered how this problem is surfacing, and this problem will be undermining the product integrity in the market place right now. It concerns how configuration is deployed from one sync server to another ...
In the MIIS/ILM days this was a no brainer, as it was the only way to also preserve metaverse precedence. These days with FIM the FIM MA and the declarative sync idea seems to want to undermine this benefit, but if done correctly I believe the precedence can still be retained regardless - just takes some extra work (see my blog post from December 2011 - pre dates all other discussion on the topic in a FIM context because at the time the only collective FIM experience we had at UNIFY was the 2 MCS engagements I had where I had to learn the hard way).
Regardless of what I think, however, obviously others will continue to deploy using the individual MV/MA xml file option - and this has been done recently at SSICT, leading to the problems which caused me to raise this issue in the first place!!! This will mean that if they have Event Broker 3.1 or earlier they will be forced into the same situation as I was ... and trust me, you don't want to be doing this at 2 AM in the morning.
Brad Dornan - this is exactly the problem I was referring to last night over IM, and which threatens to sabotage the best efforts of future SSICT deployments. Please either add your weight behind this request, or ensure that SSICT processes are changed so that Event Broker 3.1 config can be migrated without having to hack the guids.
The Guid is used as it was seen to be the least likely to change according to best practice FIM deployments. There is a case for this feature in a future version, but I don't see this having necessary priority to give it the critical status that is being discussed.
Rather than marking it critical to bend the product around the practices, the practices should be brought into line. Why is it not possible to export the server configuration as per regular practice?
The migration was successful at SSICT the last few times anyway by changing the Guids in the migration XML files to be the same across the environments. I am not aware of any additional failure here but whatever it is could be worked around as it has in the past.
Matthew Clark - I am not aware of any other effort that has been taken to correct the guid inconsistency since I was up all night on one occasion in Brisbane manually changing them to get the initial FT Test config working. If this has been done then great.
Please think for a minute of the wider ramifications here ... if people within UNIFY have been doing it, then it is almost certain external users of our product will run into the same problem, and when (not if) they do, do you think they will be so understanding as we are with our own product?
Yeah I agree with the feature request, we'd probably have to check the names as well or something and try to override the Guids that have been stored already for the management agents. Since the names are more changeable than the Guid, we use the Guid as the main reference for the management agent and I don't believe we store anything else in current versions (names of management agents and run profiles are requested from FIM on a routine basis as they can change).
I don't think a future version of FIM Event Broker is likely any time soon so if the push is to have this in place for this particular client, I'm thinking this is not a likely proposition.
Thanks for your responses here Matthew Clark but we'll let management make that decision - trust me that SSICT success is high on the priority list, and either this is a dependency or it is made not to be. Then if it's not an issue elsewhere that we are aware of we should probably keep as quiet as we can for now about the limitation ... problem now is that on this morning's UG meeting (when the recording comes out) you will hear explicit reference to this guid retention problem, and the fact that Event Broker has trouble with it (when PowerShell alternatives to Event Broker do not apparently). This will very quickly lead to bad PR, and be picked up by those voices in the market who will be eager to bag Event Broker. I hope that doesn't happen, but my hunch is that we will hear about this within days.
As part of the initial migration we have found that the MA-GUIDs in the source (test) environment was different than the GUIDs in the Production environment. The FT-test environment was first a successfully migration from Production so the GUIDs was the same in the FT-test as the Production environment.
My WIP script below is to fix a broken Unify.Product.EventBroker.OperationEnginePlugInKey.extensibility.config.xml file after FIM Sync guids have changed (so long as names still match).
Note that this doesn't replace the existing file - just creates a new one with a .new file extension for you to swap over with the existing one while handling Event Broker service restarts, etc.
Migrated to Visual Studio Online.