Monday, January 5, 2009

How not to mess up your environments (or learn from my mistakes)

Here is a fun one:
An error has occurred. Try this action again. If the problem
continues, check the Microsoft Dynamics CRM Community for solutions or
contact your organization's Microsoft Dynamics CRM Administrator. Finally,
you can contact Microsoft Support.


Right, lots of info there. Troubleshooting? Let's not even talk about what I tried to do. What happened? Well, I broke it. Good thing this was development environment and not production. I did what everyone tells you not to do, but at least I had the forethought to "TRY" it out first.

I had been working with a development system that was quite old. No one really knew when it was set up, if it was a snapshot of production, when the last time data or configurations had been migrated...all we knew was that it wasn't 100% perfect, but it was good enough. I'd been using it for a couple of weeks, trying some configurations out, code, entities, all sorts of stuff.

Suddenly, we were given a new environment built on virtuals - "Yeah!" yelled the developers. This sounded great. It was a recent snapshot of production (minus data), but it worked (for the most part). Minor inconsistencies (that I wont elaborate on) aside, it was good.

At this point, I needed to move any new developments from the old dev system to the new one. No big deal. This would be a good test for moving changes we'd made to the production system...Here goes. First, back up the customizations from the dev virtual, then we dove in. Made a few changes, added some objects, then pulled 3 or 4 entities from the old dev and imported to the virtual.

Let's publish...and get an error. No biggie...we get those. But no solution to be found.

After searching and looking, importing backups and everything it came down to this...

Creating an object in CRM assigns a GUID that is carried over (within the database) when exporting and importing to new environments. If you create a new object in 1 enviroment that has some 1:N or N:1 or N:N relationship to another, then recreate that object in a new environment EVEN IF YOU DON'T IMPORT THAT OBJECT those N:1, 1:N, N:N relationships reference the GUID...if you import an object that is related to the one you created...you're dead in the water. You can't "un-import", even importing the backup entity doesn't fix the issue.

I may explore the configuration database and see if I can manually remove/update, but I think that will just create other issues. I can't delete those objects in my new dev and try to recreate them with an import because the relationships somehow prevent this and they (the relationships) cannot be removed.

Anyway, this has rambled on longer than I wanted to, but wanted to get this info out as I find it important to know.

Again, really good that we found this out now rather than doing it in production :)

2 comments:

vandelden said...

Hi,
Did you try to delete the relationships and retry to import the customizations?

Sometimes this will work...

Seth said...

Thanks vandelden,

I think I understand...so delete the relationships from the original dev system and re-import to my now broken system?

I don't think I actually tried that approach. I think it's worth a shot if I run into it again.