Fix para erro “Item Not found” ao movimentar arquivos e diretórios no Windows 7 SP1

Olá caro leitor,

Estamos atualmente na fase de beta para o Windows 7 Service Pack 1. Problemas, imcompatibilidades, bugs, etc. são situações normais de serem encontradas no uso de um software BETA.

Neste caso, iremos tratar de um erro que ocorre com alguns usuários que após instalarem o Windows 7 Service Pack 1, enfretaram problemas ao movimentar arquivos e/ou diretórios no Windows 7.

Ao tentarem movimentar arquivos/diretórios a seguinte mensagem era exibida:

Item not found

Could not found this item

This is longer located in “Source:\destination”. Verify the item’s location and try again.

Usuários reportaram este tipo de problema onde foi identificado que o mesmo está ligado a uma modificação feita no Windows 7 puro para desabilitar as Libraries (novo recurso do Windows 7).

Há diversos websites que demonstram como desabilitar as Libraries com arquivo de registro e/ou diretamente editando os dados necessários.

A questão aqui é que para corrigir este erro ao movimentar arquivos/diretórios, o usuário precisa restaurar as Libraries no Windows 7.

Abaixo você possui o link para remover completamente as Libraries do Windows Explorer, remover apenas o ícone e restaurá-la para o padrão.

AskVG – Libraries Regsitry Script

É isso pessoal. Até o próximo post…

Como identificar o que causa um Wake-up involuntário no Windows Vista/7

Olá caro leitor,

Me deparei esta semana com dois equipamentos que misteriosamente acordavam do Sleep Mode sem a solicitação do usuário.

Estes colegas de trabalho me questionaram se havia algum problema e como poderiamos identificá-los. Pois bem, o processo é bem simples.

Abra o Command Prompt (cmd), digite o comando POWERCFG -LASTWAKE e pressione ENTER.

No Command Prompt serão exibidas informações como estas abaixo:

C:\>PowerCfg -LASTWAKE
Wake History Count – 1
Wake History [0]
  Wake Source Count – 1
  Wake Source [0]
    Type: Wake Timer
    Owner: [PROCESS] \Caminho\do\processo\que\acordou\o\windows.exe
    Owner Supplied Reason: Windows will execute ‘Alguma tarefa por exemplo’ scheduled task that requested waking the computer.

Simples pessoal. Com este comando podemos identificar o que realmente causou o Wake-up do equipamento e tratar isto da forma correta (no caso destes dois companheiros de trabalho, desativar a tarefa agendada que estava acordando o Windows 7).

Espero que tenha sido de bom proveito a informação caro leitor!

Muito obrigado e até o próximo post…

Troubleshooting para arquivos bloqueados com RESMON

Olá caro leitor,

Estou aqui mais uma vez para falar a ferramentas do Windows Vista/7. O Resource Monitor.

Já vimos em posts anteriores algumas das funcionalidades do RESMON e agora, vamos ver como interromper um determinado arquivo que está bloqueado e sendo utilizado por um processo no Windows Vista/7. 

É comum encontrarmos usuários que passam por problemas em remover um determinado arquivo recebendo a seguinte mensagem informativa:

Mensagem informativa ao usuário

É também comum o uso de programas de terceiros para identificar qual é o processo que está bloqueando arquivo. O Unlocker é o software mais utilizado para este tipo de finalidade.

Cabe dizer aqui, que o uso do Unlocker é bem mais prático devido ao software lhe dar as informações rapidamente.

Entretanto, se não houver um software como o Unlocker em mãos para ser utilizado, como fazer este tipo de troubleshooting no Windows Vista/7 nativamente?

Eis aqui a resposta meu caro leitor! O RESMON possui essa particularidade e o próprio Windows 7 lhe fornece o nome do aplicativo, já que, em sua caixa de diálogo é exibido o nome do processo que está usando o arquivo. Podemos ver isto na imagem anterior onde a mensagem informa que é o Microsoft Office Word que está usando o arquivo.

Agora, como utilizar o RESMON para finalizar o uso deste arquivo pelo Word neste caso? Simples! Abra o RESMO e selecione a tab CPU e em seguida localize o processos ou todos os processos que estejam sendo executado, neste caso o winword.exe.

Marque a Checkbox dos processos para que eles sejam filtrados nos paineis Services, Associated Handles e Associated Modules como na imagem abaixo:

RESMON - Tab CPU + Associated Handles

Para quem já leu os outros posts e brincou com o RESMON, já deve ter identificado esta feature. Para quem ainda não percebeu, preste atenção ao lado direito do filtro Associated  Handles e verá um campo chamado Search Handles.

