Open saturnreturn opened 6 years ago
ryannewington
commented
6 years ago @saturnreturn thanks for reporting this one. The MA resolver mechanism users ID first to find the MA (to detect renames), and if that fails, uses name. So in principal the use case of porting between environments has been taken care of.
I think there might be a problem with the enumerator of missing management agents. I will try to replicate this situation and repro the problem on my end.
ryannewington
commented
6 years ago So i've reproduced and fixed this issue, it was actually to do with the partitions, rather than the MA itself. Now that that is working, it's exposed another problem where the AD MA's partition name and ID are different across different domains/environments, and they are not being matched. I've got to have a bit of a think about how to handle this scenario.
saturnreturn
commented
6 years ago Came across another scenario that might be related to this issue.. if you delete (or rename) an MA from the Sync Manager, then create a new one with the same name, then go back to AutoSync and do "reload config", you get the same error, "Item with the same key has already been added". The AutoSync GUI shows the execution monitor, but all of the other items that used to be in the left hand list are gone, so AutoSync can basically not be configured any more. Also at this point, the backup/restore are greyed out, so the previously working config cannot be loaded either! Not sure how to recover from this...
ryannewington
commented
6 years ago @saturnreturn apologies for this. It is the same root cause - a bug in the partition matching code.
I have fixed this in the code base, but i'm still working on some other issues before I can release it.
Can you work around this by modifying the config.xml file with the new ID?
saturnreturn
commented
6 years ago Hi Ryan,
Thanks for the tip. This did work. It took me a while to work out that it was not just the MA ID, but also the Partition ID that needed to be updated manually in the config.xml, but it's back now, so that's good.
I'd noticed you made a commit that looked like it might have resolved it and tried to build the project myself, but ran in to all sorts of dependency issues. I've resolved most errors, but still having issues getting the AutoSync.Editor project to build. Not sat down properly to work it out, but think I might not have the correct Presentation (or some other lithnet) package from NuGet.
Severity Code Description Project File Line Suppression State Error CS1501 No overload for method 'AddItem' takes 5 arguments Lithnet.Miiserver.AutoSync.Editor C:\github\miis-autosync\src\Lithnet.Miiserver.Autosync.UI\ViewModels\MainWindowViewModel.cs 65 Active
This scenario occurs when the AutoSync configuration is exported on one MIM environment, and is imported on a different environment which may contain a similar but not identical set of MAs.
For example:
The 5 missing MAs are reported in the log file correctly as: 2017-10-24 09:04:25.9283| WARN|Management agent could not be found. Name: 'Repopulation Test'. ID: 'e9e96f5e-274f-4674-b475-3669fa84e2ce'
However, the import fails with a message "Could not import the file. An item with the same key has already been added"
On investigation, comparing the exported configuration from both environments, whilst the 15 MAs that they have in common have the same name, not all of them have the same GUID.
By modifying the xml to be imported so that the GUIDs match the values found in the production config, the import completes successfully.
It would be good if the import allowed for a match by MA name, and if one is found, ignores the conflicting ID and applies the configuration as an update rather than treating it as an "additional" MA. This is similar to how the sync engine "Update Management Agent" works when you import an updated config from test -> production. The GUIDs apparently don't need to match in that case.