Implantação do SharePoint 2010: Prepare-se para atualizar para o SharePoint 2010
Pode ser tentador entrar de cabeça em uma atualização do SharePoint 2010, mas isso exige um planejamento substancial. Este artigo o guiará pelo processo de planejamento da atualização.
Brien Posey
A atualização para o SharePoint 2010 será diferente de todas as que você já fez. Antes de começar o processo de planejamento de sua atualização, você precisa se familiarizar com os requisitos do sistema do SharePoint 2010. Ao contrário das versões anteriores do SharePoint, o SharePoint 2010 é apenas para 64 bits. Sendo assim, você terá de instalar o SharePoint 2010 sobre uma versão de 64 bits do Windows Server 2008 ou do Windows Server 2008 R2.
O SharePoint requer um banco de dados do SQL Server, mas esse banco de dados não precisa residir no mesmo servidor que o SharePoint. O SharePoint 2010 ainda exige o SQL Server, mas a Microsoft fez algumas alterações importantes. O SharePoint 2010 exige que o banco de dados esteja executando uma edição de 64 bits do SQL Server 2005 ou 2008. Isso vale mesmo que o banco de dados não esteja instalado localmente no servidor do SharePoint.
Embora esse não seja tecnicamente um requisito do sistema, convém considerar os navegadores da Web que você utiliza. O SharePoint 2010 foi projetado para usar os padrões da Web de forma melhor. Isso significa que os usuários deverão ter uma experiência consistente, estejam eles usando o Internet Explorer ou o Firefox (3.x ou posterior). Um probleminha aqui é que o SharePoint 2010 tem suporte limitado para o Internet Explorer 6. Os usuários do IE6 não deverão ter nenhum problema para exibir o conteúdo do SharePoint, mas a criação de conteúdo requer o IE7 ou posterior (ou o Firefox 3.x ou posterior).
Atualizações in-loco
Como você já deve ter ouvido falar, o SharePoint 2010 permite atualizações in-loco a partir do Microsoft Office SharePoint Server (MOSS) 2007. Mas, como o SharePoint 2010 é de 64 bits, você só pode executar uma atualização in-loco se o seu MOSS 2007 existente estiver sendo executado sobre uma versão de 64 bits do Windows Server 2008. Se os seus servidores do SharePoint existentes atenderem aos requisitos do sistema obrigatórios, você poderá executar uma atualização in-loco em todos os servidores de seu farm do SharePoint.
Embora o SharePoint ofereça total suporte a essas atualizações, eu só recomendaria uma atualização in-loco se você tiver uma implantação simples do SharePoint e não tiver feito nenhuma personalização. Nos ambientes mais complexos, são recomendadas as migrações completas porque elas fornecem um nível mais alto de controle sobre o processo de atualização. Elas também são aconselháveis para os ambientes nos quais foram feitas personalizações, para que elas não sejam substituídas acidentalmente.
Uma migração geralmente envolve a criação de um farm totalmente novo do SharePoint executando o SharePoint 2010. Depois de fazer isso, você pode anexar seus bancos de dados do SharePoint existentes ao novo farm. Você também pode usar uma estratégia de migração híbrida, que combina atualizações in-loco e servidores do SharePoint 2010 totalmente novos.
Verificação de pré-atualização
Seja em uma atualização in-loco ou em uma migração, você precisará de algum planejamento e de preparação antes de iniciar o processo efetivamente. Executar o verificador de pré-atualização é uma das etapas mais importantes da preparação da atualização para o SharePoint 2010. Antes de lançar o MOSS 2007, a Microsoft criou o utilitário Prescan.exe, que ajudava a garantir a integridade de sua implantação do SharePoint antes da atualização para o MOSS 2007.
Embora o Prescan.exe fosse uma boa ferramenta na época, ele não é realmente adequado para uma análise de pré-implantação para o SharePoint 2010. Sendo assim, a Microsoft forneceu uma nova ferramenta chamada Pre-Upgrade Checker. O Pre-Upgrade Checker é um enorme aprimoramento em relação ao Prescan.exe. Para começar, o Pre-Upgrade Checker é somente leitura, portanto, você não precisa se preocupar com o fato de que ele faça atualizações em seus servidores do SharePoint.
O que torna o Pre-Upgrade Checker realmente útil é que ele realiza um trabalho muito mais completo de detecção de problemas do que seu antecessor, o Prescan.exe. Ele também é extensível. O Pre-Upgrade Checker vem com um conjunto de regras que ele utiliza ao analisar os seus servidores do SharePoint. Essas regras estão em formato XML, o que significa que você pode criar suas próprias regras personalizadas, caso seja preciso. O uso de regras baseadas em XML também facilita para a Microsoft a atualização do Pre-Upgrade Checker caso suas práticas recomendadas mudem, algum dia.
Mas o melhor do Pre-Upgrade Checker são, sem dúvida, as informações que ele compila. Embora a Microsoft tenha projetado o Pre-Upgrade Checker como uma ferramenta para preparar uma atualização para o SharePoint 2010, algumas organizações o estão utilizando para outras finalidades. Uma empresa, na verdade, usa o Pre-Upgrade Checker como parte de seu plano de recuperação de desastre. O utilitário, na verdade, não faz nada para ajudar a salvar um servidor do SharePoint com falha, mas as informações que ele coleta podem ser inestimáveis se você um dia tiver que recriar uma implantação do SharePoint (desde que você tenha executado a ferramenta antes da ocorrência da falha).
Da mesma forma, outra organização usou o Pre-Upgrade Checker como uma ferramenta para garantir que seus servidores do SharePoint estavam configurados de forma consistente. Quando executado em cada um de seus servidores do SharePoint, o Pre-Upgrade Checker é capaz de comparar os relatórios de cada servidor e procurar por elementos individuais da configuração que não estão de acordo com diretiva corporativa.
Então, onde você pode obter o Pre-Upgrade Checker? Provavelmente, você já o possui. A Microsoft incluiu o Pre-Upgrade Checker no MOSS 2007 SP2. Mas, ao contrário do que você poderia esperar, o Pre-Upgrade Checker não é uma ferramenta autônoma. Em vez disso, a Microsoft o incorporou ao utilitário STSADM.EXE. Acidentalmente, depois de aplicar o SP2, tive que reinicializar meu servidor de teste duas vezes antes que o Windows me permitisse acessar a nova funcionalidade do STSADM.EXE.
Disto isso, quero mostrar a você como o Pre-Upgrade Checker funciona. Como mencionei antes, o Pre-Upgrade Checker funciona analisando um arquivo de regras baseado em XML e, depois, usando essas regras como base para a análise de sua implantação do SharePoint. O Pre-Upgrade Checker vem com um conjunto de regras interno. Essas regras, que se baseiam no Analisador de Práticas Recomendadas, estão dentro de um arquivo chamado OssPreUpgradeCheck.xml. Você pode ter uma ideia desse arquivo na Figura 1.
Figura 1 O Pre-Upgrade Checker usa um arquivo de regras baseado em XML.
Quando você invoca o Pre-Upgrade Checker, não precisa chamar explicitamente esse arquivo de regras. O Pre-Upgrade Checker o chama por padrão. Você tem a opção de usar arquivos de regras personalizados. A sintaxe completa do Pre-Upgrade Checker é a seguinte:
STSADM.EXE –O PreUpgradeCheck
[[-RuleFiles “<rule file name>”] [-ListRuleFiles]] [-LocalOnly]
Como você pode notar na sintaxe anterior, os únicos parâmetros necessários são o –O e as palavras PreUpgradeCheck. O parâmetro –RuleFiles é opcional e é usado apenas se você quiser especificar manualmente um arquivo de regras a ser usado. Da mesma forma, você pode usar o parâmetro –ListRuleFiles para exibir os arquivos de regras que estão disponíveis para você. Por fim, você pode usar o parâmetro –LocalOnly para executar as regras apenas no servidor do SharePoint local.
Para que você tenha uma ideia melhor de como funciona o Pre-Upgrade Checker, dê uma olhada na Figura 2. Como você pode notar na figura, comecei abrindo uma janela do Prompt de Comando e navegando pela estrutura de diretórios até C:\Arquivos de Programas\Common Files\Microsoft Shared\Web Server Extensions\12\BIN. Lá, executei o seguinte comando:
STSADMIN.EXE –O PreUpgradeCheck]
.jpg)
Figura 2 O Pre-Upgrade Checker testa a sua implantação do SharePoint.
Como se pode notar na Figura 2, o Pre-Upgrade Checker executa diversos testes diferentes na implantação do SharePoint. Os resultados de cada teste são codificados por cores. Vermelho indica um teste com falha e verde indica que o servidor passou no teste. Os itens informativos são indicados em amarelo.
Obviamente, a saída do Pre-Upgrade Checker não é exatamente detalhada. A captura de tela da Figura 2 informa apenas se houve aprovação ou falha no teste; não há informações detalhadas. Se você olhar para a parte inferior da captura de tela, porém, notará que há uma mensagem indicando que você pode revisar os resultados em um arquivo HTML localizado na pasta C:\Arquivos de Programas\Common Files\Microsoft Shared\Web Server Extensions\12\Logs.
Cada vez que você executa o Pre-Upgrade Checker, ele cria três arquivos de log separados. Um deles é o arquivo HTML mencionado no final da verificação de atualização, mas também há um arquivo LOG e um arquivo XML. Você pode usar qualquer um desses arquivos de log, mas o arquivo HTML é o mais fácil de ler.
Como já mencionei, o Pre-Upgrade Checker compila muitas informações. Portanto, não é de se surpreender que os logs resultantes sejam longos demais para que possamos incluí-los aqui por inteiro. Mas você pode ter uma ideia da aparência dos logs HTML na Figura 3.
.jpg)
Figura 3 Os resultados do Pre-Upgrade Checker podem ser exibidos em um navegador da Web.
Identifique suas personalizações
Outra etapa crítica do processo de planejamento da atualização é identificar as personalizações feitas por você nos servidores do SharePoint. Independentemente de você estar executando uma atualização in-loco ou uma migração, não é difícil substituir personalizações por acidente. Portanto, você deve documentar suas personalizações e fazer um backup apenas desses arquivos, para que eles possam ser facilmente reaplicados após a atualização, se preciso.
O ideal é que você tenha documentado detalhadamente todas as suas personalizações à medida que seu ambiente do SharePoint foi evoluindo. Na realidade, pode ser difícil acompanhar todas as alterações. Portanto, reserve algum tempo para revisar seu log de personalização, mesmo que ache que todas as suas personalizações foram bem-documentadas. Infelizmente, o SharePoint não contém nenhuma ferramenta interna para identificar as personalizações. Mas isso não significa que você precisa revisar manualmente todos os arquivos de seus servidores do SharePoint.
Uma das maneiras pelas quais você pode obter informações sobre as personalizações é usando uma técnica chamada diffing (comparação). A ideia por trás dessa técnica é que você pode configurar um servidor MOSS 2007 de reserva (certifique-se de que ele esteja executando os mesmos patches que seus servidores de produção) e, depois, usar um programa de comparação para ver quais arquivos de seus servidores de produção são diferentes de um servidor do SharePoint original.
A Microsoft recomenda o uso do WinDiff, mas existem diversos utilitários de comparação disponíveis, muitos dos quais com um conjunto de recursos muito mais completo do que o WinDiff.
Teste o processo de atualização
À medida que você se prepara para fazer a transição para o SharePoint 2010, eventualmente chegará o momento de desenvolver um plano para execução da atualização. Supondo-se que você já tenha resolvido todos os problemas reportados pelo Pre-Upgrade Checker, o processo de atualização deverá ser relativamente tranquilo. Mas você não deve contar com a sorte.
Implante o MOSS 2007 em um ambiente de laboratório isolado e experimente seu plano de atualização no laboratório antes de tentar atualizar seus servidores de produção. O uso de um laboratório pode ajudá-lo a se familiarizar com o processo de atualização, assim como a identificar questões que podem criar problemas na hora da atualização real.
A melhor abordagem nas empresas de pequeno a médio porte (SMBs) é configurar alguns servidores virtuais e, depois, realmente restaurar backups de seus servidores de produção nos servidores do laboratório. Isso lhe permitirá experimentar o plano de atualização em um ambiente praticamente idêntico ao de produção.
Nas organizações maiores, a criação de uma réplica exata da implantação do SharePoint na produção é, provavelmente, impraticável. Nesses tipos de situações, convém configurar um ambiente em pequena escala que seja configurado de forma semelhante à implantação na produção. Você também pode tentar restaurar backups de alguns (porém não todos) dos seus servidores do SharePoint em um ambiente de laboratório. Embora essa abordagem possa parecer que você está contando muito com a sorte, lembre-se de que você provavelmente não vai converter toda a implantação para o SharePoint 2010 de uma vez; é aconselhável se concentrar na implantação em uma área por vez.
Verifique seus backups
A última etapa antes de iniciar uma atualização para o SharePoint 2010 é verificar se os seus backups estão funcionando corretamente. Esta semana mesmo, tive que ajudar alguém que achava que tinha feito o backup de seus servidores corretamente, mas descobriu da forma mais difícil que seus backups eram inadequados. Não deixe que isso aconteça com você. Teste seus backups e certifique-se de que eles possam ser restaurados.
.jpg)
Brien Posey**é um MVP e é um autor técnico freelance com milhares de artigos e dezenas de livros com seu nome. Você pode visitar o site dele embrienposey.com.