Troubleshooting Mori-Server Standard-User Connection

Daniel Price10 min read
Industrial NetworkingOther ManufacturerTroubleshooting
Licensed PE Working through this on a live machine? A Maine-licensed engineer can take it from here — included with IMD hardware, by the hour for everything else. Book an engineer

Mori-Server 5.6 launches for a standard Windows user, but its communication test fails against a powered, networked DMG Mori machine. The same test succeeds when Mori-Server is elevated or run from an account with local administrator rights. Follow the request from the application to the CNC: local initialization, host security controls, physical Ethernet, IP reachability, transport connection, and the selected machine interface.

Where does the Mori-Server request stop?

The data path begins in the interactive Mori-Server process. Before any packet can leave the PC, the program must read its machine definition, initialize local components, open any required configuration or log files, access required registry data, and create a network socket. The packet then crosses the Windows filtering stack, the PC network adapter, cabling and switching, and finally the CNC network interface. Only after that path is open can the selected MAPPS interface exchange application data.

The reported standard-user failure is:

Communication Error!
Error -3003102 in PC
13000000:-3003102: 0: 0: 0:
Initialize Error.

The word Initialize matters. Elevation cannot repair a disconnected cable or power up a CNC. If the same PC, address, cable, switch path, and machine work immediately after elevating only the application, the deciding variable is inside the PC: application initialization permissions, a user-scoped configuration difference, or a host security rule.

The message alone does not identify the failed layer because Mori-Server also presents an apparently identical communication error when the machine is off. That means the application collapses multiple failures into one visible result. Diagnose the path instead of treating -3003102 as proof of an Ethernet outage.

Which supported approach fits this failure?

Approach What it proves or changes Operational effect Decision
Give operators local administrator rights Bypasses the privilege boundary that triggers the failure Restores communication in the affected installation but grants privileges unrelated to machine communication Use only as a controlled diagnostic comparison, not as the production design
Run only Mori-Server as administrator Shows that elevation of the process changes the result Communication works, but each launch still depends on elevated credentials or an elevation mechanism Useful for reproducing the boundary; it does not identify the denied resource
Correct the specific file, registry, component, or firewall permission Removes the actual standard-user block while retaining least privilege Lets the operator run Mori-Server normally Recommended after tracing the failed operation
Replace Mori-Server Changes the application and possibly the communication method Introduces compatibility, configuration, and validation work Consider only after identifying the required CNC interface and confirming that Mori-Server cannot be remediated or supported

Mori-Server does not inherently require every user to be a local administrator. A separate Windows 10 installation connected from a standard local account to an M730BM control using MAPPS IV, the correct IP address, and no username or password. That comparison does not prove compatibility with every control, but it shows that elevation is not a universal protocol requirement.

The affected fleet reported the behavior across Windows XP, Vista, Windows 7, and Windows 10. Windows 7 and older systems consistently required local administrative rights in that installation, while Windows 10 results varied between PCs. That pattern favors a host-specific installation, permission, security-policy, or per-user configuration difference over a CNC network requirement.

Why can ping succeed while Mori-Server fails?

Ping tests IP reachability with ICMP. Mori-Server uses an application conversation whose transport port and direction must be learned from the working connection, product configuration, or manufacturer documentation. A successful ping proves that the PC can resolve a route to the address and receive an ICMP response. It does not prove that the application initialized, that its executable may use the network, that the required transport port is open, or that the CNC accepted the application request.

One comparison system reached 192.168.1.119 from both administrator and local-user sessions. Four requests received four replies with 0% loss; reported round-trip values were 0 ms minimum, 1 ms maximum, and 0 ms average. Mori-Server also connected under either account on that system. Use those values only as that system's result, not as acceptance limits for another network.

Observed result Layer reached Next check
No link indication or no network-adapter connection Physical layer has not passed Power, adapter state, switch port, and cable
Ping fails for both standard and elevated sessions IP path remains unresolved Target address, subnet, route, duplicate address, and CNC state
Ping works in both sessions, but no Mori-Server packet leaves in the standard session Failure occurs before or at socket creation Denied files, registry data, local components, and endpoint-security events
Packets leave both sessions, but only the elevated session receives or accepts a response Host filtering or process policy differs Firewall and security rules by executable, user, profile, direction, and observed port
Both sessions complete the same transport exchange, but only one reports -3003102 Network path is not the differentiator Local application state, output files, logs, component activation, and per-user settings

