Related
The problem
We're running IIS on Windows 8.1 with Update. We're at the Orchard CMS first time setup screen, and IIS is giving 401s for all static content. We have read the following to no avail:
IIS 7.5 no images css js showing
IIS 7.5 no images css js showing
The official Orchard deployment documentation
Based on those, this is what I have tried that doesn't work.
Turn on the IIS feature to Serve Static Content.
Give IIS_IUSRS permission to Read, write & execute.
Give the site's application pool permission to Read, write & execute.
What does work though is the nuclear option: to give Everyone the Read permission (unless we want to proceed with the Orchard setup; then we need to give Everyone even more permissions.) That leads me to believe that I must give permission to some principle with less scope than Everyone but more scope than both IIS_IUSRS and the application pool combined.
Who/what is that principle?
Pictures to show the problem
We receive a 401 on ..\Themes\SafeMode\Styles\site.css
The task manager confirms that the site is running as the orchard user.
The security properties of the ..\Themes\SafeMode\Styles\ directory gives Read permission to orchard.
Why does it only work when we give Read permission to Everyone?
I had a similar problem. Under authentication, I right clicked "Anonymous Authentication" and clicked "Edit". That shows a dialog giving you the ability to set the identity of the anonymous user. I set it to "Application pool identity" and that fixed the problem for me.
.
This may not be the most secure configuration though, but I'm on a dev server so I don't care.
Try turn on the Static Content and Directory Browsing features under Internet Information Services->World Wide Web Services->Common HTTP Features node.
In my case I had to set Read permission for IUSR user for the web site folder.
So, what I had to do to fix this problem was the following:
(and please understand, that this is not ASP or PHP script related, the server wouldn't even show basic simple .html files, yet would serve out PHP results all day long!)
Two fold…
Had to set the application pool for each site, under advanced settings, to use LocalSystem for it’s process
Under site, advanced settings, security, add the IUSR account to have read & list contents access, for the site… :-)
See any problems with doing that?
'cuz it's working....
Updating windows feature for WWW services/Common Http Features/static content by selecting Static Content checkbox fixed my IIS not service static content issue.
Open IIS -> go to advanced settings of selected website and open Physical Path Credentials -> Select specific user and enter your local user credentials. Open below screenshot for further visualising the things:
IIS Settings
I am trying to install IIS on my Windows 8.1 laptop and followed the directions at Microsoft for installing IIS. But when I type localhost, instead of getting the IIS start page, I get a blank page.
When I do Windows + R and type services.msc, the resulting list of services is long but does not include Internet Information Services.
When I look at the Windows filesystem, I do find the inetpub folder with four subfolders, including wwwroot. In the wwwroot folder is the iisstart.htm file that is supposed to display when I type localhost into my browser.
I have read that one possible problem is that both Skype and IIS want to use Port 80 and there is a conflict. So I decided to try to change the default port for IIS, but I found that I don't appear to have the IIS Manager on my system. When I go to Administrative Tools, Internet Information Services Manager is not on the list of administrative tools.
I added both the HTTP Redirection module as well as the IIS Management Service on top of the initial basic installation that Microsoft described. Still no luck getting IIS working or IIS Manager to appear.
I have tried to research this problem of getting IIS to work on Windows 8.1 with no success and am at a loss. Suggestions welcome!
In Control Panel --> Programs --> Programs And Features --> Turn Windows features on or off -> Internet Information Services -> World Wide Web Services -> Common HTTP Features -> Static Content.
Also make sure .NET Extensibility 3.5 and .NET Extensibility 4.5 are checked.
Major fail by Microsoft. Why the hell would they turn off the most basic features by default. Go to Turn Windows features on or off (just search "features"). Look in IIS, WWW, Common HTTP Features. See attached image.screenshot
I have solved a couple of my problems.
I installed several more IIS modules: Static Content, IIS Management Console, and HTTP Errors.
I am now am able to find the IIS Manager in the Administrative Tools list and can use the IIS Manager.
Also, when I pressed Windows key + R and typed in services.msc, I still don't see Internet Information Services in the list. However, I do see "World Wide Web Publishing Service" in the list and it is shown as running. A page at Microsoft's Technet site indicates that it is related to IIS.
The HTTP Errors module gave me an error page rather than a blank page when I typed in localhost and also when I typed localhost/filename. This proved a HUGE help, because the error page identified the problem as a permissions issue. I thought I had dealt with the permissions issues, but this error page made it apparent that I had not.
When I typed in localhost, I got the permissions error. When I typed in localhost/iisstart.htm, I got the proper display of the file. When I created a simple .htm file, statictest.htm, and placed it in the wwwroot folder along with iisstart.htm, and typed localhost/statictest.htm, I got the permissions error.
So since one of the files was working and one wasn't, I decided to compare their permissions. (You do this using the File Explorer. Right click on the file, click on Properties, click on Security Tab. To make changes, click on Edit.) I saw that the successful one had a user listed that the unsuccessful one did not. So I added a user for the statictest.htm file to the permissions list with full control. That solved the issue for that file and it displayed normally.
I now am back to getting a blank page when I type in localhost. It must not be a permissions issue, because otherwise I'd get the permissions error page. I'm not sure what the cause of the blank page is. But as long as I can get files to display when I give their name, I am happy enough.
I am happy to report that my PHP installation is also working, at least as judged by the fact that the phpinfo() function displays properly.
So to sum up: if you are having problems getting IIS to work on Windows 8.1, try adding more IIS modules and make sure your permissions are in order. I think the most important ones to add are Static Content and HTTP Errors. Also, of course, CGI if you are going to use PHP.
I know this is an older post, but in case anyone, like me, already had "static content" enabled, there was one other thing that needed to be done to resolve this issue.
Under "Programs and Features" -> "Turn Windows features on or off"
Expand "Internet Information Services" -> "World Wide Web Services" -> "Application Development Features"
Make sure that "ASP.NET 4.5" (and if needed/installed 3.5) are selected. This should automatically check ".Net Extensibility" for the selected version, and it should also enable ISAPI filters and Extensions.
By default (for me at least) these options were not turned on when I enabled IIS. I was getting a 500 error in IE if I had "Show Friendly Error Messages" turned on in IE, but if I turned that option off, I would get a completely blank page.
For me, the reason was that I had two different HTTP handlers in the config with the same name. I didn't get any errors, just blank response.
I'm guessing that some other parts of the configuration may result in a similar behavior. Try commenting out some parts of Web.config file in case you cannot figure the problem out.
Same issue.
Win 10 upgraded from 7. Default documents server blank and without error.
Static Content and Default Document features already enabled.
I resolved by disabling both features, rebooted and tried(received error 404), enabled both features, rebooted, pages served properly.
For me, I was using Windows Server 2008 on an Azure machine, it was missing some packages which can be installed using "Web Platform Installer", and then search for "recommended server configuration for web hosting providers"
I encountered the blank page problem as well on IIS 8.5 on Windows Server 2012 R2.
I had StaticContent installed as Windows feature.
What finally fixed it for me was changing the Path Type of the StaticFile Handler under [IIS Manager -> Server on left pane -> Handler Mappings -> StaticFile] from "Unspecified" to "File or Folder".
You can also change this on a per web site basis instead of the entire server (but I don't really see a reason why to do so, as it breaks pretty much any page). Make sure, however, that the site does not have an overriding setting for the StaticFile handler, as the site scoped one is preferred over the global one.
I need to change the default logon domain on our website, but for some reason it still puts the computer domain as the default at login. I tried the following: http://technet.microsoft.com/en-us/library/cc772009(v=ws.10).aspx but get the same results. what else could it be?
I can't seem to find any other solutions on the web, any ideas? I compared the IIS configuration to another server (that works) and it looks identical. can't for the life of me figure out what's going on.
When you authenticate to a website there are many points at which one can be presented with a login dialog. I'm going to assume you have a simple website made of only basic .HTM .CSS and .JS files. (Meaning, you aren't using ASP.NET and looking to have forms based authentication.)
The website itself, runs under the domain/user configured on the Application Pool the website runs under. I suspect you are NOT trying to adjust this. It is the security level under which the entire website's process runs. Meaning, without an end user logging in at all, this is what the website's security level is in regards to accessing the file system, network, registry, etc.
If you want ONLY users in one of your network's Windows domains to have access, you should go to the IIS website, click 'Authentication' and disable Anonymous, ASP.NET Impersonation and Forms Authentication. Then set just the domain in basic authentication to what you need it to be.
If this is what you've done, and it still fails. Then I suspect it's because the IIS machine probably needs to meet some requirement to allow this to happen. For example: It needs to be added as a member of the domain you are trying to configure. Another possibility is that some setting on the domain controller, or an inability to reach it, is preventing the webserver from presenting your web visitors with the option to log on to that domain.
I thought I'd give SharePoint development a go, to broaden my understanding of Microsoft technologies and ran into a situation I refuse to understand.
I have a new web application created: http://localhost:11523 and set up the site collection as required. I can browse to the web site fine, without any issues, but now I want to start developing against this, using the object model.
Right, so after I struggled with SPSite site = new SPSite("http://localhost:11523"); I figured that I'm not running VS2008 in elevated permissions, so restarting VS I finally got one step further.
Whenever I step into my code, I get:
The Web application at
http://localhost:11523/ could not be
found.
I've Googled this without luck. The application is most definitely there, I can browse it, add web parts and go mad. I just can't seem to connect to it via Visual Studio.
Any ideas would be great.
EDIT
I thought I'd isolate my method, called "GetListFromSharePoint(string name)" into a test method (nUnit Framework) and to my surprise returned 9 entries from the list, as expected. When I dumped the method back into my web application (not SharePoint, trying to test the Composite Control through a normal Web site), and run into the mentioned problem.
This is in SharePoint 2007, and I'm developing on the same machine onto which SharePoint 2007 is installed.
This approach used to work, for some reason, I just can't get it to recognize SharePoint. The test stubs work find, just not the web application.
Edit 2
So there where a couple of things I "missed", which kind of solved the problem by itself.
Firstly, I was developing on a x64 Windows 2008 box, thus SharePoint 2007 was running in x64 mode. Cassini, turns out, is 32bit regardless of the platform you run it on, which caused some compiler bugs (I did not have IA64 compilers installed). After installing this, I figured out that the default web site (localhost:80) had been disabled by SharePoint.
Renabling the default web site, allowed me to create my web application as a virtual directory against it, which allowed my debugger compiler to run in x64.
My next challenge was access permissions. Because any new virtual directory on port 80 is assigned to the default application pool, is it assumed that the user does not have the right permissions, so I had to change my web application to run under my SharePoint web application's application pool.
The last thing I had to do was run my SharePoint code with elevated permissions.
Working like a charm :D
Note! Enable debug on your SharePoint web application....
Thanks,
Eric
(You have not specified version - assuming SharePoint 2010).
You need to decide what object model you want to use:
client (to be able to access the server from any other machine)
server (the one that you are trying now, can only be run locally).
Most likley reasons your code not work:
using "localhost" instead of ""computer name" in the Url. (I believe it is the reason.)
you are running your code not on the same machine as the SharePoint
you are running code under non-admin account
Check out how sites collections are configured in "Central Administration" site - urls associated with each site collection are listed there - make sure you are using correct one.
You can also try enumerating all site collections in SPWebApplication (http://msdn.microsoft.com/en-us/library/microsoft.sharepoint.administration.spwebapplication.sites.aspx) to start expiriments.
I dont think the SPSite connect through the IIS, and if SharePoint isn't set up to respond to localhost (done in the Central Administration) you wont be able to connect to that url. IIS works a bit different here since it relays the signals to "localhost" to the "web application instance".
Start by checking in your SharePoint Central Administration. Go to "Configure alternate access mappings" in the "System Settings" section. Here you have your SharePoint instances, there are three properties which you can see directly in the list; 'Internal URL', 'Zone' and 'Public URL for Zone'.
If the Internal URL isn't set to Localhost you wont be able to use that connection you suggested. It bay be improper to change this to another url as well, so simply try to set your SPSite site = new SPSite("http://yourinternalurl:11523"); to whatever's in that box! :)
Cheers
I have a MOSS 07 site that is configured for anonymous access. There is a document library within this site that also has anonymous access enabled. When an anonymous user clicks on a PDF file in this library, he or she can read or download it with no problem. When a user clicks on an Office document, he or she is prompted with a login box. The user can cancel out of this box without entering a log in, and will be taken to the document.
This happens in IE but not FireFox.
I see some references to this question on the web but no clear solutions:
http://www.microsoft.com/communities/newsgroups/en-us/default.aspx?dg=microsoft.public.sharepoint.windowsservices.development&tid=5452e093-a0d7-45c5-8ed0-96551e854cec&cat=en_US_CC8402B4-DC5E-652D-7DB2-0119AFB7C906&lang=en&cr=US&sloc=&p=1
http://www.sharepointu.com/forums/t/5779.aspx
http://www.eggheadcafe.com/software/aspnet/30817418/anonymous-users-getting-p.aspx
To disable login prompt opening office documents from SharePoint 2010 do the following settings in web.config
<system.webServer>
<security>
<requestFiltering allowDoubleEscaping="true">
<!-- here's where the magic happens -->
<verbs allowUnlisted="true">
<add verb="OPTIONS" allowed="false" />
<add verb="PROPFIND" allowed="false" />
</verbs>
</requestFiltering>
</security>
</system.webServer>
If Sharepoint Shared Workspace is enabled in MS Word this may prompt users with a Windows login if users do not have permissions to access or create a Shared Workspace. Do the followoing to turn this off:
Open MS Word
Go to Tools/Options
Click General Tab
Click Service Options
Click Shared Workspace
Uncheck box that says “The document is part of a Workspace or SharePoint Site.”
Click OK
Click OK
Try to hit a MS Word document from the SharePoint site.
If this resolves issue repeat steps with every MS Office program to eliminate the prompt. (Excel, PowerPoint, Visio, ect)
http://office.microsoft.com/en-us/word/HP010414641033.aspx
Unfortuantly the only work around I've found breaks some functionality for logged in users (can't upload multiple files, connect to outlook ect..)
If that is acceptable, or you want to try it and see:
In central admin > application management > application security > authentication providers select your web app and select your provider (likely "default").
Select No for client integration and save the settings.
Open your web config, find the line <add verb="OPTIONS,PROPFIND,PUT,LOCK,UNLOCK..... and remove the verb OPTIONS.
You should no longer be asked in ie for credentials. To reverse this simply undo both changes.
If you can click cancel and it comes up the problem is...
AuthForwardServerList
http://support.microsoft.com/kb/943280
Office doesn't know the site is trusted/local so it doesn't fwd your credentials and prompts you with an opportunity to provide them. It's a feature....
If you list your site in the proper registry key it will forward your credentials which are not needed but you won't get prompted.
If you have a url rewriting module or urlscan, configure the software to send http 403 to http OPTIONS requests.
In the Sharepoint Server 2010, The solution method is a little bit changing because the new generation Sharepoint can not hold verbs in web.config. Therfore, you must change the method. First of all, you open IIS 7.0 and choose your application site. You can see many items at the middle of the screen. You choose and double click Request Filters. In the request filtres, you can see "Verbs". You can add OPTIONS and PROPFIND verbs to a deny mode. And finally test your site. Sometimes, Sharepoint needs to close Client Integration Mode of your site. If need, you can close Client Integration Mode in Central Administration.
Possible cause and resolution:
http://support.microsoft.com/kb/943280
"You are prompted to enter your credentials when you access an FQDN site from a computer that is running Windows Vista or Windows 7 and has no proxy configured"
"For example, when you open a Microsoft Office file from a Microsoft Office SharePoint site by using 2007 Microsoft Office on a Windows Vista-based client computer that has no proxy configured, you are prompted for authentication."
My guess is that the Office client is loading the underlying document template from another location where anonymous access is enabled. This also explains why you can still open the document as the Office client can also work without loading the template the document was originally created from. To see the template URL in Word 2007, enable the Developer Ribbon from Word options and click the Document Template button on the ribbon.
That doesn't seem to be it. Once of the documents in question is an Excel file, which would not use the .doc template. Also, in the Document Template dialog, it doesn't give me a url to the SharePoint template file if I create a new Word document based on it. It just says the template is "Normal." I also tried disabling the template at the document library level and it doesn't change the password situation.
When opening an Office document in IE, an ActiveX component is used to call the client application, and prompt it to open the document. In other browsers, the download is a standard hyperlink, handled by the browser.
Does this happen in search results and in standard linked columns in document libraries as well?
Using a tool like Fiddler (as referenced/suggested in your first link reference, see http://www.fiddlertool.com/fiddler/ for more info) is the only efficient way of determining the root cause of this type of issue I'm aware of. Whatever is causing this will be happening over HTTP. A debugging proxy like Fiddler will show you exactly which URL/resource is causing the request for authentication.
On a related note, are you running a recent build of the platform? It might be wise to check to make sure this issue hasn't already been addressed by MS e.g. in a hotfix. The best list of updates I'm aware of is here: http://www.harbar.net/articles/postsp1.aspx
Check this : Remove Login box when anonymous users download office document from SharePoint Site
http://www.theblackknightsings.com/RemoveLoginBoxWhenAnonymousUsersDownloadOfficeDocumentFromSharePointSite.aspx
When developing Extranet/Internet site in SharePoint you often want to allow anonymous access and this works fairly well.
But there is one are where the out of the box experience fails regarding anonymous access and that is when you allow the users to download Microsoft Office documents. In that case IE/Office pops up a couple of Login dialogs, if the user cancels out of these the document opens as expected, but you really don't want the user to have to cancel a couple of dialogs to open your documents
The problem is that office tries to be intelligent and issues a Microsoft Office Protocol Discovery request to see how much the user is allowed to do, but SharePoint responds with access denied until the users logs in.
The solution I've found is to implement a HttpModule which rejects the Microsoft Office Protocol Discovery request if the user isn't logged in and this gets rid of the Login boxes
I'm guessing that you use Windows Vista. We had this problem on Vista but not on XP.
From Microsoft: In Windows Vista, Internet Explorer uses the Web Client service when you use Internet Explorer to access a WebDAV resource. The Web Client Service uses Windows HTTP Services (WinHTTP) to perform the network I/O to the remote host. WinHTTP sends user credentials only in response to requests that occur on a local intranet site. However, WinHTTP does not check the security zone settings in Internet Explorer to determine whether a Web site is in a zone that lets credentials be sent automatically.
If no proxy is configured, WinHTTP sends credentials only to local intranet sites.
Note If the URL contains no period in the server’s name, such as in the following example, the server is assumed to be on a local intranet site:
http://sharepoint/davshare
If the URL contains periods, the server is assumed to be on the Internet. The periods indicate that you use an FQDN address. Therefore, no credentials are automatically sent to this server unless a proxy is configured and unless this server is indicated for proxy bypass.
This is a known issue that has not quite been completely fixed yet. There is a MSDN blog about it here: http://blogs.msdn.com/sharepoint/archive/2007/10/19/known-issue-office-2007-on-windows-vista-prompts-for-user-credentials-when-opening-documents-in-a-sharepoint-2007-site.aspx
There is an interesting workaround posted here: http://grounding.co.za/blogs/neil/archive/2008/11/10/workaround-sharepoint-keeps-prompting-for-login-when-creating-office-2007-documents-on-vista.aspx
Ultimately there is a patch that has been included with Vista SP1 but it also requires a registry edit. We just recently got this to work using the following steps on a Windows Vista SP2 client:
Open regedit. Navigate to the following subkey:
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\WebClient\Parameters
Create a new Multi-String value called AuthForwardServerList and give it a value of (for example):
https://.Contoso.com
http://.dns.live.com
*.microsoft.com
https://172.169.4.6
Then restart the WebClient service.
We were able to get this working by changing IE settings.
We have the site URL in Trusted Sites.
Under Custom Settings set User Authentication to: Automatic logon with current user name and password
I found a solution. First of all, you open the web application config file under the inetpub. Then you find the add verbs section. In this section, many verbs were added in the installation time. Delete Options and Profind verbs and save config file. Finally test the problem and see it. The problem is finished.
I've found the following workaround:
http://www.objectsharp.com/cs/blogs/max/archive/2008/04/21/sharepoint-public-facing-website-and-microsoft-office-documents.aspx
To keep it simple:
Disable client integration
Remove the OPTIONS verb from the registration line in the web.config file for the site