Product: Mingcedar CONTROL

Prepare and troubleshoot Site connections | Mingcedar

Scroll horizontally to view the full table

Published 2026-10-25T12:48:42.640823531Z Updated 2026-10-26T19:56:55.647943625Z

<div class="manual-doc-article manual-doc-article-section"><h2 id="site-connection-setup">Deployment preparation: Prepare and troubleshoot Site connections</h2>

Ordinary LAN enrolls Node identities through Portal addresses. This chapter covers network, permissions, connection verification and project-certificate mode.

<h3 id="site-trust-boundaries">1. Separate user login, Site connections and API credentials</h3>

<p class="doc-table-hint">Scroll horizontally to view the full table</p>

<thead><tr><th scope="col">Purpose</th><th scope="col">Identity</th><th scope="col">Where to prepare it</th></tr></thead><tbody>

<tr><th scope="row">Browser access to configuration or runtime screens</th><td>Signed-in account and browser HTTPS trust.</td><td>The installed Portal address and user/role configuration.</td></tr>

<tr><th scope="row">One Mingcedar server accessing another Site</th><td>Persistent Node identity and directional authorization.</td><td>Ordinary LAN enrollment runs through Discover Sites / Add by Address. Explicit project-certificate installations use their project configuration.</td></tr>

<tr><th scope="row">An external application calling IO State API</th><td>A separate API Access Key and read scope.</td><td>IO State API credential and scope configuration.</td></tr>

</tbody></table></div>

<p class="doc-step-result"><strong>Expected result</strong> A Site connection does not replace user login, and an API Key is not a Site joining password.</p>

</article>

<h3 id="site-trust-identities">2. Prepare addresses and network access</h3>

<ol>

<li>Open both Portals and record their full HTTPS root addresses, versions and Site names. A hostname must resolve from the peer server; an actual IP address can also be used.</li>

<li>Check that the peer Portal port is reachable from the server network. Browser access alone does not prove that the two servers can reach each other.</li>

<li>Use the published address and port reachable by the peer for both native and container deployments. Container-internal addresses and the peer’s <code>127.0.0.1</code> are not Site connection addresses.</li>

<li>Check time synchronization and persistent data/identity storage. Sign in to the initiating Site with Site management permission.</li>

</ol>

<p class="doc-step-result"><strong>Expected result</strong> Sites collaborate over HTTPS without exposing PostgreSQL or Redis. Use reachable hostnames or IPs; custom DNS is unnecessary.</p>

</article>

<h3 id="site-trust-certificates">3. Identity handling for ordinary LAN connections</h3>

<p>Each installation retains its Node identity. The first connection verifies and remembers the peer Node, trust root and Runtime Unit; later traffic uses mutual TLS and authorization checks. No manual certificates are needed.</p>

<ol>

<li>Verify the target server address on the trusted deployment network before connecting or adding it through Discover Sites. The first connection trusts the server actually reached.</li>

<li>To inspect Devices first, expand the target or select Connect and View Devices. To establish membership, select Add Site / Join.</li>

<li>Wait for success, then choose the required sources in Local Capabilities.</li>

</ol>

<p class="doc-step-result"><strong>Expected result</strong> Scanning discovers addresses. Device preview may establish a connection, but does not join a Site or select sources. Each installation retains its private key.</p>

</article>

<h3 id="site-trust-register">4. Verify an unfinished connection</h3>

<ol>

<li>If a connection times out or its result is unconfirmed, select Verify Enrollment beside the original target. The system reads that operation’s result.</li>

<li>Once continuation is available, select Continue Joining or Continue Viewing Devices. The first continues membership; the second retains the Device-preview purpose.</li>

<li>If Site Joined appeared but the list failed to refresh, close the dialog and refresh the Sites page.</li>

<li>If connection records cannot be saved or read, restore browser session storage and reload. While new connections are paused, Verify Enrollment remains available for checking existing results.</li>

</ol>

<p class="doc-step-result"><strong>Expected result</strong> Follow the next step shown after verification. You do not need to enter or add the same address again.</p>

</article>

<h3 id="site-certificate-registration">5. Address changes and identity conflicts</h3>

<p>An address locates the server; the Node identity identifies the installation. Matching display names do not establish matching identity.</p>

<ol>

