.: Windows Management Systems :.

Olá pessoal,

Recentemente, passei por uma situação inusitada, onde precisei parar uma instalação de agente SCCM via client push installation para uma collection inteira.

A forma que encontrei de fazer isto rapidamente foi excluir os arquivos .CCR que são criados nas inboxes do SCCM.

Abaixo, uma breve descrição do feito:

Quando uma instalação via Client Push é iniciada, o ConfigMgr gera um arquivo .CCR (Configuration Request File) para cada recurso da collection (ou para o recurso em específico). Podemos deletar estes arquivos parando o processo de Push Install. Conforme estes arquivos são processados, eles se movem entre 3 pastas diferentes:

1. Inicialmente, os arquivos são criados em: \inboxes\CCR.box
2. Quando o arquivo é processado, o registro é movido para: \inboxes\CCR.box\inproc
3. Quando uma instalação falha, o registro será armazenado em: \inboxes\ccrretry.box

Aconselho a não deletarem nenhum registro que já esteja na pasta \inboxes\CCR.box\inproc.

Sds,

Alexandre Perazza

Olá pessoal,

Este é mais um cenário que encontrei recentemente durante a migração de um ambiente SMS 2003 para o SCCM 2007.

• Cenário: Durante a migração de máquinas do ambiente SMS para o SCCM algumas máquinas da rede travavam (congelavam) e só era possível estabelecer seu funcionamento através de um system restore no S.O.
• Causa: Observando o log gerado pelo ccmsetup (C:\Windows\system32\ccmsetup\ccmsetup.log) vemos que a instalação trava justamente quando o processo de instalação está removendo os drivers de controle remoto (RemoteW2KDrivers).
  
  
• Resolução: Para que a instalação do client seja efetuada com sucesso, via CCMSETUP, renomeamos o arquivo “kbstuff5.sys” na pasta “C:\WINDOWS\System32\drivers” e então rodamos novamente a instalação (que no nosso caso era via script). Com isto, a instalação sucedeu de forma correta. A única observação, é que este processo necessita que a máquina seja reiniciada durante a remoção do driver, e então após o reset a instalação é concluída corretamente.

Sds,

Alexandre Perazza

• Cenário:
  Após a migração do ambiente SMS 2003 para SCCM 2007 e após o deployment de dos clients SCCM, máquinas que tiveram o client instalado com sucesso e reportados para o FSP (Fallback Status Point) aparecem na collection “All Systems” como “Client=No”
• Causa:
  
  Algumas razões no lado do site server:
  
  - As boundaries não estão configuradas corretamente
  - AD não foi extendido e não existe um SLP configurado.
  
  Algumas razões comuns para isto no client:
  
  - O client não está assinado para nenhum site > Valide pelo log “ClientLocation.log”
  - O client não consegue localizar o Mgmt Point padrão > Valide pelo log “LocationServices.log”
  - O client não conseguiu se registrar > Valide pelo log “ClientIDManagerStartup.log”
  - O client não consegue se comunicar com o Mgmt Point > Valide pelo log “Ccmexec.log” (procure erros HTTP ou HTTPS)
  
  A causa mais provável para isto, é a duplicação do SMS Unique Identifier  no client. Isto pode acontecerdevido a uma duplicação de disco por exemplo (GHOST). Você pode validar as informações do ID de uma máquina através do arquivo “SMSCFG.ini” localizado na pasta “C:\WINDOWS”. Abaixo dois exemplos de arquivos de máquinas duplicadas:
  
  

  Máquina 1: [SMS MultiBoot Configuration] Number of Opal Installations=1 [Configuration - Client Properties] SMS SMBIOS Serial Number Identifier=430034005A003600420046003100 SID=S-1-5-21-2699641826-735199054-3616249295 SMS Hardware Identifier 2=0080A6B40100006A SMS Hardware Identifier=7880A6B40196006A SMS Unique Identifier=GUID:9B5D8ABA-4C94-41A7-8645-D653EA3D903A Previous SMSUID=GUID:7D8559B8-0670-4AD5-A81E-DC74A7D1FBA9 Last SMSUID Change Date=04/07/2009 15:44:30 Last Version=4.00.6221.1000

