quarta-feira, 21 de novembro de 2012

Instalando o SharePoint 2013

Fala pessoal, boa tarde, hoje vou postar rapidamente a instalação do SharePoint 2013 no SQL Server 2012 no ambiente de testes que estou montando.



Com todos os pré-requisitos instalados, conforme o post publicado neste link, execute o instalador do SharePoint 2013.


Entre com a chave do produto para continuar a instalação.


Aceite os termos de licença de software.


No meu caso, como vou trabalhar com as funcionalidades de BI do SQL Server 2012 e SharePoint, estou realizando a instalação Completa, que tem como pré-requisito um domínio para instalação. 
Inicie a instalação.


Aguarde a instalação para podermos configurar o SharePoint.


Marque o checkbox para iniciar o   Configuration Wizard do SharePoint 2013 após o termino da instalação.


Pode passar a tela de requisitos de banco de dados.



Vai aparecer um warning de serviços necessários para a configuração do SharePoint.


Estou criando uma nova Farm do SharePoint, então selecione a opção Create a new server farm.



Entre com as informações do SQL Server (Note que estou usando um Aliase para o SQL Service, post sobre Aliases neste link). Note que aqui fala que é necessário utilizar uma conta de domínio.


Entre com uma senha para o Passphrase, esta senha será necessário caso queira juntar qualquer outro servidor de Sharepoint a farm.


Entre com a porta da central de administração do SharePoint e a forma de autenticação.
Como o SharePoint e o SQL estão no mesmo servidor, vou utilizar o NTLM.


Confira as informações e inicie a configuração do Sharepoint.


Aguarde enquanto o assistente realiza as configurações.


Pronto, temos o SharePoint 2013 configurado.

Sei que este post ficou muito em cima do configurador do SharePoint. Quando comecei a trabalhar com o SharePoint 2010, lembro de configurar todos os serviços necessários somente para o BI manualmente (hábito que aprendi com meu amigo Guilherme Schmidt), não utilizando o wizard, e levava bastante tempo tentando resolver problemas, isso porque nem tudo no SharePoint pode ser feito por GUI, tinha que utilizar o PowerShell do SharePoint para configurar alguns serviços, como o State Service (não sei se já dá para fazer por GUI hoje em dia), e era um recurso necessário para o PowerPivot. Utilizando o configuration wizard, estes serviços já são criados por padrão.

No próximo post, vou mostrar como criar um site com o template de BI e como integrar o Reporting Services 2012 no SharePoint 2013. Até lá!
















4 comentários:

  1. Olá Luís,

    Qual seria a diferença se eu optar por Kerberos no lugar do NTLM?

    ResponderExcluir
  2. Olá Rafael, o Kerberos é um protocolo de autenticação da Microsoft que trabalha com tickets no AD, e é muito utilizado para persistir as credenciais do usuário. Isso quer dizer que o usuario ao se logar no Sharepoint, por uma unica vez é feito uma requisição ao AD, que gera este ticket. Já no caso do NTLM, sempre que é feita uma solicitação de autenticação, é necessario que a aplicação faça esta solicitação ao AD. Isso a grosso modo. Se você estiver executando tudo em um único servidor, não terá nenhum problema com qualquer que seja a sua escolha, agora, se você distribuir por exemplo o Sharepoint e o SQL Server, e estiver utilizando o Kerberos, você precisa configurar SPNs para as contas de serviços para que estas aplicações possam "delegar" as credenciais do usuário pelo serviço de Sharepoint para acessar o SQL Server. Você pode ler mais sobre Kerberos nestes links:
    http://msdn.microsoft.com/en-us/library/windows/desktop/aa378747(v=vs.85).aspx
    http://technet.microsoft.com/en-us/library/ee806870.aspx
    http://technet.microsoft.com/en-us/library/cc280745(v=sql.105).aspx

    ResponderExcluir
    Respostas
    1. Entendi, mas o custo benefício parece pouco para muito trabalho não é?

      Excluir
  3. Depende da sua demanda, não é uma boa pratica ter todos os serviços rodando em um único servidor quando falamos de produção, isso gera gargalos que podem prejudicar a performance da solução.
    O Kerberos te permite delegar as credenciais de usuários, e com isso, você pode gerar regras de acesso a nível de dados em um cubo, como por exemplo, permitir que o usuário xpto só possa visualizar dados da sua filial, pensando em uma multinacional, sem nenhuma customização na parte de relatório. O relatório é o mesmo para toda a multinacional, mas quando o usuário visualiza o relatório, o data source passa essa credencial delegada, e filtra a informação baseado na regra criada no cubo.
    O NTLM não faz essa delegação, então quando você acessa esse relatório, o usuário utilizado esta registrado no data source, e você perde esse recurso.
    Como disse inicialmente, tudo depende da sua demanda!

    ResponderExcluir