Em algumas situações a gente pode precisar forçar um truncate dos logs de transação (transaction logs) no Exchange. Em uma situação normal, o truncate acontece automaticamente sempre que seu Database é backupiado corretamente. Quando isso acontece, é registrado um Evento no "Event Viewer" com os seguintes dados:
Evento: 9780
Exchange VSS Writer (instance bb1fb924-30f2-4f2d-a038-336c5b80c0ed:15) has successfully completed the full or incremental backup of database 'DATABASE1'.
The database engine has also successfully executed log file truncation procedures for this database. (Note that this may or may not have resulted in the actual truncation of log files, depending on whether any log files existed that were candidates for truncation.)
Porém em alguns casos, a gente pode precisar forçar o truncate dos transactions logs. Por exemplo, recentemente tive que resolver um problema onde o Backup não estava sendo executado com sucesso e os logs não estavam sendo truncados por uma falha de consistência na base de dados.
Eventos 9782 565 2034 Informanco falhas de consistência no seu database
Uma solução possível para este problema é você forçar um truncate dos logs de transação.
CUIDADO: Ao executar esta ação, você só poderá recuperar mensagens até o seu último backup FULL em caso de falha.
Na sua console do Exchange, abra as propriedades do Database em questão que está apresentando os erros durante o backup. Na Aba Manutenção, marque a opção "Enable Circular Logging"
Hoje, dando aula, um aluno me pediu ajuda para montar um comando que retornasse todos os usuários que estão conectados agora em um servidor via OWA.
Para você saber número de conexões ativas, o Performance Monitor vai te fornecer este contador. Se você quiser saber quem é está conectado no OWA, segue o comando:
Get-LogonStatistics -Server mailbox_server
Onde mailbox_server é o nome do servidor Exchange com a Role Mailbox Server.
Você já passaram por um situação em que o mesmo usuário precise de políticas diferentes?
Por exemplo, você tem na sua empresa a figura de uma recepção para pagamento de faturas. Quando um operador usa um computador destinado para o software de recebimento financeiro (caixa), você quer a máquina toda travada, mas quando ele usar uma máquina de uso comum, você pode liberar para ele uma política de segurança mais branda.
Outro exemplo comum, você usa um servidor Remote Deskto Service na sua rede e precisa que as políticas que um usuário recebe quando usa sua estação de trabalho comum seja diferente das políticas recebidas quando ele se loga no servidor.
Uma A.T.E (Adaptação Técnica Emergencial, vulgo gato), seria criar para este usuário duas contas de usuários, uma que ele deve usar quando seus acessos precisam mínimos e outro quando seus acessos podem ser mais comuns. Mas isso pode complicar as coisas, principalmente se você usa outras ferramentas que usam o serviço de diretório do AD, como Lync, OCS, Exchange, etc.)
Agora uma solução bonita para este problema é usar um recurso chamado: User Group Policy loopback processing mode. Isso funciona assim:
1. Crie uma OU nova e coloque as máquinas que precisam de uma política mais especial. Nos exemplos acima, seriam as máquinas de caixa ou os servidores de RDP;
2. Abra o GPMC e crie uma GPO linkada à OU que vc criou no passo anterior.
3. Dentro desta GPO, edite a seguinte política:
Policies >> Administrative Templates >> System >> Group Policy >> User Group Policy loopback processing mode.
Ao habitar a política, poderemos notar dois modos. Replace e Merge.
Ao habilitar esta política, você faz com que a seção desta GPO de "User Configuration" seja aplicada ao usuário que se logar nesta máquina, independente de qual OU esteja o objeto do usuário. Mesmo que o usuário não esteja nesta OU, mas apenas o computador, a GPO será aplicada.
Os modos Replace e Merge, significam o seguinte:
Replace: A(s) GPO(s) que seriam aplicadas ao usuário por estarem linkadas à OU do usuário, serão ignoradas. No lugar dela, serão aplicadas as configurações de usuário da GPO linkada à OU do computador.
Merge: Ele aplica a(s) GPO(s) dos usuários, porém, as configurações de usuário definidas na GPO de loopback aplicada ao computador será prioritária em relação às configurações do usuário.
Quem já tentou instalar um NLB (Network Load Balance) usando máquinas virtuais no Hyper-V já deve ter percebido que, se você deixar todas as configurações padrões, na hora de criar o cluster NLB, você recebe um erro.
Para resolver isso, nas configurações das máquinas virtuais no Hyper-V, lembre-se de marcar a opção que habilita MAC Spoofing. Esta opção precisa estar maracada para funcionar o NLB.
Abraço e boa sorte!
O objetivo deste artigo é tentar explicar de uma maneira clara e concisa como funciona a criptografia de arquivos nativo do sistema de arquivos NTFS da Microsoft.
Resumidamente, criptografar o arquivo é uma forma de garantir que apenas você poderá ter acesso às informações contidas nele. Ao criptografar um arquivo, ele pode ser aberto apenas por você e, se definido anteriormente, um agente de recuperação do seu computador ou do seu domínio. O agente de recuperação é uma conta de usuário que também consegue abrir algum arquivo criptografado.
Como criptografar?
Criptografar um arquivo ou pasta é tão simples quanto alterar qualquer outro atributo e o usuário normalmente não precisa entender este processo a fundo. Basta seguir os seguintes passos:
1 - Botão da direita em cima do arquivo ou pasta
2 - Propriedades
3 - Avançado
4 - Selecionar a opção de criptografar conteúdo para proteger dados
Aconselho sempre evitar criptografar apenas um arquivo. O processo de criptografia de um arquivo individual não faz com que novos arquivos sejam criptografados. Ao abrir um arquivo criptogrado em algum programa que gera um arquivo temporário para salvar as alterações, no momento que você clicar em salvar, ele vai excluir o arquivo original, salvando em definitivo o arquivo temporário. Neste momento o arquivo deixará de ser criptografado. Para evitar isso, marque a criptografia na pasta, selecionando para criptografar todos os arquivos contidos nesta pasta.
Como funciona?
Dentro do perfil do usuário ele tem um par de chaves de certificado específico para manipular arquivos criptografados. Com uma chave pública ele criptografa o arquivo e com a chave privada ele abre o arquivo criptogrado. Atenção, o certificado está dentro do perfil do usuário. Caso você tenha algum problam com este perfil, caso ele seja corrompido, se você não tiver um backup deste certificado, não será mais possível abrir algum arquivo criptogrado. Então certifique-se de fazer uma cópia deste certificado e guardá-lo em local seguro.
Para visualizar este certificado:
1 - Execute o MMC
2 - Clique em "Adicionar remover Snap-in"
3 - Selecione Certificado
4 - Selecione "Usuário Atual"
5 - Em Pessoal, clique em Certificados
Você verá um certificado com o objetivo de "Sistema de Arquivo Criptofado" ou "Encripting File System", com o nome do usuário logado.
Este é o certificado que você deve copiar em backup para não correr o risco de perder os arquivos criptogrados. Antes tarde do que nunca, se você trabalha com arquivo criptogrado e não tem backup disso, corra.
O que é o agente de recuperação EFS?
Em um computador, ou no domínio é possível ter um agente de recuperação para arquivos criptogrados. Se isso estiver definido na sua máquina ou na sua rede corretamente, existe uma conta que, se tiver um certificado correto, pode abrir qualquer arquivo criptografado por qualquer pessoa. Você pode até não gostar disso, mas é a única forma que foi pensada para que uma empresa não perca informações críticas em sua rede ou nos seus computadores com a perda de um perfil de usuário.
Atenção, você precisa definir o agente de recuperação ANTES de criptografar qualquer dado. Se o agente de recuperação for definido corretamente, sua chave pública também é usada no algorítmo de criptografia do arquivo ou pasta, logo, sua chave privada também pode ser usada para descriptofar o arquivo, entendeu?
Para definir um agente de recuperação EFS, faça o seguinte:
1. Faça logon como um Administrador.
2. execute o seguinte comando um prompt de comando "cipher /r: certificado" onde certificado é o nome do arquivo do certificado do agente de recuperação.
3. Quando solicitado, digite uma senha que será usada para proteger esse certificado.
Pronto, você gerou um par de chaves para atribuir a uma conta. Este procedimento acima vai gerar um arquivo .cer (chave pública) e um arquivo .pfx (chave privada).
Agora vamos designar a conta para ser o agente de recuperação propriamente dito.
1 - Crie uma conta para este fim
2 - Faça logon na conta que deseja designar como agente de recuperação
3 - Em certificados, selecione a pasta Certificados - Usuário Atual\Pessoal\Certificados
4 - No menu Ação, todas as tarefas, clique em Importar
5 - Na página Arquivo a ser importado, digite o caminho e o nome do arquivo do certificado (.pfx)
6 - Digite a senha que você definiu anteriormente
7 - Marque para Selecionar automaticamente o armazenamento de certificados conforme o tipo de certificado
8 - Clique em Concluir
9 - Agora que certificado foi importado com sucesso, vamos atribuí-lo para ser usado como agente de recuperação. Execute o aplicativo secpol.msc
10 Em configurações locais, Configurações de Segurança, Diretivas de Chave Públicas, Sistema de arquivos Criptografados, no menu Ação, clique em Adicionar agente de recuperação de dados
11. Na página Selecionar agentes de recuperação, clique em Procurar nas pastas, e vá para a pasta que contém o arquivo .cer criado anteriormente (chave pública);
12 Selecionar o arquivo e clique em Abrir
13. A página selecionar agentes de recuperação, mostra um agente chamado "USER_UNKOWN", ou usuário desconhecido, Não se preocupe com isso, é normal, não existe a informação do nome do usuário dentro do arquivo
14. Clique em Avançar e Concluir
Agora este usuário pode ser usado para abrir qualquer arquivo criptografado a partir de agora neste computador. Se você administra um domínio, poderá usar uma group policy para poder distribuir esta chave pública do agente de recuperação para todas as máquinas. Assim a conta designada como agente de recuperação é atribuída a todas as máquinas.
Um procedimento de segurança é você fazer um backup da chave privada deste agente em uma ou mais mídias, excluí-la de qualquer computador e deixar a mídia armazenada em cofre. Lembre-se que esta conta tem acesso a todo arquivo dentro da corporação que esteja criptografado.
Descrição do Problema
Tenho em minha corporação um cluster de servidores WEB montado em cima de NLB e com o conteúdo das páginas replicado através do DFS Replication. Todo o site é replicado com sucesso para qualquer formato de arquivo. Meus problemas começaram quando a webdesigner reclamou que alguns arquivos que ela coloca com sucesso em um dos servidores, no local correto, simplesmente não replica. Minha primeira ação foi achar que ela estava fazendo alguma coisa errada, mas qual não foi minha surpresa quando descobri que era exatamente isso. Alguns arquivos de imagem, que ela salva em um dos servidores, não replica para os demais. Analisando o erro vi que o arquivo está correto, não é corrompido, não registra erro no event viewer e está com as permissões corretas, mas não replica. E para completar o problema, outros arquivos de imagem, no mesmo formato do rebelde, ela coloca exatamente no mesmo local com as mesmas permissões, e replicam perfeitamente para todos os servidores.
CAUSA
Depois de uns bons cabelos arrancados, pesquisa no google, bing e meus recursos de criatividade, consegui resolver o problema e posto os passos usados no troubleshooting para você ter como referência em casos parecidos.
Por padrão o DFS-R gera um arquivo de log com todos os seus processos com considerável nível de riqueza. Estes arquivos de logs são gerados na pasta %systemroot%\debug. Analisando este log achei a seguinte entrada referente ao meu arquivo que não estava sendo replicado:
20101103 08:34:54.959 1912 USNC 1204 UsnConsumer::ProcessUsnRecord Skipping USN_RECORD with FILE_ATTRIBUTE_TEMPORARY flag:
+ USN_RECORD:
+ RecordLength: 88
+ MajorVersion: 2
+ MinorVersion: 0
+ FileRefNumber: 0x1200000000446a
+ ParentFileRefNumber: 0x1000000013b82
+ USN: 0xf20fdf18
+ TimeStamp: 20101103 08:34:54.959 E. South America Standard Time
+ Reason: Close File Delete
+ SourceInfo: 0x0
+ SecurityId: 0x3f0
+ FileAttributes: 0x120
+ FileNameLength: 26
+ FileNameOffset: 60
+ FileName: FlashImg.jpg
Quando li este log, entendi que o arquivo foi pulado do processamento por ser um arquivo temporário. Mas o arquivo não começa com "~" ou termina como .tmp, como são as exceções padrões do DFS. É um arquivo .jpg como vários outros. Então, de onde diabos este infeliz achou que este arquivo era temporário? Neste momento descobri que, apesar de não aparecer em quase nenhuma interface padrão do Windows, console ou aplicativo, existe um atributo em cada arquivo em uma partição NTFS que marca este arquivo como temporário. Este atributo é mostrado na linha copiada acima: + FileAttributes: 0x120
Pesquisando um pouco percebi que o 0x120 representa os atributos marcados neste arquivo, onde 0x100 representa uma flag de arquivo temporário e 0x20 representa um arquivo pronto para ser arquivado (arquive).
O problema é que DFS Replication não replica arquivos com esta flag de temporário marcada. Esta é uma política implícita e não existe opção de mudá-la (pelo menos nas versões atuais). Ele simplesmente pula o arquivo e pronto. Uma maneira de visualizar este atributo via linha de comando para você poder testar seus arquivos é através da seguinte linha de comando:
fsutil usn readdata Nome_arquivo (Execute como administrador e em arquivos locais);
O resultado será algo perecido com isso:
Major Version : 0x2
Minor Version : 0x0
FileRef# : 0x000c000000044e24
Parent FileRef# : 0x000200000002c892
Usn : 0x000000008d082d50
Time Stamp : 0x0000000000000000 00:00:00 01/01/1601
Reason : 0x0
Source Info : 0x0
Security Id : 0x0
File Attributes : 0x120
File Name Length : 0x1a
File Name Offset : 0x3c
FileName : Nome_Arquivo
Ainda como referência, veja a seguinte tabela de atributos que podem ser representados como saída deste comando:
READONLY 0x1
HIDDEN 0x2
SYSTEM 0x4
DIRECTORY 0x10
ARCHIVE 0x20
DEVICE 0x40
NORMAL 0x80
TEMPORARY 0x100
SPARSE_FILE 0x200
REPARSE_POINT 0x400
COMPRESSED 0x800
OFFLINE 0x1000
NOT_CONTENT_INDEXED 0x2000
ENCRYPTED 0x4000
Resolução
Como opção de resolução podemos simplesmente desmarcar o atributo de arquivo temporário, porém com esta solução você mata apenas o sintoma, e acaba fazendo o arquivo ser replicado. O ideal é você achar em que momento este arquivo se tornou temporário e por qual aplicação e tentar mudar o comportamento desta aplicação para resolver o caso. Só assim você garantirá que isso não voltará a acontecer.
Mas se você quiser limpar o atributos de temporário, pode fazer isso até para vários arquivos dentro de uma pasta, porém não é tão simples como usar um attrib, já que este aplicativo não toma ciência deste atributo. Instale o powershell neste servidor (http://www.microsoft.com/powershell) e execute o seguinte comando:
Get-childitem D:\Data -recurse | ForEach-Object -process {if (($_.attributes -band 0x100) -eq 0x100) {$_.attributes = ($_.attributes -band 0xFEFF)}}
Onde D:\Data é o diretório onde estão seus arquivos. A opção -recurse vai executar o comando em todos os subdiretórios.
Também existe aplicativos terceiros como File Tweak que te dá a chance de controlar este atributo de uma maneira mais simples.
Um grande abraço a todos
Você já tentou usar o System Center Operations Manager para simplesmente executar um "ping" para um dispositivo na sua rede? Apesar de parecer extremamente simples e básico em qualquer software de monitoramento, quem já tentou fazer isso no SCOM sabe que não é tão simples. O discovery de Network Devices no SCOM exige que o dispositivo tenha suporte a SNMP v1 ou v2.
Existe alguns dispositivos de rede como alguns APs, Mainframes, aparelhos de ponto e acesso, etc que não suportam SNMP, mas que precisamos ser avisados se ficarem offline. Após uma certo tempo de pesquisa, estudando scripts complexos e artigos não muito simples, consegui achar uma solução fácil com a valiosa ajuda do amigo Cleber Marques, da Opslogix, (http://www.clebermarques.com/), especialista na plataforma System Center.
Para conseguir executar um simples ping para um dispostivo qualquer, existe um software terceiro GRATUITO da opslogix (http://www.opslogix.com/), que extende o Operation Manager para conseguir este monitoramento. Inclusive com gráficos de performance, relatórios de tempo de resposta, disponibilidade e etc. Veja abaixo exemplos de ScreenShots.
| Tela de Status |
| Relatório de Tempo de Resposta |
| Relatório de Disponibilidade |
Para instalar o procedimento é simples:
1 - Registre o seu e-mail no site abaixo e faça download do pacote de gerencimanto (coloque e-mail válido porque o link para download vai para seu endereço);
http://www.opslogix.com/#ping
2 - Depois do download concluído, e executado, você vai extrair 3 arquivos principais. Um é o manual em pdf, outro é o arquivo de instalação msi que deve ser instalado no RMS (Root Management Server) e o Outro é o extensor da console que deve ser instalado em toda máquina com uma console instalada; Siga o procedimento do manual.
3 - Depois disso, na parte de Monitoring, você vai ver uma nova View chamada Opslogix. A configuração é bem intuítiva, você precisa adicionar os dispositvos que devem ser monitorados informando um display name e um nome ou endereço IP que será monitorado (pode ser feita uma carga grande através de CSV), e selecionar entre os servidores e máquinas já monitoradas com agente, aquele que será usado para executar o ping.
Pronto, você já tem o monitoramento por ping e relatórios para monitorar sua rede. Ressalto ainda que a empresa ainda oferece alguns Pacotes de Gerenciamentos que não são gratuítos, mas que vale a pena saber que existe, por exemplo, um que extende o Operation Manager para suportar SNMP v3, que ainda não é nativo na solução.






