terça-feira, 9 de novembro de 2010

Como assim não existe uptime no Windows?

Recentemente um artigo do Viva o Linux me chamou a atenção:

Comando uptime no Windows?


Sim, o artigo está correto, o comando uptime no Windows é uma ferramenta do Resource Kit, um pacote de ferramentas de apoio que vejo instalado em 10 de cada 10 servidores Windows bem administrados.


Uptime é provavelmente o modo mais fácil de obter esta informação, mas não é o único. Há tempos escrevi umas linhas sobre as maneiras alternativas de obter esta mesma informação e, embora eles não sejam exatamente o caminho menos complicado, cada um deles revela uma particularidade interessante da arquitetura Windows.
 
Método 1: net statistics server

Sistemas suportados: Windows 2000, Windows XP, Windows 2003, Windows 2008

Onde obter:  Embutido no sistema operacional. Um artigo da Microsoft sobre este comando: http://support.microsoft.com/kb/555737

Basta abrir a linha de comando e digitar:

net statistics server

O resultado na tela será:

C:\>net statistics server
Server Statistics for \\TEST-PC
Statistics since 4/27/2009 8:00 PM
Sessions accepted                  1
Sessions timed-out                 0
Sessions errored-out               0
.
.
.

Para saber o uptime, apenas a segunda linha do resultado nos interessa, pois ele mostra há quanto tempo o serviço SERVER (responsável por compartilhamento de arquivos via SMB) está no ar.

Vantagens: não requer instalação de software, o comando estará disponível em 100% dos sistemas suportados, rápido de executar.

Desvantagens:  só é possível obter o uptime local, e o uptime mostrado é o do serviço SERVER. Se este serviço tiver sido reiniciado há pouco ou não estiver sendo executado, o resultado não será exato.



Método 2: Uptime.exe (sim, nós temos uptime!)

Sistemas suportados: Windows NT 4.0, Windows 2000, Windows XP, Windows 2003, Windows 2008.


É uma ferramenta bem velhinha, do tempo do NT 4.0, mas que acredito que faça parte da mala de truques de muitos sysadmins. O resultado dela é cru:

C:\>uptime
\\TEST-PC has been up for: 2 day(s), 17 hour(s), 12 minute(s), 57 second(s)

Mas a parte divertida desta ferramenta é verificar o uptime em servidores remotos, algo que é muito útil para criar scripts que cuspam o uptime de um grupo de servidores.

Vantagens: verifica o uptime de sistemas remotos, mostra o uptime real, ao contrário do método anterior.

Desvantagens:  não é nativo do sistema operacional, isto é, você vai ter que instalar a cada vez que usar. Recomendo mantë-lo no seu pen drive/CD/DVD de truques para usar a qualquer hora. Apesar de permitir a execução remota, ele necessita de comunicação com o Event Viewer remoto, ou seja, não irá funcionar em servidores atrás de um firewall que barre as portas usadas pelo serviço.


Método 3: Event Viewer, eventos 6008 (crash) e 6009 (shutdown/reboot normal)

Sistemas suportados: Windows NT 4.0, Windows 2000, Windows XP, Windows 2003, Windows 2008.


Eis um “truque” que uso muito: saber exatamente quando o servidor reiniciou pela última vez e se a causa foi uma falha inesperada ou se foi reiniciado manualmente por um administrador é vital no trabalho de qualquer sysadmin. Ao iniciar uma investigação, a primeira coisa que faço é filtrar o event viewer em busca do evento 6008 (reínicio inesperado) ou 6009 (reboot normal).




Figura 1: Event Viewer com filtro para evento 6009.


Note que a fonte deste evento é o serviço eventlog, que é  o serviço responsável pela manutenção dos logs encontrados no event viewer. O evento 6009 é logado sempre que serviço é iniciado após um reboot. O 6008 é logado após um reboot causado por fatores externos (interrupção da energia ou falha severa de hardware) ou após um crash BSOD.


Figura 2: um evento 6008, com a data/hora do reboot inesperado.  Observem a correlação com o evento 6009 correspondente na fig. 1.
 
Note que o evento 6009 não é classificado como um erro (Type: Information), já que o eventlog entende houve um reboot com intervenção manual, mas o 6008 é classificado como um erro e requer atenção.

Vantagens: permite verificar não só o uptime, mas também se o último reboot foi causado por um problema ou se houve intervenção manual.

Desvantagens:  ok, eu menti, este método não mostra diretamente o uptime do sistema, apenas o horário do último reboot. Mas saber a diferença entre um 6009 e um 6008 é tão fundamental que não resisti à tentação de explicar.


Método 4: SystemInfo

Sistemas suportados: Windows 2000, Windows XP, Windows 2003, Windows 2008 (com ressalvas).

Este é o método preferido por quem gosta de linha de comando ou quem precisa de uma saída bem organizada para a informação de uptime. O SystemInfo lista várias informações extremamente úteis sobre o sistema, como a disponibilidade de memória e os hotfixes instalados, mas se você precisa apenas do uptime, simplesmente execute na linha de comando:
                                                                     
systeminfo | find /i "up time"

O resultado será:

C:\>systeminfo | find /i "up time"
System Up Time:            2 Days, 21 Hours, 34 Minutes, 52 Seconds

Curiosamente, no Windows 2008 não existe a informação de uptime na saída do SystemInfo. Utilizando systeminfo | find /i "time" o resultado será o horário do último reboot. 

Vantagens: não requer instalação de software, a saída é limpa, mas o comando pode demorar um pouco a ser executado por inteiro. Adicionando o switch /S ao comando systeminfo, pode-se obter o uptime de sistemas remoto.

Desvantagem: no Windows 2008, a saída mostra apenas o horário do último reboot.


Método 4: Task Manager

Sistemas suportados: Windows 7, Windows 2008

Novidade no Windows 7 e no Windows 2008, o bom e velho Task Manager aprendeu alguns truques novos,  como mostrar a informação de uptime na tab performance:
Figura 3: tab Performance do Taskman com a informação de uptime.
 
Vantagens: obtenha a informação de uptime com dois cliques no mouse.

Estes são os cinco métodos que mais utilizo por aqui. Se você conhece ou usa outros métodos, por favor avise pelos comentários.

sábado, 27 de fevereiro de 2010

Rise from your grave!

Recentemente tive que formatar meu computador de trabalho e não tive como salvar minhas VMs de laboratório. Como terei que recriá-las do zero, decidi começar uma série de posts que vai mostrar como criar três VMs para simular um ambiente de alta disponibilidade para aplicações com o uso do MSCS (Microsoft Cluster Service) no Windows 2003 R2.

Começo daqui a pouco, assim que a preguiça deixar :-)

terça-feira, 18 de agosto de 2009

Como encontrar o OU container de um usuário ou grupo

Situação: Preciso criar um novo grupo dentro da mesma OU de um grupo existente.

Problema: Não sei em que OU o grupo original foi criado. A busca do ADUC retorna o grupo, mas não a OU.

Solução: Abrir o ADUC, clicar em View, Advanced Features. Uma nova tab é habilitada nas propriedades da conta/grupo - na tab "Object" você encontrará o canonical name, que nada mais é que o caminho do objeto no diretório, incluindo a OU que contém o objeto.

Fica a dica (argh).

domingo, 26 de outubro de 2008

De zero a virtual em 60 minutos - como instalar Windows XP ou Vista no Virtual PC 2007

Nota: este vai ser um post bem leve tecnicamente. O objetivo é mostrar ao pessoal da FATEC SBC o passo à passo de uma instalação de uma camada de virtualização, criação de uma VM e instalação de um OS.

Eu só vou deixar de fora os passos da instalação do OS em si, fica como lição de casa!

Material necessário:

  • Microsoft Virtual PC 2007
  • CD-ROM ou um .ISO de instalação do Windows XP ou do Vista

Vamos ao passos:


Instalar o Virtual PC 2007

Vamos começar baixando o bichinho:

Download do Virtual PC 2007 (apenas em inglês)


Basta executar o setup.exe baixado para iniciar a instalação.




