Sophos Mobile: migrar do Administrador do dispositivo Android para o Android Enterprise

Este artigo ajuda a definir o percurso de migração e as verificações necessárias. Não constitui autorização para uma reposição de fábrica em produção. A Sophos considera o Administrador do dispositivo um modo de gestão obsoleto: no Sophos Mobile, só está disponível para o Android 9 ou anterior; dispositivos com Android 10 ou posterior não podem ser inscritos nesse modo. Isto não significa que todas as funções do Android Device Policy Manager tenham sido descontinuadas de forma geral, nem recomenda continuar a utilizar o Android 9. Não inscrever novos dispositivos no modo antigo. A migração descrita abaixo pressupõe que o ambiente Android Enterprise já está preparado e configurado.

Determinar primeiro a propriedade e o modo de destino

Antes de qualquer alteração, confirmar o modo de gestão efetivo, a identidade do dispositivo, a propriedade, a versão do Android, a associação do utilizador, as políticas, as aplicações, a conectividade e o último estado do dispositivo tanto no dispositivo como no tenant Sophos correto.

Preparar a nova inscrição antes da intervenção

Esta verificação é feita enquanto o dispositivo antigo ainda está sob gestão. Não desencadeia qualquer reposição nem desinscrição. Registar no relatório de migração os seguintes dados para o modo de destino escolhido:

Em Sophos Fusion > My Products > Mobile > Setup > Google setup > Android Enterprise, verificar o Android Enterprise mode existente, os detalhes da conta apresentados e o estado de Use managed Google domain device enrollment. Reutilizar o registo existente da organização, sem executar novamente Register account nem substituir a associação à Google. Se a associação estiver em falta ou não for clara, esclarecer primeiro a situação seguindo a secção Associar a organização à Google.
Ter preparada uma Android Enterprise device policy para o dispositivo empresarial e uma Android Enterprise work profile policy para o dispositivo pessoal. Anotar os nomes da política de destino e do respetivo pacote de tarefas. O pacote para cada tipo de dispositivo deve conter, no mínimo, Enroll e Assign policy, com essa mesma política. Uma política antiga do Administrador do dispositivo não serve de substituto.
Se for utilizado o portal de self-service, abrir em Setup > Self Service Portal a configuração efetivamente aplicada ao utilizador. Nas definições da plataforma Android, Enrollment package deve apontar para o pacote de tarefas preparado. Confirmar Owner, o Device group de destino, a prioridade dos grupos e a quota de dispositivos restante. Verificar uma configuração existente adequada, em vez de criar uma nova ou alterar Default indiscriminadamente. A preparação é descrita em Preparar a política, o pacote e a identidade do utilizador.
Verificar a aprovação de Sophos Mobile Control no Managed Google Play. Sem esta aprovação, a aplicação gerida não é atualizada automaticamente. Se a inscrição de dispositivos no domínio estiver ativada, os utilizadores previstos têm de existir no domínio Google gerido. Esta inscrição de dispositivos no domínio exige Mobile Control 9.8 ou posterior; nos perfis de trabalho, também têm de estar instaladas todas as atualizações disponíveis do sistema operativo e das aplicações. Numa tarefa iniciada pelo Sophos Mobile, o endereço de e-mail atribuído tem de corresponder exatamente ao identificador de início de sessão Google.
Escolher um método de inscrição permitido no modo atual da organização e preparar antecipadamente, com a equipa de TI responsável, as instruções para o utilizador descritas a seguir. Numa organização registada antes de 9 de abril de 2024 no modo de domínio Google gerido, sem a inscrição de dispositivos no domínio ativada, a inscrição pelo administrador não está disponível; nesse caso, preparar o percurso SSP permitido. Não ativar esta opção como um simples passo da migração. As alterações à associação da organização ou ao modo de inscrição exigem uma autorização própria.

Para um dispositivo empresarial com utilizador atribuído, o guia de Android Enterprise, na secção «Projeto-piloto do administrador» descreve o percurso suportado pelo assistente através de Devices > Add > Add device wizard, da seleção do utilizador, de Platform: Android e do pacote de inscrição preparado. Só executar este percurso após a reposição de fábrica ter sido autorizada separadamente e confirmada no dispositivo. Se for necessário utilizar o SSP, seguir o procedimento SSP aí descrito. Os métodos por código QR, zero-touch e sem utilizador são alternativas com preparação própria, não passos obrigatórios adicionais.

Para um dispositivo comprovadamente pessoal, disponibilizar antecipadamente ao utilizador a secção Configurar o perfil de trabalho no guia de Android BYOD. Esta orienta a seleção de Owner: Personal, a utilização do pacote de perfil de trabalho e a configuração do Mobile Control no dispositivo. A nova inscrição só começa depois de confirmada a desinscrição antiga e de eliminada, em seguida, a entrada antiga correta. Também é necessário verificar a privacidade e o consentimento conforme a secção «Antes da inscrição»; o procedimento BYOD não se aplica a dispositivos empresariais com perfil de trabalho.

