 Jefferson,  22 de junho de 2021,  manutençãoIsso se baseia no fato de que ao apagar uma conta o WLM não apaga os emails. Estou assumindo que a conta seja POP3 e acabo de fazer isso para um cliente.
Crie de novo a conta, mas não coloque a senha ainda, para que não baixe emails.
Verifique em Arquivo -> Opções -> Email -> Avançado -> Manutenção -> Pasta de Repositório qual a pasta onde as mensagens do WLM são armazenadas. Geralmente está em C:\Users\[nome do usuário]\AppData\Local\Microsoft\Windows Live Mail mas não conte com isso. Eu, por exemplo, costumo configurar essa pasta em outro lugar, geralmente outra partição.
Feche o WLM
Nessa pasta ordene as sub-pastas por data de modificação, a pasta mais nova deve ser a conta que você acaba de criar. certifique-se de que dentro dela as pastas “Inbox” e “Sent Itens” estão vazias.
Procure agora nas outras pastas, começando pelas mais novas, qual é a pasta da conta que foi apagada. Você vai se deparar com um monte de arquivos .eml, que são as mensagens de email individuais. Você pode abrir um deles com um duplo clique e checar pelo conteúdo se você está na conta certa. O usuário da conta normalmente é o mais capacitado a fazer essa avaliação.
Ao achar a pasta com as mensagens da conta apagada, copie (você pode mover, mas isso é arriscado) as mensagens da pasta “Sent itens” para a pasta de mesmo nome vazia da conta nova. Repita o processo para a pasta Inbox.
Abra o WLM
Na conta nova, abra a pasta Itens Enviados. As mensagens devem começar a aparecer como se estivessem sendo baixadas nesse momento. Se isso não acontecer você fez algo errado. Aguarde terminar.
Faça o mesmo para a Caixa de Entrada.
Nesse ponto, se seu programa de email estiver configurado para apagar as mensagens do servidor ao recebê-las você não precisa fazer mais nada a não ser colocar a senha para começar a receber as mensagens novas, mas se não for assim você vai se deparar com um possível problema: todas as mensagens no servidor serão baixadas novamente e você pode acabar com uma duplicação gigante de mensagens e todo o SPAM que você já tinha apagado vai voltar para assombrar você (ou o usuário).
Por via das dúvidas faça o seguinte:
No WLM, crie uma pasta dentro da conta. Por exemplo, dê a ela o nome “backup”. Mova as mensagens da Caixa de Entrada para essa pasta.
Termine de configurar a conta para baixar as mensagens.
Quando o download de mensagens terminar, compare o conteúdo da pasta backup com o novo conteúdo da Caixa de Entrada. Apague todas as mensagens da Caixa de Entrada que você já tem no backup (isso pode ser feito com menos de meia dúzia de cliques, usando click para marcar a primeira e SHIFT+click para marcar a última) e depois mova o conteúdo da pasta backup para a Caixa de Entrada.
(Prefira clicar em "Responder" se estiver comentando um comentário)
Jefferson, 17 de junho de 2021, manutençãoA partir do servidor tentar acessar outra máquina pelo nome dá o erro:
0x80070035 – The network path was not found
E pelo IP dá o erro:
0x80004005 – Unspecifed error
O problema só acontecia em um punhado de máquinas da rede. Encontrei um monte de tutoriais recomendando fazer coisas que me deixaram com um pé atrás, porque eu não sabia como reverter (eram comandos Powershell) se não resolvesse. E eu não gosto da idéia de ficar deixando rastros dos meus chutes. Encontrei a dica de como resolver nesta página e com os termos usados encontrei este artigo da MS com a explicação e o tutorial.
Isso também acontece com o Windows 10 a partir da versão 1709
- Execute gpedit.msc.
- Abra Computer Configuration > Administrative Templates > Network > Lanman Workstation.
- Clique com o botão direito em Enable insecure guest logons e selecione Edit.
- Selecione Enabled e OK.
Se for essa a causa do seu problema você deve ganhar acesso imediatamente. Não é necessário reiniciar. Se não for essa a causa é só usar o mesmo caminho e selecionar Disabled.
Esse problema só impedia acesso a um punhado de máquinas do cliente. Como todas rodam Windows 8.1 e nesse cliente o padrão é não deixar o Windows atualizar eu suponho que as máquinas que negavam acesso são justamente algumas que foram atualizadas por alguma razão. Eu não pude checar porque resolvi remotamente e só tinha acesso ao servidor.
(Prefira clicar em "Responder" se estiver comentando um comentário)
Jefferson, 20 de maio de 2021, manutençãoDireto ao ponto: experimente desativar ou ativar o suporte a UEFI no setup do BIOS.
O notebook não iniciava o boot do Windows nem apresentava qualquer mensagem de erro. A minha primeira impressão era de defeito na placa mãe, mas quando eu consegui dar boot por um pendrive, passei a desconfiar de defeito no HDD, mas depois de perder uma hora testando o HDD e não encontrar erro algum, passei a suspeitar de algo corrompido na instalação. Como era um notebook de estudante, sem nada importante e que poderia estar até infestado com vírus, decidi não perder tempo e após mover todo o conteúdo do HDD para uma pasta usando um LiveCD partir para reinstalar o Windows.
Mas após a minha mídia de instalação acusar um erro sugerindo que eu deveria desativar o suporte a UEFI e eu fazer isso, acidentalmente deixei o notebook dar boot pelo HDD e desta vez em vez de ficar com a tela piscando escura, entrou na Recuperação do Windows, que era a única coisa disponível já que eu movera todos os arquivos do HDD.
Como eu já havia decidido fazer uma nova instalação do Windows, prossegui assim mesmo e acabei esquecendo de testar se reverter essa configuração faria o defeito voltar. Já devolvi o notebook ao usuário.
(Prefira clicar em "Responder" se estiver comentando um comentário)
Jefferson, 12 de abril de 2021, manutençãoPara mim isso é até contra-intuitivo pois eu acho que o lugar mais seguro para um equipamento caro que não está em uso é o depósito, desconectado da rede elétrica. O que vou descrever aqui foi um problema bizarro que encarei e ainda não estou certo de ter compreendido completamente. Mas minhas observações podem ser úteis para alguém que se deparar com os mesmos sintomas e se sinta tão perdido quanto eu estava.
O servidor é um monstrinho HPE Proliant ML350 Gen9. Daqueles que suportam dois processadores e 24 módulos de memória:
Eu não estou habituado a lidar com servidores desse porte até mesmo porque geralmente quando empresas começam a precisar de servidores assim, já precisam ter um técnico ou uma equipe deles trabalhando em tempo integral. Mas eu tenho um cliente que já foi uma empresa de grande porte e por isso ainda usa muito equipamento desse tipo, que é um exagero para o seu porte atual. Uma das tarefas que atribuí a mim mesmo quando peguei o serviço foi reduzir a complexidade do hardware, virtualizando tudo o que fosse possível. Então eu virtualizei este, que já estava mesmo com dois defeitos, e guardei a máquina para um dia que tivesse tempo de dar uma olhada nos problemas (o computador sempre travava ao ser reiniciado remotamente e meses depois a RAM que era de 24GB caiu para 16GB). Eu desliguei o servidor no dia 16 de julho e guardei no depósito.
Quando fui testar de novo pouco mais de três meses depois, no dia 22 de outubro, a surpresa: só entrou no Windows uma vez. No reboot seguinte já congelava durante o POST apresentando uma mensagem de erro que apesar de clara não justificava o problema:
312-HPE Smart Storage Battery 1 Failure – Communication with the battery failed. Its output may not be enabled.
Action: Verify battery is properly installed. Refer to user guide. Contact HPE support if condition persists.
Eu fiz uma pesquisa por esse erro e nada do que li explicava por que o servidor estava congelando durante o POST. Todas as pessoas relatando o erro o encontraram por acaso, investigando outros problemas.
O servidor também dava uma mensagem de erro de perda de configuração da controladora RAID:
Embedded Storage: Dynamic Smart Array B140i – Configuration Required
Mas esse erro já existia antes.
A bateria a que essa mensagem se refere não é a habitual CR2032, mas uma bateria similar às de notebook, escondida debaixo dos ventiladores (destaque em vermelho na foto).
Não havia uma relação direta entre meu problema e a bateria (e não explicava por que o servidor havia inicializado uma vez), mas como era minha única pista resolvi testar deixando o servidor ligado na tomada para ver se a bateria carregava. Eu já tinha visto baterias supostamente mortas “acordarem” após muita insistência. No dia seguinte o problema foi ligeiramente diferente: o servidor iniciou uma única vez, depois reiniciou sozinho enquanto eu não estava olhando e não iniciou mais. Na semana seguinte eu testei de novo: agora não iniciava nem uma única vez. O danado continuava congelando durante o POST. Eu não tinha mais nada para fazer, porque:
- Não fazia idéia de como desmontar para chegar até a bateria;
- A mensagem de erro sugere que o servidor se comunica com a bateria. Então simplesmente colocar outra com a mesma tensão nominal não ia resolver o problema. Tinha que ser uma bateria HPE e a empresa não tinha dinheiro para isso naquele momento. Eu não sei o modelo exato da bateria mas tem gente cobrando de R$1000 a R$2600 por uma (pense no tamanho da encrenca…);
- A empresa não precisava do servidor.
Deixei desligado, mas ainda propositalmente conectado a uma tomada em uma mesa da sala de TI e fui cuidar do resto dos problemas da empresa.
Pouco menos de dois meses depois, no dia 16 de dezembro, eu fui chamado porque faltara energia durante a madrugada na empresa e era preciso iniciar os servidores. Quando entrei na sala lá estava esse servidor ligado, parado na tela de logon do Windows. Impossível deixar de ver porque o monitor estava voltado para a porta.
Eu fiquei olhando para aquilo por um tempo tentando entender como era possível. Eu certamente não havia deixado esse servidor ligado e a sala era trancada a chave. Então fui olhar nos logs do Windows quando tinha acontecido. Fora às 4h51 do mesmo dia, provavelmente quando a energia voltou. O servidor simplesmente iniciou normalmente. Reiniciei mais de uma vez para testar e venho testando desde então. Problema aparentemente resolvido.
Minha conclusão até agora é que o congelamento no POST era causado mesmo pela bateria descarregada e que deixar quase dois meses na tomada conseguiu dar a carga que em uma semana não tinha conseguido. Mas se eu realmente tivesse precisado do servidor essa bateria teria me colocado numa encrenca danada.
(Prefira clicar em "Responder" se estiver comentando um comentário)
Jefferson, 21 de março de 2021, manutençãoPedido de ajuda de Luciano Sturaro feito em outro post:
“Meu PC está lento pra carregar o windows, e bota lento. E isso porque está com SSD, desconfio que tem alguma coisa prendendo a inicialização do Widnows. Tem como verificar, analisar isso? Windows 7 64bits.”
No final, como poderão ver nos comentários, ele conseguiu resolver sozinho. E a causa é interessante.
(Prefira clicar em "Responder" se estiver comentando um comentário)
Jefferson, 21 de fevereiro de 2021, manutençãoDiferentemente do que ocorre habitualmente, eu sabia exatamente por que estava vendo esse erro e já esperava por ele. Eu precisei clonar uma instalação do Windows 10 usando o Acronis Trueimage e após repetidas falhas, com cada tentativa durando uma hora, ao tentar copiar todas as partições (esses notebooks modernos costumam ter um número absurdo delas) eu me contentei com apenas copiar o MBR e a partição C:. Eu só tinha o horário do almoço para clonar o notebook desse usuário e já tinha tentado por dois dias fazer essa cópia, sem sucesso.
A cópia ocorreu sem dar erro, mas aí eu fiquei com o problema de como fazer o clone dar boot, já que a partição de boot estava ausente na minha cópia. Eu sabia que podia pegar uma instalação pronta do Windows 10, apagar a partição C: e inserir a minha no lugar, mas decidi experimentar um caminho mais direto.
Acabou sendo muito simples. Eu me baseei neste texto.
Dei boot por um DVD de uma versão similar do Windows (no caso, Windows 10 2004 x64), escolhi Reparar o Windows e nas Opções Avançadas escolhi o Prompt de Comando.
Mudei para o drive C: e me certifiquei que era essa a partição correta com a instalação do Windows que eu queria recuperar. Depois dei os seguintes comandos (só porque eu li que tinha que dar todos os três, nessa ordem):
- bootrec /fixmbr – Provavelmente desnecessário, já que eu clonara o MBR do original;
- bootrec /fixboot – Acusou acesso negado, mas eu arrisquei prosseguir assim mesmo, já que eu suspeitava que isso também não era realmente necessário;
- bootrec /rebuildbcd – Após eu responder com um “s” à pergunta sobre se eu queria adicionar a instalação encontrada, acusou Operação Concluída com Êxito.
Isso foi suficiente para resolver o problema. E o HDD continuou com uma partição apenas, pois o Windows simplesmente definiu que a partição com o Windows era agora também a partição de boot.
(Prefira clicar em "Responder" se estiver comentando um comentário)
Jefferson, 01 de novembro de 2020, manutençãoEu ainda não sei dizer exatamente qual a configuração está errada, mas me deparei com diversos casos nas últimas semanas trabalhando para o mesmo cliente e em todos eles o problema foi resolvido usando a opção “Load Optimized Defaults” ou similar do setup do BIOS. A lógica diz que de alguma forma as portas haviam sido configuradas para USB 1.1, mas não vi isso nas configurações. Exemplo de motherboard onde ocorreu: MSI G41M-S01.
Eu suponho que o problema tenha a ver com a descarga da bateria e sua substituição sem carregar o default. Eu admito que sou culpado de fazer isso. Eu criei o hábito de ao trocar a bateria só ir no setup mudar alguma coisa se algo der errado no boot, porque até a data/hora o Windows tem se encarregado de atualizar no BIOS há muitos anos quando está configurado para sincronizar o horário pela internet (o padrão). Eu assumia que o BIOS auto carregava o default automaticamente ao notar que os dados na CMOS estavam zerados, porque se não fosse assim trocar a bateria sem carregar o default deveria provocar toda sorte de problemas esquisitos no computador por causa dos valores corrompidos de configuração presentes na memória CMOS. E até hoje o único problema com o qual me deparei foi esse. E somente nas últimas semanas.
Houve uma situação em que o BIOS se ofereceu para carregar o default durante o BOOT e eu aceitei, mas isso não resolveu o problema. Talvez o BIOS tenha carregado o “fail safe default”, porque para resolver eu ainda tive que manualmente carregar o “optimized default”. Eu me deparei com esse problema agora porque esse cliente tinha dezenas de máquinas estocadas há anos e grande parte delas estava com a bateria esgotada.
(Prefira clicar em "Responder" se estiver comentando um comentário)
Jefferson, 31 de outubro de 2020, manutençãoWindows 8.1 de 32bits. A troca foi de uma PCWare PW-945GCX para uma Biostar G31D-M7. Ambas igualmente velhas (a Biostar tem chipset superior) e com southbridge Intel ICH7. Mas aí nem mesmo um teclado PS/2 funcionava após entrar no Windows. Você já notava o problema pela luz do mouse acender ao ligar o computador mas apagar durante a carga do Windows. Dando boot por um Windows live-USB (Sergei Strelec) tudo funcionava e mesmo no Windows problemático, plugar um pendrive que nunca havia sido plugado mostrava o ícone de instalação de driver, sinalizando que a port USB estava funcionando e o problema era apenas com os dispositivos de interface humana (HID).
Neste ponto é importante lembrar que no caso do Windows 8.1 o fato do teclado PS/2 não estar funcionando pode ser proposital e não ter relação com a falha USB.
Para resolver o problema, primeiro eu forcei a entrada no modo de recuperação do Windows. O único jeito que encontrei foi apertar o botão de reset durante a inicialização do sistema (com os pontinhos ainda girando na tela). De lá eu acessei as Opções Avançadas e pude entrar no Modo de Segurança. Mouse e teclado USB continuaram sem funcionar, mas o teclado PS/2 funcionou. Com isso eu pude executar devmgmt.msc e conferir que havia problemas nos drivers USB.
Então ainda no modo de segurança eu usei o teclado PS/2 para a abrir meu ISO do Snappy driver R1909 e instalar os drivers USB. A instalação falhou acusando erro. Desconfiado de que podia ser um driver muito novo para a placa, abri o ISO do meu Driverpack Solution 11 (a versão mais antiga que tenho) e mandei instalar os drivers. Isso resolveu o problema.
É possível operar tanto o Driverpack 11 quanto o Snappy Driver R1909 usando apenas o teclado, mas é um saco. Só observe que quando ENTER não funcionar experimente teclar ESPAÇO. Se eu tivesse à mão um mouse PS/2 talvez tivesse sido mais fácil. Porém ainda foi muuuuito mais fácil e rápido do que reinstalar o Windows e todos os programas.
Se isso não funcionasse, antes de partir para o caminho de reinstalar tudo eu iria tentar trocar o arquivo C:\windows\system32\config\SYSTEM pelo backup em c:\windows\system32\config\RegBack e se isso também não funcionasse (afinal, era o backup da placa mãe anterior) eu iria tentar com o arquivo SYSTEM de outra máquina rodando a mesma versão do Windows.
Pensando bem… hora de colocar no meu kit de ferramentas arquivos SYSTEM de diversas máquinas diferentes. Isso pode me tirar de um sufoco um dia.
(Prefira clicar em "Responder" se estiver comentando um comentário)
Jefferson, 12 de outubro de 2020, manutenção
O problema apareceu repentinamente enquanto eu estava usando o computador ligado ao no-break. Eis o que diz o manual a respeito:
O primeiro problema que eu tive ao ler isto foi entender: como eu diferencio bip curto do bip “normal” (os bips que eu ouvia não eram o que eu chamaria de “longos”)? O que significa “desliga a entrada do no-break”? Quem escreveu esse manual precisa se colocar no lugar do usuário.
Mas após ponderar sobre os dois você só chega a uma conclusão: em qualquer caso é defeito do no-break e deve ser levado para conserto.
Porém, apesar do que diz o manual, pode ser a bateria.
Se você já abriu um número suficiente de no-breaks para trocar a bateria já deve ter se deparado com a cena: em um dos terminais se formou uma crosta azul-esverdeada, que também ocorre com baterias automotivas, que em alguns casos já destruiu a capa plástica do terminal e nos casos mais severos já rompeu o fio e danificou o terminal da bateria. Foi isso o que aconteceu no meu no-break. A bateria original estava muito danificada para testar com ela mas com outra bateria o no-break parece operar normalmente.
Meu melhor palpite é que a “engenharia” da APC (que comprou a Microsol e deve estar empregando os mesmos engenheiros) não sabe (ou não quer) detectar um mero mau contato na bateria. Eu entendo que o sensor pode mesmo detectar uma sobretensão caso o terminal seja desconectado porque a tensão de carga, que não deveria passar de 13.6V, é de 15.6V com a bateria desconectada (confira aos 2min44s deste vídeo). Mas o manual poderia dizer “verifique a conexão da bateria interna” antes de “encaminhe para a autorizada”.
(Prefira clicar em "Responder" se estiver comentando um comentário)
Jefferson, 10 de outubro de 2020, manutençãoPara agilizar a reinstalação do Windows para o cliente do qual falei no post anterior, eu tenho uma imagem Trueimage (poderia ser qualquer outro software, como o Macrium Reflect) das instalações para cada modelo de placa mãe usada na empresa. Com isso uma reinstalação que demoraria normalmente entre 40 minutos e uma hora, sujeita a erros (muitos detalhes de configuração do Windows específicos para esse cliente) e exigindo minha atenção durante uma boa parte desse processo, fica reduzida a apenas uns 10 minutos, durante os quais eu posso fazer outra coisa. E já fica tudo pronto. O único problema é a licença do Windows, que precisa ser a que está atrelada a cada máquina para evitar problemas com a ativação.
Para contornar esse problema eu aproveito que em todas as máquinas eu já divido o HDD em duas partições para colocar na segunda, que eu não preciso apagar ao reinstalar, dois arquivos .bat:
apagar_chave_windows.bat
slmgr.vbs /upk
pause
instalar chave windows.bat
slmgr.vbs -ipk AAAAA-BBBBB-CCCCC-DDDDD-EEEEE
pause
Em cada máquina este segundo .bat contém a sua chave correta de licença. Eu não sei se realmente eu preciso apagar a licença existente antes de instalar a correta, mas faço assim mesmo por precaução.
Então após restaurar a imagem eu inicio o Windows com a máquina desconectada da rede, rodo apagar_chave_windows.bat e em seguida instalar chave windows.bat
O correto mesmo é apagar a licença do Windows antes de criar a imagem, para evitar iniciar o Windows com a licença errada e a máquina acidentalmente conectada à rede. Eu faço isso, quando lembro.
Até agora eu não tive problema com a ativação usando esse processo. Em teoria você pode acelerar a ativação rodando o seguinte comando:
slmgr.vbs /ato
Mas não funcionou comigo. A ativação sempre ocorre “quando quer”.
(Prefira clicar em "Responder" se estiver comentando um comentário)
|
|
Minutos depois o cliente me ligou dizendo que não podia fazer o acesso inverso: da máquina Windows 8.1 para o servidor Windows 2019. O erro era: “Falha de Logon: não foi concedido ao usuário o tipo de logon solicitado neste computador”
Como eu não tinha muito tempo para resolver o problema, resolvi aplicando o que é explicado aqui, que simplifico (não precisei de todos os passos) a seguir:
No servidor Windows 2019
1 – Execute gpedit.msc.
2 – Expanda até Configuração do Computador > Configuração do Windows > Configurações de Segurança > Diretivas Locais > Atribuição de Direito de Usuário
3 – Procure pela opção “Negar acesso a este computador pela Rede” e remova o usuário “Convidado” (Guest) da lista.
Funcionou imediatamente mas não estou satisfeito com as implicações disso e outro dia vou ver como resolver de outra forma.
A própria MS está “banindo” versões antigas do Windows com o server 2019 para forçar uma atualização geral para Windows 10.
Eu acho um tiro no pé, mas vai entender!
Até mesmo MSTSC – acesso remoto – tem dado problema quando acesso de windows 8.x para traz um servidor 2019.
Reforçar a segurança é sempre bom. Já percorremos um longo caminho desde a segurança ridícula do Windows 9x e até conseguimos achar graça da segurança default do XP (o “compartilhamento simples de arquivos” é uma temeridade). O problema é quando o servidor vem com o mesmo default não importando o tamanho e requerimentos de segurança da empresa
O jeito é aproveitar e atualizar para o Windows 10 enquanto é gratuito
Para a maioria de meus clientes, a não ser que eu possa desabilitar as atualizações automáticas com a mesma certeza que tenho no Windows 8.1 de que não serão habilitadas ao acaso, o Windows 10 não é melhor opção nem de graça. Do caixa de supermercado ao computador do financeiro, ninguém quer perder tempo com esse comportamento.
Bom dia! Já tentou usar o StopUpdates10?
https://stopupdates10.br.uptodown.com/windows
Ah e vamos nos preparando que logo vem o Windows “11”…
Ryan,
Acho que para esses casos com Windows 10. A ideia é o LTSC ou LTSB. Que aplicam apenas patches de segurança criticos sem “features” e etc.
Da wikipedia
Enterprise LTSC
Enterprise LTSC(Long-Term Servicing Channel) (anteriormente LTSB (Long-Term Servicing Branch)) é uma variante de suporte de longo prazo do Windows 10 Enterprise lançado a cada 2 a 3 anos. Cada lançamento é compatível com atualizações de segurança por 10 anos após seu lançamento e intencionalmente não recebe atualizações de recursos. Alguns recursos, incluindo a Microsoft Store e aplicativos agrupados, não estão incluídos nesta edição.[11][1][3] Esta edição foi lançada pela primeira vez como Windows 10 Enterprise LTSB (Long-Term Servicing Branch).[12] Existem atualmente 3 lançamentos do LTSC: um em 2015 (versão 1507), um em 2016 (versão 1607) e um em 2018 (versão 1809).[13]
— Particularmente utilizo LTSC versão 1809 de 2018 – em equipamentos críticos de Produção, IHS’s, e outras máquinas que fazem SCADA para ambiente de produção.