Usar uma atualização de avaliação para encontrar problemas em potencial no SharePoint 2013

Artigo
03/08/2023

APLICA-SE A: yes-img-13 2013 no-img-16 2016 no-img-19 2019 no-img-se Subscription Edition no-img-sop SharePoint no Microsoft 365

Antes de iniciar uma atualização dos Produtos SharePoint 2010 para o SharePoint 2013, deve testar o processo de atualização para se certificar de que sabe exatamente o que tem de fazer para ter uma atualização com êxito. Uma atualização de avaliação para testar o processo pode revelar os seguintes problemas:

Se um plano de atualização funcionará ou se você deve fazer ajustes.
As personalizações em seu ambiente para que você possa planejar lidar com elas durante a atualização.
Se você deve atualizar seu hardware para tornar uma atualização mais eficiente e rápida.
O prazo para atualização ou quanto tempo a atualização levará para seu ambiente.
O que você deve planejar, operacionalmente – por exemplo, recursos disponíveis.

Além disso, é possível usar a atualização de avaliação para se tornar familiar com as ferramentas de avaliação e os próprios processos para que você saiba exatamente o que realizar no processo real. Durante o teste, é possível, descobrir os seguintes problemas:

Como a interface de usuário de atualização se parece? Como você sabe que terminou uma fase e está passando para outra?
Onde estão os arquivos de log e como você os lê? Quais informações eles oferecem?
Se você deve ajustar qualquer scripts ou comandos usados durante o processo de atualização, especialmente se você está confiando em qualquer scripts usado na atualização do Produtos do SharePoint 2010.
Se você tem o plano correto para resolver qualquer interrupção.

Este artigo descreve as etapas básicas para testar a atualização e oferece recomendações para revisar os resultados e ajustar um plano de atualização com base no que você aprendeu durante os testes.

Além disso, os seguintes recursos podem ser úteis ao testar o processo de atualização:

SharePoint 2013 – Como testar o modelo do processo de atualização

Baixe o pôster Visualização do Produtos do SharePoint 2013 – Teste seu modelo do processo de atualização para ver uma exibição das informações sobre como testar o processo de atualização.
Veja as práticas recomendadas para testar o processo de atualização em Práticas recomendadas para atualização do SharePoint 2010 para o SharePoint 2013

Configurar um ambiente de teste

É possível usar hardware físico ou virtual para testar o processo de atualização. Cada ambiente é único. Portanto, não há diretrizes gerais sobre quanto tempo a atualização levará e quão difícil é uma determinada personalização para atualização. A melhor forma de calibrar como a atualização será realizada é uma série de atualizações de avaliação.

Aqui estão algumas coisas a considerar ao criar seu ambiente de teste:

Fazer seu farm de teste o mais semelhante possível ao seu farm real — por exemplo, hardware, software e espaço disponível.
Use a mesma URLs em seu farm de teste que seu farm real. Caso contrário, você perderá tempo diagnosticando problemas relacionados às URLs que não ocorrerão na atualização real. É possível fazer isso usando as mesmas URLs e testando apenas por computadores que possuem mudanças do arquivo de host.
Use diferentes nomes de computador para seus servidores da Web e de aplicativo;

Isto evitará conflitos dos Serviços de Domínio do Active Directory (AD DS).
Use servidores separados que executam o SQL Server para seu farm de teste

Se estiver a utilizar os mesmos servidores que executam o SQL Server para o seu farm de teste e produção, pode afetar o desempenho do farm de produção enquanto executa os testes. Recomendamos que utilize diferentes computadores do SQL Server (e não apenas instâncias) para os farms de produção e de teste.
Use os mesmos nomes do banco de dados em seu ambiente de teste.

Desta forma, é possível validar qualquer scripts usado para gerenciar seu ambiente. Mais uma vez, certifique-se de que utiliza servidores separados que estão a executar o SQL Server ou corre o risco de afetar o seu ambiente de produção.
Certifique-se de transferir todas as configurações e personalizações ao ambiente de teste. A seção Identificar e instalar personalizações oferece informações sobre a coleta desta informação.

Certifique-se de que as ações realizadas no ambiente de teste não afetam o ambiente ao vivo. Tenha cuidado com o seguinte:

