Our website not running on new server Tour website we have 2 servers one of them the site working good, we have moved the portal to other server, so when we point the dns it is not working...Web not working and then you can see the panel of that server in second imageCWP web control panel I need the solution, kindly give the proper solution...
You are using CentOS Web panel as the hosting control panel. While browsing the website check the apache error logs on the server at path
/usr/local/apache/logs/
and those logs will give you idea of whats happening.
My website is working with some ISP while it is not working with others. Also not working from other countries.
The app is hosted at our company. Developed using sharepoint asp.net.
The app works at my home.
But if I visit the website at my brother's home who is registered to different ISP, the website opens and a login dialog appears. When entering correct username and password then submit , textboxs cleared and dialog come again.
The problem is happening with many visitors.
I just want to know what would be the problem! Does anyone faced such problem before?
I checked all IIS restrictions. There is no restrictions made.
I created a new app using sharepoint with login page and it works great.
somebody said that users with public ip can access the site while others with dhcp cannot. Can somebody explain that !
Some ISPs have transparent proxies in use. And some of them are accidentally (or even intentionally) broken and cache more, than they should. You can check whether that's the problem:
Set up your server to also allow https and then use that. You should move to https for privacy reasons anyways, so just do it now ;)
This way, the proxy can't do anything but to pass the data between client and server unmodified.
If that is not an option: Use tcpdump/wireshark/other-sniffer on both - client and server - at the same time and compare the logs. Did the second access even make it to the server?
Do you have a laptop/tablet/smartphone with which you can access the web server? Try moving that laptop from one location to the other and check, whether it works with that one laptop using one ISP and fails with the same laptop on the other ISP.
This should be a comment, but I do not have enough to post it as such.
Are sure that it is not a browser issue?
Is the login dialog from SharePoint, your app or the browser itself?
If it is from your app, can you debug it or write the log-in attempts in a log?
Like a lot of programmers, I test sites locally.
I use the hosts file to map domain names to my local ip (127.0.0.1).
I use qualified domain names, usually with a "d" subdomain (for "development").
For example:
d.somewebsite.com
d.anotherwebsite.com
and so on...
In Microsoft edge, most of the web sites work. However, a couple of them do not. There is nothing special or weird about the domain names that won't work. Just a simple d.someletters.com.
They work fine in Chrome, IE, and Firefox.
In Edge, I get the error message:
"Hmm, we can't reach this page."
At first I thought it wasn't resolving the IP. However, I realized when I made a typo on another non-related url, that requests which are not routed by the hosts file are sent to my ISP to be resolved. If my ISP can't resolve it, they send back this special search results page with suggestions of what you might be trying to find. Well, when I go to my local domain, I do not get this page from my ISP. I get the error mentioned above straight from edge.
So, it seems to me that Edge is resolving the domain correctly, otherwise it would have been sent off to my ISP's DNS.
So, I would think then that maybe Edge just can't connect to the local machine. But like I said, several of these local domains are working fine. Also, using 127.0.0.1 directly in Edge also works. It's just these couple of domain names giving me a problem. And only in Edge (all other browsers work) Any ideas?
The web server is Apache2 for Windows (xampp) if that matters.
Also, if I open the debug window in Edge and monitor the network, I do not see any requests going out at all.
EDIT: I am no longer using the hosts file. I have dnsmasq running on one of my Linux boxes and I am using it for DNS instead of hosts. Also no longer using loopback (obviously since DNS is on another box now), I am using an internal private ip address (192.168...). Same issue.
Your network can block loopback as a security measure in Windows 10.
Open a command prompt as administrator, and run this to exempt Edge from a loopback:
CheckNetIsolation LoopbackExempt -a -n="Microsoft.MicrosoftEdge_8wekyb3d8bbwe"
(Microsoft.MicrosoftEdge_8wekyb3d8bbwe is the identifier for the Edge app)
There's a blog post here giving more detail:
https://blogs.msdn.microsoft.com/msgulfcommunity/2015/07/01/how-to-debug-localhost-on-microsoft-edge/
I (thought I) solved it!
Things that did not work:
Making changes to IE compatibility settings or Windows compatibility lists
Using fully qualified domain names
Using an IP address other than loopback
using http vs https
remove all javascript and cross-site scripts/resources from the web page
checking / unchecking the option in about:flags for allowing localhost loopback or using compatibility settings
removing / adding / editing the entries in the TabProcConfig of the Windows Registry
deleting browsing history, cache, cookies
The Solution: in a complete counter-intuitive twist:
Remove the domain names from your trusted sites list!
Open the Internet Options dialog (just ask Cortana or use windowskey+s)
Go to the Security tab
Click on the Trusted Sites zone
Click the Sites button
Remove the troubled domain names from the trusted sites list
Click Apply and then close the dialog
Open Edge (or restart it if it is already running)
Viola
I should note that I, using common-sense, figured that it wasn't just the fact that the site was merely present in the "Trusted Sites" zone that caused the issue. I figured it was some setting on that zone. So, before I deleted the domain names from the "sites" list, I made all of the settings match my Internet Zone settings exactly (Medium high security, enable protected mode, do not require server verification for all sites), and I also tried every other combination I could find. There was no combination of zone security settings that worked. The only solution was to simply remove the domains from the Trusted Sites list completely. Funny thing is that it works in IE regardless, even though this is the internet settings dialog for IE. This only seems to affect Edge.
EDIT:
Two weeks later I change my configuration to, instead of the hosts file, use dnsmasq on a local Linux machine and using it for DNS. I'm not sure if it happened right away but at some point Edge stopped working again! I already had the "allow loopback" checkbox checked in about:flags, so I didn't expect the CheckNetIsolation fix to work. But, it did. Edge version is 20.10240.16384.0. I used the fix from Can't open localhost in Microsoft Edge (Project Spartan) in Windows 10 preview
EDIT #2
A couple of months later and Edge is having this problem again. I tried both previous solutions (and others) and neither of them work for me anymore.
I'm leaving this answer because I am assuming I experienced two separate problems.
Edge doesn't support VPN IP addresses so any workaround needs to employ some sort of proxy. Here are some solutions that I found work:
Install and run fiddler. Fiddler will basically intercept the request from the browser then forward it to the destination. This is the easiest workaround.
Configure a proxy via the built-in Windows tool: netsh. The basic steps involve assigning your development domain to an available local private IP address in the 127.0.0.0/8 range, then mapping this IP to the webserver's IP on the VPN. See step by step instructions here
Use the port forwarding feature of ssh to configure a proxy. Assuming that port 80 is available on localhost, add 127.0.0.1 d.somewebsite.com to your host file, then run the following ssh command: ssh -L localhost:80:localhost:80 user#devwebserver, where devwebserver is the hostname of your development webserver (say in the VM or vagrant instance, or across the VPN). This option assumes you have ssh access to the dev server.
Your "remove from trusted sites" solution didn't work for me because my local sites were not on my trusted sites.
But you got me looking the Internet Options and I managed to get IIS working for local sites for me on Windows 10. This is what I did:
Open Internet Options and select "Local intranet"
Click on "Sites"
Click on "Automatically detect intranet network"
Click OK. Try your local machine site in Microsoft Edge and it should now work.
May not apply to your situation, but nonetheless. My setup was as follows. A public space address (internet) page was attempting to load a page with a private space address (intranet) in an iframe and Edge would refuse to load the intranet page with the same "Hmm, we can't reach this page" message, and with "SEC7117 Error" in the debug console. Turns out Edge doesn't like mixing internet/intranet zones (see Understanding Enhanced Protected Mode blog post for reasons why). Edge runs tabs in separate AppContainers, and AppContainer network restrictions are sensitive to your network configuration.
My solution was to take the server which hosted the intranet page in question out of the domain network by assigning a second private space IP to it, and create a second DNS entry to that IP. The server ends up having 2 IPs: one on the domain network and an alternative one and 2 different DNS entries. Edge is then pointed to the alternative URL and it starts loading the intranet page just fine. It seems like as long as the IP masks of the PC and the page URL in question do not match, Edge will load the page.
The blog post I mentioned has info on Loopback-blocked for localhost and lack of privateNetworkClientServer capability in IE. As far as I can tell all that info applies to Edge.
When this happens to me I can find a domain entry in the registry key below that matches the domain. When I remove it things work, for a while... I don't know why but Edge will add it back eventually.
Computer\HKEY_USERS\S-1-5-21-964789662-521690395-1734141374-1111\Software\Classes\Local Settings\Software\Microsoft\Windows\CurrentVersion\AppContainer\Storage\microsoft.microsoftedge_8wekyb3d8bbwe\MicrosoftEdge\TabProcConfig
Noting from your edit that you are now accessing the site on 192.168.0.0/16 address, rather than on 127.0.0.1, I am guessing you are running into an issue with the way the Edge browser behaves differently depending on the interface used to access the site. Other browsers I tried don't behave this way.
In my environment, I had a Virtualbox host-only network setup and this had an NdisDeviceType of 1. Edge would only allow me to navigate to sites over this interface after I changed NdisDeviceType to 0. The registry key you need is:
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Class\{4d36e972-e325-11ce-bfc1-08002be10318}\XXXX
Instead of XXXX, you need the correct key for your interface, which I determined from "route print" and subtracted 1. For me it was "0016".
The value to change is called *NdisDeviceType. (That's a literal asterisk.) I changed it from 0 to 1 and had to reboot for Windows to notice the change.
My answer was gleaned from a post by "Jani L" dated Oct 3, 2017. I also posted this solution in more detail to another stackoverflow question. Also see a Virtualbox ticket 15565.
None of the other solutions worked for me. It turns out that my issue relates to VPN. Microsoft Edge still doesn't support VPN IP addresses, while Internet Explorer 11 does. Impressive that this is still an issue as of May 2016.
Additional Details:
https://social.technet.microsoft.com/Forums/en-US/b3a687ae-345d-4c3f-9070-184b33fb1fc6/microsoft-edge-cant-access-vpn-ip-address-but-ie-11-can?forum=win10itprogeneral
Currently Microsoft Edge seems to be not working well with VPN. And the mechanism to connect to Internet from Microsoft Edge is a little different from Internet Explorer 11 and the other desktop browsers, which I can't explain clearly as I don't know much about it.
So based on the current situation, please take use of Internet Explorer 11 instead.
In my case changing the network type from private to public did the trick. This is also reproducible and changing the network type reliable changes the state from "working" to getting: Http failure response for (unknown url): 0 Unknown Error
For me, I went to Internet Options (control panel), then Security, then selected local intranet and then put a tick in the "Automatically detect intranet network". This greyed out the nested options below, and Edge immediately started using my hosts file.
my website opens with xx.xxx.xxx.xxx IP address till friday it was working fine..after wards not able view the site in webbrowser...what could be the problem ? how can we solve it?
My server with this IP is working and can able to view the updated data in database ..but not able to view, or open the page of website.before the website under IIS configuration was stooped and now started again..still no use..am couldnt view Login page at all.My application was developed in classic asp long back.Kindly give me any suggestion to this...its very urgent...
I tried browsing the website in IIS manger(server) .It showing page cannot be displayed.
Thanks in advance.
First, Don't Panic. Staying calm can avoid further damage.
While it's hard to tell what could be the problem, the first thing you can do is to "ping" the domain from terminal.Can you login remotely? "wget" (on linux) will download the files from website, and could help you see if the files on the site are still accessible. Check from different browsers or machines, if possible. I'm no expert in asp or IIS, so won't advice on that front. But once I had faced the same situation with my website. So I just called up the hosting service provider, and it turned out it was their problem, and they brought the server online. If it's okay from their end, you might have changed some configurations in your server or application or there might be some up-gradation changing parameters, or even an accidental deletion/ moving/ renaming of files. Just try to remember what are the things you did with your server and application, before it went down, and also ask your server administrator. That will surely help you understand the problem better, if not help to solve it right away.
Good Luck.
A cheeseburger to the first person who can help me make sense of this. I have a page in a Sharepoint app that uses Telerik's RadUpload to upload files. This has worked for months; last week it stopped working (in Internet Explorer, this detail is important). After talking with a co-worker about the problem, I tried the upload with Firefox; it worked. Not only that, all subsequent uploads from Internet Explorer started working. Flash forward an hour, and the aforementioned coworker, on another Sharepoint site, running on different servers, was having problems downloading (using Internet Explorer). Being half serious, half smart-aleck, I said 'try it in Firefox'. Not only did that work, ALL SUBSEQUENT DOWNLOADS IN INTERNET EXPLORER WORKED! And he re-produced this behavior on another machine. My fear is that this a browser issue. All advice will be greatly appreciated.
a
IE will try and present credentials to a server it knows to be in its Local Intranet zone when it tries to connect (depending on the setting of "Automatic logon only in Intranet zone").
Firefox will only present credentials when prompted, and will generally ask you by popping up a box (unless you've configured a list of sites for it to always present NTLM credentials to).
I've seen a similar case with Sharepoint where you can cause IE to work by logging in with Firefox. I theorized it was due to a permission on a remote resource being for "Authenticated Users", and you're causing your user to authenticate by logging in forcefully. We eventually set the "Automatic logon only in Intranet zone" to "Prompt" and it worked. My theory there was that it wasn't detecting the site as being in the Local Intranet zone for some reason. If you're not accessing a domain with no .'s in it, try also setting your Local Intranet site policy to match the full domain of the Sharepoint server, not just *.example.com - I've read that that can help.
Was it as simple as IE not re-downloading miss-cached .js file, maybe, that firefox did download, making IE work after that?
Pretty gnarly to debug.