Search Handles Text Box

Excelente meu caro leitor! É com o uso desta caixa de pesquisa que podemos localizar rapidamente o arquivo que está sendo utilizado e finalizar sua execução.

Podemos ver na imagem abaixo que precisamos apenas digitar parte do arquivo+extensão para que ele seja mostrado particularmente no filtro.

Usando a pesquisa em Associated Handles

Acabamos de identificar qual é o processo que está utilizando o arquivo DOC (PID = 5192) e para terminar o acesso ao arquivo, clique com o botão direito sobre ele e escolha End process e confirme na próxima caixa de diálogo.

Perfeito meu caro leitor, acabamos de aprender agora como localizar arquivos que estão sendo utilizados no Windows Vista/7 e também como finalizar o uso destes para assim ser possível realizar qualquer tipo de tratamento que não é possível por estarem em uso.

Espero que este feature tenha sido de ótimo proveito caro leitor!

Muito obrigado e até o próximo post…

Inventário de servidores/workstations Windows com GP Inventory

Olá caro leitor, 

Estou aqui hoje para falar sobre um assunto muito importante em grandes ambientes controlados. Em pequenos ambientes verificar um item de hardware em determinado equipamento pode ser uma tarefa simples e rápida. 

Mas como seria a mesma tarefa em um ambiente grande onde há centenas e/ou milhares de servidores? Trabalho atualmente em um ambiente onde há aproximadamente 600 servidores físicos. Já imaginou um inventário de hardware em 600 servidores de forma não automatizada? 

Pois bem, atualmente temos ferramentas gratuitas que permitem realizar um inventário não somente em plataforma Windows, mas também Linux, UNIX e Mac OS. 

Posso citar aqui e recomendar dois nomes de aplicativos excelentes para esta finalidade. O OCS Inventory NG e o Spiceworks. 

Tais ferramentas exigem algum tempo de estudos e testes para implementação e configuração. Entretanto, com fóco somente em servidores executando plataforma Windows, podemos utilizar uma ferramentas simples e rápida da Microsoft, o Group Policy Inventory (GPInventory). 

O GPInventory é uma ferramenta que permite coletar informações sobre GPOs via RSoP de servidores e também obter informações sobre hardware/software via WMI (Windows Management Instrumentation). 

O GPinventory é um MSI de 300KB aproximadamente que pode ser obtido diretamente pelo Microsoft Download Center neste link: Group Policy Inventory (GPInventory.exe) 

Faça o download do GPInventory e execute o MSI. O processo de instalação é rápido e simples sem muitas informações a serem inseridas. 

Por default, na instalação do GPInventory assume o diretório C:\Program Files\Windows Resource Kits\Tools por ser a localização de ferramentas de Resource Kit Tools instaladas no Windows. Caso escolha outro local, altere o assistente de instalação. 

Após finalizar a instalação, navegue até o diretório de instalação e crie um atalho em seu Desktop por exemplo para o executável do GPInventory (gpinventory.exe) e execute a ferramenta. 

A interface inicial é simples e limpa como podemos visualizar na imagem abaixo: 

GPInventory

Explicando as opções disponíveis na barra de menus: 

• File > New query file: permite criar uma nova query com computadores + WMI definidas a serem executadas.
• File > Open: abre um arquivo XML com queries WMI definidas a serem executadas.
• File > Save: salva as configurações atuais computadores + WMI queries em um arquivo XML.
• File > Save as…: mesma função anterior.
• File> Exit: sai do GPInventory.
• Query > Select computers to target from a text file: permite usar um arquivo TXT como entrada para os nomes dos computadores que serão alvos das WMI queries.
• Query > Select computers to target using Active Directory: permite que os computadores sejam escolhidos por meio de OUs no Active Directory caso houve um ambiente com o  mesmo.
• Query > Select information to gather: permite escolhermos quais WMI queries desejamos executar nos computadores alvos (já existem WMI queries default definidas mas é possível criar mais).
• Query > Run query: Executa as WMI queries selecionadas nos computadores alvos.
• Results > Save to an XML file: exporta o resultado para um arquivo XML.
• Results > Save to an TXT file: exporta o resultado para um arquivos TXT.

Como pode ver, são opções simples as existentes na interface do GPInventory. Agora vamos ver como obter informações de um computador com a finalidade de realizar um inventária de hardware. 

O primeiro passo é saber qual é ou são os computadores alvos e quais informações se deseja saber. Como um teste local, crie um arquivo TXT chamado computer em seu Desktop. 

Abra o arquivo e nele digite o nome de seu computador. Salve em seguida e feche o arquivo. Agora na interface do GPInventory, use a opção Query > Select computers to target from a text file para usar este arquivo. 

