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

Kevin50 · ‎02-22-2019

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 · ‎02-22-2019

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?

View solution in original post

DaveHertel · ‎02-25-2019

Kevin -- if your DEV environment is setup identically using the method described above, which keeps the SYS-ID's identical between environments, its possible to define schedule and behaviors in DEV and push them thru via update sets to PROD.. and expect them to work with little/no modification. Because DEV & PROD are very similar (except of DEV mid is physically installed on a different host than PROD is).

As for credentials, you need to recreate those in PROD. Update sets aren't a good solution for creds... nor should you want them to be... because its not a good practice to have files (i.e. update sets) laying around that contain the keys-to-your-kingdom... Have the information security folks (or whomever owns this critical info) enter the CREDS in PROD. Then when you refresh DEV from PROD, the creds will be there too... so further testing in DEV should theoretically work because the creds were entered in a trusted source (PROD)

Hope this helps?

DaveHertel · ‎02-27-2019

Kevin - did any of this help? If so, please mark/click as appropriate. This encourages participation in the SN community forums. Thanks, Dave

Todd36 · ‎10-02-2019

Hi Dave,

Took a class w/you recently... if this works like it should, maybe a follow up to this solution:

SN Support suggests just excluding the tables below in a clone, my co-worker suggested that there may be further impacts like "something about promoting code/jobs that reference specific servers".

Are you aware of any other impacts to NOT syncing your mids like this?

--------------------------------

Tables:

discovery_functionality

discovery_credentials

ecc_agent_cluster

ecc_agent

blanca12 · ‎10-02-2019

Thanks for helping.

______________________________________________________________

Sarkari Result Pnr Status 192.168.l.l