Se faltar algum destes pré-requisitos, parar antes de qualquer um dos dois percursos de migração. Antes de uma intervenção em produção, verificar o percurso escolhido num dispositivo de teste representativo e autorizado. Contas preparadas, um pacote guardado ou opções visíveis no portal não comprovam uma inscrição bem-sucedida do dispositivo. Após a inscrição, verificar o modo de gestão, a associação do utilizador, o estado das tarefas e a política efetivamente aplicada no Sophos Mobile e no dispositivo.

Percursos de migração documentados

Não misturar os dois percursos documentados:

Empresarial, anteriormente no modo Administrador do dispositivo → Android Enterprise: gestão integral do dispositivo. Em Gerät anzeigen > Aktionen > Zurücksetzen, repõe-se o dispositivo para as definições de fábrica; depois, inscrevê-lo novamente. A Sophos indica como opções o assistente «Gerät hinzufügen», o portal de self-service Sophos Fusion e a inscrição por código QR ou zero-touch. Executar esta intervenção apenas após autorização específica.
Pessoal, anteriormente no modo Administrador do dispositivo → Android Enterprise: gestão do perfil de trabalho. Em Gerät anzeigen > Aktionen > Deregistrieren e depois Aktionen > Löschen; só então inscrever o novo perfil de trabalho. A Sophos indica o assistente «Gerät hinzufügen» ou o portal de self-service Sophos Fusion. Esta intervenção também exige autorização específica. A reposição de fábrica não é um passo padrão para BYOD.

Estas designações provêm da ajuda da Sophos em alemão de 22 de setembro de 2026; numa consola configurada em inglês, surgem Show device > Actions > Wipe, Unenroll e Delete. Confirmar previamente os menus concretos, as permissões e os métodos de inscrição disponíveis no tenant de destino. Um Wipe do Sophos Fusion, um Zurücksetzen do Mobile Admin e a remoção de um perfil de trabalho já configurado não são designações ou passos de migração equivalentes. Os dispositivos empresariais existentes com perfil de trabalho e outros modos exigem uma decisão separada, em vez de uma classificação automática nesta divisão em dois percursos.

Parar antes de qualquer ação destrutiva

Dispositivo empresarial: Obter autorização por escrito para a reposição de fábrica deste dispositivo específico; verificar os dados locais, contas empresariais, aplicações, autenticação, uma cópia de segurança utilizável e o restauro. Uma reposição programada destrói os dados locais sem cópia de segurança. Devem estar disponíveis um método de nova inscrição no Android Enterprise efetivamente funcional, acesso por Wi-Fi ou rede móvel, as credenciais necessárias e as permissões. Verificar antecipadamente as contas Google e os bloqueios de reposição de acordo com o dispositivo e o método de reposição. A Sophos documenta a Factory Reset Protection para dispositivos Android Enterprise totalmente geridos; isso não implica que a mesma configuração FRP já controlasse a reposição no modo Administrador do dispositivo antigo. Não prometer contornar o FRP.
Dispositivo pessoal: Esclarecer com o utilizador o consentimento, a distinção entre dados pessoais e empresariais e o efeito da desinscrição no modo antigo. A desinscrição do modo antigo desativa o administrador do dispositivo Sophos Mobile Control, remove as credenciais de acesso ao servidor e os dados recebidos e repõe o Sophos Intercept X for Mobile. Primeiro confirmar a desinscrição e só depois eliminar a entrada correspondente; uma tarefa pendente e uma entrada que desapareceu da consola não comprovam que a gestão foi removida do dispositivo. A remoção de um perfil de trabalho configurado posteriormente provoca a perda das suas aplicações e dos seus dados locais, não a recuperação do perfil antigo. Não garantir a preservação dos dados pessoais sem verificar o dispositivo.
Dispositivo offline, com estado desconhecido ou bloqueado: Não considerar o processo concluído nem desencadear uma segunda eliminação ou reposição por suposição. Esclarecer com o utilizador e o suporte Sophos/do dispositivo o estado real do equipamento, a entrega da tarefa e o percurso de recuperação autorizado. Uma tarefa enviada pela cloud não comprova a sua execução.

Antes da intervenção, se existirem Restrictions, registar o estado efetivo da encriptação do dispositivo e do cartão SD, bem como um método de cópia de segurança e restauro permitido e comprovadamente utilizável. Em alguns dispositivos antigos, a encriptação solicitada do cartão SD pode ter sido interrompida; a atribuição não comprova o estado. Segundo a fonte antiga, desativar Allow backup desativa as cópias de segurança da Google, não todos os métodos alternativos. Os bloqueios de USB/MTP podem impedir o método de transferência de ficheiros necessário. Não aliviar bloqueios por suposição. Allow factory reset diz respeito à reposição pelo utilizador; não permite concluir que o Wipe da consola, autorizado separadamente, esteja autorizado ou possa ser executado.

Usar a política antiga apenas como inventário, não como modelo para Android Enterprise

A política de dispositivo Android destina-se ao modo Administrador do dispositivo antigo. Android Enterprise full device e Android Enterprise work profile têm famílias de políticas próprias. Antes de autorizar a migração, criar uma matriz documentada da origem e do destino para todas as 14 subconfigurações antigas; registar por linha o modo de destino, a nova definição suportada ou a ausência explícita de substituto, o sistema operativo/OEM/licença, os testes, os efeitos e o percurso de recuperação:

Os seguintes domínios de verificação devem constar desta matriz. Registar os valores existentes, não criar novas configurações do Administrador do dispositivo. A ausência de um substituto deve ficar visível como decisão pendente; opções de destino com nomes semelhantes não comprovam o mesmo efeito.

Ligações e certificados

Para cada configuração APN existente, inventariar também estes campos:

User-friendly name, o nome adicional apresentado no dispositivo; as duas entradas Server separadamente como servidor HTTP para tráfego web e gateway WAP, mais o Port do servidor web.
User name e a dependência de User password, apenas através de uma referência de identidade com acesso restrito e uma referência segura ao segredo; MMSC (Multimedia Messaging Service Center), MMS proxy server e MMS proxy port separadamente para o percurso MMS.
Authentication type para a autenticação PPP, APN type para os tipos de ligação de dados, Bearer para a tecnologia de acesso rádio e Protocol e Roaming protocol para os protocolos da operadora na rede de origem e em roaming.

Todos os campos antigos, exceto APN, são opcionais; assinalar expressamente os não utilizados como não configurados, sem preencher valores supostos. Em APN type, * ou um campo vazio significa todos os tipos de dados. Só uma configuração APN pode utilizar Use as default APN. Estes significados explicam o estado antigo, não a criação de um novo APN no modo antigo. Associar cada valor utilizado a um substituto de destino suportado e verificado separadamente, ou indicar expressamente a sua ausência; confirmar separadamente a aceitação da operadora para o SIM/a subscrição de destino. A ligação independente de recuperação continua a ser necessária.

Para APN, registar o ponto de acesso anterior, a operadora e o SIM ou a subscrição utilizados. Confirmar com a operadora se aceita esse APN para a subscrição prevista. Registar e conferir também os valores existentes de Mobile Country Code (MCC) e Mobile Network Code (MNC): estes valores restringem a utilização do APN antigo à operadora indicada. Uma opção Use as default APN incorreta pode interromper os dados móveis. Por isso, guardar os valores da operadora e garantir uma ligação independente antes da intervenção, em vez de alterar o APN predefinido como experiência.

Para Wi-Fi e VPN, registar os certificados WLAN/EAP antigos, o SSID e os tipos de VPN e verificar separadamente o acesso de destino; WEP não é um padrão seguro para o destino. Testar também o contacto com o sistema de gestão através de uma ligação independente.

Para cada configuração Wi-Fi existente, incluir na matriz os seguintes valores antigos:

SSID e o Security type efetivo: None, WEP, WPA/WPA2 PSK, EAP/PEAP, EAP/TLS ou EAP/TTLS. None e WEP não são recomendações para o destino. A descrição antiga exclui a atribuição da política com WEP a dispositivos com Android 12 ou posterior; esta condição histórica não permite inscrever dispositivos no modo de gestão antigo.
Phase 2 authorization apenas para EAP/PEAP e EAP/TTLS: registar a opção existente, None, PAP, CHAP, MSCHAP ou MSCHAPv2. Não acrescentar um valor antigo deste campo para EAP/TLS.
Para EAP, identificar separadamente Identity e Anonymous identity. Esta última é o pseudónimo enviado sem encriptação na fase 1 da negociação EAP. Para Password, documentar a dependência da palavra-passe Wi-Fi existente e o método seguro de a guardar ou disponibilizar uma substituição, não a própria palavra-passe.
Registar Proxy host como o nome ou endereço IP do proxy desta ligação Wi-Fi e Proxy port separadamente. Global HTTP proxy não é um substituto equivalente comprovado para este proxy específico da ligação.

Para cada configuração VPN existente, registar Connection name (nome visível no dispositivo), Server (nome de host ou endereço IP do gateway) e o Connection type efetivo. A descrição antiga distingue as seguintes dependências:

L2TP/IPsec (PSK): documentar a associação ao utilizador em User e a dependência da palavra-passe em Password separadamente da chave de autenticação pré-partilhada no campo L2TP/IPsec (PSK).
L2TP/IPsec (certificate): incluir os certificados Client certificate e Root certificate selecionados, bem como User e a dependência de Password. Neste percurso antigo, a seleção dos certificados não substitui a dependência do utilizador e da palavra-passe.
Cisco AnyConnect: inventariar separadamente o XML do perfil VPN e o XML do perfil NVM (Network Visibility Module) existentes, cada um com o responsável, a versão e uma referência de armazenamento seguro; assinalar como ausente um perfil que não exista. Não concluir daí que haja importação automática de XML ou a mesma visibilidade da rede no destino.

Registar as associações de identidade apenas no relatório de migração com acesso protegido. Para palavras-passe, PSKs e chaves privadas, incluir exclusivamente referências para armazenamento ou disponibilização seguros; não incluir segredos nem identidades reais sensíveis em comprovativos públicos. Associar cada valor Wi-Fi antigo utilizado e cada dependência VPN a um substituto de destino verificado separadamente, ou documentar expressamente a sua ausência. Para VPN, verificar o suporte da aplicação, do sistema operativo, do gateway e da autenticação, sem o deduzir do tipo de ligação antigo. Verificar o significado dos campos de destino, os papéis dos certificados e a configuração da aplicação VPN no artigo Conectividade Android referido; as verificações de certificados que se seguem continuam a ser necessárias.