O resultado será este abaixo: 

Host inserido no GPInventory

Agora que já temos um host alvo, iremos selecionar quais informações desejamos obter deste host. Use agora a opção Query > Select information to gather e iremos visualiza as seguintes opções de WMI Queries: 

WMI Queries - Part 1

WMI Queries - Part 2

Como podemos visualizar, por default já possuimos diversas WMI Queries configuradas no GPInventory, todas elas bem simples de serem compreendidas para qual é a sua finalidade. 

Vamos assumir que neste momento fosse necessário saber a versão do Sistema Operacional instalado, o modelo de processador e quantia de memória RAM no host. 

Seria necessário marcar a caixa a esquerda das seguintes WMI Queries e clicar no botão Ok: 

1. WMI: Operation System
2. WMI: Processor Name
3. WMI: Processor Speed
4. WMI: Computer Memory

Na imagem abaixo vemos que algumas colunas (WMI que selecionados anteriormente) foram inseridas na interface do GPInventory: 

WMI Queries selecionadas

Estamos prontos agora para executar as WMI Queries que selecionamos para obter as informações que desejamos. Pressione F5 ou então escolha a opção Query > Run query e aguarde o término da execução. 

No final teremos um resultado como este na interface do GPInventory: 

Resultado das WMI Queries

Perfeito, temos aqui as informações (Sistema Operacional, Tipo do processador, Clock em MHz e a quatia de memória em Bytes) que solicitamos ao GPInventory de forma rápida e simples. 

Tendo em mãos as informações, exporte o resultado para XML e abra com o Excel para tratar da forma que precisa estas informações. 

Entendendo como funcionam as WMI Queries 

Vamos ver aqui como é que o GPInventory obtem as informações por WMI. Navegue até o diretório C:\Program Files\Windows Resource Kits\Tools e abra o arquivo XML wmiqueries com o Notepad. 

Esté é o repositório onde estão todas as WMI Queries default do GPInventory que vimos anteriormente 

Repositório de WMI Queries

 Vamos entender agora a estrutura declarada de uma WMI Query em um arquivo XML. Tomemos como exemplo a seguinte string referente a Processor Name: 

<ManagedObject Name=”WMI: Processor Name” Query=”select Name from Win32_Processor”/> 

ManagedObject Name é usado para a exibição do nome da query. Este atributo pode ser alterado de acordo com a vontade do usuário sendo necessário editar o que está entre as aspas duplas. 

Por exemplo, se eu precisasse alterar o nome desta query anteriormente mencionada, eu poderia chamá-la de “Nome do Processador” deixando-a da seguinte forma: 

<ManagedObject Name=”Nome do Processador” Query=”select Name from Win32_Processor”/> 

Query indica quais são os parâmetros selecionados e qual é a query WMI que será executada: 

Query=”select parametro1,paramentro2,etc. from wmiquery” 

A Microsoft implementa nativamente estas queries na plataforma Windows, sendo apenas necessário que o serviço Windows Management Instrumentation esteja em execução no host local e/ou remoto onde a query será executada. 

Cada WMI Query possui diversas informações que podem ser extraídas de um host. A seguir temos todos os parametros que podemos obter de um processador usando a classe WMI Query Win32_Processor e também o tipo e cada um destes parametros: 

class Win32_Processor : CIM_Processor
{
  uint16   AddressWidth;
  uint16   Architecture;
  uint16   Availability;
  string   Caption;
  uint32   ConfigManagerErrorCode;
  boolean  ConfigManagerUserConfig;
  uint16   CpuStatus;
  string   CreationClassName;
  uint32   CurrentClockSpeed;
  uint16   CurrentVoltage;
  uint16   DataWidth;
  string   Description;
  string   DeviceID;
  boolean  ErrorCleared;
  string   ErrorDescription;
  uint32   ExtClock;
  uint16   Family;
  datetime InstallDate;
  uint32   L2CacheSize;
  uint32   L2CacheSpeed;
  uint32   L3CacheSize;
  uint32   L3CacheSpeed;
  uint32   LastErrorCode;
  uint16   Level;
  uint16   LoadPercentage;
  string   Manufacturer;
  uint32   MaxClockSpeed;
  string   Name;
  uint32   NumberOfCores;
  uint32   NumberOfLogicalProcessors;
  string   OtherFamilyDescription;
  string   PNPDeviceID;
  uint16   PowerManagementCapabilities[];
  boolean  PowerManagementSupported;
  string   ProcessorId;
  uint16   ProcessorType;
  uint16   Revision;
  string   Role;
  string   SocketDesignation;
  string   Status;
  uint16   StatusInfo;
  string   Stepping;
  string   SystemCreationClassName;
  string   SystemName;
  string   UniqueId;
  uint16   UpgradeMethod;
  string   Version;
  uint32   VoltageCaps;
}; 

