Non-existant management agents after upgrading from v3 to v4

I dropped them in the Services folder and restarted the service, but no change. I also tried refreshing the MAs again but it didn't help.

Where does the managementAgentId in the Operations config file come from? It does not correspond to the MA GUID in MIM Sync so there must be a matching somewhere - but where?

Hey Carol,

In previous versions of EB, an improvement was made such that the MA and run profile id's were stored separately, keyed using a new id internal to EB - as a number of MIM solutions were not being properly migrated between Dev->Test->Prod, we were seeing the id's change.

The patches found above were written to resolve a potential bug in the upgrade process. 

Could you try the upgrade again and place the patches in before starting the service for the first time?

I can uninstall and reinstall but I can't upgrade again - no VM snapshot or anything like that.

How does one migrate the internally stored id mapping? Wouldn't that be the more sensible approach?

What is legacyKeyMode?

I have:

- Uninstalled EB from the Test server

- Cleared out the Extensibility folder

- Installed EB 4.0.1 (not starting service)

- Put those DLLs in the Service folder

- Copied the Agents and Operations config files from Dev to Test

- Started EB

- Fixed the Agents (which had Dev SQL server name in them) - all agents reporting fine

- Refreshed MAs

No change - everything still broken with the same error.

Hey Carol,

Can you double check that the DLL files you've placed in aren't zone blocked? (right click, unblock, apply).

Can you also please attach a copy of the following:

• Extensibility files
• Logs showing the errors you're having
• EventBrokerStoredValues.xml file, located in isolated storage. 

The path to the StoredValues file will be similar to:

C:\ProgramData\IsolatedStorage\s5qxz2zq.wns\gzjiptql.dr4\Url.k53zrnx23fuyza4tycitlynapfpnwmoi\AssemFiles\EventBrokerStoredValues.xml

Could you please let me know the MIM id's for one of the MA's and associated run profiles? I might then be able to track down why it's not picking it up. Thanks.

I sent lots of files to Matt including the MIM Sync server exports from both Dev and Test, so all the info you need will be in there.

I got it working by copying that hidden EventBrokerStoredValues.xml file from Dev to Test - though I would class that as a workaround.

This happened again and I couldn't get my workaround to work this time - no idea why it worked in Test and not Prod. I have ended up having to manually go through and reset every operation again.

This is still an issue without any upgrade. Fresh install of EB v4.0.1 at a completely different site. MIgrated the Operations and Agents config files from Dev to Test, and lost all the MA guids. Each operation had to be manualy edited to fix the pending export checks and run profiles.

As I mentioned last time, please supply the configuration, the hidden file, and let me know the details of a failing run profile (MIM internal id's and our id's). Thanks.

Also, was that with the patches in place or not? Thanks.

From Carol:

It's exactly the same as I saw at the original client and those patch DLLs don't help at all. 

At original client I managed to get it working by copying the DEV hidden file over the TEST one. However when I tried the same thing from TEST to PROD it did not work and I had to fix all the operations by hand. 

I tried copying the hidden file from DEV to TEST here at the current client - did not help. MIM Sync has been deployed with a full server config migration so the GUIDs should be the same in both environments. 

The other thing that concerns me - we already fixed the Test operations by hand once. I had assumed this would mean that the mapping was established and I'd be able to recopy the Operations file as I needed to promote changes to Test. But doing that broke all operations in Test again. Oscar has already gone through and fixed the Test operations again as he has testing to do today, so we can't leave it in a broken state. Next time I will remember to back up the existing Operations file.

Hi Carol

I've been looking into this issue and have confirmed that with the current release (v4.0.2) the normal upgrade process is working as intended. I did identify a potential cause, however, in that stored values relating to MIM agent and run profile ids were not being updated on the process starting. Having an out of date (or missing) stored values files resulted in error messages as you described and would explain the behaviour you were seeing when migrating configuration, and if pre-patch EB updated the stored value file incorrectly. 