Registar separadamente Client certificate, Root certificate e SCEP. Os certificados de cliente e as âncoras de confiança antigos dependem da política; SCEP exige a CA do servidor SCEP como configuração de raiz. Comprovar de novo a identidade de destino, a emissão/renovação, a confiança na CA e o início de sessão em Wi-Fi/VPN; nunca desativar a verificação de certificados para resolver problemas.

Na política de dispositivo Android antiga, o certificado de raiz configurado em Root certificate era instalado no dispositivo com a atribuição da política. Para o inventário antigo, documentar o ficheiro de certificado X.509 configurado e a respetiva codificação PEM ou DER. Cada certificado de raiz adicional exigia uma configuração Root certificate própria; por isso, incluir individualmente todas as configurações de raiz existentes na matriz de origem e destino. A atribuição antiga, por si só, não comprova o estado efetivo dos certificados nesse dispositivo específico nem a sua transferência automática para o Android Enterprise.

Para cada configuração Root certificate existente, registar também a política antiga e as outras configurações da mesma política que utilizam efetivamente esse certificado de raiz, incluindo a confiança no servidor WLAN/EAP, se existir. Distinguir a confiança no servidor da identidade do cliente e da CA do servidor SCEP. Associar cada dependência à política e ao modo de destino escolhidos, ou documentar a ausência de um substituto suportado. No projeto-piloto de destino autorizado, comprovar a identidade esperada do servidor, a confiança na CA e a ligação/autenticação; não pressupor uma transferência automática.

Apenas para interpretar os campos SCEP antigos: URL podia estar associado através de %_SCEPPROXYURL_% ao URL do servidor no separador SCEP da página Sophos setup; Challenge podia referir-se através de %_CACHALLENGE_% ao URL de desafio aí configurado. Depois de substituir os marcadores pelos dados reais, Subject tem de ser um nome X.500 válido. As opções SAN antigas significam: RFC 822 name = um endereço de correio eletrónico válido; DNS name = o nome DNS do servidor da CA; Uniform resource identifier = o URL totalmente qualificado do servidor da CA. Registar os campos configurados e não configurados e a identidade efetivamente resolvida no inventário com acesso restrito; para os segredos, usar apenas referências seguras de custódia/aprovisionamento. Isto não é uma instrução para voltar a aprovisionar o modo antigo nem reutilizar segredos de desafio. Não deduzir daqui os significados SAN do destino nem copiar estes antigos significados relativos à CA para uma nova identidade de cliente.

Para cada configuração SCEP existente, registar as seguintes dependências com a equipa responsável por PKI/MDM, sem alterar as entradas antigas para as identificar:

Obtenção: Documentar os endpoints do servidor e do desafio, as respetivas dependências e, se aplicável, a associação de variáveis resolvida através da configuração. Não incluir palavras-passe de desafio nem outros segredos no relatório ou no artigo.
Identidade e seleção: Registar o alias antigo ou a referência de seleção, a associação ao utilizador/dispositivo, a expressão Subject e o nome resolvido, bem como os tipos/valores SAN configurados e o AD-UPN. Assinalar expressamente como ausentes os campos não configurados. No projeto-piloto, comparar com a identidade exigida pelo serviço e com a seleção efetiva do certificado de destino; deixar pendentes as associações não suportadas.
Associação de confiança: Identificar inequivocamente o certificado de raiz efetivamente selecionado na política antiga atual, recorrendo à impressão digital se necessário. Verificar a confiança no servidor SCEP separadamente da confiança no certificado de cliente emitido e da confiança no servidor do serviço. Não remover uma âncora de confiança ainda necessária antes de observar e validar o funcionamento no destino.
Chave e finalidade: Registar o valor existente de Key size, os requisitos de compatibilidade da CA e as seleções/finalidades distintas para assinatura digital e encriptação. Esclarecer os requisitos de destino com a equipa de PKI e o serviço que utiliza o certificado; verificar no projeto-piloto o certificado emitido e a utilização necessária. Não ativar indiscriminadamente ambas as finalidades nem transferir automaticamente o valor antigo da chave.

Verificar de forma independente o método suportado de obtenção no destino, os papéis dos certificados e as finalidades de utilização com base na conectividade Android e no runbook de certificados/SCEP aí referido. Estas instruções de destino não substituem o inventário nem a comprovação do efeito real no destino.

Identificar também inequivocamente o Client certificate existente através de uma referência segura ao ficheiro real PKCS #12 (.pfx) e ao Certificate name lido desse ficheiro. No inventário de certificados, registar quais as configurações da mesma política antiga que o selecionam. Outras políticas antigas exigiam carregamentos separados; é uma dependência antiga, não uma instrução para novo aprovisionamento no modo antigo. Não publicar nem exportar uma chave privada nem presumir a transferência automática para o destino.

Aplicações, permissões e palavra-passe das aplicações

