Ativando clientes Windows 10 em KMS Host Windows Server 2012 R2

Com lançamento do Windows 10 e o ínicio da adoção do mesmo por empresas, em ambientes onde é utilizado um KMS Host para ativar os clientes, torna-se necessário prepará-lo para que suporte a ativação dos novos clientes com este SO.
Trabalhei dias atrás em um cenário similar e mostrarei aqui como configurar o KMS Host para que suporte não só o Windows 10, mas também as versões anteriores do Windows.
No caso, a versão do KMS Host é Windows Server 2012 R2 que, de acordo com o documento abaixo, suporta a ativação de todos os SOs (server e client) desde o Windows 7 até o Windows 10:

KMS Host Keys to Products Activated for Volume Activation
https://technet.microsoft.com/en-us/library/dn502537.aspx

Bem, no KMS Host Windows Server 2012 R2, primeiramente, deve-se aplicar o update abaixo:

Update that enables Windows 8.1 and Windows 8 KMS hosts to activate Windows 10
https://support.microsoft.com/en-us/kb/3058168


Depois (muita atenção neste passo), ao acessar ao portal do VLSC (Volume Licensing Service Center) para obter a chave KMS, caso tente instalar a chave "Windows 10" no host, a operação falhará. No caso, esta key deve ser usada em cenários onde o SO do KMS Host é Windows 10, porém este apenas suportaria a ativação de SOs clients e para este cenário desejamos um KMS Host que suporte versões de sistemas operacionais cliente e servidor.
Para obter a chave correta no portal do VLSC obtenha a chave "Windows Srv 2012R2 DataCtr/Std KMS for Windows 10" seguindo o procedimento descrito no KB abaixo:

Error 0xC004F015 when you try to activate Windows 10 Enterprise on a Windows Server 2012 R2 KMS host

http://support.microsoft.com/en-us/kb/3086418

Com a mesma em mãos, configure o KMS Host Windows Server 2012 R2 da mesma forma que as versões anteriores:

> slmgr /ipk (instalar a chave)

> slmgr /ato (ativar o KMS Host)

OBS: caso o KMS host não tenha acesso direto a internet, certifique-se que o proxy esteja devidamente configurado no Internet Explorer ou, caso contrário, a ativação falhará.

Uma abraço e até a próxima.

É o fim do Forefront TMG...

Agora é oficial, o Forefront TMG 2010 será realmente descontinuado. Segue abaixo as informações:

http://blogs.technet.com/b/server-cloud/archive/2012/09/12/important-changes-to-forefront-product-roadmaps.aspx

Já adianto que no artigo não há informações se uma nova versão ou outro produto será lançado.

Forefront TMG + Symantec Endpoint Protection + cabo de rede conectado = blue screen (WTF...?!!)

Recentemente, lidei com dois casos semelhantes e no mínimo curiosos: servidor Windows Server 2008 R2 com Forefront TMG 2010. Ao conectar o cabo de rede, após alguns segundos, aparecia a famosa tela azul do Windows com a mensagem IRQL_NOT_LESS_OR_EQUAL e várias outras informações como bugcheck, nome do driver, etc.

Nos dois casos, se máquina fosse iniciada sem o cabo de rede, ela funcionava normalmente.

Bem, como um firewall depende de conexão com a rede, propor como solução não conectar o cabo de rede não daria muito certo :-)

Assim, foi efetuada a análise do dump gerado e descobriu-se que o componente Teefer2, era o culpado.

Em consulta rápida na internet, consegui o documento What is the Teefer2 driver?. Se vocês acessarem-no obterão que ele é o driver do componente de firewall do Symantec Endpoint Protection (SEP). De fato, este anti-virus estava instalado no servidor em ambos os casos.

Assim, como teste inicial, foi proposto desinstalar o suspeito e, bingo! O servidor de firewall Forefront TMG 2010 continuou operando mesmo após conectar o cabo de rede!

De acordo com o documento acima, não é possível apenas desabilitar o Teefer2:

Please note that it is not possible to disable the Teefer2 driver without removing SEP 11's firewall component.

Assim, para permitir que o servidor não ficasse sem anti-virus, a solução foi instalar o SEP sem o componente de firewall. De acordo com este link, a feature Network Threat Protection é responsável pelo firewall do SEP.

O Forefront TMG 2010 possui um driver (fweng) que captura o tráfego de rede da máquina para efetuar as inspeções necessárias e liberá-lo ou bloqueá-lo, de acordo com as regras. Neste caso, dois drivers em modo kernel estavam tentando efetuar a mesma operação e possivelmente, um acessou a área de memória do outro. Estou supondo isso, baseado na explicação acerca do erro IRQL_NOT_LESS_OR_EQUAL, na documentação oficial da Microsoft:

This Stop message indicates that a kernel-mode process or driver attempted to access a memory address to which it did not have permission to access. The most common cause of this error is an incorrect or corrupted pointer that references an incorrect location in memory.

Antes de instalar algum software anti-virus em um servidor com o Forefront TMG ou ISA Server, consulte o documento da Microsoft: Considerations when using antivirus software on FF Edge Products.

Espero ter contribuido de alguma forma. Em breve novos artigos!

Um abraço e até a próxima!

Printbrm, cadê as minhas portas?

Para quem deseja migrar servidores de impressão Windows, a Microsoft disponibiliza o Print Migration Wizard. Bem, mas este não é o foco do artigo. Vamos ao que realmente interessa.

Dias atrás me deparei com o seguinte problema: haviam dois servidores de terminal service. No primeiro deles foram instaladas e configuradas mais de 400 impressoras com portas UNC que direcionavam as impressões para outro servidor de impressão. Para não repetir a instalação das mais de 400 impressoras na segunda máquina, foi utilizado o Print Migration Wizard (Printbrm) para facilitar a tarefa. As impressoras foram exportadas da primeira máquina e importadas para a segunda, no entanto, após a conclusão da operação, verificou-se que as portas UNC não foram importadas no segundo servidor.

Bem, nenhum erro foi gerado em lugar algum e a importação tanto pela interface gráfica, quanto pela linha de comando, informava que a operação havia sido concluída com sucesso.

Após quebrar a cabeça um pouco verifiquei que no registro do primeiro servidor, a chave HKEY_LOCAL_MACHINE\Software\Microsoft\Windows NT\CurrentVersion\Ports, possuia todos os valores correspondentes as portas das impressoras e, na segunda máquina, não constavam os mesmos dados.

Fiquei intrigado e resolvi fazer alguns testes com o Printbrm e cheguei a uma conclusão. A ferramenta apenas transfere portas LPR e Standard TCP/IP, o que faz todo sentido, pois, nos servidores de impressão, as portas de impressoras sempre apontam para o endereço IP da impressora ou elas são conectadas diretamente a máquina.

As portas configuradas com UNC path são portas locais que contém o caminho \\ServidorDeImpressao\Impressora. Por se tratar de portas locais, elas não devem ser exportadas mesmo, pois são portas locais e pode variar entre diferentes computadores.

Bem, com tudo isso, para resolver o problema, no servidor de origem, as impressoras foram migradas entre as máquinas utilizando o Printbrm. Para transferir as portas, foi exportada a chave de registro HKEY_LOCAL_MACHINE\Software\Microsoft\Windows NT\CurrentVersion\Ports da máquina de origem para um arquivo .reg. Em seguida, o mesmo foi importado no servidor de destino. Para finalizar, foi necessário reiniciar o serviço Print Spooler:

> net stop spooler && net start spooler

Voilà! As impressoras e as respectivas portas UNC foram transferidas entre os servidores.

Um abraço e até a próxima!

Erro "Access is denied" ao efetuar logon em servidor de terminal service

Recentemente, me deparei com um problema um tanto bizarro. Ao tentar efetuar logon em servidor de terminal services com o Windows Server 2008 R2 SP1 instalado, utilizando uma conta do Active Directory que era membro de muitos grupos, era obtida a mensagem de erro: "Access is Denied".

Bem, ao olhar no event viewer, nenhum erro foi encontrado. Ao efetuar logon com conta, diretamente na máquina, o erro não acontecia. Ao testar em um servidor com o Windows Server 2008 SP2, o logon era efetuado com sucesso, sem erros.

Primeiramente, poderia-se pensar no problema do limite de 1015 grupos suportado pelo Active Directory, conforme descrito no artigo http://support.microsoft.com/kb/328889/en-us, porém, a conta era membro de muitos grupos, mas não chegava a 1015.

Após várias pesquisas e testes, um companheiro meu encontrou a reposta. Neste artigo da Microsoft, é descrito o valor MaxTokenSize e fala justamente sobre o problema do usuário ser membro de muitos grupos. No entanto, o documento diz que é só instalar o último service pack do sistema operacional que o problema é resolvido.

