Okay, this seems too daft to be true, but I can't see how you stop a site in IIS 7.5
Various info on the web says things like in Features View - under Manage Web Site - click Stop Web Site.
But, what I am looking at is .. Features View, but, on the right it says Manage Application (not Manage Web Site) and the only thing under that is
Browse Application,
Advanced Settings,
Help
Nowhere is the ability to stop the site presenting itself.
Related
I can't found nothing recent on the web about if deleting Default Web Site in IIS is a good practice, i'm using IIS v10 and as in wwwroot i have each website inside it's own folder in IIS i've just created a website for each of them..
So i'm just not using the Default Web Site and i was wondering if will it cause any problem if i will delete it (for now i've just disabled it but seeing it in the list is a bit triggering), about deleting or keeping the Default Web Site i just found an article from 2001 so i would know something more recent about it.
Yes, you can safely delete the Default Web Site in IIS Manager, even though delete the files under the wwwroot. And it should be a good practice to do that to avoid some unexpected web accesses or attack.
And the Default Web Site in IIS Manager, even though the files under the wwwroot, is used for the first validation of IIS installation.
More, the Default Web Site will take the default port 80 if not disabled/deleted.
So, please go ahead to delete it.
nutshell: How can I debug an azure website?
I'm at a loss. I've been changing and re-publishing an MVC asp net core site on and off for a while, publishing always works fine.
Today, I've been messing with codeFirst migrations etc. and have published my site again - which works completely fine in VS in any environment - but in Azure it's just empty space.
The azure troubleshooting says "everything's fine", but it's clearly not - where do I begin? Or do I just revert all my changes and see which branches break the site?
The first thing to do is turn on debugging and look at the logs. You can enable debugging in the portal and turn on various options.
Once you have that setup, if you go to the "development tools" section in the portal and then click on "Advanced Tools (Kudu), this will take you to the backend view of your web app. In the drop-down at the top select "debug console" then either CMD or PowerShell, and you will be presented with a way to browse the content of your app. If you look in the "LogFiles" folder you will see logs that may have useful information.
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 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
We've installed Windows Search Server Express on one of our servers, which apparently runs on top of sharepoint.
Sharepoint was installed on port 80, where our "normal" intranet runs. When I disable the intranet and run the sharepoint site, everything works as intended. The intranet is linked in many places it would be a pain to move it, so I'm trying to move sharepoint to another "place" (hoping this is less of a pain), either a different port or as a virtual directory under the main site.
First, when I make any of these changes, it fails to get access to the intranet root. Not sure what it is looking for there, but ok, I give "Network service" (the acocunt the "Sharepoint 80" application pool is running under) access to the intranet root. This gets me one step further, I am stumped:
When I move the Sharepoint website to another port, it complains that it can't find default.aspx (there is none, but also it doesn't need it when running on port 80)
When I move it to a sub folder of the existing site, and try to open the global.asax in the browser, ti tells me that this extension is prohibited, even though the "Application configuration" is - as far as I understand - identical to that of the Sharepoint site, and allows GET, HEAD, POST, DEBUG for .asax.
Any suggestions?
Sharepoint sites should be able to run on any port- if you go into Sharepoint Central Admin and create or delete web applications without a problem.
Is it your intention to run heterogenously with Sharepoint and your regular site both on Port 80? I know that you can create a web application on 80 and then not have a root site collection ( Sharepoint applications consist of a Web Application that runs on a certain port and any number of Site Collections within that, each of which has it's own directory path and can contain lists, libraries, other Site Collections and so on ) just creating one on a different path, but I don't know for sure how that would work alongside an existing web site on the same port- it may not play nice. Again, you can create and delete site collections from the Sharepoint Central Admin page, which is linked from your Administrative Tools list on your server.I would try this first, as if it works it's an easy solution.
Is Windows Search Server Express related to Sharepoint's own search facilities? If it is you may find that it expects to run using some of the Shared Service Provider facilities, which even Sharepoint doesn't expect to be running on the same port as the sites it's providing services for.
An even better way would be to create another alias (cname) in your DNS for your server, just set a different host header for each web site.
for example, in DNS your machine might be named 'intranet'. Create an alias for that machine named 'sharepoint'
In IIS, create a new website for sharepoint, and set the host header for that site to 'sharepoint.domain.com', where domain.com is your domain.
Do the same for the intranet website, but set the host header to 'intranet.domain.com'
That way, your users don't have to use another port in the URL.
Thank you! I found the option in the sharepoint administration website.
I add this response to detail the steps I have taken - maybe they are useful for someone else.
In the sharepoint administration website (running flawlessly on another port), I chose "create or extend web applications", then "extend existing web application".
There, from the the drop down "Web application", "change web application" opens a popup with the web applications available. Search server was installed as "Sharepoint 80", so I selected that.
Then I selected "Create new IIS website", with a new name and a new port. All the other options looked fine to me as default.
Clicking OK, this creates a new web site in IIS, which was configured correctly. it doesn't work via the IP address of the server (http://192.x.x.x:8080), only using the server name - but that's ok with me :)
I still had to make some adjustments with the access rights, but the full crawl is running and I can find a few documents already. Yay!
This is much easier when you first backup your site and then create a new site from the central admin with a new port number and then restore the backup to it(overwrite)