Standalone replication does not respect bindings

Products

• Inventory Solution

Issue/Introduction

Historically, SMP was taking first available web site binding for the URL to be assigned as “NS entry point” for various operations.

 

If source server has 2 bindings (HTTP:80, HTTPS:443) and administrator uses replication over HTTPS then destination server may still callback using HTTP. In case of firewall between

servers replication would fail. The workaround was to disable http binding for replication to work.

 

Administrator was not able to choose different bindings for callbacks or particular port binding.

Environment

Release : 8.6 ru2 and earlier

Cause

Product design

Resolution

With 8.6 release update 3 we introduce set of changes, that helps administrator to get around this problem:

    1. number of Core Settings, that will force SMP to choose type of binding
    2. extra column in [ForwardServer] table – [ReplicationWeb] to keep it different from main url in [Web] column of the same table
    3. internal UI to change core settings for local server (@ Hierarchy and Replication/Servers page)

 

CORE SETTINGS:

Preferred Base Site Protocol

 <!-- preferred protocol for overall server web activities
 0 - no preference, 1 - http, 2 - https
 -->
 <customSetting key="PreferredBaseSiteProto" type="registry" regKey="Notification Server" regValue="PreferredBaseSiteProto" defaultValue="0" regValueType="DWORD" />

 

if not '0', this will force to choose either HTTP or HTTPS for the base site URL (the one in [Web] column of [ForwardServer] table for local server entry).

 

Preferred Base Site Port

<customSetting key="PreferredBaseSitePort" type="registry" regKey="Notification Server" regValue="PreferredBaseSitePort" defaultValue="0" regValueType="DWORD" />

If this setting is not '0' – we'll try to bind URL for exact port, but only if IIS have this port available as binding for specified protocol type – HTTP/HTTPS.

 

Preferred Replication Site Protocol

 <!-- preferred protocol for replication web activities
 0 - no preference, 1 - http, 2 - https 
 (if 0 or not set - using 'PreferredBaseSiteProto')
 -->
 <customSetting key="PreferredReplicationSiteProto" type="registry" regKey="Notification Server" regValue="PreferredReplicationSiteProto" defaultValue="0" regValueType="DWORD" />

same logic as “PreferredBaseSiteProto”, but for [ReplicationWeb] column of [ForwaredServer] table of local machine entry.

 

Preferred Replication Site Port

<customSetting key="PreferredReplicationSitePort" type="registry" regKey="Notification Server" regValue="PreferredReplicationSitePort" defaultValue="0" regValueType="DWORD" />
 
same logic, as for “PreferredBaseSitePort”, but for ReplicationWeb URL.

 

NEW UI in the “Servers” page:

Now it is possible activate “Edit” for local server – new UI with all the binding related settings will appear:

After setup and clicking “OK”, the API will change the Core Settings, but will it be effective – depends on the IIS being able to find out these bindings as available.

 

How it works

After changing the settings for local NS server, the “ReplicationWeb” can be used as “call back” entry point for remote replication peers.
If you do the Standalone replication – the target NS should use it, when connecting back to our local NS machine with replication feedback.

 

Manual steps to be performed on peers

Since peer does not get any certificates automatically in the standalone scenario, it means that customer have to manually install “replication source” certificate to access it's web site via HTTPS.