I've attached a patch if needed, otherwise this fix will be included in the next release (v4.0.3) sometime in the near future. This does not address the case of incorrect stored value from the pre-patch version, but in that case the Refresh MAs button on the FIM Agents Management Agents page will correct this.

Unify.EventBroker.Agents.dll

Hi Beau. I have attempted to implemet this patch but now I get "Operation fauled: Value cannot be null. Parameter name: serverName - please see the log viewer for more details." I'll send the full error by email.

The version I have installed is 4.0.1. Do I need 4.0.2 for this patch?

Yes that was the case, however v4.0.3 was released yesterday. I would recommend upgrading to that over the patch at this point. 

That said, the fixes in v4.0.2, v4.0.3 and the patch relevant to this issue were specifically for the upgrade process. If your v4.0.1 is functional though your manual configuration edits there is no need for the patch or any other action at this time.  

The problem I'm having is not related to upgrade at all - I thought it might have been when I started this topic, but having seen it in another site with a fresh install now the upgrade thing is not relevant. The problem is specifically that I cannot migrate event broker config from one environment to another - every MIM Sync operation gets broken. This is the real problem, and it's going to be an especially big problem for me next week as the customer will be doing the deployment to their UAT environment, not me. I don't want to tell them they have to correct every operation by hand.

So is your expectation that upgrading to 4.0.3 will fix this specific problem?

Yes, it should.

No improvement.

I now have 4.0.3 in Dev and Test. I copy the Operations file from Dev to Test, restart the service, refresh MAs, repeat a couple of more times just in case - no help, all operations with pending export checks and MIM run profiles are broken.

I revert back to my old Operations file in Test and everything is fine again. But this is not a fix - I have to be able to promote changes from Dev.

Thanks - this sounds promising. Also I prefer the mapping file being where I can find it more easily, I think that makes sense. For those environments where we have always migrated the full Sync Server config, thus maintaining the same GUIDs, it is better to have a way to also migrate the mapping file.

I'll be back at the customer tomorrow and will get 4.0.4 installed in Dev and Test, and then test the config migration.

Success!

I had the same problem at a different site yesterday and I had to upgrade to version 4.0.3 to get it working ... but it involved trashing the internal UNIFYNow guids by replacing them with the real MIM MA and RP guids, and setting the legacyKeyMode to 'true'.  The script I used to replace all the guids is attached.Reset MA And RP Guids.
I decided against an upgrade to v4.0.4 because it's not yet RTM ... but that was before I found this thread.

In my (reverse) migration scenario (prod=>test) if I upgrade to 4.0.4 in test only will that mean that I can go back to the orig prod config, or will I need to upgrade prod first then deploy to test again?

Thanks.

Incidentally I have now noticed that while UNIFYNow appears to operate correctly with the "real" guids and legacyKeyMode set to 'true', when disabling an operation list and editing a run profile operation, the correct MA and RP are not selected in the respective wizard drop-downs.  Before I raise a ticket I am unable to find any documentation on whether I am using this option correctly - noting that multiple "Refresh MAs" doesn't seem to help (I can't work out what this is doing - I had a hunch it would replace the "real" guids with internal ones and change the legacyKeyMode back to 'false', but I guessed wrong).

It's hard to say now that you've manually updated the configuration. Can you roll back, upgrade UNIFYNow, and try again? The refresh button retrieves the MA's and run profiles, matching up unchanged guids and closest match on the remaining item names. We swapped over to an internal id so that we could track the name and id without it breaking if either/both changed.

I will do just that, but first don't I need to upgrade the PROD instance to 4.0.4 to get the new xml extensibility file generated, Adam?

My experience was that migration of config between environments was broken until 4.0.4, so yes you would have to upgrade. Bob's comment on 4.0.4 not yet being RTM - is this correct? I have it running in two production solutions.

Thanks for the update Carol. Now that it has been accepted I can RTM it. I'll schedule it in.

Thanks.