MSM installation wreaked havoc with Publishing Variables

Rhythmyx Technical Discussion
1

When we MSM’d from our development environment to production last week, it completely messed up the Publishing Variables in production, bringing in values from development. We had never seen this before. Reviewing the MSM and tracing through all the dependencies, we still cannot see how the development Variables were brought over. So, two questions:

  1. In what table are the Publishing Variables stored? We’d like to review what was working last week with what we’ve pieced back together, but so far we’re unable to determine where these variables are stored.

  2. Going forward, how do we avoid this happening? What components in the MSM process might possibly bring over the Variables as dependencies, and does the MSM UI give us a means of excluding those?

Thanks for your help
Brian J. Coan

2

When using MSM it is very important that you map your system objects between the servers correctly. Before you install anything map all elements between the source and target servers. If you allow it to “Guess” - it will overwrite your variables in Prod

What elements were you migrating?
Do you have any variables hardcoded in Content Types?

You can exclude it if you create a custom archive.

3

We had this happen to us before. yep, nightmare…

I believe you’ll find that the publishing variables travel along the MSM route as dependencies of a site definition. In our case, although the site defs were mapped correctly, the associated variables were assigned to incorrect sites defs. The variables were never displayed as dependencies (to be included or excluded), but upon inspection of the MSM xml documents, there were the variables. We removed these nodes directly from the XML document, and then we were able to safely apply the MSM to our production instance.

It “seemed” to me that behavior was introduced by a patch somewhere near the end our our 6.5.2 (upgraded to 6.7), so we didn’t delve to deeply…

As for the table you’re looking for… RXASSEMBLERPROPERTIES.

4

vtdarrell,

What are the MSM XML documents you’re referring to? We had an unexpected template overwrite as a result of attempting to install a package with just a content type in it, so I am investigating how to avoid that in the future.

The archive file (.pda file) isn’t XML, so I assume you are referring to something else?

Thanks,
Kathleen

5

I believe you can rename the .pda to a .zip and view the contents (should be multiple files). You should modify those files at your own risk. (of course rename back to .pda once you’re done)…I highly doubt this is supported (or documented) anywhere…

6

My learned colleague is correct. A trek through the MSM xml is not for the faint of heart.

Based on the description of your problem, the first place I’d look is the MSM ID mappings on the target server (that is if by “template overwrite,” you mean one template was overwritten by a completely different template). It may be that the template was included as a dependency of your content type.