Máquina 2: [SMS MultiBoot Configuration] Number of Opal Installations=1 [Configuration - Client Properties] SMS SMBIOS Serial Number Identifier=460033005A003600420046003100 SID=S-1-5-21-2699641826-735199054-3616249295 SMS Hardware Identifier 2=00E0A3B40100006A SMS Hardware Identifier=78E0A3B40196006A SMS Unique Identifier=GUID:9B5D8ABA-4C94-41A7-8645-D653EA3D903A Previous SMSUID=GUID:BE86F657-F25E-4FB3-B562-349579BECEB5 Last SMSUID Change Date=04/07/2009 16:07:44 Last Version=4.00.6221.1000



• Workaround:
  
  Podemos utilizar nestes cenários, a ferramenta “Tranguid.exe” contida no “SMS Toolkit 2”. Apesar de originalmente ser desenvolvida para troubleshooting em clients SMS, apresenta bons resultados com clients SCCM. Para utilizá-la neste cenário:
  
  1. Localize as máquinas que possuem o SMS GUID duplicado. Você precisará atuar em uma delas.
  2. Copie o arquivo “tranguid.exe” para uma pasta local nesta máquina.
  3. No prompt de comando, localize a pasta e o executável. O comando que será utilizado é: “tranguid.exe /r”
  4. Pare o CcmExec.exe na máquina; em seguida inicie o serviço.
  5. Observe que o arquivo “SMSCFG.ini” gerou um novo SMS GUID.
  6. Aguarde até que um novo ciclo DDR seja criado, ou então, faça isto manualmente. A máquina aparecerá corretamente na collection em instantes.
   
• Recursos adicionais:
  
  - Parâmetros suportados pela ferramenta “Tranguid.exe”:
  
  
  Syntax

  TranGUID [/W:<directory>] /G <filename>
  TranGUID [/W:<directory>] /X <filename>
  TranGUID [/W:<directory>] /R
  TranGUID /?

  Command-Line Options
  

  Option	Description
  /W	When set, this option specifies the location of the Windows directory where the SMScfg.ini file resides. Otherwise, this location is taken from the system environment.
  /G	Gets the client identifier from the current computer and saves it to the specified file. Use the /W option to access remote computers.
  /X	Gets the client identifier from the current computer and saves it to the specified file, but it also forces the client to generate a new SMS ID when the SMS client service restarts. The client receives a new record in the server's database.
  /R	Forces the client to regenerate the SMS ID when the SMS client service restarts. The client receives a new record in the server's database.
  /?	Prints the list of command options.

Sds,

Alexandre Perazza.

Antes da instalação do SCCM 2007 e para permitir que informações sejam publicadas no AD pelo SCCM precisamos criar o container “System Management” e dar permissão a conta de computador que é o site server. Aqui, utilizei o ADSIEdit para efetuar este processo:

1. Você irá precisar do “Support Tools” do Windows Server 2003: http://www.microsoft.com/downloads/details.aspx?FamilyID=96a35011-fd83-419d-939b-9a772ea2df90&displaylang=en
2. Após o download e instalação, vá no prompt de comando do support tools e registre a DLL: adsiedit.dll:
   
   
   
   
   
3. Vá no executar e digite adsiedit.msc:
   
   
   
4. O console do ADSIEdit será iniciado. Expanda “Domain”, expanda DC=Seu Dominio, DC=Seu dominio. Vá na pasta CN=System, botão direito, selecione “Novo” e então “Object”:
   
    
   
5. Selecione “container”:
   
   
   
6. Em “Value” insira: “System Management”:
   
   
   
7. Vá na pasta “CN=System Management” que acabou de criar, botão direito e então propriedades. Em segurança, adicione a conta de computador que será seu site server. Dê permissão “Controle Total” ou “Full Control” (se estiver em inglês). Clique em “Avançado”:
   
   
   
8. Selecione a conta do computador e clique em “Edit”. A seguinte telá irá aparecer. Na opção “Aplicar em:” selecione “Este objeto e todos os objetos filho”. Clique em OK.:
   
    

Pronto. O container System Management foi criado e as configurações de segurança requeridas pelo SCCM para publicação de dados no AD já foram configuradas. Você poderá seguir com sua instalação.

Sds,