Conexões de dados externos

Mesmo se você estiver trabalhando com uma cópia do ambiente, o link para a fonte de dados é real. As mudanças realizadas nos dados do ambiente de teste afetam o ambiente de produção.
Executando comandos em um banco de dados ao vivo ainda na produção

Certifique-se de usar cópias de seus bancos de dados para testar, não uma versão ao vivo do seu ambiente de produção. Por exemplo, se você executar o Test-SPContentDatabase em um banco de dados ao vivo, ao invés de uma cópia, você pode afetar o desempenho em seu ambiente de produção.

Uso de um ambiente de teste virtual

Ao testar o uso de um ambiente virtualizado, você não precisa ter muito hardware. É possível replicar seu ambiente usando apenas dois servidores com o Hyper-V em execução. Um servidor com imagens para servidores da Web de front-end e servidores de aplicativos e outro servidor com imagens para servidores do banco de dados.

No entanto, ambientes virtuais podem não afetar a mesma métrica de desempenho que ambientes físicos. Se seu ambiente de produção é físico, você deve considerar esta diferença ao calcular o momento que é necessário atualizar seu ambiente de produção. Geralmente, pode obter melhores estimativas de desempenho se utilizar um servidor físico para o SQL Server. Certifique-se de que tem especificações de desempenho semelhantes ao servidor que executa o SQL Server no seu ambiente de produção.

Distribuidores de servidores em um ambiente de teste virtual

Farm de teste virtual para a atualização

Uso de um ambiente de teste físico

Ao testar usando um ambiente físico, você deve replicar seu ambiente do farm do servidor de produção proposto o mais próximo possível. Se você simplificar demais o número de servidores da Web de front-end, servidores de aplicativo ou servidores de banco de dados, não terá uma estimativa precisa de quanto tempo o processo de atualização levará. Não pode ter em conta as complicações resultantes de interações entre servidores na mesma função (como transações do SQL Server). Se você possui vários servidores em uma função no seu farm de produção proposto, use pelo menos dois servidores para essa função no farm de teste para testar esses problemas.

Distribuição de servidores em um ambiente de teste físico

Farm físico para testar a atualização

Identificar e instalar personalizações

Para ter um processo de teste preciso, você deve encontrar todas as personalizações em seu ambiente atual e copiá-las no ambiente de teste. Para obter mais informações sobre os tipos de personalizações que tem de identificar, consulte Criar um plano para personalizações atuais durante a atualização para o SharePoint 2013.

Utilize a operação Stsadm -o enumallwebs em todas as bases de dados de conteúdos no seu ambiente de Produtos do SharePoint 2010 para identificar personalizações específicas em subsites. Esta operação lista uma ID para cada conjunto de sites e subsite em seu ambiente e os modelos que o site confia. Para obter mais informações, consulte Operação Enumallwebs: Stsadm.
Use uma ferramenta como WinDiff (uma ferramenta oferecida com a maioria dos sistemas operacionais da Microsoft) para comparar seus servidores do ambiente de produção com seus servidores do farm de teste. É possível usar essa ferramenta para ver quais arquivos existem em seus servidores e a diferença entre eles.
Verifique os arquivos web.config por quaisquer mudanças e procure no elemento SafeControls para encontrar qualquer controle personalizado.
Crie uma lista de todas as personalizações que você encontrar. Identifique a fonte das personalizações, se possível. Por exemplo, existem complementos de terceiros ou modelos personalizados internamente? Após identificar a origem, é possível verificar versões atualizadas das personalizações.

Dica

Quem contatar sobre personalizações que você não criou? > Contacte a Microsoft se tiver problemas com um modelo que transferiu a partir do site da Microsoft. > Contacte o fornecedor da solução de terceiros se tiver problemas com um modelo ou componente que lhe forneceram para a versão anterior. Uma versão atualizada pode estar disponível.

Após identificar todas as personalizações, copie-as para os servidores adequados em seu farm de teste. Certifique-se de que as seguintes personalizações são implantadas:

Soluções - por soluções herdadas padrões implantadas em diretórios /14. Use o parâmetro CompatibilityLevel ao instalar soluções para implantá-las em diretórios /15. Para obter mais informações, consulte Install-SPSolution.
Páginas mestres personalizadas
JavaScript personalizado
Arquivos CSS personalizados (incluindo aqueles para temas)
Ações do fluxo de trabalho personalizado (deve ser incluído em arquivo de ações)
Confirme as configurações de aceleração de consulta de grande lista para garantir que grandes listas são exibidas como esperado.

Ao testar personalizações, use a seguinte orientação:

Verificar alterações visuais.
Verificar alterações de comportamento.
Testar em conjuntos de site do modo 2010 e 2013.
Procurar por qualquer idioma ou problemas de carregamento de recursos.

Há um problema que pode ocorrer quando existirem personalizações no modo 2010 e novas personalizações as substituem no modo 2013. Como há apenas um diretório global para recursos de idioma, pode haver um problema ao carregar o arquivo correto. Certifique-se de que as substituições das personalizações 2012 incluem recursos de 2010 para que as personalizações possam continuar a funcionar corretamente em ambos os modos.
Validar que a atualização não afeta personalizações. Certifique-se de que as personalizações não bloqueiem a atualização do conjunto de sites.

Pode utilizar o cmdlet Test-SPContentDatabase do Microsoft PowerShell antes de anexar uma base de dados ao SharePoint 2013 para determinar se faltam personalizações no ambiente. Execute este comando para cada banco de dados após restaurar os bancos de dados ao seu servidor de banco de dados, mas antes de executar a atualização. Observe que este cmdlet é executado silenciosamente — não será retornado qualquer resultado a não ser que um problema seja encontrado.

Copiar dados reais para testar o ambiente e atualizar bancos de dados

Não é possível atingir suas metas de teste a não ser que você use seus dados atuais. Utilize as ferramentas de cópia de segurança e restauro do Microsoft SQL Server para criar uma cópia das bases de dados de conteúdos e serviços.

Não há melhor forma de dizer o que pode ocorrer durante a atualização ao invés de realizar o teste em uma cópia de todos os dados. No entanto, isto pode não ser sempre uma opção real para o teste inicial. É possível testar em fases ao testar um banco de dados por vez (se o banco de dado é muito grande) para que você possa garantir que seu teste é exclusivo neste conjunto de dados. Em alternativa, é possível montar um subconjunto de dados de sites representativos no seu ambiente. Se você deseja primeiro testar usando um subconjunto de seus dados, certifique-se de que o subconjunto possui as seguintes características:

O subconjunto de dados contém sites comuns que você suporta em seu ambiente.
O tamanho e a complexidade do subconjunto de dados assemelha-se muito ao tamanho e complexidade real do seu ambiente.

Importante

Testar um subconjunto de seus dados não produz uma marcação válida por quanto tempo levará para processar todo o volume de dados de seu ambiente.

Após copiar os dados, obtenha uma primeira passagem pelo processo de atualização para ver o que acontece. Isto é apenas uma rodada preliminar. Siga os passos em Atualizar bases de dados de conteúdos do SharePoint 2010 para o SharePoint 2013 para experimentar o processo de atualização de anexação da base de dados.

Ao testar o processo de atualização, certifique-se de testar os serviços compartilhados entre farms. Considere todos os estados, como o seguinte:

Um farm do SharePoint Server 2010 conectado a um farm de serviços do SharePoint 2013.
Um farm do SharePoint 2013 conectado a um farm de serviços do SharePoint 2013.
Farms de versões diferentes para serviços diferentes.

Use o ambiente de teste para encontrar qualquer problema de segurança, configuração, compatibilidade e desempenho para aplicativos de serviço.

Revise os resultados após atualizar seus bancos de dados

Após sua atualização de teste ter concluído, é possível revisar os resultados e revisar seus planos. Procure nos arquivos de log, procure por sites atualizados e revise suas personalizações. Como a atualização funciona em seu ambiente? O que você descobriu? O que você precisa pensar novamente sobre o plano de atualização?

Revise os arquivos de log

