Sage 100

EBM 3.71 problem - customer redid their IP address scheme, and after adjusting all the EBM settings in MAS and in the MASISAPI.ini file, the web engine just comes back with ""Internet Explorer cannot display the web page"". From the internet, this appears after a minute or two of nothing happening. While on the machine where the web engine is installed, http://127.0.0.1/iwwiaa.pvx?;login returns the same result immediately. netstat -a shows listening on ports 2953 and 2954, web config shows the web engine as running. I have tried this with the web engine running as a service and as an application. Web engine and IIS boxes have both been rebooted, webhide.ini file path to MAS 90 verified as accurate and reachable. Any ideas??

does the __debug work? In the masisapi.ini file what is the remappings? are they using DNS or IP address. You stated that you rebooted the services but did you make sure that there were no pvxwin32.exe programs still running on the server?

Start by looking at the Web Engine Error Log under MAS / eBusiness Manager / Main. It could be something silly. Also do loopback test as Todd suggested: http://<website>/__debug.pvx Also you could try to reach the web engine directly. Don't remember the syntax but something like: http://<ip_of_web_engine:2953>/iwwiaa;login Basically if you see a unformatted login page (and syntax is correct) then firewall policy is okay.

http://127.0.0.1:2953/__debug.pvx results in ""the webpage cannot be found"". http://127.0.0.1:2953/iwwiaa;login results in the login screen http://127.0.0.1:2953/iwwida;products_no_tree results in the ebm page header (with missing images as they are on the IIS server) and the text ""Web access not available."" External access still results in a long pause followed by ""Internet Explorer cannot display the webpage"". From the IIS box, http://<ip of webengine>/iwwiaa;login results in ""Internet Explorer cannot display the webpage"". No stray pvxwin32 processes when the web engine services is stopped. MASISAPI.ini uses IP addresses on the ""map to"" side.

Dont put the port number in the __debug.pvx line. Did you look at Web Error Log in eBusiness Manager / Main

Removing the port number from the __debug.pvx line makes no difference. Nothing in web error log since 4/3.

Got it thanks. Since nothing is in Web Error Log it means you haven't made it to the Web Engine or not very far after reaching it. Since you can see the login screen and products screen (without images) but the loopback test fails, this means the problem is somewhere in the .pvx ISAPI configuration. I don't know which IIS version you're on but look through the whole ISAPI configuration in IIS Mgmt Console (maybe even remove the .pvx mapping and add it back). Perhaps there is a reference to the old IP somewhere or the Execute permissions is not set to ""Scripts and Executable"" .. something along those lines.

I went through all the steps in the ""ISAPI manual install"" procedure, including removing and adding back the pvx mapping and extension, stopped and restarted IIS, still no joy. I can get the login screen by calling the web engine directly from either the web engine server or the IIS server, but that's it.

Last thing. Now that I'm back at my PC with a screen much bigger than my phone, I see I overlooked 1 point of detail you mentioned. You said: http://<ip of webengine>/iwwiaa;login --> fails (this was the public IP right?) http://127.0.0.1:2953/iwwiaa;login --> okay This could simply be the firewall policy of the Web Engine is not set to Allow inbound access from the new IP of the IIS box. Here's 1 way to test. Check if you can ping the web engine external IP from the IIS box. If you can't then you can't run this test as it means the firewall is blocking ICMP requests (no PINGs and similar allowed). But if you can ping then try this command from the IIS box. telnet w.x.y.z 2953 (where w.x.y.z is the public / external IP of the web engine) In the end, if you can ping but you can't telnet then it's the firewall policy. Of course it might be easier to just ask IT if they have added a firewall entry yet to Allow Inbound 2953 and 2954 from the new IIS box IP.

Sometimes it's the simple things, like IT people. When they redid the DNS, they had the web name of the IIS box resolving to the IP address of the computer where the web engine is running. I will confirm when they get that fixed. @AlnoorCassim and @ToddMartin, thank you for your help!