Filtro de aplicações de Restrictions: Registar o valor de Filter type separadamente de App Control: documentar Allowed apps ou Forbidden apps, o grupo de aplicações associado e os seus membros, bem como as aplicações efetivamente abrangidas. Segundo a fonte antiga, as aplicações instaladas pelo Sophos Mobile estão excluídas deste filtro; por isso, o bloqueio de início de App Control não é um substituto comprovado. Ainda segundo a fonte antiga, o bloqueio do navegador nativo não abrange navegadores de terceiros. Comprovar separadamente o âmbito de destino e o efeito real para o objetivo de proteção das aplicações/do navegador.
App Control: Documentar o grupo de aplicações antigo selecionado e os seus membros. Este bloqueio impede o início das aplicações, incluindo aplicações do fabricante que não podem ser desinstaladas; não as remove. Para cada aplicação bloqueada, registar o modo de destino e a nova associação ao grupo. Isto não implica uma transferência automática para a Play Store nem o bloqueio de aplicações pessoais no destino.
App permissions: Para cada aplicação antiga, anotar a identidade exata e cada permissão em tempo de execução configurada, com o respetivo valor: Selectable significa que o utilizador pode alterá-la, Granted concede-a e Denied recusa-a. Para cada aplicação e permissão, indicar o modo de destino, a aplicação de destino, o efeito pretendido e as alterações permitidas ao utilizador, ou assinalar a ausência de substituto. Num perfil de trabalho a partir do Android 12, as permissões de localização, câmara, microfone, sensores corporais e atividade física podem ser recusadas em nome do utilizador, mas não concedidas. Esta limitação tem de ser considerada na decisão sobre o destino.
App Protection: Registar o grupo de aplicações antigo e os seus membros, Password complexity, Grace period in minutes e Allow fingerprint authentication. Todas as aplicações protegidas utilizam a mesma palavra-passe; o utilizador define-a ao abrir uma delas pela primeira vez. Durante o período configurado após fechar uma aplicação protegida, é possível abrir aplicações protegidas sem novo pedido de palavra-passe. A impressão digital é uma alternativa possível à palavra-passe das aplicações. A proteção antiga pode ser contornada através de outras aplicações/funções do sistema ou de várias janelas; não constitui, por isso, proteção empresarial equivalente. Comparar separadamente as definições suportadas para a gestão integral do dispositivo e para o perfil de trabalho.

Conta de correio e instruções para o utilizador

Para Email account, verificar separadamente a aplicação de correio, a cloud Exchange, o início de sessão OAuth suportado e o fluxo de correio real. Um campo de palavra-passe antigo ou Allow all certificates não é um método de recurso para Exchange Online. Além do servidor, dos certificados e da associação do utilizador, incluir no relatório os seguintes valores antigos:

Nome da conta, percurso, transporte e conteúdos

Registar Account name e o Server name real; distinguir um endpoint Exchange direto do URL de um EAS proxy. outlook.office365.com aplica-se à cloud mundial do Microsoft 365, não universalmente às outras clouds Microsoft. Observar o percurso de correio efetivamente aprovado, sem o substituir sem verificação.
Registar os valores resolvidos de Email address e Sender independentemente de User; %_EMAILADDRESS_% é substituído pelo endereço real em ambos os campos. Os dados de identidade permanecem no relatório com acesso restrito.
Para Password, documentar apenas a referência segura de custódia/aprovisionamento e a dependência existente: um campo antigo vazio exigia que o utilizador introduzisse a palavra-passe no dispositivo. Não é uma recomendação de recurso a palavra-passe em vez de OAuth suportado.
Registar os estados existentes de SSL/TLS e Allow all certificates, o Client certificate selecionado e Synchronize content types. A opção antiga de contornar a validação não é um valor de destino seguro. Associar cada campo de correio utilizado a um efeito de destino suportado ou indicar expressamente a ausência de substituto. No piloto autorizado, verificar a identidade real da conta/remetente e do servidor, a confiança TLS e os conteúdos selecionados para sincronização com dados inofensivos; não recorrer a palavra-passe nem contornar a validação de certificados.

Identidade na conta antiga e no destino

Registar primeiro o valor antigo de User e o nome de início de sessão efetivamente obtido a partir dele. Para os marcadores de posição %_USERNAME_% e %_EMAILADDRESS_%, os campos Exchange Login e Email Address do utilizador atribuído têm de estar preenchidos no Sophos Fusion. A fonte antiga indica normalmente %_EMAILADDRESS_% para Exchange Online e %_USERNAME_% para Exchange Server. Ainda assim, o endereço de e-mail e o identificador efetivo de início de sessão não são automaticamente iguais.

Incluir também Domain no relatório. Segundo a descrição antiga, o campo fica vazio para Exchange Online e contém o domínio da conta do utilizador para Exchange Server. Estes dados explicam a identidade utilizada pela conta antiga. Antes da autorização, comparar os valores antigos resolvidos e a associação do utilizador com a identidade de destino escolhida. Verificar como o nome de utilizador e o domínio são representados no destino; o método de início de sessão suportado é verificado separadamente, como descrito acima.

Configuração no dispositivo antigo

Documentar o OEM/API e se a configuração da conta era automática ou manual. A descrição antiga refere LG GATE, Samsung Knox e Sony Enterprise API para a configuração automática. Nos outros dispositivos, o utilizador tinha de configurar a aplicação de correio com base nos detalhes de configuração apresentados em Sophos Mobile Control. Preparar instruções próprias para o utilizador e um projeto-piloto da aplicação de destino, em vez de repetir a configuração antiga.