<li>If only the IP or hostname changed, discover and verify the new published address while preserving the original persistent identity.</li>

<li>For Identity Conflict, check whether the address reaches the wrong server or the server was reinstalled with different identity material.</li>

<li>If a reinstall genuinely changed identity, follow the deployment’s identity recovery or replacement procedure, then explicitly recreate required membership, capability selections and Device scopes.</li>

</ol>

<p class="doc-step-result"><strong>Expected result</strong> A new address for the same identity does not become a separate Device configuration, and a changed identity does not silently inherit the old source’s authorization.</p>

</article>

<h3 id="site-initial-policy">6. Select capabilities and scopes after connecting</h3>

<p class="doc-table-hint">Scroll horizontally to view the full table</p>

<thead><tr><th scope="col">Action</th><th scope="col">When it takes effect</th><th scope="col">What remains to configure</th></tr></thead><tbody>

<tr><th scope="row">Add Site</th><td>The successful join appears in Joined Sites.</td><td>Select each required capability source.</td></tr>

<tr><th scope="row">Add capability node</th><td>After saving, subject to current availability and routing prerequisites.</td><td>IO needs a PLC usage scope; Alarm, Trend and Screens need their respective business configuration.</td></tr>

<tr><th scope="row">Save remote PLC scope</th><td>After preview, confirmation and a saved/effective result.</td><td>Individual Tag references and caller permissions.</td></tr>

<tr><th scope="row">Reverse sharing or PLC writes</th><td>After their separate authorization and operation workflows.</td><td>A → B does not automatically enable B → A or grant PLC writes.</td></tr>

</tbody></table></div>

</article>

<h3 id="site-trust-configuration">7. Installations with explicit project certificates</h3>

<p>If the deployment explicitly uses a project CA, Node certificates or project communication policy, prepare both endpoints’ certificates and connection permissions according to that plan. Ordinary LAN connections do not require these project materials.</p>

<ol>

<li>Use installation records to check each Node identity, project CA, Node certificate and private-key location, validity and revocation state.</li>

<li>Verify certificate registration and the active communication policy against the project deployment plan, including direction and capability. The ordinary Site join dialog does not edit these project materials.</li>

<li>After the applicable runtime configuration has loaded, scan again. Project Identity Unverified points to project connection configuration. Automatic Site Identity Verification Incomplete points to ordinary LAN versions, connection records and services.</li>

</ol>

<p class="doc-step-result"><strong>Expected result</strong> Add the Site after verifying its configured identity mode. Ordinary LAN needs no CA or shared key.</p>

</article>

<h3 id="site-trust-handover">8. Follow the connection feedback</h3>

<p class="doc-table-hint">Scroll horizontally to view the full table</p>

<thead><tr><th scope="col">Feedback or symptom</th><th scope="col">Action</th><th scope="col">Completion</th></tr></thead><tbody>

<tr><th scope="row">No Sites found / discovery incomplete</th><td>Search by name or full HTTPS address, or use Add by Address. Check server-to-server port access.</td><td>The target address is discovered or verified.</td></tr>

<tr><th scope="row">Read-only account / 403</th><td>Check Site management permission for the acting account; sign in again if needed.</td><td>The corresponding management controls and requests are available.</td></tr>

<tr><th scope="row">Automatic identity verification incomplete</th><td>Check compatible versions, service state and the original connection records on both servers.</td><td>Identity verification completes, allowing Device preview or joining.</td></tr>

<tr><th scope="row">Project identity unverified</th><td>Check the project connection configuration using this chapter’s project-certificate steps.</td><td>The Site can be added after scanning again.</td></tr>

<tr><th scope="row">Join outcome unconfirmed</th><td>Use Verify Enrollment and continue as prompted.</td><td>The original operation has a confirmed result.</td></tr>

<tr><th scope="row">Joined but no data</th><td>Check selected/available capability sources, then PLC scope and source Tag enablement and quality.</td><td>The scope is effective and the specific Tag has a valid value.</td></tr>

</tbody></table></div>

<li><a href="/en/hqserver/manual/sites/#sites-join">Connect Sites and choose capabilities</a></li>

<li><a href="/en/hqserver/manual/io-sharing/">Select PLCs and read remote data</a></li>

</ul>

</article>

</div>