Your network uses TCP/IP only. Some remote-access clients see “IPX/SPX compatible computer reported error 733: The PPP control protocol for the network is not available,” yet they still connect to TCP/IP services. How do you prevent this warning from appearing?

Introduction / Context:
Error 733 occurs when a PPP client attempts to negotiate a network control protocol (NCP) that the server does not support. In this case, the environment is TCP/IP-only, but the client is attempting to bring up IPX/SPX over PPP. The connection proceeds using TCP/IP, but the IPX NCP negotiation fails, generating the warning.

Given Data / Assumptions:

• RRAS server supports only TCP/IP, not IPX/SPX.
• Clients still connect and can use TCP/IP services.
• Undesired warning message appears during connection establishment.

Concept / Approach:
The fix is to stop the client from attempting to negotiate unsupported protocols. On Windows dial-up/VPN connection properties, uncheck IPX/SPX (and NetBEUI, if present) so only TCP/IP is bound and negotiated. This prevents the PPP negotiation from proposing IPX NCP at all, eliminating error 733. Enabling IPX on the server contradicts the TCP/IP-only design. Assigning IPX addresses on clients will not help if the server refuses IPX.

Step-by-Step Solution:
1) On the client, open the connection's Networking tab.2) Uncheck “NWLink IPX/SPX/NetBIOS Compatible Transport Protocol.”3) Ensure only “Internet Protocol (TCP/IP)” remains enabled.4) Reconnect; the warning should no longer appear, and TCP/IP services will continue to function.

Verification / Alternative check:
Reconnect and confirm the absence of the message; review RAS logs for negotiated protocols showing only IPCP (IP Control Protocol) succeeding.

Why Other Options Are Wrong:

• Assign IPX address or enable IPX on server: Contradicts the TCP/IP-only policy and adds unnecessary complexity.
• Disable multilink: Unrelated to protocol negotiation errors.

Common Pitfalls:
Leaving legacy protocols enabled in client connection properties; troubleshooting servers unnecessarily when the issue is client-side negotiation.

Final Answer:
Configure the client to use only TCP/IP for the remote connection