Cada atributos da classe Win32_Processor deve ser separada por uma virgula ( , ) quando inserida no arquivo XML. Você pode brincar com os parametros inserindo-os no arquivo wmiqueries.xml.

IMPORTANTE! Faça uma cópia de segurança do arquivos e depois brinque editando-o e executando as queries em seu host local.

Como descobrir quais as classes WMI queries que o Windows suporta e quais o atributos destas classes?

Há uma repositório da Microsoft onde podemos verificar todas as WMI Queries disponíveis que podem ser utilizadas. Este repositório pode ser acessado no link abaixo: 

Microsoft Library – Win32 Classes 

Neste repositório você encontrará não somente as classes para o sistema operacional como também outros tipos, para hardware por exemplo. 

É uma ótima base de conhecimento e uma excelente forma de verificar quais atributos podem ser utilizados para obter as informações das quais precisa em um ou vários hosts remotos. 

Dica: Para quem possui um ambiente Active Directory, é simples o processo. Exporte o conteúdo do container onde estão os nomes do servidores e/ou workstations para um arquivo txt e importe para o GPInventory como realizamos no inicio com o teste local. 

NOTA: Se houverem descrições para cada servidor/workstations, será necessário remover estas informações do arquivo TXT. O mesmo deve conter somente os nomes dos hosts, um em cada linha para que seja possível utilizar o GPInventory.

Informação EXTRA!

Está fora do escopo deste post, mas como o GPInvenroty também trabalha com WMI para obter informações sobre GPOs, aqui também está o repositório onde há todas as classes WMI que podem ser utilizadas: 

Microsoft Library – RSoP WMI Classes 

Muito bem meu caro leitor, este é o fim de mais uma dica de utilidade diária para profissionais em IT. 

Espero que aproveitem as informações e quem tornem mais produtivo seu dia a dia. 

Até o próximo post e muito obrigado!

Troubleshooting para identificar a necessidade de aumento de memória com o RESMON

Olá caro leitor,

Esté é o terceiro post focado nesta ferramenta do Windows Vista/7. O Resource Monitor.

Em posts anteriores, já vimos como identificar serviços com alto consume de CPU e processos que não estão respondendo devido a espere de outros processos/serviços.

Uma outra dúvida muito comum entre usuários é saber quando há ou não necessidade de inserir mais memória em um sistema.

Cade vez mais há o uso de aplicações pesadas e/ou o uso de várias aplicações simultaneamente, exigindo mais recursos físicos do equipamento.

Como identificar que meu uso do sistema operacional+aplicativos demanda ou não a adição de mais memória RAM?

É um troubleshooting simples de se fazer meu caro leitor, entretando, precisamos entender novamente um pequeno detalhe que já foi mencionado no primeiro post sobre a ferramenta RESMON referente as informações sobre memória disponíveis. Esté é o detalhe importante:

Hard Fault é um evento gerado quando um endereço de memória de um programa não está mais presente na memória principal (RAM) por que foi movido para o SWAP.

Entendendo um pouco mais como funcionar o Memory Management do Windows.

O mecanisco de gerencia de memória do Windows trabalha alocando em memória física (RAM) os processos em execução. É de conhecimento geral dos usuários de Windows que o sistema operacional, tal como outros como UNIX, Linux, etc., que há um recurso chamado memória virtual (SWAP).

O mecanismo de gerencia da memória do Windows verifica constantemente as páginas alocadas em memória física e o uso destas páginas. Quando é identificado que uma página está com determinado tempo sem uso, está é movimentada automaticamente da memória física (RAM) para a memória virtual (SWAP) para que estejam disponíveis mais recursos físico para outros processos se necessário.

Este tipo de tratamente do Memory Management ocorre durante todo o tempo em que o sistema operacional está Online (motivo pelo qual desativar o SWAP do Windows pode não ser uma boa idéia antes de levar em consideração estes detalhes).

Resumindo, uma Hard Fault ocorre por que uma ou mais páginas em memória de um determinado processo foi movimentada da memória RAM para o SWAP, seja por estar ociosa em memória física ou por não haver recursos suficientes para outro processo, forçando o Memory Management a movê-la para que o outro processo tenha recursos.

Agora, como identificar este comportamento com o RESMON? Abra-o e selecione a tab Memory como na imagem abaixo:

Tab Memory

