Configuring microsite functionality using ContextUrls or RelativeUrls

Question

I'm seeing a localization error when testing microsite functionality in Web 8.5 and DXA 2.0 (.NET), ie servername:port/abc. I see there are two ways to do this, using either the server-relative URLs or context-relative URLs. Either looks like it should work, although using a context appears to be slightly more elegant. However on my test server for both scenarios, I am seeing same debug error "Request URL 'http://servername:8888/CO/' maps to Localization [5 ('English')]", any pointers for where the misconfig is would be welcome. Localized language/culture is not a requirement, but I've followed that convention to help troubleshoot.

I have three test websites/publications (edited to respond to Rick's answer):

Publications

• 400 Example Site (tcm:0-5-1)
• 400 Example ES (tcm:0-3719-1)
• 400 Example NL (tcm:0-3720-1)

Websites

• http://servername:8888/es/ --> 403 error, Access to servername was denied
• http://servername:8888/nl/ --> DXA 404 error

Topology config

get-ttmwebsite
BaseUrls             : {http://<servername>:8888}
CdEnvironmentId      : CdEnvironmentStagingId
EnvironmentPurpose   : Staging
Id                   : Website1

get-ttmwebapplication
ContextUrl           : /
WebsiteId            : Website1
EnvironmentPurpose   : Staging
Id                   : Website1_RootWebApp
ContextUrl           : /nl
WebsiteId            : Website1
EnvironmentPurpose   : Staging
Id                   : WebApplication2

get-ttmmapping
CmEnvironmentId     : TridionCM_localhost
PublicationId       : tcm:0-5-1
EnvironmentPurpose  : Staging
WebApplicationId    : Website1_RootWebApp
RelativeUrl         : /
PrimaryMappedUrl    : http://<servername>:8888/
IsOffline           : False
Id                  : Mapping1
CmEnvironmentId     : TridionCM_localhost
PublicationId       : tcm:0-3719-1
EnvironmentPurpose  : Staging
WebApplicationId    : Website1_RootWebApp
RelativeUrl         : /es
PrimaryMappedUrl    : http://servername:8888/es
IsOffline           : False
Id                  : Mapping3
CmEnvironmentId     : TridionCM_localhost
PublicationId       : tcm:0-3720-1
EnvironmentPurpose  : Staging
WebApplicationId    : WebApplication2
RelativeUrl         : /
PrimaryMappedUrl    : http://servername:8888/nl/
IsOffline           : False
Id                  : Mapping4

Preceding configuration are as noted from forum posts are:

Multilanguage with DXA 2.0 SDL Web 8.5

All binary images stopped working when created Ttm Mapping with default value for Relative Url

Configuration

1. Have published the ES and NL publications, and verified they are in broker DB via discovery endpoint http:///PublicationMappings(TCMID)
2. Master publication (400 Example Site) config
3. Child NL (400 Example NL) config, localized Localization configuration
4. Child ES (400 Example ES) config, localized Localization configuration
5. Have published all three publications, and published again Publish Settings after making any config changes

6. Force synced TTM

   sync-ttmcdenvironment -Id CdEnvironmentStagingId Synchronizing CdEnvironment 'CdEnvironmentStagingId' Are you sure you want to perform this action? Y

7. Have restarted IIS, done /admin/refresh on front-end
8. _all.json file from master publication

9. _all.json file from child publication ES

   10. No ES or NL website in IIS

   11. Copy of staging webapp under master webapp with foldername es.

Edit to reflect updated ttmmapping

After updating the NL microsite mapping to have a RelativeUrl of "/nl", output is below, which has an extraneous /nl appended to the PrimaryMappedUrl param.

CmEnvironmentId     : TridionCM_localhost
PublicationId       : tcm:0-3720-1
EnvironmentPurpose  : Staging
WebApplicationId    : WebApplication2
RelativeUrl         : /nl
PrimaryMappedUrl    : http://servername:8888/nl/nl
IsOffline           : False
Id                  : Mapping4

Answer 1

In your screenshots, I see a mix of server-relative URLs and context-relative URLs. The former are supported mainly for backwards compatibility and the latter are recommended. This means:

• Leave the Publication URL empty (note it is the only field which is not required)
• Ensure the Images URL does not start with a slash and make it relative to the context URL (which you can see in the Publishing Mappings)
• Ensure the Mappings in Topology Manager have a RelativeUrl set to reflect the context URL.
• Republish the “Publish Settings” Page to ensure the URL configuration is up-to-date in DXA config (_all.json)

In general, Topology Manager URL configuration (on Website, WebApplication and Mapping) should reflect your infrastructure.

You mention two “websites”, but technically speaking those are probably one Website in IIS and probably also one (root) Web Application, which can map to multiple Publications, because of distinct URL paths (RelativeUrls on Mappings in Topology Manager).

So: WebApplication2 (with ContextUrl of /nl) probably does not reflect your infrastructure. Or did you really create a separate nl Web Application in IIS?

Furthermore, I don’t see a Mapping for /nl, which can explain the 404 error.

The 403 error is remarkable and does not seem to be related to Topology Manager Configuration. You should check the IIS logs and/or the response body to determine what the root cause is. Could be a file permission issue.