Alternate Access Mappings make me cry

Question

-- 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.

Answer 1

@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)

Answer 2

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?