Alexandre Perazza.

.

Extender o AD Schema para o Configuration Manager 2007 permitirá que clientes da rede consultem o Active Directory Domain Services para localizar recursos do site SCCM. Podemos extender o schema antes ou depois da instalação do Configuration Manager, porém, temos como boa prática extender o schema antes da instalação.

Existem duas formas de extender o schema para o Configuration Manager; podemos utilizar um dos arquivos contidos no CD de instalação, dentro da pasta \SMSSETUP\BIN\I386:

• ExtADsch.exe
• ConfigMgr_ad_schema.ldf

Lembrem-se:

1. Crie um backup do seu DC Schema Master utilizando o NTBACKUP.
2. Desconecte o DC Schema Master da rede.
3. Execute a ação de extender o schema com uma conta que seja Schema Admins.

Aqui, vamos utilizar o arquivo LDIF e entender o processo para extender o AD schema utilizando-o:

• Abrindo o arquivo ConfigMgr_ad_schema.ldf com o bloco de notas vemos:

• Defina o domínio que deve ser extendido. Para isto, substitua todas as instâncias “DC=x” pelo nome completo do domínio a ser extendido:

• Em seguida, utilize o comando:

Considerações:

1. Utilize o comando a partir do diretório onde se encontra o arquivo .ldf modificado. No meu caso, C:\> foi utilizado.
2. Quando utilizar o switch –j defina a pasta onde quer que o log da operação seja salvo. Por padrão, se este switch não for definido, o caminho atual é utilizado.

• Aqui, observamos o progresso da operação:

• Podemos abrir o log criado e constatar o sucesso da operação:

Sds,

Alexandre Perazza.

Olá pessoal,

Este vídeo foi feito por um integrante da equipe de suporte Windows – Espanha.

Mostra os aspectos de uma migração do SMS 2003 para o SCCM 2007, caracterísitcas do produto, visão geral do processo de extensão do schema e instalação do produto.

Muito legal, simples e rápido, vale a pena conferir.

Sds,

Alexandre Perazza.

Uma das funcionalidades que gostei no SCCM, tratando-se de collections, foi a opção “Modify Collection Settings”, onde dentro dela, na guia “Advanced” podemos especificar configurações para restart countdown e policy polling interval.

Esta é uma facilidade muito útil, para ambientes que possuem um grupo de máquinas que precisam baixar novas policies com maior/menor frequência e diminuir/aumentar o tempo de contagem antes de um restart. Definindo uma configuração desta na collection, você não irá impactar o funcionamento de seu site por completo. Somente as máquinas dentro da collection sofrerão as alterações configuradas.

Para isto, botão direito na collection desejada>>”Modify Collection Settings”>>”Advanced” como abaixo:

Configure aqui, os valores que melhor se adequam a sua situação.

;-)

Sds,

Alexandre Perazza

Existem algumas formas de realizar a instalação de um sccm client no ambiente de rede, dentre elas as mais comuns:

• Push Installation
• GPO (Logon script)
• Instalação manual

Recentemente, em um processo de instalação via script, tivemos alguns problemas quando executavamos o ccmsetup.exe buscando os aquivos de instalação em um compartilhamento da rede, utilizando o parâmetro /source: na instalação (C:\ccmsetup.exe /source:\\server\share – por exemplo)

Resumidamente, o ccmsetup.exe, pode ser executado de 2 formas: como um serviço ou como um executável independente. Por padrão, quando executamos a instalação do client via Push, o ccmsetup roda como um serviço. Em um script, se não inserirmos nenhuma indicação no código, o ccmsetup também irá rodar como um serviço. Com isto, poderemos observar erros na instalação do client sccm como segue abaixo:

Na primeira etapa da instalação do sccm client, o ccmsetup copia a si próprio para uma das pastas em:

• %windir%\system32\ccmsetup (para sistemas 32 bits)
• %windir%\ccmsetup (para sistemas 64 bits)

Na segunda etapa, após a cópia ele se registra como um serviço do Windows e inicia o processo de instalação buscando os arquivos de instalação no compartilhamento de rede indicado no código do script. Todo o andamento da instalação você pode acompanhar pelo log ccmsetup.log que é gerado dentro de uma das pastas citadas acima.

Podemos observar no log a seguinte linha:

Running as user "SYSTEM"    ccmsetup    3/24/2009 2:31:23 PM    4648 (0x1228)

Neste ponto, poderemos ter problemas na instalação se a conta de computador não tiver acesso aos arquivos de instalação que estão armazenados em no compartilhamento da rede. No log observaremos a seguinte mensagem:

Failed to access source file (2). Waiting for retry...    ccmsetup    3/24/2009 2:31:23 PM    4648 (0x1228)
Next retry in 10 minute(s)...    ccmsetup    3/24/2009 2:31:23 PM    4648 (0x1228)

Para contornar isto, podemos inserir o parâmetro /noservice na linha de comando do ccmsetup, por exemplo:

(C:\ccmsetup.exe /noservice /source:\\server\share)

Isto fará com que o ccmsetup seja iniciado como um executável e então todo o processo de deployment do client será efetuado utilizando a conta do usuário que iniciou o processo. Com as permissões no compartilhamento, configuradas corretamente, a instalação do client  será bem sucedida.

Para maiores informações sobre o processo de deployment do client SCCM:

• http://technet.microsoft.com/en-us/library/bb680373.aspx (Plan and Deploy)
• http://technet.microsoft.com/en-us/library/bb693897.aspx (Log files)
• http://technet.microsoft.com/en-us/library/bb680980.aspx (Parâmetros da instalação)

Sds,

Alexandre Perazza.

Pessoal,

Vou compartilhar com vocês a planilha que levo sempre comigo contendo todos os log files gerados pelo SCCM 2007 tanto no lado do servidor quanto do lado cliente. É uma planilha simples, onde somente foi consolidada as informações de logs. Tem me ajudado muito :)

Baixe em formato Office 2007 ou Office 2003 em: SCCM 2007 (SkyDrive)

Sds,

Alexandre Perazza.

Essa é uma dica simples, na verdade uma observação sobre o comportamento de um advertisement. Muitas vezes, nos deparamos com a necessidade de utilizar a opção “re-run” e ela simplesmente está inativa:

Isto ocorre, porque configuramos este advertisement para ser mandatório e com a opção de rodar “ASAP – as soon as possible”:

Remova esta opção de seu advertisement, configure o schedule e sempre que precisar rodá-lo novamente, teremos de volta a opção “Re-Run” :-)

Sds,

Alexandre Perazza.

Se você precisa criar uma nova collection, resultante da combinação de diversas outras collections, esta query pode te ajudar: (Lembre-se, localize o ID das collections que deseja inserir e substitua xxxxxxx1 pelos IDs coletados)

Sds,

Alexandre Perazza.

Sempre que instalamos o client do SMS em uma máquina, cria-se um ícone no painel de controle chamado “System Management” onde contém diversas informações sobre o nosso ambiente como por exemplo: site code, cache size, componentes, etc.

Muitas vezes me deparei com situações onde o cache do SMS havia sido reduzido pelo próprio usuário, então o SMS não conseguia finalizar a distribuição do software corretamente ou o serviço do SMS havia sido parado na máquina. Para prevenir que usuários com direitos administrativos alterem o funcionamento do SMS Client, podemos tentar o seguinte:

1. Remover (esconder) o ícone do SMS do painel de controle:
   • Na chave de registro HKEY_CURRENT_USER\Control Panel\don't load, crie um novo “valor da sequencia” chamado “SMSCFGRC.cpl” com o valor “No”
2. Reiniciar o serviço ccmexec na máquina remota:
   • É claro que hoje temos diversas formas de se fazer isto, por exemplo através de ferramentas como o SMS Client Center, porém, em um ambiente de grande escala, fica um pouco complicado saber quais máquinas estão com o serviço parado. Para contornar isto, uma forma simples é criar uma tarefa agendada que reinicie o serviço digamos a cada 4 horas. Se o usuário parou o serviço WMI, então a coisa fica um pouco mais complicada. Para isto, podemos usar o script (vbs) abaixo para resolução:

Sds,

Alexandre Perazza.

Recentemente tive uma experiência com um ambiente SMS 2003, onde estavamos analisando o desaparecimento de máquinas válidas de algumas collections. Após algum tempo, descobrimos que foram feitas alterações em 2 itens específicos: “Heartbeat Discovery” e na task “Delete Aged Discovery Data”.