Sincronização e conta predefinida

Registar Synchronization interval como intervalo entre sincronizações, separadamente de Synchronization period, que indica a antiguidade das mensagens abrangidas. Documentar o mecanismo de destino ou a ausência de substituto para a frequência de consulta. Incluir também Default account e esclarecer como a aplicação de destino escolhe a conta predefinida ou se não existe uma definição gerida para esse efeito.

Fluxo de dados, formato e tamanho das mensagens

Para Allow forwarding emails e Allow use of HTML format, registar os valores existentes e as decisões anteriores relativas às necessidades empresariais e à proteção de dados. Para ambas as definições, indicar se a aplicação de destino ou o Exchange consegue aplicá-las. Caso contrário, assinalar expressamente a ausência de substituto.

Registar literalmente o valor de Maximum attachment size in MB. Apesar do nome do campo, a Sophos descreve-o como o tamanho máximo de uma mensagem de e-mail individual, não expressamente apenas de um anexo. Verificar separadamente o efeito relevante para a operação e o limite imposto pela aplicação de destino ou pelo Exchange.

Caso particular Sony nos dispositivos antigos

A fonte alemã refere Enterprise API Level 6.x ou anterior, e a inglesa Level 6 ou anterior. Nos dispositivos abrangidos, os dados da conta Exchange têm de corresponder ao utilizador atribuído. O Mobile Control não consegue transmitir a ActiveSync-ID nesses dispositivos. No primeiro contacto com o proxy EAS, este procura, por isso, um dispositivo com ActiveSync-ID desconhecida e uma associação de utilizador correspondente. Se o encontrar, associa a ID enviada pelo cliente de correio e encaminha o pedido; caso contrário, rejeita-o. Confirmar a versão da API, o utilizador atribuído e a identidade efetiva do cliente antes de autorizar a conta antiga. Observar o percurso de correio autorizado existente, sem repor identidades nem contornar controlos de acesso. Comprovar separadamente o percurso de destino; não transferir esta condição antiga para o Gmail do Android Enterprise.

Quiosque e saída autorizada

Para Kiosk mode, registar o valor existente de Select source (Custom, App list ou No app), a App ID exata, a instalação efetiva, o estado da atribuição e o estado do dispositivo. Para App list, documentar a entrada da aplicação Android selecionada, já adicionada ao Sophos Mobile, e comparar a identidade do pacote resolvida a partir dessa entrada com App ID e com a aplicação efetivamente instalada, antes de a associar ao destino. Se faltar a aplicação de quiosque configurada no momento da atribuição da política antiga, a tarefa de atribuição da política permanece Incomplete / Unvollständig até a aplicação ser instalada. Perante esse estado antigo, confirmar primeiro a identidade e a instalação; uma reposição não é uma forma de resolver um problema por suposição. No app, pelo contrário, significa que as restrições são transferidas, mas nenhuma aplicação é iniciada. Não confundir isto com um pacote em falta nem com uma opção Enterprise chamada None.

Se as funções do dispositivo não estiverem desativadas, o utilizador pode sair da aplicação de quiosque antiga e utilizar o dispositivo normalmente; a seleção da aplicação, por si só, não comprova que a saída esteja bloqueada. Documentar, em particular, os estados existentes de Allow Home button e Allow task manager, bem como o acesso administrativo físico ou alternativo autorizado. Verificar a aplicação de quiosque, a possibilidade de a iniciar e de sair antes da reposição e comprovar estes aspetos separadamente para o modo de destino.

Segundo a fonte antiga, em Sony Enterprise API Level 9 ou posterior, basta desativar uma das opções Allow volume up, Allow volume down ou Allow volume mute para desativar todos os botões de volume. Registar o modelo afetado, o nível da API e o estado antigo. No projeto-piloto de destino autorizado, verificar os controlos de som e de botões suportados para esse modelo e para o modo de gestão escolhido. Testar no dispositivo o som e os botões necessários, em vez de pressupor o efeito antigo.

Knox Premium, proteção do arranque e aplicações de administrador

Registar o valor existente de Allow firmware auto update options, o responsável e o suporte do dispositivo/licença. A opção antiga faz o dispositivo procurar automaticamente atualizações de firmware; o utilizador não pode alterar este comportamento nas definições do dispositivo. Não significa que todas as atualizações sejam instaladas automaticamente. Documentar separadamente o substituto de destino suportado ou a sua ausência e observar o comportamento real das atualizações no piloto autorizado, sem voltar a ativar opções antigas.

As Knox Premium restrictions antigas atuam no dispositivo Samsung Knox, não no contentor Knox. A aplicação das restrições exige uma licença Samsung Knox Premium registada no Sophos Mobile. Verificar separadamente o tipo de dispositivo, o registo da licença e o efeito real no dispositivo. Para o modo Enterprise de destino escolhido, esclarecer especificamente a licença necessária e o efeito suportado no dispositivo; o registo da licença antiga não comprova a sua transferência.

Registar o estado existente de Enable ODE Trusted Boot verification. Segundo a descrição antiga, no arranque, a partição de dados só é desencriptada se o binário e o kernel forem oficiais. Esclarecer o acesso aos dados e o percurso de recuperação autorizado antes de reiniciar ou repor; não desativar a verificação como atalho de migração ou recuperação.

