Perguntas frequentes sobre os Arquivos do Azure e a Sincronização de Arquivos do Azure

O Arquivos do Azure oferece compartilhamentos de arquivos totalmente gerenciados na nuvem, acessados por meio do protocolo padrão da indústria Server Message Block (SMB) e do protocolo Network File System (NFS). Você pode montar compartilhamentos de arquivos do Azure simultaneamente em implantações locais ou na nuvem do Windows, do Linux e do macOS. Usando o Sincronização de Arquivos do Azure, você pode armazenar em cache compartilhamentos de arquivos do Azure em máquinas Windows Server para acesso rápido a dados próximos ao local onde são usados.

FAQ sobre Sincronização de Arquivos do Azure

  • É possível ter servidores conectados e não conectados ao domínio no mesmo grupo de sincronização?
    Sim. Um grupo de sincronização pode conter pontos de extremidade de servidor com diferentes associações do Active Directory, mesmo que eles não estejam conectados ao domínio. Embora essa configuração funcione tecnicamente, não a recomendamos como uma configuração típica, pois as ACLs (listas de controle de acesso) que são definidas para arquivos e pastas em um servidor podem não ser impostas por outros servidores no grupo de sincronização. Para obter melhores resultados, recomendamos a sincronização entre servidores que estão na mesma floresta do Active Directory, entre servidores que estão em florestas diferentes do Active Directory, mas que estabeleceram relações de confiança, ou entre servidores que não estão em um domínio. Recomendamos que você evite usar uma mistura dessas configurações.

  • Se eu criar um arquivo diretamente em meu compartilhamento de arquivo do Azure usando o SMB ou no portal, quanto tempo levará para que o arquivo seja sincronizado com os servidores no grupo de sincronização?

    As alterações feitas ao compartilhamento de Arquivos do Azure usando o Portal do Azure ou SMB não são detectadas e replicadas imediatamente como as alterações no Ponto de extremidade do servidor são. Os Arquivos do Azure ainda não têm notificações/diário de alteração, portanto, não há nenhuma maneira de iniciar automaticamente uma sessão de sincronização quando os arquivos são alterados. No Windows Server, a sincronização de Arquivos do Azure usa o diário de USN do Windows para iniciar automaticamente uma sessão de sincronização quando os arquivos são alterados.

    Para detectar alterações para o compartilhamento de arquivos do Azure, a sincronização de arquivos do Azure tem um trabalho agendado chamado um alterar o trabalho de detecção. Um trabalho de detecção de alteração enumera todos os arquivos no compartilhamento de arquivos e, em seguida, compara a versão de sincronização para esse arquivo. Quando o trabalho de detecção de alteração determina que os arquivos foram alterados, a sincronização de Arquivos do Azure inicia uma sessão de sincronização. O trabalho de detecção de alteração é iniciado a cada 24 horas. Como o trabalho de detecção de alteração funciona enumerando todos os arquivos no compartilhamento de Arquivos do Azure, a detecção de troca demora mais nos namespaces grandes do que namespaces menores. Para esses namespaces, pode levar mais de uma vez a cada 24 horas para determinar quais arquivos foram alterados.

    Para sincronizar imediatamente os arquivos alterados no compartilhamento de arquivo do Azure, o cmdlet Invoke-AzStorageSyncChangeDetection do PowerShell pode ser usado para iniciar manualmente a detecção de alterações no compartilhamento de arquivo do Azure. Esse cmdlet pode ser usado em cenários em que algum tipo de processo automatizado faz alterações no compartilhamento de arquivo do Azure ou as alterações são feitas por um administrador (como mover arquivos e diretórios para o compartilhamento). Para alterações de usuário final, a recomendação é instalar o agente de Sincronização de Arquivos do Azure em uma VM IaaS e permitir que os usuários finais acessem o compartilhamento de arquivos por meio da VM IaaS. Dessa forma, todas as alterações serão rapidamente sincronizadas com outros agentes sem a necessidade de usar o cmdlet Invoke-AzStorageSyncChangeDetection. Para saber mais, confira a documentação Invoke-AzStorageSyncChangeDetection.

    Estamos explorando adicionar detecção de alteração para um compartilhamento de arquivos do Azure semelhante ao USN para volumes no Windows Server. Ajude-nos a priorizar esse recurso para desenvolvimento futuro votando nele em Feedback da Comunidade do Azure.

  • Se o mesmo arquivo é alterado em dois servidores quase ao mesmo tempo, o que acontece?
    Os conflitos de arquivo são criados quando o arquivo no compartilhamento de arquivos do Azure não corresponde ao arquivo no local do ponto de extremidade do servidor (o tamanho e/ou a hora da última modificação é diferente).

    Os seguintes cenários podem causar conflitos de arquivo:

    • Um arquivo é criado ou modificado em um ponto de extremidade (por exemplo, Servidor A). Se o mesmo arquivo for modificado em um ponto de extremidade diferente antes da alteração no Servidor A ser sincronizada com esse ponto de extremidade, um arquivo de conflito será criado.
    • O arquivo existia no compartilhamento de arquivos do Azure e no local do ponto de extremidade do servidor antes da criação do ponto de extremidade do servidor. Se o tamanho do arquivo e/ou a hora da última modificação for diferente entre o arquivo no servidor e o compartilhamento de arquivos do Azure quando o ponto de extremidade do servidor for criado, um arquivo de conflito será criado.
    • Você recria o banco de dados de sincronização devido à corrupção ou devido ao limite de conhecimento ter sido alcançado. Depois que você recria o banco de dados, a sincronização entra em um modo chamado reconciliação. Se o tamanho do arquivo e o tempo de última modificação forem diferentes entre o arquivo no servidor e o compartilhamento de arquivos do Azure quando ocorre a conciliação, um arquivo de conflito é criado.

    Depois que o upload inicial para o compartilhamento de arquivos do Azure é concluído, o Sincronização de Arquivos do Azure não sobrescreve nenhum arquivo no seu grupo de sincronização. Em vez disso, ela usa uma estratégia simples de resolução de conflitos: ela mantém ambas as alterações nos arquivos que são alterados em dois pontos de extremidade ao mesmo tempo. A alteração gravada mais recentemente mantém o nome do arquivo original. O arquivo mais antigo (determinado por LastWriteTime) tem o nome do ponto de extremidade e o número de conflito acrescentado ao nome do arquivo. Para os pontos de extremidade de servidor, o nome do ponto de extremidade é o nome do servidor. Para os pontos de extremidade na nuvem, o nome do ponto de extremidade é Nuvem. O nome segue esta taxonomia:

    \<FileNameWithoutExtension\>-\<endpointName\>\[-#\].\<ext\>

    Por exemplo, o primeiro conflito de CompanyReport.docx se torna CompanyReport-CentralServer.docx se CentralServer fosse o local em que a gravação mais antiga ocorreu. O segundo conflito é chamado CompanyReport-CentralServer-1.docx. A Sincronização de Arquivos do Azure dá suporte a 100 arquivos de conflito por arquivo. Após o número máximo de arquivos de conflito ser atingido, o arquivo deixa de sincronizar até que o número de arquivos de conflito seja menor que 100.

  • Minha camada de nuvem está desabilitada. Por que há arquivos em camadas na localização do ponto de extremidade de servidor?
    Há dois motivos pelos quais os arquivos em camadas podem existir na localização do ponto de extremidade de servidor:

    • Ao adicionar um novo ponto de extremidade de servidor a um grupo de sincronização existente, se você escolher a opção Recuperar namespace primeiro ou Recuperar somente namespace para o modo de download inicial, os arquivos serão exibidos como se estivessem em camadas até serem baixados localmente. Para evitar isso, selecione a opção evitar arquivos em camadas para o modo de download inicial. Para recuperar arquivos manualmente, use o cmdlet Invoke-StorageSyncFileRecall.

    • Se a camada de nuvem foi habilitada no ponto de extremidade de servidor e, depois, desabilitada, os arquivos permanecem em camadas até que sejam acessados.

  • Por que meus arquivos em camadas não estão mostrando miniaturas nem visualizações no Explorador de Arquivos do Windows?
    Para os arquivos em camadas, as miniaturas e as visualizações não estarão visíveis no ponto de extremidade de servidor. Esse comportamento é esperado, pois o recurso de cache de miniatura do Windows ignora intencionalmente a leitura de arquivos com o atributo offline. Com a camada de nuvem habilitada, a leitura de arquivos em camadas fará com que eles sejam baixados (uma nova recuperação). No entanto, você pode configurar a Sincronização de Arquivos do Azure para ignorar a configuração do atributo offline.

    Esse comportamento não é específico da Sincronização de Arquivos do Azure. O Explorador de Arquivos do Windows exibe um "X cinza" em todos os arquivos que têm o atributo offline definido. Você verá o ícone X ao acessar arquivos via SMB. Para obter uma explicação detalhada sobre esse comportamento, veja Por que não recebo miniaturas para arquivos marcados offline?

    Caso tenha dúvidas sobre como gerenciar arquivos em camadas, confira Como gerenciar arquivos em camadas.

  • Há uma opção para ignorar o atributo offline para arquivos em camadas?

    Se preferir tornar as miniaturas e as visualizações visíveis para arquivos em camadas, você poderá configurar a Sincronização de Arquivos do Azure para ignorar a configuração do atributo offline.

    1. Adicione a seguinte chave do Registro no servidor:

      reg ADD "HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Azure\StorageSync" /v SkipOfflineAttributeOnTieredFile /t REG_DWORD /d 1 /f

    2. Reinicie o serviço FileSyncSvc .

    Após a configuração:

    • Novos arquivos em camadas não terão mais o atributo offline.
    • Os arquivos em camadas existentes serão atualizados na próxima execução de manutenção (ocorre a cada 24 horas).

    Observação

    Essa configuração é aplicada globalmente em todos os arquivos, não a extensões específicas. Sem o atributo offline, o Explorador de Arquivos do Windows mostra um ícone diferente. Você pode adicionar a coluna Atributos no Explorador de Arquivos para identificar arquivos em camadas (atributos ALM). Com base nos padrões de uso, ignorar o atributo offline pode aumentar as recuperações de arquivo, portanto, você deve monitorar a atividade de recuperação e garantir que os custos de saída permaneçam dentro de um intervalo aceitável. Veja como gerenciar arquivos em camadas.

  • Por que os arquivos em camadas existem fora do namespace do ponto de extremidade de servidor?
    Antes do Sincronização de Arquivos do Azure agente versão 3, o Sincronização de Arquivos do Azure bloqueava a movimentação de arquivos em camadas para fora do endpoint do servidor, mas no mesmo volume do endpoint do servidor. Operações de cópia, movimentações de arquivos não em níveis e transferências de arquivos em níveis para outros volumes não foram afetadas. O motivo para esse comportamento foi a suposição implícita de que o Explorador de Arquivos e outras APIs do Windows que têm essas operações de movimentação no mesmo volume são operações de renomeação (quase) instantâneas. Essa suposição significa que os movimentos fazem o Explorador de Arquivos ou outros métodos de movimento (como linha de comando ou PowerShell) parecerem não responsivos, enquanto o Sincronização de Arquivos do Azure recupera os dados da nuvem. A partir do Sincronização de Arquivos do Azure agent versão 3.0.12.0, o Sincronização de Arquivos do Azure permite mover um arquivo em camadas para fora do endpoint do servidor. Os efeitos negativos mencionados anteriormente são evitados ao permitir que o arquivo em camadas exista como um arquivo em camadas fora do terminal do servidor e, em seguida, recuperando o arquivo em segundo plano. Essa abordagem significa que movimentos no mesmo volume são instantâneos, e o Sincronização de Arquivos do Azure recupera o arquivo para o disco após a conclusão da movimentação.

  • Estou tendo um problema com a Sincronização de Arquivos do Azure no meu servidor (sincronização, camada de nuvem etc.). Devo remover e recriar o ponto de extremidade de servidor?

    Não: remover um ponto de extremidade do servidor não é como reiniciar um servidor! Remover e recriar o ponto de extremidade do servidor quase nunca é uma solução apropriada para corrigir problemas com sincronização, camadas de nuvem ou outros aspectos da Sincronização de Arquivos do Azure. Remover um endpoint do servidor é uma operação destrutiva. Isso pode resultar em perda de dados caso os arquivos em camadas existam fora do namespace do terminal do servidor. Confira Por que os arquivos em camadas existem fora do namespace do ponto de extremidade do servidor para saber mais. Ou pode resultar em arquivos inacessíveis para arquivos em camadas existentes no namespace do terminal do servidor. Esses problemas não serão resolvidos quando o endpoint do servidor for recriado. Arquivos em camadas podem existir em seu ponto de extremidade do servidor, mesmo se você nunca tiver habilitado nuvem em camadas. É por isso que recomendamos que você não remova o ponto de extremidade do servidor, a menos que queira parar de usar a Sincronização de Arquivos do Azure com essa pasta específica ou tenha sido explicitamente instruído a fazê-lo por um engenheiro da Microsoft. Para obter mais informações sobre remover pontos de extremidade do servidor, consulte remover um ponto de extremidade do servidor.

  • Posso mover o serviço de sincronização de armazenamento e/ou a conta de armazenamento para um grupo de recursos, uma assinatura ou um locatário do Microsoft Entra diferente?
    Sim, você pode mover o serviço de sincronização de armazenamento e/ou a conta de armazenamento para um grupo de recursos, uma assinatura ou um locatário do Microsoft Entra diferente. Depois de mover a conta de armazenamento ou o serviço de sincronização de armazenamento, é necessário permitir o acesso do aplicativo Microsoft.StorageSync à conta de armazenamento. Siga estas etapas:

    1. Faça login no portal do Azure e selecione Controle de acesso (IAM) no menu de serviços.

    2. Selecione a guia Atribuições de função para listar os usuários e aplicativos (entidades de serviço) que têm acesso à sua conta de armazenamento.

    3. Verifique se Microsoft.StorageSync ou Serviço Híbrido Sincronização de Arquivos (nome do aplicativo antigo) aparece na lista com a função de Leitor e Acesso a Dados.

      Se a Microsoft. StorageSync ou Hybrid File Sync Service não aparecem na lista, siga estes passos:

      • Selecione Adicionar.
      • No campo Função, selecione Leitor e Acesso a Dados.
      • No campo Selecionar, digite Microsoft.StorageSync, selecione a função e selecione Salvar.

      Observação

      Ao criar o ponto de extremidade na nuvem, o serviço de sincronização de armazenamento e a conta de armazenamento devem estar no mesmo locatário do Microsoft Entra. Depois que o endpoint na nuvem for criado, você pode mover o serviço de sincronização de armazenamento e a conta de armazenamento para diferentes locatários do Microsoft Entra.

  • A Sincronização de Arquivos do Azure preserva as ACLs do NTFS no nível de diretório/arquivo, juntamente com os dados armazenados nos Arquivos do Azure?

    A partir de 24 de fevereiro de 2020, as ACLs novas e existentes colocadas em camadas pela Sincronização de Arquivos do Azure serão persistidas no formato NTFS e as modificações de ACL feitas diretamente no Compartilhamento de Arquivos do Azure serão sincronizadas em todos os servidores no grupo de sincronização. As alterações nas ACLs feitas nos Arquivos do Azure serão sincronizadas por meio da Sincronização de Arquivos do Azure. Ao copiar dados para os Arquivos do Azure, use uma ferramenta de cópia que dê suporte à "fidelidade" necessária para copiar atributos, carimbos de data/hora e ACLs em um compartilhamento de arquivo do Azure, via SMB ou REST. Ao usar as ferramentas de cópia do Azure, como o AzCopy, é importante usar a última versão. Verifique a tabela de ferramentas de cópia de arquivo para obter uma visão geral das ferramentas de cópia do Azure e garantir a cópia de todos os metadados importantes de um arquivo.

    Se você tiver habilitado o Backup do Azure nos compartilhamentos de arquivo gerenciados da Sincronização de Arquivos do Azure, as ACLs de arquivo poderão continuar a ser restauradas durante o fluxo de trabalho de restauração de backup. Isso funciona para todo o compartilhamento ou arquivos/diretórios individuais.

    Se estiver usando instantâneos como parte da solução de backup autogerenciado para compartilhamentos de arquivos gerenciados pela Sincronização de Arquivos do Azure, suas ACLs poderão ser restauradas incorretamente para ACLs NTFS se os instantâneos tiverem sido obtidos antes de 24 de fevereiro de 2020. Se isso ocorrer, você pode entrar em contato com o Suporte do Azure.

  • A Sincronização de Arquivos do Azure sincroniza o LastWriteTime para diretórios? Por que o carimbo de data e hora de modificação em um diretório não é atualizado quando os arquivos dentro dele são alterados?
    Não, a Sincronização de Arquivos do Azure não sincroniza o LastWriteTime para os diretórios. Além disso, o Arquivos do Azure não atualiza o carimbo de data e hora da modificação (LastWriteTime) para diretórios quando os arquivos dentro do diretório são alterados. Este comportamento é esperado.

  • Como o espaço em volume funciona para a camada de nuvem como parte da interoperabilidade com o Dedup?
    Em alguns casos em que o Dedup é instalado, o espaço disponível pode aumentar mais do que o esperado após o acionamento da coleta de lixo do Dedup. Por exemplo, digamos que a política de espaço livre para a camada de nuvem esteja definida como 20%. Sincronização de Arquivos do Azure é notificado quando há pouco espaço livre (por exemplo, quando o espaço livre é 19%). O processo de camada determina que é necessário liberar mais 1% de espaço, mas, como margem de segurança, há 5% adicionais, então a camada é elevada para 25% (por exemplo, 30 GiB). Os arquivos são organizados em camadas até atingirem 30 GiB. Como parte da interoperabilidade com a Deduplicação, a Sincronização de Arquivos do Azure inicia a coleta de lixo ao final da sessão de organização em camadas.

  • Por que o software antivírus do servidor Sincronização de Arquivos do Azure está recuperando arquivos em camadas?
    Quando os usuários acessam arquivos em camadas, alguns antivírus (AV) podem causar recalls de arquivos não intencionais. Esse problema ocorre se o software antivírus não estiver configurado para ignorar arquivos em camadas (aqueles com o RECALL_ON_DATA_ACCESS atributo). Veja o que acontece:

    1. Um usuário tenta acessar um arquivo em camadas.
    2. O software AV bloqueia o identificador de leitura.
    3. O software antivírus então realiza sua própria leitura para escanear o arquivo em busca de vírus.

    Esse processo pode parecer que o software antivírus está recuperando os arquivos em camadas, mas na verdade é acionado pela tentativa de acesso do usuário. Para evitar esse problema, certifique-se de que o fornecedor do seu antivírus configure o software para ignorar a varredura de arquivos em camadas com o RECALL_ON_DATA_ACCESS atributo.

  • O software de inspeção SSL pode bloquear o acesso aos servidores Sincronização de Arquivos do Azure? Garanta que seu software de inspeção SSL (como Zscaler ou FortiGate) permita que os endpoints do Sincronização de Arquivos do Azure acessem o Azure. Essas ferramentas de inspeção de SSL podem substituir as configurações de firewall e permitir tráfego seletivamente. Entre em contato com seu administrador de rede para resolver esse problema. Use o testnet comando para determinar se seu servidor Sincronização de Arquivos do Azure está enfrentando esse problema.

Provedores de recursos e compartilhamentos clássicos de arquivos

  • Qual é a diferença entre os provedores de recursos Microsoft.Storage e Microsoft.FileShares? O que é um compartilhamento de arquivos Azure versus um compartilhamento de arquivos Azure classic?

    Provedores de recursos são serviços de gerenciamento que entregam tipos específicos de recursos no Azure. Você implanta compartilhamentos de arquivos clássicos do Azure em uma conta de armazenamento, que é um recurso de nível superior que usa o provedor de recursos Microsoft.Storage. Todos os recursos de armazenamento em uma conta de armazenamento compartilham os limites que se aplicam a essa conta de armazenamento. Compartilhamentos de arquivos oferecidos pela Microsoft. O provedor de recursos FileShares é um novo recurso de alto nível que simplifica a implantação de compartilhamento de arquivos ao eliminar a necessidade de uma conta de armazenamento. Atualmente, a Microsoft. FileShares suporta apenas o protocolo de compartilhamento de arquivos NFS. Compartilhamentos de arquivos clássicos suportam tanto SMB quanto NFS.

Segurança, autenticação e controle de acesso

  • Como posso auditar o acesso aos arquivos e às alterações nos Arquivos do Azure?

    Há duas opções que fornecem funcionalidade de auditoria para os Arquivos do Azure:

    • Se os usuários estiverem acessando diretamente o compartilhamento de arquivos Azure, você pode usar os logs do Armazenamento do Microsoft Azure para rastrear as mudanças nos arquivos e o acesso do usuário para fins de solução de problemas. As solicitações são registradas em uma base de melhor esforço.
    • Se os usuários estiverem acessando o compartilhamento de arquivo do Azure por meio de um Windows Server com o agente de Sincronização de Arquivos do Azure instalado, use uma política de auditoria ou um produto de terceiros para controlar as alterações de arquivos e o acesso do usuário no Windows Server.

  • Os Arquivos do Azure dão suporte ao uso ABE (Access-Based Enumeração) para controlar a visibilidade dos arquivos e pastas nos compartilhamentos de arquivos do Azure SMB?

    Arquivos do Azure não suporta o uso do ABE, mas você pode usar DFS-N com compartilhamentos de arquivos SMB Azure.

  • Posso salvar em um compartilhamento de arquivos do Azure usando uma impressora ou scanner?

    Os Arquivos do Azure são compatíveis apenas com Windows, Linux e macOS. Não há suporte para acessar um compartilhamento de arquivos do Azure diretamente de uma impressora ou scanner. No entanto, se você já estiver usando a Sincronização de Arquivos do Azure, poderá imprimir ou verificar o servidor de arquivos do Windows e sincronizar o arquivo com um compartilhamento de arquivos do Azure.

  • Os Arquivos do Azure dão suporte a fluxos de dados alternativos?

Os Arquivos do Azure não dão suporte a fluxos de dados alternativos. A transferência de dados via SMB lançará uma mensagem de arquivo já existente se for encontrado um fluxo de dados alternativo. Você pode verificar fluxos alternativos usando o seguinte comando do PowerShell:

get-item <file path+name> -Stream *

Se mais de um fluxo for mostrado, você poderá removê-los usando o seguinte comando do PowerShell:

remove-Item <file path+name> -Stream *

Fluxos de dados alternativos são preservados localmente quando a Sincronização de Arquivos do Azure é usada.

Autenticação baseada em identidade

  • O Microsoft Entra Domain Services dá suporte ao acesso SMB usando as credenciais do Microsoft Entra de dispositivos ingressados ou registrados com o Microsoft Entra ID?

    Não, não há suporte para esse cenário.

  • Posso usar o nome canônico (CNAME) para montar um compartilhamento de arquivos do Azure enquanto uso a autenticação baseada em identidade?

    Sim, agora há suporte para esse cenário em ambientes de floresta única e de várias florestas para compartilhamentos de arquivos SMB do Azure. No entanto, os Arquivos do Azure só dão suporte à configuração do CNAMES usando o nome da conta de armazenamento como um prefixo de domínio. Se você não quiser usar o nome da conta de armazenamento como prefixo, considere o uso de Namepaces DFS.

  • Posso acessar compartilhamentos de arquivos do Azure com as credenciais do Microsoft Entra de uma VM em uma assinatura diferente?

    Se a assinatura sob a qual o compartilhamento de arquivos foi implantado estiver associada ao mesmo locatário do Microsoft Entra como a implantação do Microsoft Entra Domain Services para o qual a VM ingressou no domínio, você poderá acessar os compartilhamentos de arquivos do Azure usando as mesmas credenciais do Microsoft Entra. A limitação é imposta não na assinatura, mas no locatário associado do Microsoft Entra.

  • Posso habilitar o Microsoft Entra Domain Services ou a autenticação de AD DS local para compartilhamentos de arquivos do Azure usando um locatário do Microsoft Entra que seja diferente do locatário principal do compartilhamento de arquivos do Azure?

    Não. Os Arquivos do Azure só oferecem suporte à integração do Microsoft Entra Domain Services ou do AD DS local com um locatário do Microsoft Entra que reside na mesma assinatura do compartilhamento de arquivos. Uma assinatura só pode ser associada a um locatário do Microsoft Entra. Ao usar AD DS locais para autenticação, a credencial do AD DS deve ser sincronizada com o Microsoft Entra ID ao qual a conta de armazenamento está associada.

  • A autenticação do AD DS local para compartilhamentos de arquivo do Azure dá suporte à integração a um ambiente do AD DS usando várias florestas?

    A autenticação do AD DS local dos Arquivos do Azure se integra apenas com a floresta do serviço de domínio em que a conta de armazenamento está registrada. Para dar suporte à autenticação de outra floresta, seu ambiente precisar ter uma relação de confiança de floresta configurada corretamente. Para ver instruções detalhadas, confira Usar os Arquivos do Azure com várias florestas do Active Directory.

    Observação

    Em uma configuração de várias florestas, não use o Explorador de Arquivos do Windows para configurar permissões de ACLs/NTFS do Windows no nível raiz, do diretório ou do arquivo. Em vez disso,use icacls.

  • Há alguma diferença na criação de uma conta de computador ou conta de logon de serviço para representar minha conta de armazenamento no Active Directory?

    Não há diferença entre criar uma conta de computador (padrão) ou uma conta de logon de serviço quanto ao funcionamento da autenticação com os Arquivos do Azure. Você pode escolher como representar uma conta de armazenamento como uma identidade em seu ambiente do AD. A configuração DomainAccountType padrão no cmdlet Join-AzStorageAccountForAuth é uma conta de computador. No entanto, o tempo de expiração de senha configurado em seu ambiente AD para contas de computador ou de logon de serviço pode ser diferente e você precisa levar isso em consideração para Atualizar a senha da sua identidade de conta de armazenamento no AD.

  • Como faço para remover credenciais em cache usando a chave da conta de armazenamento e excluir conexões SMB existentes antes de inicializar uma nova conexão com credenciais do Microsoft Entra ID ou AD?

    Siga o processo em duas etapas para remover a credencial salva associada à chave da conta de armazenamento e remover a conexão SMB:

    1. Execute o comando a seguir em um prompt de comando do Windows para remover a credencial. Se você não encontrar nenhuma, isso indicará que você não persistiu a credencial e poderá ignorar esta etapa.

      cmdkey /delete:Domain:target=storage-account-name.file.core.windows.net

    2. Exclua a conexão existente com o compartilhamento de arquivo. Você pode especificar o caminho de montagem como a letra da unidade montada ou o caminho storage-account-name.file.core.windows.net.

      net use <letra-da-unidade/caminho-do-compartilhamento> /delete

  • É possível exibir o UPN (userPrincipalName) de um proprietário de arquivo/diretório no Explorador de Arquivos em vez do SID (identificador de segurança)?

    O Explorador de Arquivos chama uma API RPC diretamente para o servidor (Arquivos do Azure) para traduzir o SID em um UPN. Os Arquivos do Azure não dão suporte para essa API, portanto, no Explorador de Arquivos, o SID do proprietário de um arquivo/diretório é exibido em vez do UPN para arquivos e diretórios hospedados nos Arquivos do Azure. No entanto, a partir de um cliente ingressado no domínio, você pode usar o seguinte comando do PowerShell para exibir todos os itens em um diretório e seu proprietário, incluindo o UPN:

    Get-ChildItem <Path> | Get-ACL | Select Path, Owner

NFS v4.1 (Sistema de arquivos de rede)

Perguntas frequentes sobre compartilhamento de snapshots

Criar instantâneos de compartilhamento

  • Meus instantâneos de compartilhamento têm redundância geográfica?
    O instantâneo de compartilhamento tem a mesma redundância que o compartilhamento de arquivos do Azure para o qual ele foi criado. Caso tenha selecionado o armazenamento com redundância geográfica para sua conta, o instantâneo de compartilhamento também será armazenado de forma redundante na região emparelhada.

Limpar instantâneos de compartilhamento

  • Posso excluir meu compartilhamento sem excluir os instantâneos de compartilhamento?
    Não. O fluxo de trabalho de compartilhamento de arquivos elimina automaticamente os snapshots quando você exclui o compartilhamento.

Faturamento e precificação do Arquivos do Azure

  • O que são as transações nos Arquivos do Azure e como elas são cobradas? As transações de protocolo ocorrem sempre que um usuário, um aplicativo, um script ou um serviço interage com compartilhamentos de arquivos do Azure (gravação, leitura, listagem, exclusão de arquivos etc.). É importante lembrar que algumas ações que você percebe como uma só operação, na verdade podem envolver várias transações. Para compartilhamentos de arquivos com pagamento conforme o uso, diferentes tipos de transações têm preços distintos com base em seu impacto no compartilhamento de arquivo. As transações não afetam a cobrança de compartilhamentos de arquivos provisionados. Para obter mais informações, confira Noções básicas sobre cobrança.

Interoperabilidade do Arquivos do Azure com outros serviços

  • A diferença entre Arquivos do Azure e Azure NetApp Files?
    Arquivos do Azure e Azure NetApp Files são diferentes serviços de armazenamento de arquivos em Azure e foram projetados para diferentes cargas de trabalho e requisitos de desempenho. Arquivos do Azure fornece compartilhamentos de arquivos SMB e NFS sem servidor e oferece Sincronização de Arquivos do Azure como uma opção para armazenar em cache compartilhamentos de arquivos SMB no Windows Server. Azure NetApp Files é um serviço de armazenamento de arquivos bare-metal de alto desempenho alimentado pela tecnologia NetApp que dá suporte a compartilhamentos de arquivos NFS, SMB e protocolo duplo. Para obter mais informações, consulte Compare Arquivos do Azure e Azure NetApp Files.

  • É possível usar o compartilhamento de arquivo do Azure como uma testemunha de compartilhamento de arquivo para o Cluster de Failover do Windows Server?
    Essa configuração não é suportada para Arquivos do Azure. Para aprender como configurar essa configuração usando o armazenamento Azure Blob, veja Implantar uma Testemunha na Nuvem para um Cluster de Failover.

Confira também

  • Last updated on