Método padrão de instalação NNF - Next, Next, Finish :-)


Leia com extrema atenção as letrinhas miúdas antes de aceitar o contrato!

Outro Next!


Install!


Finish!

Pronto, instalado. Doeu? Abra o VPC para começar a parte 2, criando nossa primeira VM.



Criando uma Virtual Machine


Ao abrir o VPC pela primeira vez o wizard de criação de novas VMs será iniciado.


Vocês já sabem o que fazer neste ponto :-)


As três opções aqui são:

  • Criar uma nova VM - esta opção permite a criação de uma VM do zero, incluindo a criação de um disco virtual para ela.
  • Criar uma VM default - esta opção vai criar uma VM standard com 128MB de RAM alocada, mas sem um disco virtual associado. Útil se você vai utilizar um disco virtual já existente gerado por outra pessoa.
  • Adicionar uma VM existente - esta opção vai adicionar uma VM existente, definida em um arquivo com a extensão .VMC, ao VPC.
Escolham a primeira opção para seguir em frente.


Hora de escolher o nome e o diretório aonde a VM será armazenada. O VPC2007 criará por padrão as pastas para a VMs dentro da pasta "My Virtual Machines", que foi criada dentro da pasta "Meus Documentos" do Windows. No exemplo acima, será criada uma pasta "Meus Documentos\My Virtual Machines\FATEC SBC". Para mudar a localização, basta clicar em browse. Eu considero uma boa prática deixar as VMs na pasta padrão, fica mais fácil de não esquecê-las na hora de migrar de PC.


Hora de escolher qual sistema operacional será instalado na VM. O que o Wizard faz, neste momento, é apenas configurar a nossa VM com os requisitos de hardware mínimos para o sistema operacional suportado. Por exemplo, ao selecionar Windows XP, o valor de "Memory" muda para 128MB. Selecionando Windows Vista, o valor sobe para 512MB. O tamanho de disco também muda de acordo com o OS selecionado. Selecione a opção adequada e Next!



Esta tela permite o ajuste da memória selecionada para a VM. Como não queremos mexer nela agora, Next.


A primeira opção permite o uso de um arquivo .VHD existente. Como vamos criar um novo, selecione a segunda opção e Next.


Notem o caminho do disco virtual. Aqui podemos configurar o tamanho de disco que será usado. Como estou criando uma VM de testes, posso colocar um disco bem pequeno, já que ele irá conter apenas o sistema operacional e um aplicativo ou outro qualquer. No exemplo, selecionei 4096MB, ou 4GB, o suficiente para a instalação do Windows XP.

Isto significa que um arquivo .VHD com o tamanho de 4GB será criado. Como o limite de tamanho de arquivos no FAT32 é de 4GB, se vocês estiverem utilizando um PC com este sistema de arquivos não será possível criar VMs com discos grandes.


Finish!


Iniciando a VM

Antes de iniciar a VM, vamos passear pela opções de configuração do hardware virtual. Nosso Virtual PC ficou assim agora:


Clique no botão Settings para visualizar as configurações de hardware virtual e outras opções desta VM.


Notem que é possível, depois de criada a VM, modificar o tamanho da RAM virtual alocada, sempre dentro do limite da RAM instalada no PC físico. Não, não dá para fazer mágica e criar uma VM com 2GB de RAM em um PC com 512MB!

Também é possível adicionar mais discos virtuais, desligar a placa de som virtual, desabilitar portas paralelas e seriais virtuais, escolher o comportamento da VM ao fechar o programa e muito mais. Depois de brincar o suficiente nesta tela, volte ao VPC para inicar a VM clicando no botão Start.


A partir deste momento, você pode acompanhar sua VM realizando o boot virtual como se fosse um PC físico, passando pelos testes de memória da BIOS e tudo. Eventualmente você chegará até uma tela de erro como a acima, pois neste momento o PC não possui um sistema operacional instalado!

O que fazer? Se você possui um CD de instalação do XP ou Vista, basta inseri-lo no CD-ROM físico do host e reiniciar a VM (menu Action - Reset). A VM é pré-configurada para executar o boot a partir do CD-ROM virtual, que já está mapeado para o CD físico.

