Overview
ECE Design software activates licenses by sending a secure request to our license server over the internet. If a computer cannot activate its license, it is usually because something on the local network — a firewall, proxy, or antivirus product — is blocking or altering that request.
This article provides a set of tests your IT team can run to confirm whether the affected computer can reach our license server, and how to interpret the results.
License server details
| Host | ecelm.ecedesign.com |
| IP address | 40.67.178.37 (Microsoft Azure) |
| Port / protocol | 443 (HTTPS) |
Important: Activation uses HTTPS on port 443 — not ping (ICMP). A failed ping does not mean the server is unreachable, because our host normally blocks ping by design. The tests that matter are the port test (Step 2) and the HTTPS test (Step 4).
Before you begin
Run all commands on the computer that cannot activate, using Windows PowerShell (unless noted), in the order below. Note the result of each step.
Step 1 – Confirm the address resolves correctly
nslookup ecelm.ecedesign.com
Expected: the address returned is 40.67.178.37.
- A different address → a DNS or hosts-file problem on the network.
- No result → DNS is not working, which by itself will block activation.
Confirm the hosts file is not overriding the address (this should return nothing):
Get-Content C:\Windows\System32\drivers\etc\hosts | Select-String ecedesign
Step 2 – Test the connection to the server (key test)
Test-NetConnection ecelm.ecedesign.com -Port 443
Expected: TcpTestSucceeded : True
- True → the computer can reach the license server. Activation should work; if it still fails, the cause is likely TLS inspection (see Step 4) or an application-side setting.
- False → a firewall or proxy is blocking outbound HTTPS to this host. This is the most common cause.
Step 3 – Ping (informational only)
ping ecelm.ecedesign.com
A timeout here is normal and expected — our host blocks ping. Do not treat a ping failure as a problem. It is only meaningful if it succeeds, which confirms basic routing.
Step 4 – Test the secure connection end to end
Invoke-WebRequest -Uri https://ecelm.ecedesign.com/ -Method GET -UseBasicParsing
- Any HTTP response (even an error code such as 404 or 405) → the secure connection is working through your network. This is good.
- A certificate or SSL error → a firewall or antivirus product is inspecting secure traffic and breaking the connection. This is common with products such as Zscaler, Palo Alto, Fortinet, and some corporate antivirus.
- A timeout → the connection is blocked at the firewall (this matches a
Falseresult in Step 2).
Alternatively, using curl (built into Windows 10 and 11), which shows the full secure handshake:
curl -v https://ecelm.ecedesign.com/
Step 5 – Trace the route (find where it is blocked)
tracert ecelm.ecedesign.com
This shows the path the connection takes across the network. If it stops at the first hop, the block is on your own firewall or gateway.
Interpreting the results
| Symptom | Likely cause |
|---|---|
| Step 1 returns the wrong address or nothing | Local DNS or hosts-file problem |
Step 2 shows TcpTestSucceeded : False | Firewall or proxy blocking outbound port 443 (most common) |
| Ping fails but Step 2 is True | Normal — ignore the ping, the connection is fine |
| Certificate or SSL error in Step 4 | TLS/SSL inspection is breaking the request |
| Every step passes | The network is fine; the issue is application-side |
Most common fix
Ask your IT team to allow outbound traffic to the host ecelm.ecedesign.com (and the IP address 40.67.178.37) on port 443, and to exclude it from any TLS/SSL inspection on the firewall or antivirus.
Still need help?
If activation still fails after these steps, please reply with the output of Steps 1, 2, and 4 and our support team will help pinpoint the issue.