I am working on SharePoint Online site collection and suddenly Site Contents _layouts/viewlsts.aspx stopped working and showing the message
This page isn’t working - If the problem continues, contact the site owner. HTTP ERROR 401
I am the site collection administrator on this site, so this is not a permission related issue. Also, checked on multiple browsers and with different users and all are facing the same issue. Also, Console logs are not showing any error messages.
Scenario - I just ran a PnP PowerShell command to create lists (list provisioning) and after that Site Contents were not working, however the same command I executed few days back and everything was working fine.
My application custom pages / site settings and all the lists & libraries are working fine (when accessed directly from URL), only Site Contents is not working.
Clear the browser cache and open the site in an incognito window to check the result.
Go to Site Content and Structure page as site collection administrator, delete the provisioned list to compare the result.
_layouts/15/sitemanager.aspx
If the issue still exists, raise a new service request to Microsoft to check if there is something wrong on back-end side.
Related
Our customers(at least two from different regions) have reported an issue with access to SharePoint sites which contain spaces in URL. After open some sites in new tab, they get
After some investigation we have found that SharePoint sites register Service Worker in browser.
The Service Worker intercepts all requests going from current page, apply some logic and one of the branch in the logic leads to the error.
Let me explain what happens:
When you have custom home page on a site, and you navigate to the root site URL like https://tenant.sharepoint.com/sites/mysite, SharePoint will automatically redirect you to the custom home page like https://tenant.sharepoint.com/sites/mysite/SitePages/MyCustomHP.aspx
All these requests are handled by the Service Worker and it treats this redirect as a trigger for re-authentication and sends you to Authenticate.aspx
In order, Authenticate.aspx works incorrectly:
Steps to reproduce:
Open any modern team site(in Edge or Chrome, I tried in Edge)
(like https://tenant.sharepoint.com/sites/my-team)
Create a modern subsite with spaces and navigate to it.
(for example https://tenant.sharepoint.com/sites/my-team/Site with spaces)
Open Pages library on the subsite and create custom Site Page
Make it as Home page
Open new tab and paste the URL [https://tenant.sharepoint.com/sites/Site with spaces]
The Result you can see above. Hmmm... can't reach this page
Questions:
Why does Authenticate.aspx works incorrectly ?
May be the logic in Service Worker is wrong? and such kind of redirects should not lead re-authentication or it should encode parameters to Authenticate.aspx by other way?
When will it be fixed :) ?
Possible Workarounds
Clear IndexedDB/Route.Config in dev tools and restart Service Worker
Change the URL and remove spaces
Microsoft has fixed their code of Service Worker in 2021-08-27 release
Now, the previously buggy code, looks like:
As you can see double encoding check was added
How it looked before you can check above.
I have a simple azure web app and have set the default document in the portal to home.aspx. There is a home.aspx file published, it is browsable via http://my-domain.azurewebsites.net/home.aspx (not real domain) however the default document won't work when browsing to http://my-domain.azurewebsites.net it returns a 404. There is nothing special here. I even added it to the web.confg and it still returns a 404. It is a web forms project, set to integrated security with the correct default document added. Any ideas?
I setup the following web app (West): supportforlucuma There is only one other app in that plan which is the one that isn't working.
I can see the home.html page by visit “http://supportforlucuma.azurewebsites.net/”, Is your issue solved? If no, I will provide more information of how to debug this issue.
Except to set default document on portal and web.config, the default document also could be set in RouteConfig.cs file. For example, following code will set the index.aspx as the default page of current web application and it has the highest priority. If index.aspx file is not exist, a 404 error will response to client. Please check whether the similar code is exist in RouteConfig.cs file.
routes.MapPageRoute("default", "{page}", "~/{page}.aspx",false,new RouteValueDictionary( new { page = "index" }));
For further troubleshooting this issue, we can to get the detail information of 404 response. For example, which modules are executed on server side during the default page is accessed. To do it, we need to enable Failed request tracing. Then we could see the detail information by download the tracing log from LogFiles folder. For example, "ftp://xx.ftp.azurewebsites.windows.net/LogFiles/W3SVC355162095/".
So this afternoon users started reporting that they couldn't get to our SharePoint 2007 intranet site. We set the home page via group policy for all users to the url
http://spsite
When this url is hit, SharePoint redirects to
http://spsite/Pages/default.aspx
This has been working like this for years.
Today, our remote branches are getting returned a 'Under Construction' page. However, if these same users hit Refresh on the browser or type in the
http://spsite/pages/default.aspx
they get there without issue.
Our local users are not seeing this problem at all. This tells me there has to be some kind of DNS resolution problem. I'm not much of a SharePoint guy, so I'm at a loss.
Has anyone seen this behavior before? What would be my first step in trying to figure out where the problem is?
I'm posting the resolution for this and the theory behind the issue.
There were a few things that happened in our environment that lead to this 'Perfect Storm' scenario.
At some point in the day, our SharePoint site became unresponsive. Users hitting the site at that time then got back an odd response from the server. It seems that somehow IIS had two sites listening on port 80, both with a wildcard binding. The first site was the SharePoint site, the second one was the default site. When the SharePoint site failed to respond, IIS then went to the Default Site. Since this site hadn't been set up, the 'Site Under Construction' page was returned (IIS6 on Windows 2003 server).
This was odd in itself. However, what happened later is just as bizarre. An IISReset fixed the problem that the SharePoint site was having. As a result, the SharePoint site was again available. However, anyone that had hit the url when it was down had a cached the iisstart.htm page. It appears that when their browser was checking the URL, they were getting a 304 from the server. So the request never made it all the way into the sharepoint site, which actually returns a 302 redirect.
So, for all these users, we had to clear the cache on their machine and this then allowed the to get back to the SharePoint site.
I had created a simple portal site for our internal users, just a CSS menu with our internal web services which then displayed in an iFrame. Worked well so far.
Our helpdesk software was GLPI running on APACHE on the same server and had no issues. We recently upgraded to the latest version and in the meantime I moved it to our new web apps server and switched to IIS. The 'portal' is still hosted on the old server.
When I updated the javascript for the iFrame to point to the new address, it looked like it worked, I could get the login screen for GLPI. After logging in however I just get stuck at a white screen. If I try it in IE I get the message:
This content cannot be displayed in a frame
To help protect the security of information you enter into this website, the publisher of this content does not allow it to be
displayed in a frame.
What you can try:
Open this content in a new window
It doesn't seem to be the iFrame itself as I can get the login page.
My question is, can anyone give me some ideas on where to look at this issue? I've checked the IIS logs on both sides and see no errors, GLPI reports no errors, neither does PHP.
GLPI is on IIS 8 on Server 2012
The 'portal' is on IIS 6 on server 2003
GLPI running on PHP 5.3.0
EDIT: I've looked into the X-FRAME issue and I'm pretty sure this is not it, servers are on the same domain and I am able to get to the login screen of the second server through the iFrame, just no content after that. If it was an issue with the frame or permissions I would expect to not get to the site at all?
The only header response currently in IIS is 'X-Powered-By --> ASP.NET' am I looking in the wrong spot?
The server is returning an X-Frame-Options header used to prevent ClickJacking. That header must be removed (or updated with an Allow-From directive that lists the framing page's origin) in order for the target page to be rendered as a subframe.
I've changed the master page on a publish site collection. When I browsed back to the start site to check the new master page the browser just returned a 404 error, telling me that the page could not be found.
But when I open the site collection with the SharePoint Designer every thing seems to be ok and in its place. All pages are as expected in the page library. Within the Designer I could even open the pages for editing.
So does anyone has an idea why the browser cannot find and open the pages?
UPDTAE
To clarify my problem I should say, that also switching back to the default master page doesn't bring back the site. I still get a 404 response. So the problem shouldn't be directly related to my custom master page.
Approve the Master Page ?