We upgraded a wss 2 site according to Microsoft standard (prescan, migration etc) and resolved smaller issues on the way.
However, now we don't receive any errors, and when we access the site in wss 3 it gives us a 404 - page not found error. We now there is a site at the root, and wss confirms that...anyone knows what's wrong?
By the way: We also upgraded another site the exact same way and it works beautifully...
What does the log file say?
Is the content database correctly setup? (Name / Server.) More specifically, the permissions for the pool account.
Related
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.
My setup:
Windows Server 2012
IIS 8.5
SharePoint 2013
The SharePoint site is configured to requeire client certificate. If the user has no valid certificate or the password was wrong IIS returns error code 403 in response header. I would like IIS to return a custom error page instead where I could guide the user how to fix the issue.
There are just to many options where I can configure error pages. Which is the right one?
In IIS I have three possible sites to configure.
Default Web Site
My web application
My web aplication port 443
Custom errors in web.config
Error Pages in IIS
.Net Error Pages in IIS
I have tried some of these options but with no success. Can anybody help me?
Just edit the web.config file in your Visual Studio solution, modify the customErrors section and then check the file into Github to trigger a new deployment.
If you don't use VS, then find your web.config file. Worst case scenario you can edit it directly.
We recently updated a CRM 2011 on premise instance to use SSL i.e. https. I wasn't involved in the server part of the updates. Everything works fine except at initial login, IE displays the "Only secure content is displayed" warning. If I look at the source of the page, I see a bunch of http://... refs to microsoft sites for example. So presumably that is the source of the issue. The landing page doesn't have any custom "stuff" on it, all OOTB.
What can we do to get around this? I know we could change an IE setting but that isn't an option for us. Is there some IIS voodoo tthat we can use? Surely we don't have to go through all http refs in the web app and change them?
I know we could change an IE setting but that isn't an option for us. Is there some IIS voodoo tthat we can use?
Man, I wish. Even when we get HTML e-mails with images in them we get that message.
Because it's a security setting and it's the browser causing the error message and not the server, there really isn't much we can do about it on the server side except for serving all content over SSL.
That being said, it seems really strange that out of the box content is giving you errors.
It's possible that using a re-write rule on IIS will stop this from happening, as all the content on your server is capable of being served in SSL, but CRM is not requesting it - I'm just hoping that this doesn't break any customization and links to external services.
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've been trying in vain to get Umbraco installed on my Windows 7 box under IIS 7. I was able to use the Web Platform Installer to get it up and running via WebMatrix, but I want this running in IIS.
Whether I perform the install manually by setting up a new web site copying binaries, or whether I let the Web Platform Installer do it, I'm always presented with an installation page that's missing all CSS, images, js, etc.
When I attempt to hit those resources directly, I'm always redirected back to the install page.
I'm telling the platform installer to create a brand new web site. No virtual directory/application name is being specified. And I've followed all the online directions I can find.
Logs show 401 unauthorized errors:
2012-05-11 02:42:22 127.0.0.1 GET /umbraco_client/installer/css/all.css - 80 - 127.0.0.1 Mozilla/5.0+(compatible;+MSIE+9.0;+Windows+NT+6.1;+WOW64;+Trident/5.0) 401 3 5 10
2012-05-11 02:42:22 127.0.0.1 GET /umbraco_client/installer/css/reset.css - 80 - 127.0.0.1 Mozilla/5.0+(compatible;+MSIE+9.0;+Windows+NT+6.1;+WOW64;+Trident/5.0) 401 3 5 10
2012-05-11 02:42:22 127.0.0.1 GET /umbraco_client/installer/css/form.css - 80 - 127.0.0.1 Mozilla/5.0+(compatible;+MSIE+9.0;+Windows+NT+6.1;+WOW64;+Trident/5.0) 401 3 5 10
I tried changing the app pool identity to Network Service and granting full permissions to the web site root path, and while it didn't fix the problem, it turned all the above 401 errors into 302 redirects.
Thougts?
In my case I found that although I had created a custom App Pool running under an identity with permissions for this folder, in the IIS authentication page ( IIS Manager -> Authentication -> Anonymous Authentication ) it was using IUSR as the default user for anonymous authentication. By checking the "Use Application Pool Identity" box instead, it worked correctly.
It appears as though the root cause was that I had my umbraco files under c:\Projects\MySite\Umbraco\WWW. Despite the fact that the WWW folder had the correct permissions, IIS would not grant access to the resources in question.
Once I moved the contents to c:\inetpub\wwwroot\, it started working. I'm still not entirely sure why, as the permissions match exactly, but it is what it is.