Destacado em amarelo, temos a coluna Hard Faults/s. Com um clique sobre a coluna é possível ordenar o número de Hard Faults de forma decrescente.

Está coluna irá mostrar a você caro leitor se há ou não necessidade de inserir mais memória física em seu equipamento.

Um número alto de Hard Faults (>10) para diversos processos é a informação de que você precisará para poder justificar o aumento de memória em seu equipamento.

Abra o RESMON e faça o uso de suas aplicações do dia a dia e/ou de todas as aplicações que necessita pode ou não vir a ter necessidade de fazer uso simultaneamente. Está informação de Hard Faults do RESMON irá lhe informar se a quantia atual de memória física está ou não bem dimensionada para o seu uso.

É isso meu caro leitor, mais uma informação de utilidade diária para end-users do Windows Vista/7 aproveitarem.

Espero que tenham aproveitado as informações e até o próximo post caro leitor!

Troubleshooting de aplicações travadas no RESMON

Olá caro leitor,

Este é mais um post sobre está excelente ferramente de troubleshooting do Windows Vista/7. O Resource Monitor.

No post anterior, eu mostrei como identificar serviços do Windows em instâncias SVCHOST que fazem alto consumo de CPU.

Neste post, irei mostrar como identificar a razão de um determinado processo não estar respondendo no Windows.

Um processo que não esteja respondendo no Windows pode ter as seguintes causas:

• dependência da execução de outros processos e/ou serviços para dar continuidade
• falta de recursos (CPU e/ou memória)

No RESMON, identificar uma aplicação que não está respondendo é mais do que simples. Na tab Overview no bloco CPU na coluna Image e/ou na tab CPU no bloco Processes na coluna Image, será exibido o nome do processo e o que irá diferenciá-lo dos processo em execução normal é a coloração.

Processos que não estão respondendo são exibidos na coloração vermelha no RESMON além do status na Status como “Not Responding“.

Para entender como funciona o troubleshooting, abra o RESMON e selecione a tab CPU como na imagem abaixo:

Tab CPU

Nota IMPORTANTE: Neste exemplo irei apenas demonstrar os passos a serem tomados para identificar o problema já que não há problemas de processos não respondendo em meu sistema operacional.

O próximo passo é identificar o processo que não está repondendo, como já dito anteriormente, será exibido na coloração vermelha.

Após identificá-lo, clique com o botão direito sobre o processo e escolha a opção Analyze Wait Chain… como na imagem a seguir:

Analyze wait chain...

 Após escolhermos a opção, uma pequena janela será mostrada como na imagem abaixo:

Resultado do Analyze wait chain...

Neste caso, temos um processo iexplorer.exe esperando recursos. Em um caso de aplicação não respondendo, poderiamos realizar o troubleshotinng finalizando os processo que estão aguardando e verificar se o status do processo que não está respondendo foi modificado de “Not Responding” para “Running“.

É possível visualizar na imagem anterior que há uma caixa de seleção no bloco em braco onde se encontra o processo e um botão na parte inferior direita com nome End process. Utilizá-lo significa encerrar literalmente aquele recurso que está interrompendo a execução de um processo.

Cabe dizer aqui, já que é uma informação de suma importância, que praticar este tipo de troubleshooting exige conhecimento dos processos em execução.

Neste exemplo, há somente um processo, entretanto, poderiam ser encontrados diferentes processos que demandariam tratamentos diferentes e muito mais atenção.

Encerrar um processo pode provocar a perda de dados tal como instabilidade do sistema operacional.

Uma boa prática! Faça o troubleshooting e troque informações com outras pessoas em instant menssengers, fóruns, blogs, etc. antes de aplicar qualquer tratamento em processos.

Bem caro leitor, espero que este post seja mais uma boa prática para o dia a dia e que o mesmo tenha sido de ótimo proveito.

Até o próximo post e muito obrigado!

Como ser um troubleshooter com o Resource Monitor do Windows 7

Olá caro leitor,

Hoje vou falar sobre uma excelente ferramenta presente no Windows 7, o Resource Monitor.

Em nosso dia a dia como profissionais de IT, constantemente, nos deparamos com situações onde é necessário realizar algum troubleshooting nos sistemas que gerenciamos.

Alto consumo de CPU, Network e memória são situações corriqueiras e que muitas vezes, demandam o conhecimento de software não nativos dos sistema operacional para realizar tais análises.

É muito comum o uso de ferramentas da SysInternals, as quais eu recomendo também por serem excelentes.

Processo Explorer, AutoRuns, Process Monitor estão entre as mais utilizadas para realizar um trobleshooting mais detalhado em sistemas operacionais Windows.