Com isto, iniciamos uma discussão sobre como ajustes incorretos na task “Delete Aged Discovery Data” podem impactar na informação que é retida na base de dados do SMS.

Vamos considerar o seguinte cenário: Um SMS Admin decide que todos os sistemas que não se reportaram por 3 dias serão removidos da base de dados. Para isto, ele decide ajustar o tempo de retenção na task “delete aged discovery data” para 3 dias. No outro dia, ele nota que o número de sistemas contido na sua base de dados foi reduzido para um valor abaixo do real e esperado por ele, após as recentes configurações de remoção feitas na task.

O problema do exemplo acima é um conflito comum entre o intervalo de remoção e o intervalo do heartbeat discovey. Antes de configurar estes parâmetros, é necessário entender como o SMS determina se uma máquina é candidata para remoção da base de dados.

Pense que neste cenário, o único discovery habilitado no ambiente é o heartbeat discovery e seu intervalo está com o padrão de 7 dias. Neste caso a task “delete aged discovery data” está configurada para ocorrer bem antes que alguns SMS clients tenham gerado seus heartbeats para atualizar a base de dados. Então, o SMS verá estes sistemas como “aged” e procederá com a remoção deles – também será removido qualquer dado de inventário associado ao recurso.

Uma boa prática para prevenir que clientes que não geraram o heartbeat ainda ou estejam offline por um período de tempo sejam excluídos, é configurar a task “delete aged discovery data” para rodar com no mínimo o dobro de tempo do que o configurado no “heartbeat discovery”. Claro que poderemos ter cenários que o dobro de tempo configurado não é suficiente e para chegar aos valores que atendam será necessário um bom entendimento do ambiente que está sendo configurado (levar em consideração período de férias de usuários, rotatividade de máquinas, usuários remotos, etc).

• Para maiores informações sobre os Discovery Methods no SMS: http://technet.microsoft.com/en-us/library/cc181362.aspx
• Para maiores informações sobre Site Maintenance Tasks no SMS: http://technet.microsoft.com/en-us/library/cc181025.aspx
• Outro post, que fala sobre um conflito semelhante entre heartbeat discovery e clear install flag no SMS: http://aperazza.spaces.live.com/blog/cns!5980EAF5D2695CBF!397.entry

Sds,

Alexandre Perazza.

Para aqueles que gostariam de entender o processo de Software Updates no SCCM 2007, recomendo o download do “System Center Configuration Manager 2007 Software Updates Synchronization SuperFlow”

Após a instalação, você terá acesso a “workflows” dinâmicos do processo de Software Updates além de uma animação do processo completo, dividido em fases e com recursos de links para documentação e exemplos de log files para consulta.

Abaixo, um preview da animação:

Aproveitem!!

Sds,

Alexandre Perazza

Pessoal,

Informação obtida do blog da Priscila Silva (Microsoft): http://blogs.technet.com/psilva

Em março teremos duas webcasts com o foco em deployment, uma abordando a instalação Lite Touch (com interação limitada por parte do usuário), e outra sobre o método Zero Touch (sem interação, com o uso do System Center Configuration Manager 2007 ou Systems Management Server 2003). O melhor: em Português :-)

Instalação Lite Touch Usando o Microsoft Deployment Toolkit
Descritivo: O Microsoft Deployment Toolkit oferece instruções para instalações Lite Touch Installation (LTI). Você deve usar LTI quando não tiver Microsoft Systems Management Server 2003 ou Microsoft System Center Configuration Manager 2007 para realizar instalações dos seus clientes. Além disso, a instalação LTI exige interação mínima com usuários ou pessoal designado, ao mesmo tempo em que oferece flexibilidade para configurações de desktop.
Data: 03/03/2009
Hora: 12:00hrs
Inscreva-se

