2

In a SharePoint Development Environment whose server name is "dev", the site is deployed on the port 80.

I am accessing the site in Internet Explorer using dev:80 then internet explorer automatically creates URL : http://dev/pages/

when I try http://dev:80 in Chrome, it generates HTTPS i.e. https://dev/ and then it shows this site can't be reached

However I can access the site in Chrome using http://localhost/ but there are some problems being generated if I use Localhost/ because it keeps generating HTTPS for the files linked in the Project

For Example I am currently facing the following problem: SharePoint DateTimeControl styling is getting out in google chrome

Please help me resolve this Thanks

Update

I've placed a different host name in the hosts file refer to this question:

127.0.0.1 imcportal-dev, it is now asking for authentication in Google Chrome but not accepting the User ID and Password. I am unable to Login into the site now from any browser

Update 2:

I have configured alternate access mapping and given the alternate name as "abc" to access the site on the local machine and as well as on LAN:

enter image description here

On the Local Server, it says This page can't be displayed

On the Other system on the network, it says Servers IP address could not be found:

enter image description here

I have tried putting the same in Intranet,Custom, Extranet Categories but the issue is same

If I Put IP Address in place of abc, it works fine although I need to use the name to access the site instead of IP Address

Please Help

2 Answers 2

1

.dev is a bad choice for a local tld as it's a "real" tld and owned by google. Chrome (since version 63) will always use https to access .dev domains.

See this question for the same problem.

I'd suggest you use a different domain. .localhost, .example, .invalid and .test were designed for local development. Also .local works good.

14
  • this is the server name, there is no any domain attached to this site. can you please help me resolve this using IIS Jun 13, 2019 at 7:10
  • Kindly see my update in the question Jun 13, 2019 at 7:42
  • 1
    @AlinaAnjum your extra updated info is caused by loop back checking. In a dev environment, you should disable loop back checking, otherwise, NTLM auth fails because the host name does not match the server name.
    – Greg W
    Jun 13, 2019 at 12:03
  • And if you "only" add a different hostname in the host-file, SharePoint might not "answer" - you'd need an AAM for that (see the answer above)
    – Nils
    Jun 13, 2019 at 12:08
  • @Nils please look into the following sharepoint.stackexchange.com/questions/264649/… Jun 14, 2019 at 5:18
0

This could be caused by Alternate Access Mappings for the particular Zone.

I would suggest taking a look at the AAM setup to see if there is anything that will trigger a protocol redirection.

The basics of AAM are documented here:- https://docs.microsoft.com/en-us/sharepoint/administration/configure-alternate-access-mappings

3

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.