Take the 2-minute tour ×
SharePoint Stack Exchange is a question and answer site for SharePoint enthusiasts. It's 100% free, no registration required.

-- Please See Edit(s) at bottom ---

So, last week sometime, search broke for a WSS 3 site I administer.* I tried all kinds of things that I thought would work. The best I could do was eliminate the errors showing in the Event Log but no results would show when a user searched Sharepoint.

After awhile, I hit on something that worked. When I changed the Default AAM from https://sharepoint.mydomain.com:987 to http://servername and created another Internal URL for the Internet zone for http://servername to https://sharepoint.mydomain.com:987.

I then nuked the search database in the Operations Manager, created a new one which forced me to re-assert the credentials, of course. And, suddenly, search worked!

But, alas, there's ANOTHER problem.

In Outlook the users connect a Contacts list. During initial Send/Receive for the list, an error occurs that notes that the domain http://servername is not available and that Outlook would attempt an alternate hostname https://sharepoint.mydomain.com:987. (The server sits in a colo center deep in the heart of Texas. Everyone else is remote. No VPN.)

So, I have a few questions:

  1. Will search work if I make the default zone https://sharepoint.mydomain.com:987 ? That domain is in DNS on the server so it can be found. (It's a CNAME, linked to the server name, if that matters.)

  2. Will that fix the Send/Receive error?

  3. I can't get my head around AAM. It seems very necessary but most of what I find online has to do with reverse proxies and load balancing, of which I have neither.

Please to be helping me? :-)

Thanks so much!

*I use administer loosely. I suck at this stuff. ;-) I'm learning but frustrated.

--- EDIT 1 ---

I tried a few things this evening. I won't go completely into what I did because it's a lot of thrashing around, but here's the end result.

Since the SSL site was never set up properly in the first place, I

  1. Removed 987 from the original Sharepoint IIS site.
  2. Extended the Sharepoint Web App for a 443 instance.
  3. Extended the Sharepoint Web App for a 987 instance.
  4. Made the default zone http://servername

Search works. I don't know if the Outlook issue has been resolved. I'll have to check it a bit later and will update.

share|improve this question
add comment

2 Answers

up vote 2 down vote accepted

@tcv, yes I read your post.

Search itself likes the default zone with NTLM permissions. It will work with kerberos and SSL, but you'll save your self alot of TS time, just using 80/NTLM. Search will "mostly" work with an extended app, but you will lose things like the default scopes (this site, this list), etc. You can still search those, but only from the globa scope.

You can change the default zone to point at the extended app, and use one of the other zones to point at your original 987. Your users will still have access, and Search will work as intended. Be aware that system emails always use the URL of the default zone. see the section on zones here: http://technet.microsoft.com/en-us/library/cc287815.aspx

I suggested locking down the webapp only to avoid inadvertant use if you want to ensure it is only access via your orignal URL. This is up to you on how to do it (webapp rule, IP, firewall, all of the above, etc) depending on yoru requirements. You might just leave it open and slowly transition your users.

Also be aware that if you already have something on port 80 you need to specify a host header for the extended app (same for 443)

share|improve this answer
    
First, I am sorry if I implied that you didn't read my post. I was unsure of the timing between my edit and your comment. I think that the way things are configured now is what you're suggesting. I didn't install Sharepoint so I don't know how things were set up in the beginning but I imagine that the first site was 80/NTLM. In essence, I've gone back to that original configuration, extended the original site twice using different ports. The original site is: servername. Extended1 is sharepoint.domain.com:443. Extended2 is sharepoint.domain.com:987. –  tcv Jul 17 '11 at 13:42
    
So as far at the Zones go, Default is servername. Internet is the 987 site. 443 is in the Intranet site. This configuration seems to work in that Search still functions and Outlooks outside of the LAN don't complain about inaccessible URLs. I do need to lock down the 80 site more to my liking, however and I've not re-tested outgoing email for alerts. I'll do that shortly and update. –  tcv Jul 17 '11 at 13:46
    
Yes, they work. I did see some errors in the Event Log re: an older sharepoint URL that is no longer is use. The errors are not continuous. Rather they logged for about 1.5 hours and stopped ... I am wondering if there is an Outlook client out there trying access over this older URL.... –  tcv Jul 17 '11 at 13:54
add comment

I think the problem is most likely that you are running SSL on a non-standard port. I believe the search crawler will only crawl SSL on standard port 443. Are you using Kerberos or NTLM for authentication?

share|improve this answer
    
I'm sorry to ask this and tip my hand about how dumb I am about this... how do I find out? –  tcv Jul 15 '11 at 21:39
    
Under the Authentication Methods for the site in IIS 6, I see "Integrated Windows authentication" checked. I don't see Kerberos visible as I do in IIS 7. --- edit: I see that Integrated is Kerberos and NTLM. –  tcv Jul 15 '11 at 22:17
    
Now I'm wondering: Would it be okay to extend the application to another IIS site, run that one over 443 and utilize the Default zone for that instance? Everything else can be external to :987? I'm trying not to have to remap everyone's Outlook again. –  tcv Jul 15 '11 at 22:27
1  
I recommend if you take that route to simply extend it on port 80, leave NTLM authentication, and create a webapp rule to exclude all but your crawl accounts from accessing it. if you get a chance later, that would be what you want your default zone to look like, and extend that for any changes (SSL, non-standard ports, etc). –  Jesus Shelby Jul 16 '11 at 2:17
    
Not sure if you happened to read the edit above, but I have three IIS instances of the site now. One for port 80, one for 443, and one for 987. The users are all currently using 987 from outside of the LAN. I'd prefer not to have to reset them all up again, but will if I have to. -- Should I restrict the 80 instance as you suggest? -- Goal here is to keep search running and to prevent send/receive errors in Outlook. –  tcv Jul 16 '11 at 20:47
show 2 more comments

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.