Entretanto, para que eu vou ficar carregando plástico para cima e para baixo quando eu posso usar um arquivo que simula o conteúdo do CD-ROM? Para quem não conhece, um arquivo com a extensão .ISO é uma cópia da estrutura de um disco físico e é muito utilizado para distribuir CDs de instalação pela internet. O arquivos .ISO estão prontos para serem gravados direto para um CD-ROM através de programas especializados ou até mesmo montados como CDs virtuais em um PC físico. Em nosso caso, vamos utilizar um .ISO para simular o disco de instalação do Windows XP/Vista.

Para estes sistemas operacionais, a maneira mais fácil de obter um .ISO é através do MSDN ou MSDNAA. Existem também programas que geram um .ISO a partir de um disco físico. Fica como lição de casa para vocês encontrar um programa que faça isto.

Se você quiser se aventurar a instalar Linux no lugar de XP/Vista nesta VM, todas as distribuições Linux possuem páginas de download dos .ISO de instalação.

Com o .ISO em mãos, com a VM ligada, basta inserí-la no disco virtual, através do menu CD - Capture ISO Image.


Pronto! Com o .ISO inserido, basta reinicar a VM (Action - Reset) para iniciar a instalação:


Daqui para a frente é com vocês! Dicas: após ter o sistema operacional instalado, instale as VM Additions nele - são ferramentas da camada de virtualização que vão permitir um melhor funcionamento do video e do mouse virtuais e maior integração da VM com o host físico. A opção de instalar está no menu Action - Install or Update Virtual Machine Additions. Para instalar software na VM, a maneira mais fácil de transportar arquivos para dentro dela é através da opção de Shared Folders da VM - esta opção é acionada clicando com o botão direito na pasta na barra de status da VM.

terça-feira, 19 de agosto de 2008

Montando ISOs do MSDN no VI Client

Ho!

Um bug divertido - e não consertado ainda, até a versão 2.5.0 build 64192 do VI Client - é fato de não conseguir abrir certas ISOs, em especial as que eu tentava montar direto do DVD do MSDN. Curioso com o fato de que algumas ISOs funcionavam perfeitamente, fui atrás do problema e descobri a solução:

Renomeie a extensão do arquivo .ISO para caixa baixa :-) Isto mesmo, pegue o exemplo abaixo, direto do MSDN:

Arquivo ISO: EN_WIN2003_ENTWITHSP1_WIN2003_STANDARDWITHSP1.ISO

Vamos tentar montá-lo no VI Client:



E agora vejamos o erro:


Efeitos sonoros no post: www.sadtrombone.com :-(

Solução? Renomear a extensão .ISO para .iso. Sim, provavelmente algum engenheiro de qualidade de software tomou uma enorme bronca por conta disto. VMware, se vocês estiverem lendo isto, eu conheço alguns engenheiros de software ninjas que não deixariam algo assim passar. Drop me a line.

terça-feira, 17 de junho de 2008

Invertendo adaptadores de rede no ESX - via linha de comando

Problema clássico: configuramos o console de gerenciamento do ESX num adaptador de rede qualquer. Ao espetar o cabo de rede, você percebeu que o Service Console foi conectado à placa errada. Para quem não pode ir fisicamente ao servidor e trocar os cabos (meu caso!) ou simplesmente é preguiçoso (meu caso também!), o jeito é recorrer à linha de comando para resolver o problema.

Nota para os novatos em ESX: não existe interface gráfica local para gerenciamento do ESX, a única opção para gerenciamento quando não temos rede é usar a linha de comando. Para os administradores de ESX, nenhum problema. Para os implementadores ou engenheiros de suporte: fique íntimo da linha de comando :-)

Um pouco de teoria

No ESX, os endereços ip não são associados a uma placa de rede diretamente, mas sim a uma interface virtual, que é associada a um switch virtual que, por sua

vez, uma placa física como uplink. Algo assim:

Interface Virtual do Service console (vswif0) ----> Grupo de portas "Service Console" no switch virtual vSwitch0 ----> vmnicx

