Russ,
De um modo geral, a maneira correta de fazer isso é com a opção # 1: estender o aplicativo da web. Existem algumas grandes razões para isso:
-
Provavelmente, o motivo mais importante para usar a opção 1 foi mencionado por Moo em sua postagem (acima): as configurações mantidas no IIS (por exemplo, cabeçalhos de host) também são rastreadas no SharePoint. A menos que não exista uma outra maneira de manipular uma determinada configuração do IIS do SharePoint (a vinculação de um certificado SSL é um bom exemplo), é altamente recomendável que todas as alterações do IIS sejam gerenciadas por ações e configurações no SharePoint. Fazer alterações no IIS sem atualizar a configuração de suporte do SharePoint muitas vezes resulta em um comportamento extremamente estranho. Um dos trabalhos do serviço SPAdmin (serviço de configuração do Windows SharePoint Services) é aplicar as alterações feitas no SharePoint ao IIS e em um farm (se houver vários servidores); É melhor deixar este serviço fazer o seu trabalho.
-
Quando você estende o aplicativo da Web, associa o novo URL a uma zona específica (Internet, Extranet, Intranet ou Personalizada). Ao criar links para outros sites do SharePoint dentro do farm, o SharePoint tentará usar uma URL para o site que esteja alinhado à sua zona atual. Por exemplo, se você estender o aplicativo da Web A para a zona da Extranet e o aplicativo da Web A contiver links para o aplicativo da Web B, o SharePoint tentará usar os links da zona da Extranet para o aplicativo da Web B se estiverem disponíveis - não a zona padrão links. Se o aplicativo da Web B não for estendido para a zona Extranet, haverá um processo de fallback (até a zona padrão) usado para atribuir um link ... mas é importante saber que isso está acontecendo por trás -scenes.
Uma abordagem alternativa seria associar um nome de host adicional à URL de zona padrão que você já possui por meio da funcionalidade Mapeamentos de Acesso Alternativo (AAM) incorporada à plataforma. Antes de fazer isso, porém, há uma consideração muito importante a ter em mente: cada zona (novamente: Padrão, Intranet, Extranet, Internet ou Personalizada) só pode ter uma URL pública associada a ela. No seu exemplo, abc123.com é o URL público da zona padrão. Você poderia usar AAMs para mapear www.abc123.com como um ponto de entrada adicional para a zona Padrão ... mas quando você fizer isso, todos os links na página farão referência a abc123 .com . Assim, a primeira solicitação de página pode chegar por meio do www.abc123.com , mas ao clicar em qualquer um dos links na página que postarem de volta no site, serão enviadas solicitações para abc123.com . Em essência, isso torna o AAM útil apenas para a primeira chamada (a menos que você esteja usando algo como a funcionalidade de publicação do SharePoint do ISA Server - mas isso é outra história e fora do tópico).
Eu não acredito que a opção 2 funcione. Se o SharePoint não estiver ciente do nome do host associado a um site (ou seja, ele é atribuído somente no IIS), não terá como saber de onde o conteúdo desse site deve ser extraído. O SharePoint não funciona como um site tradicional com suporte a arquivos; a URL é analisada pelo redirecionador virtual do SharePoint para extrair o conteúdo do banco de dados de conteúdo apropriado para o site. Se o IIS tiver um nome de host, mas o SharePoint não souber nada sobre ele, não esperaria que nenhum conteúdo fosse recuperado e uma condição de erro resultasse.
Eu não testei, mas eu esperaria que a opção 3 funcionasse para a entrada inicial no site. Depois disso, todos os pedidos e links de páginas iriam para o destino redirecionado.
Espero que ajude!