Registar separadamente Prevent installation of another administrator app e Prevent activation of another administration app. A primeira opção antiga impede a instalação de aplicações com direitos de administrador do dispositivo, exceto as instaladas pelo Sophos Mobile; a segunda impede a ativação desses direitos. Verificar antecipadamente o efeito real nas aplicações necessárias e no método de inscrição previsto, sem aliviar os bloqueios indiscriminadamente.

Se existir Allow Common Criteria mode, registar também as seis condições antigas:

encriptação do dispositivo ativada;
encriptação rápida desativada;
encriptação do armazenamento externo ativada;
limite de tentativas falhadas até à eliminação do dispositivo definido;
revogação de certificados ativada;
histórico de palavras-passe desativado.

Sem estas condições, o CC Mode não é aplicado, segundo a fonte antiga. São dependências de origem, não uma instrução para ativar novamente opções antigas nem para enfraquecer a proteção por palavra-passe no destino. Não testar a eliminação por tentativas falhadas em dispositivos de produção. Verificar separadamente, no projeto-piloto autorizado, o suporte atual, o substituto no destino e a recuperação; a descrição antiga não comprova uma certificação atual.

Bloqueio do ecrã e restrições

Para o bloqueio do ecrã existente em Password policies, registar o valor de Password type e o seu significado antigo: Pattern, PIN or password exige um bloqueio do ecrã sem restrições adicionais; Simple password exige uma palavra-passe com pelo menos uma letra, permitindo algarismos; PIN or password permite estes dois tipos de bloqueio. Alphanumeric password e Complex password exigem uma palavra-passe com letras e algarismos. Apenas Complex password acrescenta os seis valores mínimos de composição indicados abaixo. Isto descreve a política de origem, não a configuração de uma nova política antiga nem um comportamento idêntico no Android Enterprise.

Para Simple password, PIN or password, Alphanumeric password e Complex password, registar também os valores existentes de cada campo: Minimum password length (número total de caracteres), Maximum idle time before password prompt (período de inatividade configurado; o dispositivo pode impor um período mais curto), Maximum password age in days (intervalo de alteração; intervalo antigo de 0–730 dias, sendo que 0 não exige alteração), Maximum sign-in attempts (tentativas falhadas até à eliminação do dispositivo no modo antigo) e Password history (número de palavras-passe anteriores guardadas que não podem ser reutilizadas). Não inventar valores para campos ausentes no tipo escolhido. Antes da autorização, documentar, para o tipo e para cada campo, o efeito suportado no destino ou a sua ausência explícita, o sistema operativo/OEM e o bloqueio do dispositivo ou do perfil de trabalho escolhido; não transferir automaticamente os valores antigos.

Para um Complex password existente em Password policies, registar individualmente os seis valores mínimos: letras, minúsculas, maiúsculas, caracteres não alfabéticos, algarismos e caracteres especiais. Caracteres não alfabéticos e caracteres especiais são valores antigos distintos, não uma única exigência combinada. Comparar cada valor com a gestão integral do dispositivo, o bloqueio do dispositivo ou o bloqueio do perfil de trabalho escolhido e com as indicações de sistema operativo/OEM. Para cada mínimo, documentar o substituto suportado ou a sua ausência, bem como a aplicação da exigência observada de forma não destrutiva.

Registar também Allow fingerprint authentication e Allow iris authentication, com a seleção existente. Os métodos de desbloqueio antigos só se aplicam a dispositivos que os suportem. Verificar separadamente, por sistema operativo e OEM, a disponibilidade e os métodos de desbloqueio efetivamente permitidos no modo de destino. A impressão digital de App Protection ou Weak biometric recognition não comprova um substituto idêntico.

Para Password policies e Restrictions, verificar a recuperação, as cópias de segurança e o efeito de cada bloqueio e restrição relevante segundo o sistema operativo e o modo; não pressupor efeitos iguais em dispositivos pessoais e empresariais. Um limite de tentativas falhadas pode apagar o dispositivo; não o testar em dispositivos de produção.

Para as Restrictions efetivamente utilizadas, preencher a matriz até ao nível de cada definição relevante: valor antigo, efeito observado no dispositivo, objetivo de proteção empresarial, sistema operativo/OEM e dependências entre opções principais e subordinadas, substituto suportado no destino ou divergência explícita com autorização. Incluir, em particular, a partilha e gravação de dados, a utilização de ligações sem fios/partilha e periféricos, a conectividade/comunicações de emergência/roaming, as atualizações/recuperação, as contas, incluindo a remoção de contas Google, bem como as fontes de instalação de aplicações e a desinstalação. Excluir justificadamente o que não é utilizado ou não é aplicável. Não avaliar bloqueios apenas pelo nome: segundo a fonte antiga, a proibição de vídeo permite fotografias e streaming; a área de transferência partilhada exige Allow clipboard. Se for utilizado Bluetooth, verificar também os emparelhamentos e perfis existentes; para tethering ou a câmara no ecrã de bloqueio, verificar igualmente a opção principal. Registar também os valores subordinados relevantes de SD/USB juntamente com as respetivas opções principais. Um bloqueio antigo de Beam não controla o Quick Share. No projeto-piloto de destino autorizado, comprovar as funções necessárias e os fluxos de dados proibidos com dados de teste inofensivos; se faltar um substituto ou o efeito for diferente, parar a implementação até existir uma decisão documentada.

