USD Matt's questions

Parece que tenho cada vez mais problemas com a Microsoft pressionando para tentar forçar tudo em seu serviço online ultimamente.

A partir de hoje, de repente, tenho duas estações de trabalho que se recusam a permanecer conectadas ao Exchange. Este é um domínio local e um servidor Exchange local. Do nada, eles agora aparecem com uma janela de login online da Microsoft na inicialização. Se eu fechar a janela, o status da conta muda de conectado ao Exchange para "Precisa de senha".

A caixa de login é pré-preenchida com [email protected], e tentar clicar em Avançar apenas erros que "Esta conta não está em nosso sistema" (sim, grande surpresa, é um domínio local, troca local e nada a ver com a Microsoft online).

O que devo fazer sobre isso? Qual é a maneira correta hoje em dia de permitir que meus usuários se conectem à sua conta de troca local sem que o Outlook exija que eles façam login em uma conta online da Microsoft inexistente?

Eu tenho um servidor Exchange 2019 que está funcionando bem, mas, idealmente, gostaria de executar a desfragmentação offline em um banco de dados de arquivo que agora é muito maior do que o necessário depois de remover uma caixa de correio que, devido a uma importação errônea, copiou muitas vezes mais dados ao arquivo do que realmente existia na caixa de correio.

Name                        DatabaseSize                    AvailableNewMailboxSpace
----                        ------------                    ------------------------
Archives                    50.13 GB (53,821,308,928 bytes) 49.8 GB (53,472,526,336 bytes)

O problema é que os bancos de dados não estão acessíveis (o administrador recebe um erro de permissão mesmo tentando navegar até eles) e prefiro não mexer nas permissões nas pastas do Exchange, a menos que não tenha escolha - ou siga os procedimentos documentados da Microsoft.

Qual é o processo correto hoje em dia para fazer qualquer tipo de recuperação/manutenção diretamente nos arquivos do banco de dados quando o Exchange está configurado por padrão para permitir apenas acesso a si mesmo? Ainda é eseutilsuportado ou eles não recomendam tocar nos arquivos edb?

Recentemente, configurei um servidor interno do Exchange 2019 para alguns usuários que usamos principalmente para testes. Existem apenas 5 contas lá e, em um caso, importei todo o backup de e-mail existente dos usuários do arquivo PST. Esse backup tinha cerca de 10 GB, embora na verdade não fosse totalmente importado, pois atingiu o erro "TooManyLargeItems". Eu não estava muito preocupado com isso, pois tenho uma cópia PST da caixa de correio de cada usuário como um arquivo offline.

Alguns dias depois, habilitei o arquivo online para este usuário, usando todos os padrões de >2 anos em um banco de dados de Arquivos autônomo. Depois disso, notei que a unidade do Exchange estava enchendo rapidamente. Em poucos dias, ele cresceu para 100 GB dos 300 GB que aloquei. Eventualmente, percebi que era o banco de dados Archive usando espaço em excesso e descobri que o arquivo para esse usuário está crescendo constantemente. Depois de alguns dias, estava em 50 GB -

Name                     FolderSize                      ItemsInFolder
----                     ----------                      -------------
Top of Information Store 0 B (0 bytes)                               0
Calendar                 124.1 MB (130,100,547 bytes)            10241
Deleted Items            29.06 KB (29,756 bytes)                     3
ExternalContacts         0 B (0 bytes)                               0
Files                    0 B (0 bytes)                               0
Inbox                    22.47 GB (24,125,848,037 bytes)        193193
Sent Items               27.09 GB (29,090,235,340 bytes)        224726
Sync Issues              0 B (0 bytes)                               0
Conflicts                379.5 MB (397,940,955 bytes)             5483
Recoverable Items        0 B (0 bytes)                               0
Calendar Logging         136.1 MB (142,698,692 bytes)            20681
Deletions                2.763 GB (2,967,210,171 bytes)          23899
Purges                   0 B (0 bytes)                               0
Versions                 0 B (0 bytes)                               0

Quase um quarto de milhão de itens em Enviados e 200k na Caixa de entrada.... Isso não pareceu parar e agora fui forçado a simplesmente desabilitar o arquivo para este usuário.

Alguém tem alguma ideia de como uma caixa de correio que deve ter apenas <= 10 GB de e-mail no total pode criar um arquivo fugitivo como esse ou que outros métodos eu poderia usar para entender por que isso acontece?

Eu tenho um servidor executando o Windows Server 2016 Essentials. (Geralmente tento evitar as versões do tipo SBS, embora eu esperasse que eles não tivessem atrapalhado as coisas em 2016, ...

O servidor anterior deste cliente fez backup em um NAS usando o Symantec System Recovery, com o qual sempre tivemos um bom sucesso

Neste sistema, estou tentando usar o Backup do Windows Server integrado, o que deve ser ótimo, certo?

Infelizmente, no Essentials, parece que você não pode fazer backup em um local de rede. Você pode tentar acessar o Backup do servidor diretamente (em vez de usar o painel), mas isso deseja contas correspondentes no sistema e no NAS e ainda reclama de problemas de permissões. Também interrompe a opção de backup no painel.

Decidi que no final era mais fácil seguir as opções do Essentials e usar uma unidade USB, mas prefiro não confiar totalmente nisso para o armazenamento de backup.

Gostaria de sincronizar os arquivos de backup com o NAS, para o qual estou feliz em usar o RoboSync. No entanto, obter os arquivos parece ser um problema. Eu já atribuí uma letra de unidade ao disco USB para que eu possa ver a pasta de backup - esperando que isso já não seja suficiente para atrapalhar o processo de backup.

Ainda não é possível copiar alguns dos dados, executando o RoboSync como administrador com o modo de backup ativado.

Ele acessará alguns dos arquivos e está copiando o arquivo de imagem principal (.vhdx), mas está mostrando erros em outros arquivos como o seguinte -

New File 18.7 g {faa21756-730f-11e7-be75-901b0ed00c98}{3808876b-c176-4e48-b7ae-04046e6cc752} 2017/07/28 09:23:43 ERROR 5 (0x00000005) Copying File F:\System Volume Information\{faa21756-730f-11e7-be75-901b0ed00c98}{3808876b-c176-4e48-b7ae-04046e6cc752} Access is denied.

Existe alguma maneira de criar facilmente uma duplicata dos dados de backup sem pular obstáculos? Evitei alterar as permissões nas pastas de backup, pois não ficaria surpreso se isso interrompesse os backups futuros.

Edit: Olhando para isso novamente, os únicos arquivos que não serão copiados estão na System Volume Informationpasta, que está na raiz da unidade USB. Eu não acho que isso seja realmente algo a ver com o backup... Alguém pode confirmar que a WindowsImageBackuppasta é tudo que eu preciso para poder recuperar a máquina completa no futuro?

Estou usando uma combinação de Postfix e Procmail para lidar com e-mails de entrada em um dos meus servidores. Cada usuário tem uma conta local e eu uso o abaixo /usr/local/etc/procmailrccom sucesso há anos:

DEFAULT=$HOME/mail/
LOGFILE=/var/log/procmail

Recentemente, adicionei uma receita para direcionar mensagens sinalizadas como spam para uma pasta separada:

:0
* ^X-Spam-Flag: YES
$HOME/mail/.Junk/

No entanto, parece que em alguns casos as mensagens que vão para esta pasta são de propriedade do root em vez do usuário correto. Nunca tive esse problema com a caixa de entrada e também parece que afeta apenas alguns usuários.

Consegui pegar um dos processos do Procmail pse ele parece ser executado como o usuário correto. (Este usuário também tem e-mail de propriedade root na pasta de lixo eletrônico)

# ps axu | grep procmail
{correct-local-username}   7402   0.0  0.2  12140   1780 ??  Ss   11:37AM      0:00.01 /usr/local/bin/procmail -a

Alguém tem uma idéia de por que as mensagens tratadas pela receita acabariam sendo de propriedade do root, enquanto as mensagens indo para a pasta padrão teriam o proprietário correto?

Existe alguma coisa que eu possa fazer (mesmo que seja hacky, como chamar chown da receita do Procmail) para garantir que as mensagens sejam sempre de propriedade do usuário correto?

Caso seja importante, o Procmail é configurado no Postix da seguinte forma:

mailbox_command = /usr/local/bin/procmail -a "$EXTENSION"