Quando nossos dispositivos Windows 10 imprimem do Microsoft Edge, a impressão atinge a fila de impressão do Windows Server 2012 e apenas trava na impressão/spooling. Isso continua até que eu limpe manualmente a fila e reinicie o spooler de impressão. Tanto quanto eu vi, o único programa com problemas de impressão é o Edge.
Isso é um problema de driver? Por onde começar a consertar isso?
Eu tenho um servidor Exchange 2016 que funciona com cerca de 14 dias entre eles. O servidor é virtual e existe em um ambiente vmware em cluster com armazenamento via iSCSI. Nenhum dos outros servidores Windows que executamos (incluindo a cópia passiva do Exchange) bsods. O Exchange passivo está recebendo backup e limpa os logs de transação como deveria no nó passivo e ativo.
Aqui está o que o visualizador BSoD me dá de informações:
052716-21921-01.dmp 27.05.2016 10:22:16 CRITICAL_PROCESS_DIED 0x000000ef ffffe000`de10d080 00000000`00000000 00000000`00000000 00000000`00000000 ntoskrnl.exe ntoskrnl.exe+14e3a0 NT Kernel & System Microsoft® Windows® Operating System Microsoft Corporation 6.3.9600.18289 (winblue_ltsb.160328-1315) x64 ntoskrnl.exe+14e3a0 C:\Windows\Minidump\052716-21921-01.dmp 8 15 9600 138 150 27.05.2016 10:22:47
051516-25765-01.dmp 15.05.2016 10:11:06 CRITICAL_PROCESS_DIED 0x000000ef ffffe001`0ad80900 00000000`00000000 00000000`00000000 00000000`00000000 ntoskrnl.exe ntoskrnl.exe+14e3a0 NT Kernel & System Microsoft® Windows® Operating System Microsoft Corporation 6.3.9600.18289 (winblue_ltsb.160328-1315) x64 ntoskrnl.exe+14e3a0 C:\Windows\Minidump\051516-25765-01.dmp 8 15 9600 138 150 15.05.2016 10:11:41
042816-19328-01.dmp 28.04.2016 22:36:50 CRITICAL_PROCESS_DIED 0x000000ef ffffe001`3da4f900 00000000`00000000 00000000`00000000 00000000`00000000 ntoskrnl.exe ntoskrnl.exe+14e8a0 NT Kernel & System Microsoft® Windows® Operating System Microsoft Corporation 6.3.9600.18289 (winblue_ltsb.160328-1315) x64 ntoskrnl.exe+14e8a0 C:\Windows\Minidump\042816-19328-01.dmp 8 15 9600 294 472 28.04.2016 22:39:45
041916-23859-01.dmp 19.04.2016 08:43:53 CRITICAL_PROCESS_DIED 0x000000ef ffffe001`23101900 00000000`00000000 00000000`00000000 00000000`00000000 ntoskrnl.exe ntoskrnl.exe+14e8a0 NT Kernel & System Microsoft® Windows® Operating System Microsoft Corporation 6.3.9600.18289 (winblue_ltsb.160328-1315) x64 ntoskrnl.exe+14e8a0 C:\Windows\Minidump\041916-23859-01.dmp 8 15 9600 294 472 19.04.2016 08:47:04
Eu vi uma postagem com o mesmo problema em um site diferente, mas nenhum realmente respondeu ao problema e a postagem envelheceu.
Alguém tem alguma indicação de como consertar isso? Eu teria que instalar OUTRO servidor Exchange e migrar para ele? Isso seria muito lamentável..
Configurei um ambiente de coexistência com o Exchange 2010 e o Exchange 2016.
No momento, o fluxo de email parece funcionar sem problemas, e migrei dois usuários de teste de 2010 para 2016.
O tráfego SMTP e o HTTPS são proxy da nova instalação do Exchange 2016 - e funcionam bem para os usuários de 2010 anteriores.
Meu problema é que, quando os usuários são migrados, o Outlook 2016 está tendo problemas para se conectar ao novo servidor.
Quando abro o Outlook, ele ainda usa RPC/HTTP no servidor antigo.
Se eu excluir o perfil antigo e recriá-lo usando a descoberta automática, ele funcionará bem.
Em seguida, vejo o tráfego MAPI e ele atinge o novo servidor conforme o esperado.
Isso causaria um problema se eu tivesse que recriar perfis manualmente para todos os usuários em nossa empresa.
Alguém tem alguma indicação?
Editado com mais informações:
Migrei meu próprio usuário e abri meu Outlook. Recebi a mensagem de que minha caixa foi migrada e que precisava reiniciar o Outlook; e assim eu fiz! Meu celular e o OWA funcionam como pretendido, e são apenas meus clientes do Outlook agindo mal. Aconteceu em dois dos meus computadores conectados à mesma caixa de correio e ao mesmo usuário (computador doméstico e do escritório).
Ao abrir meu cliente Outlook, recebo a mensagem de aviso de certificado com o nome interno dos meus servidores antigos (como: Exch2010.domain.local), e o certificado em uso é para nosso FQDN como mail.company.com.
Segunda edição:
Acabei de migrar um usuário de teste de 2010 com o Outlook fechado e tentei conectar de uma rede externa. Ele me perguntou se eu queria permitir que https://mail.company.com/autodiscover/autodiscover.xml editasse minhas configurações. Eu cliquei em "permitir" e nada aconteceu. A caixa de correio permaneceu em estado desconectado e o status de conexão tinha uma conexão que tinha o status "estabelecido". A conexão foi feita por proxy através de mail.company.com e para Exch2010.company.local. Reiniciei o Outlook e aconteceu a mesma coisa.
Em seguida, movi o cliente da rede externa e coloquei-o em nossa rede interna. Agora ele me dá a mesma mensagem "permitir que este site defina as configurações do servidor [email protected]?" mas com o nome local do NOVO servidor Exchange em um formato de URL como " https://exch2016.company.local/autodiscover/autodiscover.xml ". Eu permiti e aceitei o aviso de certificado (pois dizia que estava usando o nome local novamente - exch216.company.local; que não corresponde ao certificado SSL).
O Outlook ainda não está operacional e está em um estado "desconectado". Minha própria caixa de correio está "estabelecida", mas não é atualizada.
Por curiosidade, verifiquei os servidores executando:
Get-AutodiscoverVirtualDirectory | fl
InternalURL e ExternalURL para todos os três estão em branco. Não tenho experiência suficiente para dizer se isso é correto ou não.
Por algum motivo, parece que os servidores estão anunciando internamente seus nomes locais em vez do correto "mail.company.com".
Também verifiquei os servidores executando:
Get-ClientAccessServer -Identity SERVER | fl
Todos eles têm o AutoDiscoverServiceInternalUri definido como " https://mail.company.com/autodiscover/autodiscover.xml ".
O FQDN para todos eles é definido como seus nomes de host locais (servername.company.local).
Não tenho ideia do que tentar a seguir..
Edite o número três; como resposta a @Sembee: Olá @Sembee; Obrigado pela sua resposta. Deixei em branco e não fiz alterações. Eu verifiquei o InternalURI para clientaccessserver em todos os três servidores e eles são idênticos. Os testes de descoberta automática são concluídos sem problemas desde o início. A reconfiguração do Outlook de um usuário faz com que o Outlook funcione novamente (dados atualizados da descoberta automática). Todo o tráfego está passando pelo servidor 2016 por enquanto (afaik) e proxies OK para o servidor 2010. Nenhum mencionou problemas. O Outlook simplesmente não está funcionando depois de migrar para 2016 sem recriar o perfil e executar uma nova descoberta automática.
Quarta edição: Quando vim trabalhar hoje, meu próprio laptop (não funcionou ontem/domingo) E o laptop (não funcionou no sábado) que uso para testar ambos funcionaram bem. Poderia ser algum tipo de sincronização atrasada fazendo isso comigo? No momento, estou configurando outro teste, para ver se ele se comporta da mesma maneira - e se é possível cronometrar de alguma forma. Qualquer dica será muito apreciada.
Tentei mover um endereço de e-mail principal de uma caixa de correio para uma nova. Vamos ligar para o endereço antigo: [email protected]
Renomeei esta conta e os endereços SMTP para [email protected] e movi o antigo endereço "[email protected]" para uma nova caixa de correio.
A nova caixa de correio tem o nome de [email protected] e agora "[email protected]" como alias.
Ao enviar e-mail de fontes externas, os e-mails aparecem na nova caixa de correio. Ao enviar de dentro de nossa organização de qualquer endereço @company.com, parece atingir o "[email protected]" mesmo se eu digitar "[email protected]" no campo "to:".
Alguém poderia explicar o porquê; e como corrigir isso? Ao executar o Get-MessageTrackingLog e filtrar meu próprio endereço como remetente, posso ver meus e-mails de teste, mas o campo "Destinatários" é exibido como "[email protected]", mesmo que eu tenha 100% de certeza de que digitado "[email protected]".
A alteração ocorreu há menos de 24 horas. Poderia ser algumas listas de endereços internas que precisam ser atualizadas? O usuário de domínio da conta antiga é denominado Department.old; da mesma maneira que o endereço SMTP primário.
Estou tentando descobrir computadores baseados em sub-redes IP. O servidor de administração não faz parte do mesmo grupo de trabalho ou diretório ativo dos clientes, portanto, esta é a única maneira de fazê-lo.
Posso descobrir cerca de 1/3-1/2 dos meus computadores.
Tentei desabilitar totalmente o firewall do Windows em um dos computadores e ele pareceu se adicionar à lista de computadores não gerenciados.
Ao abrir apenas para ICMPv4, para que o servidor de gerenciamento possa executar ping no computador-cliente de destino, ele não funciona.
Parece que estou perdendo algumas portas que precisam ser abertas no firewall do Windows - mas a ótima Internet não pode me dizer quais portas!
Alguém já fez isso antes e tem uma pista sobre quais portas estou perdendo? Desativar o Firewall do Windows para todos os clientes, para instalar o Kaspersky não é uma grande solução.....