5

With SDL 8/8.5, and the introduction of Topology Manager. My understanding was that content refreshes were more streamlined and efficient.

I tend to agree here with the statement; however, I have a couple of questions regarding a refresh I did yesterday. Pretty simple restore use-case here really:

I copied down only: - Content Manager Database - All Broker Databases

Note: Topology Manager and Discovery Databases are still intact to the lower environment I am restoring.

Once the database restore was completed, I fired up PS ISE and execute my sync environment cmdlts against each target and presumably, I am done with the refresh.

I spot checked my favorite publication, quick test publish - BOOM! Works! Super Fast!!


However, once I turned back over to our users - they notice that some more recent publications for newer products do not have the environment purposes setup on their respective publication properties.

So when I look in TopMan at Get-TtmMapping on the env I am restoring too - I do not see these mappings. I open up a publication and see that nothing is configured.

enter image description here

And from my knowledge of what goes on with these environments - These are more recent publishing mappings; actually I can tell each publication that is not configured is post - TopMan migration script from prior SDL 2013 to SDL Web 8.5 upgrade migration script.

My Question: Where did they go? Are they not saved and kept with TopMan in each environment?

Is there a additional step I need to do AFTER the BA's create these publications and configure purposes on each via the UI/CME? Do I need to do anything in Topology Manager after the environments are mapped on the publication properties?

Keeping in mind that we share the same targets within our entire instance. Live, Preview etc. So all that needs to be done when creating a new publication is mapping the relative url for the bpt Topology Type that already exists..

Basically, I am stumped since, I know for a fact, the target/purposes were created/saved/mapped and working (via UI) in the target restore environment. Wouldn't that be then saved in TopMan?

Where did they go after the restore? I didn't touch TopMan or Discovery DB's. Maybe I should have since they're configured in the source env also? I have done that before, but then I need to restore the entire environment as a whole...

Do the relative urls nomenclature need to be exact? I think it was, but just thinking what I would be different between environments here.


UPDATE

This is also impacting our security model as well for publishing targets. There are way too many things I need to fix inside the CMA - to get this to work correctly.

I suppose anyone else upgrading to SDL Web 8.5 - copy down the entire environment as-is, then make your changes and you should be all set. For us it is not feasible to only restoring the Content Manager and Published Content.

enter image description here

  • I guess that the”Invalid value for property “TopologyTypeId” is because you probably have different IDs for your Topology Manager settings (Topologies, Types, CD Environments, etc.). Knowing about these issues up front, you’d have probably made different implementation decisions. I know that myself, Dominic and a few others have talked about this is the past (at TDS, etc.), but maybe the official online documentation/guidance around this needs to be more explicit. – Jonathan Williams Feb 10 at 12:47
3

Performing Lower Environment refreshes are much easier with SDL 8.5. However, I do feel I found a defect here.

If you're following and you've copy down the (Source) Content Manager and the Brokers databases to your (Target) Lower Environment, but had publications that either:

(A) existed there, and were not created in Production yet

OR

(B) created in Production (Source env), and mapped, but with different tcmids

Expect to lose your mappings and/or any dependency you had on those. For example, Security Groups based on those tcmids, any dependency obviously will break etc.

Here is my hack:

  1. Save off TopMan Discovery urls
  2. Copy all Databases down from "Source Environment"

    DO NOT COPY DOWN Topology Manager

  3. Bring down all containers in "Target Environment"
  4. Modify Dockerfile / CIS credentials to updated SQL Server DB credentials, and bring up containers
  5. Get-TtmCmEnvironment & Set-TtmCmEnvironment (to target TtmCmEnvironment)
  6. Get-TtmCdEnvironment & Disable-TtmCdEnvironment -Id Purpose_CdEnvId
  7. Export-TtmCdStructure -CdEnvironmentIds Purpose_CdEnvId -Path C:\SDLWeb\DiscoveryUrls.txt

    Open up the .txt and update the discovery urls you saved off to match Target env (bc of TopMan no tbeing refreshed)

  8. Import-TtmCdStructure -Path C:\SDLWeb\DiscoveryUrls.txt -UpdateExistingItems
  9. Enable-TtmCdEnvironment -Id Purpose_CdEnvId
  10. Sync-TtmCdEnvironment
  11. Enable-TtmCdEnvironment -Verbose -Id Purpose_CdEnvId
2

Topology Manager uses the TcmId of the Publication to map each Publication to a specified WebApplication.

Given that you're talking about a problem with newer publications only, it's likely that Mappings in your lower environments are no longer valid, and thus no longer show up, because the new Publications' TcmIds are different between Production and the lower environment(s).

Can you confirm by comparing the TcmId of these Publications in Production and the lower environment(s)?

If you run Get-TtmMapping in Production, then you'll see that these specify the TcmId of the Publication that's mapped.

PS C:\Users\Administrator> Get-TtmMapping

CmEnvironmentId     : Tridioncm_localhost
PublicationId       : tcm:0-16-1
EnvironmentPurpose  : Staging
WebApplicationId    : Website1_RootWebApp
RelativeUrl         : /
PrimaryMappedUrl    : http://localhost:93/
IsOffline           : False
CdEnvironment       :
Id                  : Mapping1
ExtensionProperties : {}

If that is the case, and the Publication TcmIds are different, then you're going to need to recreate the mappings (from the WebApplication - which should still exist) using the new Publication TcmId.

  • Ouch! If that’s the case, it doesn’t seem too efficient. – Andrew William Ross Feb 7 at 18:17
  • Yes. Maybe using the Publication Key, or something that doesn’t change between environments would’ve been better – Jonathan Williams Feb 7 at 18:42
  • Absolutely. Foe example like webdav path. Isn't that the #1 rule about programming with Tridion. Never hard-code tcmids?? I am opening a defect. For us, this impacted about 30+ publications x 5 purposes per. And i could implement a workaround for the team (use another relative url) but then publish states, yada - doesnt seem right here – Andrew William Ross Feb 7 at 18:45
  • The idea was that you will sync your DTAP environments from the start. For example, you will create your Acceptance env from a backup of Prod. With that approach, Publication IDs will be identical on all environments. If this is not the case initially, it will become the case later. You may have to redo the mapping one time, but you should then be fine for subsequent syncs. – Rick Pannekoek Feb 7 at 19:04
  • Okay. We create publications on the way up through Production, not on the way down :) – Andrew William Ross Feb 7 at 19:44

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.