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.

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