Neste caso, o último service pack estava instalado :( . Bem, encontrou-se então outro documento, situado neste link: http://support.microsoft.com/kb/938118/en-us. Ele mostra como alterar o valor MaxTokenSize.

Assim, no servidor de terminal service com problemas, foi criado o valor abaixo no registro:

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Lsa\Kerberos\Parameters
Entrada: MaxTokenSize
Tipo: REG_DWORD
Valor: 65535

Em seguida, o servidor foi reiniciado. Após isso, o problema foi resolvido e os usuários conseguiram efetuar logon sem problemas!

 

Um abraço e até a próxima!

Bloquear gravação de arquivos indesejados em compartilhamentos do Samba

O Windows Server, a partir da versão 2003 R2, possui o recurso File Screening, o qual é possível bloquear a gravação de arquivos no servidor, utilizando uma lista com extensões. Por exemplo, para a criação de uma política que bloqueia arquivos de música, as extensões mp3, wma, ogg, entrariam para a lista.

Bem, felizmente, para quem utiliza a dupla Linux/Samba, também é possível realizar tal bloqueio e de forma simples. Vamos supor que se deseja negar a gravação dos arquivos de música citados acima nos compartilhamentos.

No arquivo de configuração do Samba, vá até a seção das opções do compartilhamento e insira a diretiva abaixo:

veto files = /*.mp3/*.wma/*.ogg/

Na realidade, a política se aplica a arquivos que terminam com o nome .mp3, .wma e .ogg. Desta forma, também possível, por exemplo, bloquear arquivos que contém a string xxx no nome:

veto files = /*xxx*/

Abaixo há um exemplo da diretiva aplicada a um compartilhamento:

[documentos]
        comment = Documentos da rede
        path = /var/documentos
        valid users = @usuarios
        write list = @admin
        read only = No
        create mask = 0770
        directory mask = 0770
        veto files = /*.mp3/

Lembrando que após esta alteração é necessário reiniciar o daemon do Samba.

Esta diretiva irá não só bloquear a gravação dos arquivos, mas também irá ocultar os que já existem. Os usuários não conseguirão visualizá-los ao acessar a pasta compartilhada.

Uma outra dica é excluir ou mover os arquivos indesejados nas pastas compartilhadas do servidor de arquivos:

# find /var/documentos -name "*.mp3" -exec rm -fv {} \; (Para excluir os arquivos)

# find /var/documentos -name "*.mp3" -exec mv {} /var/lixo \; (Para mover os arquivos)

Um abraço e até a próxima.

Bloqueando broadcast no rádio Mikrotik

Recentemente, adquirimos dois rádios da Mikrotik para interligar a unidade principal da empresa a um prédio que fica próximo, alguns metros de distância. Os rádios foram instalados nos dois locais e configurados no modo bridge. Desta forma, todos os pacotes são encaminhados entre os rádios, gerando um problema: se tudo é transferido para a outra ponta, o tráfego broadcast também e? A resposta é sim!

Isso gerou vários transtornos, pois eles interligam duas sub-redes com faixa de endereços IP diferentes, porém, com o broadcast viajando pra todo lado, uma estação ao ser ligada, por exemplo, enviava um broadcast solicitando um endereço IP para um servidor DHCP e, às vezes, recebia resposta do que estava instalado em outra sub-rede.

Bem, após várias consultas ao Google, encontrei um fórum onde simplesmente era dito que se deveria "criar um filtro para o tráfego de broacast na bridge". Legal, mas e aí, onde raios fica isso? Bem, resolvi escrever este artigo, pois ele complementa, explicando como realizar a tal configuração.

Outro comentário que gostaria de fazer é que também foi criado um filtro para bloquear os pacotes arp, pois, ele só é utilizado na comunição de computadores em uma mesma sub-rede.

Bem, vamos a obra.

Gostaria de lembrar que na interface web do rádio não há esta opção. É necessário utilizar o winbox.

Após efetuar o logon, na tela inicial, clique em Bridge.

Em seguida, será aberta a tela de configuração da bridge. Vá na aba Filters e clique no botão indicado na figura abaixo.

Primeiramente, vamos criar o filtro que bloqueia os pacotes arp. Assim, nas configurações do novo filtro, deve-se escolher o chain FORWARD, o qual é aplicado aos pacotes que trafegam através do rádio, de uma interface a outra. As configurações devem ficar iguais a exibida na figura abaixo.

Para finalizar, é necessário acessar a aba Action e escolher drop.

Após clicar em OK, o filtro será criado.

Agora, vamos para a criação da regra que bloqueia o broadcast.

Na tela de criação do novo filtro, com exceção da opção MAC Protocol, as demais são iguais a do filtro para o protocolo arp.

Em seguida, deve-se acessar a aba Advanced e em Packet Type selecionar Broadcast.

Para finalizar, escolha drop na aba Action e clique em OK para salvar as alterações.

Após a criação dos filtros, eles serão exibidos conforme abaixo.

Um abraço e até a próxima.

Monitorar "Event Viewer" do Windows no Zabbix através do SNMP

Uma das tarefas que fazem parte da rotina de um administrador de redes é verificar com certa frequência os logs de eventos dos servidores em busca de erros. Dependendo da quantidade de máquinas contidas na empresa, esta atividade pode se tornar tediosa e cansativa.

Na empresa onde trabalho utilizamos o Zabbix para monitorar nossos servidores. Entretanto, as verificações se restringiam a itens como uso de processador, memória, rede, disco, entre outros. Os eventos gerados pelo sistema operacional ainda eram necessários ser visualizados, individualmente, em cada servidor. Em pesquisas pela internet, encontrei o artigo Trapping Windows Events with SNMP, escrito por Eric A. Hall, o qual ele descreve como configurar o serviço SNMP do Windows para enviar traps a uma estação coletora quando ocorrer algum evento no sistema operacional.

Primeiramente, é necessário configurar o agente SNMP do Windows para enviar os traps a uma estação coletora, no nosso caso, o servidor Zabbix. Este procedimento pode ser visto neste artigo da Microsoft.

A ferramenta chama-se Event to trap translator e pode ser acessada acessando o menu Iniciar > Executar > evntwin. Na tela inicial, deve-se selecionar a opção Custom na seção Configuration type. Isso ativará o botão Edit. Ao clicar nele, a janela expandirá um painel abaixo onde iremos selecionar os eventos que desejamos ser alertados através do Zabbix.

É possível selecionar todos os eventos, porém isto acarretaria em sobrecarga do servidor de monitoramento, pois o Windows grava entradas no log, frequentemente, sendo que a maioria é apenas informativa. 

No meu caso, optei por selecionar apenas os erros ou alertas de warning, e dos serviços específicos daquele servidor. Por exemplo, uma máquina que possui Oracle instalado, ativei os traps dos erros deste software.

Para habilitar o envio de traps por algum evento, navegue pelas pastas contidas do lado esquerdo da tela até encontrar a sessão desejada. Desta forma, do lado direito aparecerão os eventos relacionados.

Após decidir quais eventos serão configurados, basta selecioná-los e clicar no botão Add. Após terminar o processo, basta clicar em OK para salvar e encerrar o aplicativo. Este processo pode demorar alguns minutos dependendo da quantidade de eventos selecionados.

É possível também exportar o que foi alterado visando possuir um backup das configurações. Basta selecionar os eventos já configurados e escolher Export.... Será solicitado um caminho para salvar o arquivo gerado, que possui a extensão cnf. É possível importá-lo depois, caso necessário, utilizando o comando evntcmd.

Agora vamos ao Zabbix.

No servidor de monitoramento, primeiro precisamos editar o serviço SNMP (Net-SNMP). As configurações abaixo foram feitas em um servidor com o Ubuntu Server instalado.

Primeiro deve-se editar o arquivo /etc/default/snmpd alterando a linha:

SNMPDOPTS='-Lsd -Lf /dev/null -u snmp -I -smux -p /var/run/snmpd.pid 127.0.0.1'

Para:

SNMPDOPTS='-Lsd -Lf /dev/null -u snmp -I -smux -p /var/run/snmpd.pid'

E a opção TRAPDRUN conforme abaixo:

TRAPDRUN=yes

Depois, precisamos alterar o arquivo /etc/snmp/snmptrapd.conf, inserindo as linhas abaixo:

traphandle default /bin/bash /var/zabbix/bin/snmptrap.sh

authCommunity log,execute,net ComunidadeSNMP

O parâmetro ComunidadeSNMP deve possuir o nome da comunidade SNMP utilizada na sua rede. O caminho /var/zabbix/bin/snmptrap.sh no seu ambiente.

Na pasta misc/snmptrap do pacote de instalação do Zabbix, possui o arquivo snmptrap.sh. Ele deve ser copiado para o diretório indicado no parâmetro traphandle default do arquivo /etc/snmp/snmptrapd.conf conforme exibido acima.

Abaixo há um exemplo do arquivo snmptrap.sh.

#!/bin/bash
ZABBIX_SERVER="localhost"; #IP ou hostname do servidor Zabbix
ZABBIX_PORT="10051";   # Igual ao parametro 'Listen Port' do zabbix_server.conf

#No parametro abaixo, verificar o local do executavel zabbix_sender
ZABBIX_SENDER="/usr/local/bin/zabbix_sender";     # insert you path

read hostname
read ip
read uptime
read trapoid
read payload
 

hostname=`echo $hostname|cut -f1 -d' '`

payload1=`echo $payload|cut -f2- -d' '`   

read payload
payload2=`echo $payload|cut -f2- -d' '`
read payload
payload3=`echo $payload|cut -f2- -d' '`
read payload
payload4=`echo $payload|cut -f2- -d' '`
read payload
payload5=`echo $payload|cut -f2- -d' '`

str="[$hostname] - $payload1 $payload2 $payload3 $payload4 $payload5"

KEY="snmptraps";
HOST="TRAPSERVER";

$ZABBIX_SENDER -z $ZABBIX_SERVER -p $ZABBIX_PORT -s $HOST -k $KEY -o "$str"

Em seguida, é necessário reiniciar o daemon snmpd:

# /etc/init.d/snmpd restart

A próxima etapa, corresponde a configuração dos itens na interface web do Zabbix. Primeiramente, é necessário adicionar um novo host.

  

Na criação do item que tratará os traps SNMP, podería-se associá-lo ao host, diretamente, mas, honestamente, prefiro a criação de um novo template e a adição do item e do trigger no mesmo. Desta forma, após a criação do template, adicionar ao mesmo o item conforme a figura abaixo:

Depois, adicionamos um novo trigger ao template.

O trigger permitirá que os eventos sejam exibidos na Dashboard por 60 segundos. Se desejar, pode-se criar uma ação que envia um alerta por e-mail, por exemplo.

Finalmente, associamos o template ao host, que receberá os traps, criado anteriormente.

Pronto! O Zabbix passará a receber eventos gerados pelos servidores Windows. Abaixo a um exemplo de e-mail enviado pelo Zabbix contendo um evento gerado por um servidor Windows.

Um abraço e até a próxima!

Monitorando tráfego de rede no Zabbix utilizando o SNMP.

Após pesquisa na internet visando fontes que mostrassem como verificar o tráfego de rede no Zabbix, utilizando-se o protocolo SNMP, encontrei uma em especial que sugeria a criação de um item apontando para o OID do objeto de octetos transferidos na MIB. Era mostrado que o índice a ser utilizado era 65539, 65540, assim por diante.

Verificando a MIB de todos os servidores aqui da empresa percebi que alguns o índice era 16777219, por exemplo. Como tenho um template associado a todos os servidores para monitorar uma interface conectada a determinada sub-rede, seria necessário criar itens específicos para as exceções.

Decidi contornar isso criando um shell script que pode ser utilizado para monitorar uma interface ligada em qualquer sub-rede da empresa e tanto o tráfego de saída, quanto de entrada.

Por exemplo, supondo que a empresa possua as seguintes sub-redes:

• Rede-local: 172.16.0.0/16.
• Rede-Servidores: 10.1.1.0/24.
• DMZ (Rede de perímetro): 192.168.60.0/24.

Com as informações acima, deve-se criar um arquivo na pasta de scripts externos do Zabbix (verificar parâmetro ExternalScripts do arquivo zabbix_server.conf), para este artigo, utilizarei o nome trafegointerface.sh, com o conteúdo abaixo.

#!/bin/bash
# Criado por Rafael Oliveira
# Primeiro parametro IP do host, segundo SL (Redes dos servidores), L (Rede local), DMZ (Rede de perimetro)
# terceiro I (Incoming) O (Outgoing), quarto versao do SNMP e quinto comunidade.
COMUNIDADE=$5
VERSAOSNMP=$4
declare RESULTADO=0
if [ "$2" = "L" ]; then
        REDE="172.16";
elif [ "$2" = "SL" ]; then
        REDE="10.1.1";
elif [ "$2" = "DMZ" ]; then
        REDE="192.168.50";
else
        REDE=$1
fi
INDEX=`snmpwalk -v $VERSAOSNMP -c $COMUNIDADE $1 IP-MIB::ipAdEntIfIndex | grep $REDE | cut -d : -f 4 | cut -d " " -f 2`
if [ "$3" = "I" ]; then
        RESULTADO=`snmpwalk -v $VERSAOSNMP -c $COMUNIDADE $1 IF-MIB::ifInOctets.$INDEX | cut -d : -f 4 | cut -d " " -f 2`
else
        RESULTADO=`snmpwalk -v $VERSAOSNMP -c $COMUNIDADE $1 IF-MIB::ifOutOctets.$INDEX | cut -d : -f 4 | cut -d " " -f 2`
fi
echo $RESULTADO

Lembrando que o script deve ser alterado de acordo com as sub-redes contidas na empresa e os respectivos endereços IPs.

Após salvá-lo, vamos supor que desejamos monitorar o tráfego de rede entrante de todos os servidores conectados à rede de perímetro. Desta forma, podemos criar um template, que será associados a todos eles no Zabbix, com um item que possui as seguintes configurações.

Alguns pontos devem ser observados. No campo Key, os valores 2c e public, correspondem, respectivamente a versão do protocolo SNMP e comunidade. Desta forma, devem ser ajustados conforme sua necessidade. Além disso, I indica que o tráfego monitorado é o entrante para monitorar a saída, deve ser alterado para O.

Outro ponto interessante é referente a opção Custom Multiplier, que é 8. Isso deve ser feito desta forma pois o valor contido na MIB é o número de octetos trafegados.

Com isso, pode-se criar gráficos no Zabbix para uma melhor visualização dos valores e, assim, determinar se há algum gargalo de rede naquele servidor.

Abaixo temos um exemplo de um gráfico com tráfego de rede em uma interface.

Um abraço e até próxima.

Monitorando espaço em disco no Zabbix através do SNMP

Em outro artigo postado anteriormente, tratei acerca do monitoramento de serviços no Zabbix fazendo uso do protocolo SNMP. Continuando a série, vou tratar agora da verificação dos discos (partições) utilizando o mesmo protocolo. 

Vocês podem ser perguntar porque não utilizo o agente para tais tarefas. Afinal, tudo seria mais fácil. Bem, a resposta para a questão é o fato de no passado ter enfrentado problemas de performance em alguns servidores em razão do mal comportamento do agente da ferramenta que consumia muita CPU, em alguns casos, chegando a 100%.

Como a MIB possui todos os dados que necessito para monitorar os servidores, apesar de dar um pouco mais de trabalho, os recursos consumidos pelo agente SNMP em um computador é mínimo e não prejudica sua performance.

Bem, chega de história e vamos ao que interessa. Como fiz no meu outro artigo, Monitorando serviços no Zabbix através do SNMP, criei um shell script que consulta a MIB do sistema operacional, pois o índice da partição pode variar de um computador para outro.

Assim, crie um arquivo no diretório o qual estão armazenado os scripts externos do Zabbix (parâmetro ExternalScripts do arquivo de configuração zabbix_server.conf), no exemplo colocarei discolivre.sh, com o conteúdo abaixo.

#!/bin/bash

# Criado por Rafael Oliveira

# Parametro 1 - Endereco do host

# Parametro 2 - Letra que indica a particao

# Parametro 3 - Sistema operacional

# Inicializa as variaveis

declare TOTAL=0

declare USADO=0

# Comunidade SNMP

COMUNIDADE=monitora

# Obtem o ID do disco na tabela SNMP contida na MIB

if [ "$3" == "linux" ]; then

ID=`/usr/bin/snmpwalk -v 2c -c $COMUNIDADE $1 HOST-RESOURCES-MIB::hrStorageDescr | grep "STRING: $2$" | cut -d : -f 3 | cut -d " " -f 1 | cut -d . -f 2`

else

ID=`/usr/bin/snmpwalk -v 2c -c $COMUNIDADE $1 HOST-RESOURCES-MIB::hrStorageDescr | grep "STRING: $2" | cut -d : -f 3 | cut -d " " -f 1 | cut -d . -f 2`

fi

# Com o ID, realiza a consulta para obter o valor desejado. Primeiro o tamanho, em seguida, o usado.

TOTAL=`/usr/bin/snmpget -v 2c -c $COMUNIDADE $1 HOST-RESOURCES-MIB::hrStorageSize.$ID | cut -d : -f 4 | cut -d " " -f 2`

USADO=`/usr/bin/snmpget -v 2c -c $COMUNIDADE $1 HOST-RESOURCES-MIB::hrStorageUsed.$ID | cut -d : -f 4 | cut -d " " -f 2`

expr $TOTAL - $USADO

Após salvar o arquivo, lembre-se de conceder permissão de execução e alterar o dono para o usuário zabbix.

# chmod a+x discolivre.sh

# chown zabbix.zabbix discolivre.sh

Depois, no template ou host criados no Zabbix, crie um item conforme a imagem abaixo.

Em relação a figura acima, algumas observações precisam ser feitas. 

Na opção Key, os parâmetros do script precisam ser alterados de acordo com o nome da partição e o sistema operacional. Por exemplo, caso deseja-se verificar o volume /home de um servidor com o sistema operacional Linux, ela ficaria da seguinte forma: discolivre.sh[/home linux].

O parâmetro Custom Multiplier pode variar, pois o valor contido na MIB SNMP para o disco não é em bytes e sim em unidades de alocação. Desta forma, antes de defini-lo, é necessário verificar nela o item HOST-RESOURCES-MIB::hrStorageAllocationUnits.[ÍndiceDaPartição]. Este valor é o tamanho do cluster definido na criação do sistema de arquivos.

Depois criar o item para a coleta dos dados, vamos para a criação do trigger. Na criação dele ao inserir a expressão precisamos selecionar o item criado anteriormente com as opções exibidas na tela abaixo.

O valor N da figura acima é 2400000000, ou seja, 2,4 GB. Na criação do item utilizamos a unidade B (bytes). Como 1 GB equivale a 1000000000 (10^9), o valor da expressão precisa ser definido desta forma.

Lembrando que ele pode ser alterado conforme a necessidade da sua empresa. Além disso, lembre-se de definir um nome sugestivo para o trigger como, por exemplo, "Espaço limitado na partição C:". Assim, fica mais fácil identificar o problema quando o mesmo aparecer na Dashboard ou no recebimento de alguma mensagem. 

Monitorando serviços no Zabbix através do SNMP

Uma forma de monitorar o status de um serviço utilizando uma ferramenta de monitoramento é verificando se porta do mesmo está aberta. Por exemplo, poderíamos verificar se a porta 80 está OK e assim supor que o servidor HTTP está operando. No entanto, esta opção pode se tornar inútil se o serviço não responde utilizando sua porta padrão e, com isso, obter dados errôneos.

Uma forma de contornar isso é verificando se o processo correspondente ao serviço está em execução no servidor. Isso pode ser feito através do protocolo SNMP, pois na MIB do sistema operacional há uma tabela com todos os programas abertos naquele momento. Porém, o índice do mesmo pode ser alterado quando o serviço ou o sistema forem reiniciados. A forma que encontrei para contornar este problema foi a criação de um shell script que recebe o nome do executável do processo e retorna 1 caso o mesmo esteja aberto ou 0 para parado.

Este procedimento se aplica ao Zabbix em execução em um servidor Linux. As configurações e instalação das ferramentas SNMP nos sistemas operacionais podem ser encontradas facilmente na internet.

Antes de iniciar o monitoramento através de scripts próprios, é necessário verificar a opção ExternalScripts no arquivo de configuração do servidor Zabbix, geralmente chamado zabbix_server.conf, pois é neste caminho que o software procura os scripts externos criados pelo administrador.

Em seguida, crie um arquivo no diretório citado acima, aqui eu chamo de checaservico.sh com o seguinte conteúdo:

#!/bin/bash
# Criado por Rafael Oliveira
#Comunidade SNMP
COMUNIDADE=public
#Procura o ID do processo na tabela da MIB
IDPROCESSO=`/usr/bin/snmpwalk -v 2c -c $COMUNIDADE $1 HOST-RESOURCES-MIB::hrSWRunName 2> /dev/null | grep $2 | cut -d : -f 3 | cut -d = -f 1 | cut -d . -f 2`
#Retorna o status do mesmo
STATUS=`/usr/bin/snmpwalk -v 2c -c $COMUNIDADE $1 HOST-RESOURCES-MIB::hrSWRunStatus.$IDPROCESSO 2> /dev/null | cut -d : -f 4 | cut -d "(" -f 2 | cut -d ")" -f 1`
#Para o Windows o status de execucao eh 1 no Linux eh 2
if [ "$STATUS" = 1 ]; then
        echo 1;
elif [ "$STATUS" = 2 ]; then
        echo 1;
else
        echo 0;
fi

Lembrando que a variável COMUNIDADE deve ser alterada para o community SNMP utilizada em sua rede.

Após salvar o arquivo, é necessário conceder permissão de execução ao mesmo e alterar o dono para o usuário zabbix, utilizado na execução da ferramenta. Isto pode ser realizado da seguinte forma:

# chmod a+x checaservico.sh

# chown zabbix.zabbix checaservico.sh

Agora vamos a configuração do Zabbix. 

O item pode ser associado a um host ou template. No exemplo, vamos supor que desejamos monitorar o SQL Server. O executável dele chama-se sqlservr.exe. Devemos criar um item no Zabbix com as configurações exibidas na figura abaixo.

O item acima possui outras opções como, por exemplo, Update interval, que pode ser alterada de acordo com sua necessidade. Onde trabalho, utilizo um tempo de 60 segundos para o monitoramento de qualquer serviço.

Após a criação do item, vamos a criação do trigger, pois, a partir dele, será exibido um alerta na Dashboard ou poderá criar-se uma ação para o envio de alguma mensagem.

Deve acessar a opção Configuration > Triggers e selecionar o mesmo template ou host o qual o item acima foi associado. Em seguida, ao escolher a opção de criação do trigger, na linha Expression, clica-se em Insert e seleciona-se o item criado anteriormente conforme exibido abaixo.

Após clicar em Insert é retorna-se a tela de criação do trigger. É necessário inserir um nome para o mesmo.

Após escolher Save, o trigger será criado e, a partir daí, qualquer verificação que retorne um valor 0, ou seja, serviço interrompido, o Zabbix exibirá um alerta na Dashboard.

O procedimento acima pode ser utilizado, inclusive, foi aplicado em um ambiente de produção, tanto para verificação de processos no Windows quanto no Linux.

Backup automático das configurações do ISA Server

Uma forma de efetuar um backup das configurações do ISA Server é através do console de gerenciamento. Pode clicar com o botão direito do mouse sobre o nome do servidor e escolher a opção Back Up... no menu.

O problema deste método e o fato de exigir que o administrador realize o processo, manualmente, toda vez que alguma alteração for efetuada em alguma configuração. A rotina diária com vários problemas acaba fazendo-nos esquecer de realizar tais tarefas.

Assim, para evitar problemas futuros, podemos automatizar este processo. Vamos lá!

Lembrando que este procedimento foi efetuado na versão 2004 do software. Creio que na versão 2006 também funcione. No ISA 2000 o arquivo de backup gerado possui outro formato. Desta forma, este procedimento não se aplica.

Na mídia do ISA Server, no diretório sdk\samples\Admin há um script chamado ImportExport.vbs. Automatização consistem em criar uma tarefa agendada no Windows que o executa.

Assim, após copiá-lo para algum diretório do servidor, basta criar uma nova tarefa agendada, acessando o Painel de controle (Control Panel) > Tarefas agendadas (Scheduled Tasks). Na segunda tela do assistente de criação da tarefa, deve-se selecionar o programa wscript.exe situado no diretório C:\WINDOWS\System32. Após definir o agendamento desejado, deve-se inserir uma conta de usuário com privilégios administrativos no ISA Server. Na tela final, deve-se marcar a opção para exibir as propriedades avançadas.

Na aba Tarefa (Task) a linha Executar (Run) deve ser alterada. Supomos que o arquivo ImportExport.vbs foi copiado para o diretório raiz do disco C:. Assim, ela precisar ficar da seguinte forma:

C:\WINDOWS\system32\wscript.exe C:\ImportExport.vbs //B e "Caminho onde o arquivo de backup será salvo"

A opção //B informa ao wscript que suprimir os erros a serem exibidos e ignorar qualquer pergunta. Isso é necessário pois a tarefa agendada não é executada de modo interativo. A letra e indica que deve ser efetuada a opção de exportação das configurações. 

Será gerado um arquivo no formato xml e o caminho pode ser um drive local ou um compartilhamento remoto. Lembrando que ele deve possui o nome do arquivo a ser gerado com a extensão xml.