Com a chegada do Windows Vista e preservado no Windows 7, temos uma ferramenta pouco usada para fins de troubleshooting nestas duas versões do Windows. O Resource Monitor (resmon).

O Resource Monitor é uma ferramenta nativa do Windows Vista/7 que permite um troubleshooting mais detalhado sobre o que está realmente ocorrendo com processos, serviços, conexões de rede e leitura/gravação de dados em disco no Windows.

Com o Resource Monitor, é possível filtrar processos, suas conexões, leituras/escritas específicos e verificar muitas informações que nos permitem diagnosticar alguns das questões mais comuns encontradas em nossa rotína de trabalho.

Um exemplo clássico de sua utilização e diagnóstico, é quando temos instâncias SVCHOST fazendo alto consumo de CPU. Instâncias SVCHOST possuem diversos miniaplicativos vinculadas as estas sendo executados e por muitas vezes usuários interrompem uma instância que faz alto uso de CPU para corrigir o problema.

No entanto, este é um tratamento errado já que, não diagnosticamos o problema em si e literalmente encerramos diversos outros serviços que não necessariamente deveriam receber este mesmo procedimento.

Logo, é muito mais produtivo encontrar um determinado serviço que faz alto consumo de CPU em determinada instância SVCHOST e em seguida, desativá-lo e/ou procurar por possíveis causas/soluções para tratar e resolver o problema.

Mas como fazer isto? Eis aqui a resposta! Com o Resource Monitor. Vejamos mais adiante como realizar um troubleshooting de um serviço que esteja fazendo alto consumo de CPU em um host.

Existem três (3) meios para acessar a interface do Resource Monitor.

1. Start (Iniciar) > All Programs (Todos os Programas) > Accessories (Acessórios) > System Tools (Ferramentas de Sistema) > Resouce Monitor (Monitor de Recursos).
2. Pressionar Ctrl+Alt+Del e/ou clicar com o botão direto sobre a barra de ferramentas e escolher Task Manager (Gerenciador de Tarefas), selecionar a tab Performance (Desempenho) e clicar no botão Resource Monitor na parte inferior direita.
3. Start (Iniciar) > Run (Executar) e/ou pressionar as teclas Windows Key + R, digitar resmon e pressionar ENTER.

Todos os três meios levam a exibição da interface abaixo, o Rescource Monitor:

Resource Monitor Overview

Na tab  Overview, encontramos informações sobre todos os monitores (CPU, Memory, Disk e Network) do RESMON.

Nesta tab, podemos filtrar um determinado processo simplesmente marcando a checkbox do processo e espandindo cada uma das sessões abaixo, visualizando as seguintes informações:

• em Disk (Disco) o caminho completo para os arquivos que estão sendo executados com o processo, quantia em Bytes/S de escrita e leitura, total de escrita/leitura, I/O e tempo de resposta.
• em Network (Rede) o Address (Endereço) de destino no qual o processo está conectado, quantia em Bytes/S recebida/enviada e também o total de ambas.
• em Memory (Memória) Hard Faults/S, Commit, Working Set, Shareable e Private.

Informação EXTRA!

Explicando os monitores de memória do Windows:

• Hard Fault é um evento gerado quando um endereço de memória de um programa não está mais presente na memória principal (RAM) por que foi movido para o SWAP.
• Commit mostra a quantia total de Virtual Address Space usado pelo processo no arquivo de SWAP no Windows.
• Working Set são atualmente as páginas do Virtual Address Space que estão na memória física.
• Shareable mostra atualmente a quantidade de memória que está sendo compartilhada entre outros processos.
• Private é total de Virtual Address Space não compartilhado para outros processos.

Em Overview também encontramos ao lado direito os monitos visuais para CPU, Memory, Disk e Network tal como visualizamos no Task Manager.

É uma ferramentas visual que permite ao troubleshooter, quando selecionado determinado processo, visualizar com uma linha contínua laranja, o histórico de uso dos recursos.

Vemos abaixo um exemplo filtrando o Microsoft Office Outlook e suas conexões de rede estabelecidas:

Filtrando o Microsoft Office Outlook

Como podemos visualizar, temos muitas informações em mãos das quais podemos determinar o tratamento adequado caso o problema fosse identificar, quanto de dados estão sendo injetados pelo Microsoft Office Outlook ao enviar/receber e-mails de determinado destino. O tratamento poderia ser limitar o tráfego do Outlook a X Bytes.

Neste momento, já temos muitas informações sobre como usar os filtros do Resource Monitor e extrair dados sobre um determinado processo.