How should the failure be isolated?

  1. Record the working machine definition before changing anything: Mori-Server version 5.6, the actual CNC IP address, selected MAPPS I/O option, control identification from the machine, and whether credentials are configured. The affected configuration used an IP address with no username or password.

  2. Establish layer one. Confirm that the CNC is powered, its network interface is active, the PC adapter is connected, and the switch path remains unchanged. Use the same PC, cable path, CNC, and machine definition for every privilege comparison.

  3. From the standard-user session, ping the configured CNC address. Repeat without changing accounts while Mori-Server is elevated. If the ping result changes with elevation, investigate host security software or a command environment difference. Normal IP reachability itself does not require application elevation.

  4. Run a four-case matrix: standard account with a normal launch, standard account with Mori-Server elevated, administrator-group account with a normal launch, and that account with an elevated launch. Record whether the program launches, the communication test result, and the exact error text. This separates account membership from process elevation under Windows access control.

  5. Capture the working and failing network attempts. Determine whether the standard-user process sends any packet, which destination address and port it uses, whether the exchange is inbound or outbound, and where the first difference appears. Do not create a firewall exception around a guessed port.

  6. At the same time, trace failed file, registry, and component-access operations generated by Mori-Server. Filter to the Mori-Server process and the communication-test interval. Look for access-denied results immediately before -3003102.

  7. Review Windows firewall and third-party internet-security or endpoint-control logs. Compare rules applied to the actual executable under each user and active network profile. A rule may allow the elevated process while blocking or constraining the standard-user process.

  8. Change one cause at a time, return to a normal standard-user launch, and repeat the communication test. Keep the packet and local-access traces until the first failing operation disappears and the machine exchange completes.

How should least privilege be restored?

If the trace identifies a denied application-data directory, log directory, or configuration file, grant the operator group only the access Mori-Server actually uses. Apply the permission to that specific resource. Do not grant broad write access to the full installation directory, a Windows directory, or an entire registry branch.

If a registry access fails, identify whether Mori-Server reads the value or must update it. Grant read or modification rights only at the required application key. If a local component fails to initialize, compare its registration and activation permissions with the working elevated case; repair the component installation through the approved installer or manufacturer procedure instead of granting blanket administrative rights.

If the first difference is a blocked network operation, build the rule from captured facts: the Mori-Server executable, observed direction, actual destination address, actual transport protocol and port, and the applicable Windows network profile. Scope the remote address to the CNC or machine subnet where operationally practical. Recheck third-party security controls because changing Windows firewall alone will not override a separate endpoint filter.

Per-user configuration also deserves inspection. An elevated launch may read or create state in a different user context, while a standard launch uses another profile location. Compare machine definitions and required local data between the working and failing contexts. Do not copy unrelated administrator-profile data wholesale; transfer only the Mori-Server configuration required for the connection.

What should be compared between working and failing PCs?

Field Working value to record Failing value to record
Software Mori-Server version and installation method Mori-Server version and installation method
Account Local or domain status, group membership, normal or elevated token Same four attributes
Machine setting CNC IP, MAPPS selection, control type, credential use Same fields
Address Destination observed in the working packet trace Destination observed in the failing trace
Port and direction Observed protocol, local and remote ports, inbound or outbound flow First missing or rejected operation
Timing Packet and local-access timestamps around a successful test Timestamp immediately before -3003102
Security Firewall profile, executable rule, endpoint-security decision Corresponding applied policy and event
Local resources Files, registry keys, and components accessed successfully Access-denied or missing-resource result

Windows 10 success on one PC and failure on another should be handled as a configuration comparison, not as proof of random network behavior. Match the executable version, installation context, active firewall profile, security product policy, application-data permissions, and machine definition before comparing CNC responses.

How is the correction verified?

  1. Remove the diagnostic elevation path and sign in as the intended standard operator account.

  2. Start Mori-Server normally and confirm that no administrator prompt or alternate credential is used.

  3. Run the built-in communication test against the powered CNC. Confirm that -3003102 and Initialize Error do not return.

  4. Verify the required production communication function, not only ping or application launch. Confirm from the packet trace or connection state that the exchange uses the intended CNC address and observed port.

  5. Restart Windows, repeat the normal standard-user launch, and rerun the communication test. This detects fixes that depended on an elevated process, a temporary handle, or a one-session firewall state.

What diagnostic record should go to DMG Mori support?

If no denied operation or filtering event appears, provide DMG Mori through an official support channel with the exact Mori-Server version 5.6, the full -3003102 text, Windows version, control identification, selected MAPPS interface, privilege test matrix, and sanitized working-versus-failing traces. Ask which local files, registry locations, components, transport ports, and Windows permissions that release requires.

Do not select replacement software solely because elevation changes the result. First document the CNC interface and required operations. Any replacement must support the installed control and the actual transfer workflow; a generic network connection or successful ping does not establish application compatibility.

FAQ

What happens if Mori-Server can ping the machine but still shows error -3003102?

Ping proves ICMP reachability only. Check whether Mori-Server sends its application packet, then inspect local access failures and firewall decisions at the timestamp of -3003102.

What happens if Mori-Server works only when Run as administrator is selected?

The privilege boundary is changing local initialization or host filtering. Compare file, registry, component, and security events between normal and elevated launches, then grant only the specific access the trace identifies.

What happens if the same communication error appears when the CNC is off?

Mori-Server is presenting one error path for different underlying failures. Confirm power and link first, then follow the packet to distinguish no network response from a local Initialize Error.

What happens if one Windows 10 PC works for a standard user and another does not?

Compare Mori-Server version, installation context, machine definition, firewall profile, endpoint policy, and application-data permissions. Keep the CNC address and network path fixed while testing.

What happens if a narrow permission or firewall change appears to fix Mori-Server?

Remove elevation, restart Windows, launch Mori-Server as the production standard user, and repeat both the communication test and the required machine operation. The final pass must complete without -3003102 or administrator credentials.

Back to blog