Instalação Automatizada Usando o Microsoft Deployment Toolkit e o System Center Configuration Manager 2007
Descritivo: O Microsoft System Center Configuration Manager 2007 e o Microsoft Deployment Toolkit se integram para realizar instalações sem toque do sistema operacional Windows Vista de forma mais rápida e mais fácil de configurar, assim como contribui com funcionalidades adicionais para o processo de implementação. O processo de criação e implementação de novas seqüências de tarefas para a instalação de sistemas operacionais é aperfeiçoada pelo Import Microsoft Deployment Task Sequence Wizard.
Palestrante: Raphael Perez
Data: 17/03/2009
Hora: 12:00hrs
Inscreva-se

Não deixem de conferir!

Sds,

Alexandre Perazza.

Pessoal,

Durante algumas pesquisas na semana passada, encontrei um post em um blog do Technet sobre a funcionalidade “Conflict Records” do SCCM. Este post explica de forma rápida e clara a diferença entre Conflicting Records (que é a duplicação do Hardware ID) e Duplicate GUIDs (recursos com o mesmo SMS Identifier ou GUID).

Brevemente:

Conflicting Records (Hardware ID duplicado): Geralmente ocorre quando reinstalamos o SO de uma máquina. O host irá adquirir um novo GUID do SCCM mas seu hardware ID permanecerá o mesmo. Este cenário é possível de se gerenciar automaticamente pelo SCCM ou manualmente (O administrador escolhe)

Duplicate GUIDs: (o mesmo SMS Identifier): Geralmente ocorre quando duplicamos ou “clonamos”um disco. Este cenário não é gerenciado pelo SCCM.

Para conferir o post original com maiores detalhes, acesse: http://blogs.technet.com/carlossantiago/archive/2008/06/18/are-duplicate-guids-and-conflicting-records-the-same-thing.aspx

Sds,

Alexandre Perazza.

Olá pessoal,

O ConfigMgr 2007 é uma poderosa ferramenta para os administradores quando o assunto é adquirir informações sobre o ambiente de rede. A base de dados SQL do ConfigMgr contém um grande número de informações como por exemplo computadores, usuários, grupos de usuários, dispositivos de rede, etc. Esta base de dados SQL também contém objetos que representam itens do ConfigMgr 2007 como por exemplo advertisements, software updates deployments, baselines, reports e status messages.

A ferramenta traz muitos reports pré-configurados que auxiliam no dia-a-dia do administrador mas e quando precisamos gerar um report personalizado, com informações pertinentes ao nosso ambiente?

Para auxiliar os administradores da ferramenta a entender as diferentes categorias das SQL views, qual informação é armazenada em cada uma delas e como elas podem ser interligadas (JOIN) com as demais para então criar reports que tragam as informações desejadas, podemos recorrer a documentação “Creating Custom Reports by Using Configuration Manager 2007 SQL Views”

Esta documentação deve ser baixada para a máquina e então instalada. Ela contém 4 arquivos:

• “Before You Start” – Vai te explicar como utilizar a documentação e também demonstrar como criar uma simples query utilizando diferentes views fazendo JOIN entre elas.
• “Creating Custom Reports by Using SQL Views” – Arquivo CHM contendo uma explicação de todas as views contidas na base de dados. Também explica como criar reports e acessá-los posteriormente.
• “Reference: Configuration Manager 2007 SQL Views” – Arquivo XLS contendo explicação de todas as views contidas na base de dados.
• “Reference: Configuration Manager 2007 SQL Views Schema”  - Sem dúvidas o arquivo mais interessante. São estêncils do Visio que nos dão uma visão macro sobre como as views podem ser interligadas (JOIN) para buscarmos as informações que precisamos. Os estêncils são separados por categorias. Abaixo um exemplo da categoria “Client Deployment SQL View Schema”:

Então, sempre que precisar criar um report específico que contenha informações granulares sobre diversos componentes, recorra aos estêncils e otimize o uso das informações armazenadas na base de dados do ConfigMgr 2007.

Sds,

Alexandre Perazza.

 

Olá pessoal,

Para quem está se preparando para o exame 70-401 ou gostaria de conhecer e testar o SCCM 2007, recomendo os excelentes vídeos técnicos criados pelo MVP Cléber Marques. Os vídeos cobrem desde a pré-instalação até a configuração e uso do produto.

Os links para os vídeos são:

·         Pré-requisitos para instalação do SCCM 2007

·         Estendendo o esquema do Active Directory

·         Instalando o ConfigMgr 2007 Toolkit