Agora que já entendemos o conceito sobre a ferramenta, vamos entender como efetuar um troubleshooting para identificar um serviço específico que esteja gerando alto uso de CPU em um host.

Abra o Resouce Monitor e selecione a tab CPU como mostrado na imagem abaixo:

Tab CPU do Resource Monitor

Cada tab específica do RESMON, possui informação pertinentes a esta somente. Como podemos verificar na imagem anterior, em CPU temos um bloco de Processes, Services, Associated Handles e Associated Modules necessários para um troubleshooting sobre processos.

Suponhamos neste momento que exista uma instância qualquer do SVCHOST que esteja fazendo alto uso de CPU em seu host. O primeiro passo é identificá-la entre os processos e marcara caixa de seleção ao lado esquerdo como na imagem abaixo:

INFO: Tal como no Task Manager, se for necessário ordenar os processos por critérios de colunas, o RESMON permite a mesma ação. Basta clicar na coluna na qual se deseja ordenar os processos e selecionar o item de sua escolha.

Instância SVCHOST selecionada

Na imagem acima, temos uma instância do SVCHOST referente a serviços de Network Services selecionada. Ao espandir o bloco Services, podemos visualizar quais serviços estão sendo executados dentro desta instência SVCHOST.

Neste caso, temos os seguintes serviços: NlaSvc (Network Location Awareness), LanmanWorkstation (Workstation), Dnscache (DNS Client) e CyptSvc (Cryptographic Services).

Bloco de serviços da instância selecionada

A imagem anterior é praticamente alto explicativa pelas colunas que possui.

Temos da esqueda para a direita, o nome do serviço dentro do sistema operacional (Name), o identificar de processo (PID), o nome amigável para o usuário (Description), o status do serviço (Status), o grupo ao qual pertencem (Group), o uso de CPU (CPU – coluna que será utilizada neste caso para o troubleshooting) e a média usada pelo serviço de CPU (Average CPU).

Cabe dizer que em meu caso, todo o S.O está saudável e não há problemas de alto uso de CPU, por está razão os serviços estão com consumo ZERO (0) de CPU.

Agora, suponhamos que o houvesse um serviço com algo consumo de CPU, tomemos como exemplo o CryptSvc. Ao identificar esse comportamento, a primeira medida seria desativá-lo no console de Serviços do Windows.

Os próximos passos seriam básicos, consultas ao Google, fóruns de discussão, etc. para tentar identificar se há algum problema conhecido e uma medida para solucionar o problema caso o mesmo problema tenha ocorrido com outros usuário.

Pois bem caro leitor, este é uma troubleshooting básico que pode ser feito por qualquer end-user para identificar um problema de alto consumo de CPU em seu host.

É importante mencionar também que este exemplo pode ser aplicado para todos os outros itens do RESMON. Você pode identificar precisamente objetos que estão fazendo leitura/escrita em disco, uso de memória e tráfego de rede.

Certamente, mesmo que não seja possível resolver o problemas imediatamente e seja necessário recorrer a uma ajuda externa (Comunidades, Fóruns, etc.), no momento de informar seu problema, você terá bem mais detalhes a serem levados em consideração pelas pessoas que se proporem a ajudá-lo.

Isso facilita o entendimento do problema e permite uma resposta mais precisa, clara e objetiva sobre como solucionar sua questão.

É comum encontrarmos posts em fóruns com poucas informações importantes quando estamos tratando de problema de alto consumo de CPU e está que podemos coletar com o RESMON, de fato, facilitará muito mais a compreensão do problema.

Bem, espero que tenham gostado do conteúdo e que o mesmo seja de excelente uso no momento de solucionar alguns problemas diários que possuimos.

Muito obrigado pela leitura caro leitor e até o próximo post.

Windows Installer Cleanup Utility removido do Microsoft Download Center

Olá caro leitor,

Muitos já devem conhecer este utilitário da Microsoft e mesmo os que ainda não tenham feito uso do mesmo, o nome já lhes dão uma breve descrição de sua finalidade.

O Windows Installer Cleanup Utility é uma ferramenta que permite remover itens no sistema operacional de uma forma mais eficaz quando pelo recurso Adicionar/Remover programas do Windows não remove completamente todos os componentes de uma determinada instalação.

Hoje, pela manhã precisei realizar o download do utilitário no Microsoft Download Center e para minha surpresa, percebi que o mesmo foi removido do repositório da Microsoft.

Resolvi então procurar outras fontes e durante isto encontrei relatos de que a ferramenta foi removida devido a causar alguns problemas removendo componentes não solicitados pelo usuário no momento de utilizá-la.

Fica então o alerta pessoALL! Tomem cuidado e façam um backup de seu sistema antes de executarem o utilitário por segurança.