As subpáginas históricas descrevem as definições de origem, algumas de 2022–2023, e não o suporte atual de protocolos antigos ou funções OEM nos dispositivos de destino. Os domínios de verificação mostram as dependências a esclarecer antes da migração. Antes de recomendar políticas concretas, verificar as duas políticas de destino completas e o próprio tenant. Os temas de KB separados sobre políticas para dispositivos totalmente geridos, políticas para perfis de trabalho, conectividade Android, BYOD e FRP não substituem a autorização da migração. O artigo sobre a migração do Exchange também aborda a autenticação de correio.

Projeto-piloto, suspensão e recuperação

Só depois de esclarecer a propriedade, o tenant e a licença, e de definir um percurso de recuperação autorizado, realizar um projeto-piloto em dispositivos representativos e dispensáveis para cada modo. Guardar previamente os dados dos dispositivos e as políticas anteriores; preparar separadamente a nova política e o método de inscrição. No projeto-piloto, confirmar a execução da tarefa no dispositivo, verificar o novo modo de gestão e a atribuição efetiva e observar as aplicações, o início de sessão nas contas/o fluxo de correio, o quiosque (se existir), o Wi-Fi/VPN, a emissão e renovação de certificados e os dados pessoais após a transição BYOD. Só decidir sobre outros dispositivos depois de demonstrado o efeito.

Para os valores antigos registados, documentar no projeto-piloto resultados concretos esperados e observados:

Rede móvel

Verificar o acesso a dados móveis com o SIM previsto e na operadora prevista, separadamente do acesso independente de recuperação/gestão testado anteriormente. Depois, verificar o contacto com o sistema de gestão. Se não houver acesso a dados, não migrar mais dispositivos; utilizar o acesso independente autorizado antecipadamente e o percurso de escalamento definido.

Aplicações e permissões

Verificar primeiro o comportamento ao iniciar cada aplicação anteriormente bloqueada, bem como as aplicações operacionais e de emergência necessárias. Em seguida, verificar com dados de teste cada aplicação de destino e as suas permissões em tempo de execução. Comparar o estado esperado com a função real da aplicação quando a permissão é concedida ou recusada. Verificar também se o utilizador pode alterar a permissão conforme previsto ou se a alteração é impedida. Ter em conta as limitações do Android 12 no perfil de trabalho.

Antes de uma alteração, registar as definições e a atribuição. Utilizar apenas o método de atualização ou substituição suportado e previamente testado. Se for necessário reverter uma alteração de política, confirmar a sincronização e repetir as mesmas verificações de permissões.

Não conceder permissões indiscriminadamente apenas para que uma aplicação funcione. Uma revogação posterior não recupera dados já divulgados.

Palavra-passe das aplicações e bloqueio do ecrã

No destino, verificar o pedido de palavra-passe esperado, os acessos alternativos permitidos, o período sem novo pedido e a autenticação. No bloqueio do dispositivo ou do perfil de trabalho, verificar de forma não destrutiva cada requisito mínimo e os métodos biométricos disponíveis, sem atingir o limite de tentativas falhadas.

Para o bloqueio de destino escolhido, comparar os tipos de bloqueio permitidos e o comprimento total com a decisão documentada e observar o período efetivo de inatividade até ao pedido de palavra-passe, incluindo limites mais curtos impostos pelo dispositivo. Verificar o comportamento de alteração e reutilização, quando suportado, numa conta/dispositivo de teste autorizado ou através de comprovativos de estado suportados; registar expressamente a ausência de suporte. Em dispositivos de produção, não acelerar as alterações de palavra-passe, não enfraquecer a proteção nem esgotar as tentativas falhadas. Manter o percurso de recuperação preparado e parar a implementação perante divergências.

Correio

Numa conta de teste autorizada, verificar com conteúdos inofensivos o tempo de entrega, a conta predefinida ao redigir, o reencaminhamento permitido/proibido, o comportamento do HTML e os tamanhos relevantes de mensagens. Não utilizar dados confidenciais reais. Comparar o resultado com a decisão documentada para o destino, mesmo que uma definição anteriormente gerida não exista no destino.

Parar perante divergências

Se houver uma divergência, parar a implementação. Uma configuração de destino visível, por si só, não basta; esclarecer primeiro a causa, o substituto suportado e o percurso de recuperação seguro.

Se não houver conectividade, se o estado dos dados for incerto, se o dispositivo ou o modo estiver errado, ou se o início de sessão falhar ou surgir um bloqueio de reposição, parar e escalar. Antes da intervenção, identificar o suporte responsável, uma ligação independente funcional e um método de voltar a disponibilizar o dispositivo. O rollback não desfaz uma reposição de fábrica nem recupera um perfil de trabalho eliminado: o restauro só é possível a partir de cópias de segurança comprovadamente utilizáveis e através de uma nova inscrição autorizada; não está demonstrada a entrega remota imediata nem um efeito idêntico das políticas. Sem testes no tenant e no dispositivo, não apresentar isto como instruções de migração para produção nem garantir o sucesso.