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)
Related
The title is purposely generic as I have no clue to formulate my question in any different way.
I have made an MVC 5 project using .NET 4.7.
My goal is to use IIS 10 to point to a domain so I can use that as a testing ground.
I have already edited my host-file to point my localhost ip to the domain I have in mind.
After that I have followed every step mentioned in the video below meticulously.
However I keep ending up on the 403.14 error page.
I have adjusted security to no avail, checked the app-pool to use the correct .net version... I'm all out off ideas.
https://www.youtube.com/watch?v=IwbKquNBNgQ
I hope someone here has some idea of things I have not thought of myself, so feel free to ask anything you think might make the change I need to make this work. I will edit this message (and title) as much as needed to keep up to date as possible.
EDIT: I have followed the full guide that I have marked as an answer. I had 3 differences.
Difference 1 was in Windows Features. I think I just plain didn't correctly mark all the needed features..
Difference 2 was in Security. I did not have IIS_IUSRS added, only IUSR
Difference 3 is one I have purposely keep a difference and that is Directory Browsing. Without this being enabled, it works for me.
I hope that if anyone ends up on this page in the future, the answer provided below will be as helpful as it has been to me.
make sure you enabled below iis features:
please follow the below steps to publish your MVC project in iis.
1)open the visual studio. Select your site and right-click on that-> Click publish.
2)in pick up publish target Select folder option and create choose destination where you want to publish the site. (make a new folder and publish a site in that folder) and then select publish.
3)open IIS manager.
4)expand the server name and right-click on sites and select add a new site.
5)enter the site name, physical path, and site binding details.
ip address: select your machine ip address.
port: 80
domain name: your domain name
6)make sure you enabled directory browsing in iis.
7) The application pool is running under application pool identity, a version is correct and using the integrated pipeline.
8)anonymous authentication is enabled.
9)iis_iusrs and iusr have full permission to access the site folder.
host file enry:
bind your machine IP dress with a hostname of the site.
after doing all the changes refresh the site in iis and browse.
i'm running sharepoint 2010 foundation, on win7. since installing SP2010, none of my other localhost websites load in the browser. i'm either prompted for a login, or it just returns blank pages. i've tried putting my other websites within the SP-80 directory in iis7, which allowed the pages to load, but required a login. i tried various combinations of windows authentication on different iis7 directories, but nothing worked. i'm left with the impression that iis7 requires a single port 80 directory, rather than distinct, named directors, with separate permissions. the issue could be complicated by having my other sites mapped to a virtual directory, requiring my admin creds, to allow iis access to the files.
my question is, is it possible to host public, unprotected, port 80, web sites, along with SP2010? i'm not very experienced with IIS, so please forgive me if i'm overlooking the obvious.
sure it is possible. While creating WebApplications in SharePoint you're able to specify the port, the WebApplication will run on.
You should have a look at your Site Settings within IIS. SharePoint is by default not running on anonymous authentication mode.
Please analyze if you do have site collections created under Web Application using Powershell or from Central Admin
If you have Web Application created but no Site Collections, then you will get same issue
Sandeep
If you want other sites on IIS on the same port on the same machine, you'll need to declare IIS host headers. When you create a new Site in IIS, there is a bindings section (IIS 7.5 - in IIS6, I believe it's just called Host Headers) - set your bindings to be myotherwebsite.com or myotherwebsite.local. Make sure the names you use in your bindings match DNS names that are pointing to that machine, either through public DNS (if it's a public site) or through your local hosts file (\windows\system32\drivers\etc\hosts) if it's only for your local use.
Going the host headers route, you bypass the sharepoint execution stream completely - set your site up just as you would any other.
I am working under localhost.
In IIS Manager 7.5, windows server 2008.
After adding a new application in "Application pools", I added a new asp.net web application site using that application pool.
The problem is how can I run that website on localhost to check whether the site is working correctly or not?
People told me that I have to add bindings "domains" for that site and run the site using those domains. But that is not convenient as every time adding a new site on IIS, I need to have a domain to check the result?
I think it should be possible to run the site under localhost somehow but I dont know.
Any ideas?
Thanks in advance.
The simplest way is to add a virtual directory to your default web site within IIS. Point that virtual directory to the directory to which you installed/copied your website.
The you can either browse from IIS or type the virtual directory name (preceeded by localhost/) into your browser address bar.
If the problems is with "domains" yo do not have to buy domains. By asigning different port numbers on localhost you can add new bindings.
As I know adding binding is essential for IIS to understand which site should be opened.
For example you can assign port numbers like
80 -default- , 81,82 ... 8090...
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'm trying to get crawl to work on two separate farms I have but can't get it to work on either one. They both have two WFE's with an additional WFE configured as an Index server. There is one more server dedicated for Query and two clustered SQL 2005 back end servers for the database. I have unsuccessfully tried at least 50 different websites that I found with solutions from a search engine. I have configured (extended) my Web App to use http://servername:12345 as the default zone and http://abc.companyname.com as the custom and intranet zones. When I enter each of those into the content source and then try to run a crawl, I get a couple of errors in the crawl log:
http://servername:12345 returns:
"Could not connect to the server. Please make sure the site is accessible."
http://abc.companyname.com returns:
"Deleted by the gatherer. (The start address or content source that contained this item was deleted and hence this item was deleted.)"
However, I can click both URL's and the page is accessible.
Any ideas?
More info:
I wiped the slate clean, so to speak, and ran another crawl to provide an updated sample.
My content sources are as such:
http://servername:33333
http://sharepoint.portal.fake.com
sps3://servername:33333
My current crawl log errors are:
sps3://servername:33333
Error in PortalCrawl Web Service.
http://servername:33333/mysites
Content for this URL is excluded by the server because a no-index attribute.
http://servername:33333/mysites
Crawled
sts3://servername:33333/contentdbid={62a647a...
Crawled
sts3://servername:33333
Crawled
http://servername:33333
Crawled
http://sharepoint.portal.fake.com
The Crawler could not communicate with the server. Check that the server is available and that the firewall access is configured correctly.
I double checked for typos above and I don't see any so this should be an accurate reflection.
One thing to remember is that crawling SharePoint sites is different from crawling file shares or non-SharePoint websites.
A few other quick pointers:
the sps3: protocol is for crawling user profiles for People Search. You can disregard anything the crawler says about it until you're ready for user profiles.
your crawl account is supposed to have access to your entire farm. If you see permissions errors, find the KB article that tells you the how to reset your crawl account (it's a specific stsadm.exe command). If you're trying to crawl another farm's content, then you'll have to work something else out to grant your crawl account access. I think this is your biggest issue presently.
The crawler (running from the index server) will attempt to visit the public URL. I've had inter-server communication issues before; make sure all three servers can ping each other, and make sure the index server can reach the public URL (open IE on the index server and check it out). If you have problems, it's time to dirty up your index server's hosts file. This is something SharePoint does for you anyway, so don't feel too bad doing it. If you've set up anything aside from Integrated Windows Authentication, you'll have to work harder to get your crawler working.
Anyway, there's been a lot of back and forth in the responses, so I'm just shotgunning a bunch of suggestions out there, maybe one of them is on target.
I'm a little confused about your farm topology. A machine installed as a just a WFE cannot be an indexer. A machine installed as "complete" can be an indexer, query and/or a wfe...
Also, instead of changing the default content access account, you may want to add a crawl rule instead (once everything is up and running)
Can you see if anything helpful is in the %commonprogramfiles%/microsoft shared/web server extensions/12/logs on your indexer?
The log file may be a bit verbose, you can search for "started" or "full" and that will usually get you to the line in the log where your crawl started.
Also, on your sql machine, you may be able to get more information from the MSScrawlurlhistory table.
Can you create a content source for http://www.cnn.com and start a full crawl? Do you get the same error(s)?
Also, we may want to take this offline, let me know if you want to do that.
I'm not sure if there is a way to send private messages via stackoverflow though.
Most of your issues are related to Kerberos, it sounds like. If you don't have the infrastructure update applied, then Sharepoint will not be able to use kerberos auth to web sites w/ non default (80/443) ports. That's also why (I would bet) that you cannot access CA from server 5 when it's on server 4. If you don't have the SPNs set up correctly, then CA will only be accessible from the machine it is installed on. If you had installed Sharepoint using port 80 as the default url you'd be able to do the local sharepoint crawl without any hitches. But by design the local sharepoint sites crawl uses the default url to access the sharepoint sites. Check out http://codefrob.spaces.live.com/blog/cns!7C69E7B2271B08F6!363.entry for a little more detail on how to get Kerberos & Sharepoint to work well together.
In the Services on Server section check the properties for the search crawl account to make sure it is set up, and that it has permissions to access those sites.
Thanks for the new input!
So I came back from my weekend and I wanted to go through your pointers and try every one and then report back about how they didn't work and then post the results that I got. Funny thing happened, though.
I went to my Indexer (servername5) and I tried to connect to Central Admin and the main portal from Internet Explorer. Neither worked. So I went into IIS on ther Indexer to try to browse to the main portal from within IIS. That didn't work either and I received an error telling me that something else was using that port. So I saw my old website from the previous build and I deleted it from IIS along with the corresponding Application Pool. Then I started the App Pool for the web site from the new build and browsed to the website. Success. Then I browsed to the website from the browser on my own PC. Success again. Then I ran a crawl by the full URL, not the servername, like so:
http://sharepoint.portal.fake.com
Success again. It crawled the entire portal including the subsites just like I wanted. The "Items in index" populated quickly and I could tell I was rolling.
I still cannot access the Central Admin site hosted on servername4 from servername5. I'm not sure why not but I don't know that it matters much at this point.
Where does this leave me? What was the fix?
I'm still not sure. Maybe it was the rebuild. Maybe as soon as I rebuilt the server farm I had everything I needed to get it to work but it just wouldn't work because of the previous website still in IIS. (It's funny how sloppy a SharePoint un-install can be. Manual deletion of content databases, web sites, and application pools seem necessary and that probably shouldn't be the case.)
In any event, it's working now on my "test" farm so the key is to get it working on the production farm. I'm hopeful that it won't be so difficult after this experience.
Thanks for the help from everyone!