Até o próximo post…

Remote Desktop Connection Manager for Microsoft

Olá caro leitor,

Hoje irei falar sobre uma ferramenta de gerenciamento para conexões RDP. O Remote Desktops Connection Manager.

Profissionais que trabalham com um grande número de hosts sabem que ter uma console centralizada onde se pode acessar estes hosts, significa uma grande economia de tempo e deslocamento nos ambientes.

A própria Microsoft fornece estas ferramentas FREE inclusa no Microsoft Admin Pack for Windows 2003 Server e o Microsoft Remote Server Adminitration Tools (RSAT) for Windows Vista/7/Server 2008.

Estas ferramentas incluem no sistema operacional uma console chamada Remote Desktops com o qual podemos gerenciar conexões RDP centralizadas no Windows.

A desvantagem do Remote Desktops é não ser possível categorizar e agrupar hosts na console sendo necessário criar uma console MMC para cada grupo que se deseja criar.

Com o Remote Desktops Connection Manager, você pode criar grupos, categorizar e gerenciar suas conexões RDP em uma única console.

RDC Manager possui uma interface simples e com algumas features como thumbnails dos hosts quando organizados em grupos. Ao selecionar um determinado grupo de hosts, no painel direito são mostradas as miniaturas doas conexões ativas.

No RDC Manager, por exemplo, você pode determinar credenciais específicas para cada um dos grupos que precisar gerenciar e efetuar o logon nos hosts.

Diferente do Remote Desktops, o RDC Manager redimensiona literalmente as janelas dos hosts gerenciadas e ativas. Com o Remote Desktops, ao iniciar uma sessão com um host se a interface não estiver em determinado tamanho, a sessão com seu host será criada com uma resolução baseada no tamanho da janela disponível.

Mesmo maximizando o Remote Desktops, sua sessão continuará com a resolução atual. Será necessário finalizar a sessão e iniciar outra para que a resolução seja ampliada.

No mais, o Remote Desktop Connection Manager é uma execelente ferramentas para gerenciar conexões RDP e mais uma carta na manga para profissionais de IT.

Para efetuar o download do RDC Manager, acessem: Remote Desktop Connection Manager.

Espero que aproveitem a ferramenta!

Até o próximo post pessoALL.

Remote Shutdown nativo do Windows

Olá caro leitor,

Neste primeiro de muitos outros posts, irei mostrar uma ferramentas pouco utilizada e conhecida por profissionais de IT que trabalham com plataforma Windows. O Remote Shutdown.

Está feature está presente no Windows e permite que hosts remotos sejam desligados e/ou reinicializados remotamente por intermédio de uma interface idêntica a exibida quando o Shutdown Event Tracker está ativado.

Um case real para exemplificar o uso desta feature, é possuir um grande número de host físicos e/ou virtuais do quais precisa efetuar um shutdown em horário pré-determinado. Uma parada para manutenção elétrica por exemplo seria um evento no qual seria necessário o shutdown.

Para quem não sabe e/ou quem não conhece o termo Event Tracker, está interface é exibida nativamente em sistemas operacionais Microsoft da família de servidores. Todo o evento de shutdown e/ou restart exige que o usuário informe o motivo pelo qual está executando está ação.

Deixemos a teoria de lado e passemos para a prática do recurso. Para utilizar o Remote Shutdown, clique em Iniciar (Start) > Executar (Run) e digite shutdown -i para ser exibida a interface abaixo:

Como é possível ver, a interface é semelhante a do Event Tracker com algumas opções necessárias para o uso.

O primeiro bloco permite que sejam inseridos os hosts no quais deseja-se executar o shutdown/restart remoto.  Para inserir um host e/ou uma lista de hosts, clique no botão Add (Adicionar) e digite o nome do host que deseja efetuar a ação e clique em OK.

Dica: Se possuir um número grande hosts, por exemplo, um AD, exporte o conteúdo da OU onde estão os hosts para um arquivo TXT, copie os nomes (os nomes devem estar linha por linha) e cole na caixa Adicionar.

É possível buscar hosts em um domain controller usando o botão Browser para pesquisar no Active Directory os hosts que deseja executar a ação remotamente.

Após inserir os hosts no qual será executado o shutdown e/ou restart, escolha o tempo no qual será exibido aos usuários conectados que o host será finalizado em Warn users of the action.

Configure o Shutdown Event Tracker com as opções mais adequadas para justificar o evento caso seja necessário e clique em Ok.

Espero que aproveitem essa feature jedi no Windows pouco utilizada e/ou conhecida por profissionais.

Um abraço para vocês e até o próximo post.