Revise o arquivo de log de atualização e o arquivo de log de erro de atualização (gerado ao executar a atualização). O arquivo de log de atualização (.log) e o arquivo de log de erro de atualização (.err) estão localizados em %COMMONPROGRAMFILES%\Microsoft Shared\Web server extensions\15\LOGS. Os ficheiros de registo têm o nome no seguinte formato: Upgrade- YYYYMMDD-HHMMSS-SSS.log, em que AAAAMMDD é a data e HHMMSS-SSS é a hora (horas no formato de relógio de 24 horas, minutos, segundos e milissegundos).

O formato dos arquivos de log está de acordo com as convenções ULS. Para revisar os arquivos de log e resolver problemas, comece no topo dos arquivos. Erros ou avisos podem ser repetidos se ocorrerem por vários conjuntos de sites no ambiente ou se eles bloqueiam totalmente o processo de atualização. Por exemplo, se não for possível conectar-se ao banco de dados de configuração, o processo de atualização tentará (e falhará) várias vezes e estas tentativas serão listadas no arquivo de log.

Revisar sites no modo 2010

Verifique se os conjuntos de site não atualizados funcionam como esperado no modo 2010. Os sites devem ter um aspeto e comportamento como nos Produtos sharePoint 2010. Algumas mudanças são esperadas. Por exemplo, as funcionalidades do Office Online e da análise Web foram alteradas no SharePoint 2013 e os sites que utilizaram estas funcionalidades serão afetados. Para obter informações sobre aspetos específicos a procurar, consulte Descrição geral do processo de atualização do SharePoint 2010 para o SharePoint 2013.

Execute a atualização novamente, se necessário

Se for necessário, pode reiniciar o processo de atualização de uma base de dados com o cmdlet Upgrade-SPContentDatabase do Microsoft PowerShell. Para obter mais informações sobre esse cmdlet, consulte Upgrade-SPContentDatabase. Para obter mais informações, consulte Reiniciar uma atualização de anexação de base de dados ou uma atualização da coleção de sites para o SharePoint 2013.

Atualizar conjuntos de sites Meus Sites

Após ter testado e validado a atualização para bancos de dados de conteúdo e serviços, é possível testar o processo de atualização para conjuntos de site. Siga os passos em Atualizar uma coleção de sites para o SharePoint 2013 para testar o processo de atualização da coleção de sites. Se tiver Os Meus Sites no seu ambiente, consulte Descrição geral do processo de atualização do SharePoint 2010 para o SharePoint 2013 para obter mais informações sobre o processo de atualização dos mesmos.

Observação

O conteúdo sobre Meus Sites aplica-se somente ao SharePoint 2013.

Revise os resultados após atualizar os conjuntos de site

Revise os sites atualizados visualmente para identificar qualquer problema que precisa ser resolvido antes de executar o processo de atualização em seu ambiente de produção. Para obter mais informações sobre aspetos específicos a procurar, consulte Descrição geral do processo de atualização do SharePoint 2010 para o SharePoint 2013.

Revise os arquivos de log de atualização do conjunto de sites para verificar problemas, começando do topo para baixo. Verifique a seção de resumo próximo ao final do arquivo de log para ver uma contagem de problemas e o status de atualização atual (se não houver status, isto significa que o processo de atualização falhou e a atualização de site deve ser realizada novamente). Os arquivos de log do conjunto de site são armazenados no próprio conjunto de sites (na biblioteca de documentos _catalogs/Upgrade) e no sistema de arquivos. O arquivo de log do sistema de arquivos possui mais informações sobre você deseja detalhes sobre os problemas. A versão do sistema de arquivos do arquivo de log de atualização do site está localizada em %COMMONPROGRAMFILES%\Microsoft Shared\Web server extensions\15\LOGS. Os ficheiros de registo são nomeados no seguinte formato: SiteUpgrade- YYYYMMDD-HHMMSS-SSS.log, em que YYYYMMDD é a data e HHMMSS-SSS é a hora (horas em formato de relógio de 24 horas, minutos, segundos e milissegundos).

Ajuste seus planos e teste novamente

Repita o processo de teste até ter certeza que encontrou todos os problemas que podem ocorrer e que você sabe como lidar com eles. Seu objetivo é saber qual é seu plano se for 4:00 P.M. no domingo, você precisa voltar online na segunda-feira de manhã e não está indo bem. Há um ponto de retorno? Teste seu plano de fallback e garanta que funciona antes de começar sua atualização real.