The title is not quite correct, but here is the problem situation:
Setup multiple sites on the same IIS 7 server
Installed CF10 and it works fine on all sites
CFIDE Datasources can only be found for 1 site, not all of them, even though they still work on all sites
To see CF datasources (using RDS), the URL is sitename/CFIDE/administrator/datasources/index.cfm. Each site in IIS 7 has the CFIDE directory mapped to it as far as I know. It appears in the site folder structure for all my sites as a virtual directory. I used the Web Server Configuration Tool to remove and re-add ColdFusion to all my sites.
The problem is that applications using RDS can only find datasources for one of my sites. It uses the URL given above sitename/CFIDE/administrator/datasources/index.cfm to find the datasources of the site. RDS is not picking up the datasources for any of the other sites.
I tried manually going to sitename2/CFIDE/administrator/datasources/index.cfm (sitename2 being the name of a different site in IIS to the one that's working) and I just get this error:
"The page isn't redirecting properly
Firefox has detected that the server is redirecting the request for this address in a way that will never complete."
Can anyone suggest how to fix this so the URL will resolve for each site? Otherwise my RDS feature has broken which is not good. If I test the sites themselves, they all work fine and can access my datasources just fine. So something is up with the RDS feature
I've sorted it. Looks like it was a password thing. I had to remove the require password authentication and re-apply it again.
Related
I have a webserver using IIS 7 that hosts multiple sites. We've added a few subdomains recently and the one I'm working on WAS working. It's only partially in production so I'm not sure when this problem came up.
The problem is the subdomain (vendor.domain.com) is pointing to another site on IIS (Mobile).
Advanced settings of Manage Web Site show the bindings to be correct:
ftp:<ipaddr>:21:vendor.domain.com,http:<ipaddr>:80:vendor.domain.com,https:*:443:. The physical path is Vendors and has the files that I would expect it to be showing. But...it's not.
I've gone to the "Mobile" site that it is being redirected to and edited the files there and the changes I've made there have NOT been reflected on the vendor.domain.com as I would expect. It's like I have a cached version of the "Mobile" site.
Is there a way for me to find out where these files are coming from or a way to figure out why it's not showing the expected content?
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.
We have an extranet site. The Central Admin server is internal, with an external DMZ server that hosts the extended site. The external site connects to LDAP via FBA.
Every so often, the login.aspx page comes up without any core.css formatting or fonts, and users are unable to log in. When they try to submit their login they're re-prompted.
What has worked in the past is overwriting the web.config (containing connections to our LDAP server) with a known good copy. Recently, in addition to the overwrite, we've had to run an IISRESET.
The "default" internal site, connected to the local domain, works fine and without interruption.
The web.config 'fix' worked for a couple years, but recently it has been happening more frequently, almost daily. Last time it occurred, I noted that the 'bad' web.config's Modify date hadn't changed. A file compare shows them to be identical.
Has anyone seen something like this before? The only site customizations are the standard web.config connections to LDAP.
Much thanks,
Scott
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'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!