---
sourceDocument: Yokohama Administração da Now Platform
sourceDocumentLink: https://servicenow-prod.fluidtopics.net/r/pt-BR/yokohama/platform-administration

 Release :

    - yokohama

ft:locale :

    - pt-BR

ft:publication_title :

    - Yokohama Administração da Now Platform

ft:clusterId :

    - platadm

bundleId :

    - platadm

workflow :

    - Platform


---

# Scripts de limpeza pós-clone

# Scripts de limpeza pós-clone {#ariaid-title1}

* Versão de lançamento: Yokohama
* 
* Atualizado 30 de jan. de 2025
* 
* ![](https://www.servicenow.com/docs/portal-asset/ico-clock) 3 min. de leitura

Os scripts de limpeza são executados automaticamente na instância de destino após a conclusão do processo de clonagem.

Use scripts de limpeza para modificar ou remover dados inválidos. Os scripts de limpeza são executados após a conclusão dos preservadores de dados e do clone.

Você pode adicionar novos scripts de pós-clonagem na instância de origem para executar qualquer ação que normalmente pode ser realizada por meio de inclusões de script ou regras de negócios. Para adicionar um script, navegue até Clone do sistemaClonar DefiniçãoLimpar scripts e clique em Novo .  
Nota:  
Os scripts de limpeza sempre serão executados em clones criados usando um perfil de clone. Isso é necessário, pois eles estão disponíveis em banda externa e garantem um estado íntegro pós-clone. Após a conclusão do clone, todos os scripts de limpeza são combinados como um trabalho agendado chamado Script de limpeza de clone: Execute scripts de limpeza sequencialmente e executar até a conclusão no escopo global. Os scripts de limpeza são ordenados com base no campo Pedido. Os scripts de limpeza devem ser definidos no Origem instância.
Você pode tornar os scripts pós-clone ativos ou inativos para controlar se esses scripts são executados ou não. Você também pode definir um número de pedido em cada script, o que permite definir a ordem em que os scripts ativos são executados, com números mais baixos tendo uma prioridade mais alta.   

Nota:  
Todos os scripts de limpeza são executados no escopo global, independentemente do escopo no qual você configurou o script de limpeza. Um exemplo de como executar um script com escopo é

* Crie uma inclusão de script no escopo desejado com a lógica de limpeza nele.
* Tenha uma configuração de acesso restrito do solicitante em vigor para permitir o acesso ao script com escopo. Certifique-se de estar no escopo da inclusão de script usada para criar o RCA.{#post-clone-cleanup-scripts__table_yfw_xyw_pbc__entry__2}

  | Campo | Descrição |
  |-|-|
  | Escopo de origem | Global |
  | Tipo de Origem | Escopo |
  | Status | Permitido |
  | Escopo de destino | O escopo do script inclui. |
  | Tipo de destino | Inclusão de script |
  | Meta | O script. |
  | Operação | Executar API |
  [ ]

  {#post-clone-cleanup-scripts__table_yfw_xyw_pbc}
* Chame a inclusão de script do script de limpeza de clone.
{#post-clone-cleanup-scripts__ul_f4n_4yw_pbc}  
Os scripts de limpeza pós-clone a seguir executam várias ações na instância de destino.{#post-clone-cleanup-scripts__table_hqz_gxs_gr__entry__2}

| Script | Descrição |
|-|-|
| Credenciais do MID Server inválidas após o clone | Executa uma inclusão de script chamada BadMIDCredentialAfterClone em uma instância clonada para detectar [Credenciais de usuário do MID Server inválidas](https://www.servicenow.com/docs/access?context=mid-post-clone-issue-resolution&version=yokohama&pubname=yokohama-servicenow-platform&ft:locale=en-US). Esta inclusão de script cria trabalhos agendados que Registram MID Servers no Para baixo estado para a tabela de ocorrência do MID Server \[ecc_agent_issue\] após um clone de instância. |
| Limpe a associação de nó de trabalho agendado | Redefine todos os trabalhos agendados que estavam ativos na instância de origem para Pronto estado. Este script também limpa o valor de ID do sistema e. Reivindicado por campos em todos os trabalhos agendados. |
| Configure contas de e-mail | Migrará as contas de e-mail que existiam na instância de origem para a instância de destino se elas não estiverem habilitadas lá. Este script também migra as propriedades de e-mail para a instância de destino. |
| Desabilitar e-mails | Desabilita o e-mail na instância de destino. Um preservador de dados padrão mantém outras configurações de e-mail da instância de destino. |
| Instale o plug-in desativado | Habilita o plug-in Separação de domínio para instâncias que usam este recurso. |
| Gere novamente todos os índices de texto | Reconstrói índices de texto na instância de destino após um clone. Os índices de texto não são clonados da instância de origem para a instância de destino. |
| Tabelas de backup de descarte de programação | Programa a exclusão dos dados contidos no banco de dados da instância de destino antes do clone. Esses dados originais são preservados por 24 horas após um clone para permitir que você reverta uma instância para o estado pré-clone. Se a instância de destino sofrer downgrade como parte do clone, os dados de backup não estarão disponíveis. |
[Tabela 1. Scripts de limpeza pós-clone]

{#post-clone-cleanup-scripts__table_hqz_gxs_gr}