·         Instalando o SCCM 2007 com SP1

·         Pós-configuração no SCCM 2007

·         Instalando clientes do SCCM 2007

·         Instalando clientes do SCCM 2007 Manualmente

·         Instalando a Console do SCCM 2007

·         Ferramentas para Acesso Remoto (Remote Tools)

·         Inventário de Hardware e Software

·         Distribuição de Software (Software Distribution)

·         Implementação de Sistema Operacional (OSD)

·         Atualizações de Software (Software Updates)

Se você pretende realizar o exame, recomendo fortemente:                      

• Preparation Guide for Exam 70-401: TS Microsoft System Center Configuration Manager 2007, Configuring
• Biblioteca técnica: System Center Configuration Manager 2007
• TechNet Virtual Labs: SCCM 2007
• Fóruns Technet: Gerenciamento
• Labs, Labs and Labs (Virtual PC 2007) – baixe a versão de avaliação do produto em: SCCM TechCenter

Espero que aproveitem.

Sds,

Alexandre Perazza.

Olá pessoal,

Governança de T.I., assunto muito falado em diversas empresas hoje em
dia, possui algumas certificações que validam o conhecimento
do profissional sobre o tema. Uma delas é o MOF Foundation 4.0

O MOF (Microsoft Operations Framework) é um conjunto de melhores
práticas de implementação de serviços de T.I. desenvolvido com base
no ITIL.

Hoje compartilho com vocês o excelente material de apoio para quem gostaria de aprender ou certificar-se no exame EX0-102 - MOF 4.0 Foundation, desenvolvido pelo MVP Cléber Marques:

• Vídeo-treinamento (8 vídeos)

http://www.clebermarques.com/index.php?secao=mof

http://msmvps.com/blogs/clebermarques/archive/2009/01/08/treinamento-gratuito-mof-4-0-foundation.aspx

• MOF Foundation 4.0 Spreadsheet (em inglês)

http://www.clebermarques.com/mof/mofv4/MOF4Spreadsheet-EN.zip

• MOF Foundation 4.0 Spreadsheet (em português)

http://www.clebermarques.com/mof/mofv4/MOF4Spreadsheet-PT.zip

Muito comum no dia-a-dia de quem administra sistemas Windows através do SMS ou SCCM e afins, é se deparar com alguns erros referentes ao WMI. Erros que muitas vezes não são claros e demandam um bom tempo de troubleshooting para o analista.

Com o intuito de compartilhar algumas das situações mais frequentes e pelas quais já passei, deixo aqui uma série de posts que podem ser úteis na resolução destes problemas.

Primeiro, vamos entender o que é o WMI:

Windows Management Instrumentation (WMI) é a tecnologia primária para gerenciamento de sistemas operacionais Microsoft Windows. Fornece o gerenciamento consistente e uniforme, controle e monitoria dos sistemas Windows. É baseado em padrões da indústria e permite aos administradores de sistemas consultar, alterar e monitorar parâmetros de configuração em desktops e servidores, aplicações, rede, estando estes local ou remotos.

O Windows traz um conjunto padrão de contadores de performance que monitoram seu processador, memória, filesystem entre outros. Aplicações podem instalar ou modificar seus próprios contadores. ou utilizar algum já existente. Todos os dados gerenciados pelo WMI são armazenados no chamado "WMI Repository". (C:\WINDOWS\system32\wbem\Repository)

Quais aplicações são afetadas por problemas no WMI?

Todas as que monitoram ou fazem alterações no sistema durante sua instalação, por exemplo:

• Service Packs e Updates críticos
• Drivers de dispositivos
• Ferramentas de monitoramento (ex. SMS, SCCM, SCOM - todos os agentes)
• Ferramentas de desenvolvimento (ex. Visual Studio, SQL Server, .NET Framework, etc)

Existem muitas outras aplicações que utilizam o WMI para diversas operações e que não foram listadas acima, mas se você utiliza algumas destas e tem problemas na instalação ou no uso, problemas com o WMI podem ser a causa.

Para saber mais:

• Windows Management Instrumentation: Frequently Asked Questions

Nos próximos posts saberemos como identificar se nossos sistemas apresentam problemas com WMI.

Sds,

Alexandre Perazza.