O gráfico abaixo, tirado da interface de gerenciamento Virtual Center, ilustra esta conexão:

Você pode observar isto pelo resultado de um ifconfig na linha de comando: o único adaptador de rede com IP será o vswif0 em uma instalação nova de ESX.

Suponhamos que você tenha dois adaptadores de rede no servidor. No VMware ESX 3.5 estas interfaces não são nomeadas como no Linux, como eth0, eth1, mas sim como vmnic0, vmnic1, e assim por diante.

Mas o que acontece se alguém ligou o cabo de rede no adaptador de rede errado? O que fazer, se estamos a milhões de quilômetros de distância do servidor?

Oras, mudar a placa de rede. Isto é trivial, tanto na interface de gerenciamento do ESX quanto na linha de comando. Como não temos a inteface, vamos à linha de comando:

esxcfg-nics -l

O resultado é algo parecido com isto:

Name PCI Driver Link Speed Duplex Description
vmnic0 01:01.00 tg3 Down 1000Mbps Full Broadcom Corporation

vmnic1 01:02.00 tg3 Up 100Mbps Full Broadcom Corporation

Você também pode usar

ethtool vmnicx

Para obter maiores informações sobre cada adaptador de rede.

Sabemos agora que a vmnic0 está sem cabo de rede. Para descobrir qual vmnic serve de uplink para o switch virtual do Service Console use:

esxcfg-vmswitch -l

Que resulta em algo parecido com:

Switch Name Ports Used Configured Uplinks
vSwitch0 64 1 64 vmnic0

PortGroup Name Internal ID VLAN ID Used Ports Uplinks
Service Console portgroup0 0 1 vmnic0


Ok, sabemos que a vmnic0 está sem cabo de rede. Vamos então removê-la com o comando abaixo:

esxcfg-vswitch vSwitch0 -U vmnic0

Note que a sintaxe do comando acima é: esxcfg-vswitch -. O vSwitch0 foi criado automagicamente na instalação, contendo um port group chamado "Service Console". Nota: os nomes do switch e do port group são case-sensitive.

Para ligar outro adaptador de rede como uplink para este switch:

esxcfg-vswitch vSwitch0 -L vmnic1

Voila! A mudançã foi efetuada. Eventuais problemas transientes depois disto podem ser resolvidos com:

service network restart

Nota: estes procedimentos só se aplicam ao VMware 3.x. As versões anteriores são bem diferentes!

Marcadores: , , , , ,

quarta-feira, 11 de junho de 2008

Exportando o console do Enteprise Manager no SQL 2000/2005

Certa vez, em uma das minhas andanças pelo mundo de TI, herdei o gerenciamento de vários servidores SQL2000 em um cliente, mas não herdei o desktop do antigo DBA.

Eu pensei "hmm, fácil, exporto o .msc do console antigo e uso no meu desktop, assim não tenho que perder horas digitando endereços, contas e senhas".

Bzzz. Achou que seria fácil assim? O EM do SQL 2000 (e do 2005 também) armazena as informações de grupos e servidores registrados no console no registry do Windows, junto com a conta e senha configuradas para cada servidor. Infelizmente um export/import da chave do registry não resolve o problema, apenas os grupos são criados, sequer os servidores - eu nem me importaria muito em digitar a senha em todos um a um.

Como sou extremamente preguiçoso, procurei na internet por scripts que fizessem este trabalho, já que eu desconfiava que o SQL-DMO expusesse todas as informações necessárias.

Exportar

Para exportar o EM inteiro - incluindo grupos, servidores, contas e senhas utilizados para adminstração, para um arquivo .xml. Faça o download do arquivo abaixo, renomeie para dump.js e execute com cscript dump.js export.xml na linha de comando no desktop do qual você deseja exportar a configuração do EM:

dump.js

Importar

Para importar no desktop de destino, faça o download do arquivo abaixo, renomeie para load.js e execute com cscript load.js export.xml para magicamente recriar a configuração exportada.

load.js

Nota: estes scripts não foram criados por mim e não pude identificar o autor. Já os utilizei e posso garantir que funcionam.

Marcadores: , , ,