Help! Moved MID Servers (via xml export/import) from one instance to another and ended up with duplicates

[Kevin50]

I think I got ahead of myself a little bit and tried to do a xml export of my MID Servers from Test and then an import into Dev. All the MID Servers from Test imported but now my issue is that the MID Servers that were in Dev were also duplicated by the MID Servers moved over from Test that existed previously. How can I fix this?

[DaveHertel · Accepted solution]

Hi Kevin -

  As you've learned, exporting the MID record won't work.. this is because the sysids are generated on the instance when the MID 1st comes online.  If you've copied from another instance (ie. from TEST to DEV) and these 2 environments were not literally the same -- ie.. DEV was created from a backup of TEST then restored to become DEV... then the DEV doesnt' know / didn't create the sysid's of the MIDS that you manually imported.

What follows is what I would do.... based on what I understand of your situation:

To fix in DEV -- verify the real SYSIDs of the MIDs you do have correctly installed from scratch.  Look at the config.xml file, at bottom and that has their sysid.  On the DEV instance, find the MID's that have corresponding sysids.  These are your "good" MIDs.  leave them alone.

Also on DEV, you must have some other MID records that don't have a corresponding MID installation, per their config.xml   These are probably MIDS you imported from TEST with some other 'foreign' sysids.  These MIDs might as well be deleted on the instance, I don't think they'll ever work.... because the 'foreign' sysids on DEV were not originally created on DEV (they came in from TEST when you imported them).  Along with deleting these bogus (foreign) MIDs, remove the MID server installation directory

For the record, the way I advocate to replicate identical MIDs between environments:

1.  Backup/Restore (or clone) the PRODUCTION env to DEV env . (this ensures the DEV env has the exact same sysids for mids)

2.  Presumably, you already have MIDS in PROD (and their corresponding sysids).  Now, on DEV install brand new MID servers.. pointing to DEV env URL of course.  It'll create more MID's in DEV and generate its own sysids (you'll replace them next)

3.  When new DEV mid is up and config.xml has its new sysid, shut down the MID service.  Locate and Copy the sysid that was used in PROD to DEV's version of the config.xml    This works because the "DEV" instance is a clone of "PROD" and PROD 'knows' about the prod-originated sysid.   Restart the DEV MID and it'll come up using the prod-originated sysid.  Your new installation is now associated with the MID sysid that originated in PROD.  .... its a very close duplicate of prod (except the env URL)

4. on DEV instance, delete the autogenerated MID (it'll have its own MID created in step 2).  This isn't useful anymore.

Why do all this hassle??? Because now DEV MID is a REAL DUPLICATE of PROD.  When you create range sets, behaviors, etc.. and test them in DEV, the update sets that get pushed from DEV into PROD will have true, already-validated objects & associations to sysids

There may be other ways to do this... but this is tried and true approach which provides a useful path to production for validating disco developed stuff in a non-prod environment(s).  Of course if you have TEST env, in addition to DEV, repeat the same conceptual steps above but for TEST.   This way DEV, TEST and PROD all have very similar setups.  

Hope this helps?

[robertgeen]

Dave,

This is one of the most well written and to the point responses you have ever done. This one's going into my notebook for future reference as it makes a lot sense how you wrote this up. Please give Dave his points! Props!

[DaveHertel]

Thanks Robert, 'appreciate the kudos 🙂

[Kevin50]

Wow. Thank you so much!

While I have your "ear", what do you recommend about moving discovery scheduled and credentials? Again, thanks so much for your thorough response Dave.

Best Regards,

Kevin