Já recebi diversas vezes perguntas de profissionais de TI sobre o erro abaixo do instalado do SCOM em todas as suas versões.

Realmente o erro é muito genérico e normalmente quem me perguntou consultou páginas de requisitos e não achou o problema.

Neste exemplo especifico que simulei, o erro é o SQL Server 2012 que está no SP1 e o SCOM exige o SP2, que ainda não havia sido aplicado:

Mas como chegar a este detalhe para saber se o problema é um patch, service pack ou comunicação com o servidor?

Para isso o instalador do System Center gera um log que fica no diretório C:\User\<usuário>\AppData\SCOM\Logs com o nome OpsMgrSetupWizard.txt

Neste arquivo é detalhado os passos das validações como abaixo:

[11:08:46]:    Debug:    :MSSQLSERVER on server w2012r2-sql2012 is in a running state
[11:08:46]:    Info:    :Info:Opening/Testing Sql Connection on w2012r2-sql2012, port:
[11:08:46]:    Debug:    :Connection was not open.  We will try to open it.
[11:08:46]:    Debug:    :SqlConnectionReady returned True.
[11:08:47]:    Debug:    :MSSQLSERVER on server w2012r2-sql2012 is in a running state
[11:08:47]:    Debug:    :Connection was not open.  We will try to open it.
[11:08:47]:    Debug:    :SqlConnectionReady returned True.
[11:08:47]:    Info:    :Info:Using DB command timeout = 1800 seconds.
[11:08:47]:    Info:    :SQL Product Level: SP1
[11:08:47]:    Info:    :SQL Edition: Enterprise Edition (64-bit)
[11:08:47]:    Info:    :SQL Version: 11.0.3128.0
[11:08:47]:    Always:    :Current Version of SQL=11.0.3128.0   Required Version=11.0.5058
[11:08:47]:    Always:    :Entering GetRemoteOSVersion.
[11:08:47]:    Info:    :Info: remoteOS = 6.3.9600
[11:08:47]:    Info:    :Info:Using DB command timeout = 1800 seconds.
[11:08:47]:    Info:    :Info:Using DB command timeout = 1800 seconds.
[11:08:47]:    Info:    :The SQL Collation is valid.
[11:08:47]:    Info:    :Info:Using DB command timeout = 1800 seconds.
[11:08:47]:    Info:    :Info:DatabaseConfigurationPage: DB connection attempt completed.
[11:08:47]:    Info:    :Info:DatabaseConfigurationPage: DB connection attempt completed.

Neste arquivo é possivel visualizar todos os testes que ele efetuou e saber se o problema é permissão, porta, collation ou, como neste exemplo, falta de update.

Apesar de ser um produto já lançado a algum tempo, o Exchange 2013 não tinha um Management Pack rico, sendo o mesmo do Exchange 2010 atualizado.

Porem, com o SCOM 2012 R2 e seus novos recursos para views e dashboards sentíamos muita falta de inclusão dos novos contadores, views mais especializadas e webparts ricas, bem como relatórios.

A algum tempo que os MVPs de System Center receberam os betas para testar e realmente ficou muito bom!

Segue o link para download: http://www.microsoft.com/en-ca/download/details.aspx?id=39039

Na semana passada a Microsoft disponibilizou o Cumulative Update 3 para o SCCM 2012 R2. Este update não está sendo trazido pelo Windows Update e precisa ser acessado pelo link http://support.microsoft.com/kb/2994331

Este update é importante pois resolve alguns problemas com migração de perfil após o CU2 e inclui as versões de Linux com kernel v7:

• Debian 7 (x86)
• Debian 7 (x64)
• Red Hat Enterprise Linux 7 (x64)
• CentOS 7 (x64)
• Oracle 7 (x64)

Este update já cria automaticamente 3 pacotes para atualização do agente, console e serviços em um único pacote como aconteceu com o CU2. Quem lembra dos 4 diferentes pacotes que precisavam ser instalados sabe como era complicado:

Como identificar o Cumulative Update Instalado

Pode parecer simples, mas muitos me perguntam como identificar se está ou não com o ultimo cumulative update.

Existem duas formas de fazer isso, a primeira é utilizando o Service Extension, atualmente em Beta (http://www.marcelosincic.com.br/post/Configuration-Manager-Servicing-Extension-para-SCCM-2012-SP1-e-R2.aspx).

A outra forma é por ler a chave de registry HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\SMS\Setup como abaixo: