Esos informes de mis Windows

How to launch the PAL tool

1. Ensure that the PAL tool and dependency components have been installed from http://www.codeplex.com/PAL .

2. Click Start, Run, and then PAL. This will launch the PAL wizard interface.

How to create a counter log file using PAL

Follow these steps to create a counter log .htm file once the PAL wizard has been launched. Note: This contains very specific counters instead of the full counter set that perfwiz uses, so you can choose how granular you would like to get.

1. Launch PAL.

2. Click the Threshold File Tab.

3. In the Threshold File Title drop down box, select the Threshold File Title version of your choice
clip_image001

4. Click the clip_image002

5. Save the settings to a .htm file. Follow the steps in the Exchange 2007 Perfwiz replacement steps at http://blogs.technet.com/mikelag/archive/2008/05/02/perfwiz-replacement-for-exchange-2007.aspx starting at step 4 to import this .htm file in to Performance monitor.
Note: This export feature only works on Windows 2003 servers since the ability to import htm files in Windows 2008 has changed. I will post an update on how to do this on Windows 2008 servers at a later time.

How to run the PAL wizard

1. Launch PAL. This will bring you to the Welcome Screen. Click Next

2. On the Counter Log tab, select a blg file of your choice. Click Next
clip_image003

3. Select the appropriate threshold file
clip_image001[1]

4. Answer any questions that are listed on that page. The answers to these questions are required so that during the processing of each performance file, we consume this information and pass this in to the tool for proper calculations. Click Next once finished.
clip_image004

5. On the Analysis Interval tab, select the interval that you would like to use. Note: The default of AUTO is recommended as that is the best performance option for running the tool. Any changes to this setting could cause the report generation process to be that much slower, but will allow you to get a little more granular if needed.
clip_image005
Click Next.

6. On the Output Options tab, you can select an Output Directory to store the PAL reports and what format you would like to use. Click Next once you have made your selections.
clip_image006

7. On the Queue tab, you will notice the parameters that will be passed in to the PAL tool for processing. Click Next if this satisfies your needs.
clip_image007

8. On the Execute tab, you can execute what you have just added to the queue or you could add more items to the queue for processing.
clip_image008

9. Click the clip_image009to execute the queued items.

This is a resource intensive application while these perfmon files are being parsed, so I would recommend using your fastest machine to run these reports on. Once PAL has completed processing the queued items, an IE window will open for each report in the queue.

I hope you have found this information useful and if you should have any questions regarding the tools usage, any possible problems that you may run in to or just suggestions to improve the tool, you can email paltool@microsoft.com

Happy reporting!!!

Buscar SID en Directorio Activo

Buscar SID en Directorio Activo.

Siempre nos ha surgido el caso de tener que buscar el objeto S-1-5-xxx-xxxx-xxxxxxxx-xxxxx y en ocasiones nos las hemos visto mas que negras para poder localizarlo.

Pues bien, hace tiempo descubri esta herramienta que la verdad me ha sacado de más de un apuro.

Service Level Dashboard 2.0 para SCOM 2007 R2

El Microsoft Service Level Dashboard (SLD) sirve para tener un panel con el monitoreo y dar seguimiento, gestión y presentación de informes sobre la línea de negocio (LOB) de nuestra empresa. En dicho reporte podemos ver los niveles de servicio de las aplicaciones. Veremos una lista de las mismas, el rendimiento actual y la disponibilidad de las mismas contra los objetivos propuestos al cliente.

Qué significa esto? Cuando nosotros contratamos un servicio, por ejemplo el hosting, nos dice que tendremos arriba nuestro sitio un 99% de uptime. Ese es el objetivo que luego se deberá comparar contra la realidad dependiendo la cantidad de tiempo que estuvo caído. Bueno, el SLD hace dicha comparación en un reporte con interfaz web y obtiene los datos del monitoreo mediante SCOM 2007 R2.

Recordemos que SCOM o System Center Operations Manager es el producto de Microsoft para monitorear el ambiente o plataforma de nuestra empresa. Ahí mediante los Management Packs podemos tener muchísima información de nuestros servidores, eventos centralizados, performance real time, etc. Si adicionamos este producto al SCOM tendremos un panel muy útil para el cliente o para nosotros mismos para poder conocer si estamos cumpiendo el nivel de servicio propuesto o no. Estos niveles de servicio o acuerdos de niveles de servicio suelen llamarse SLA o Service Level Agreement.

Este componente como mencioné antes trabaja gracias a la información que obtiene desde el SCOM y lo publica mediante un Sharepoint en un entorno web. Por eso es que dentro de sus requerimientos se encuentra el Sharepoint. Aquí vamos a repasar los mismos.

SLDObviamente uno de sus requerimientos es SCOM 2007 R2 con los servicios de Reporint y Data Warehouse. Además hace falta los Windows Sharepoint Services 3.0 SP1. SQL Server para la base de datos, .NET Framework 3.5, IIS para el entorno web y el Microsoft Office Compatibiilty Pack. Teniendo estos componentes instalados no vas a tener problemas para instalar el SLD.

Podemos ver el tiempo que demandó reparar el incidente y así sacar estadísticas. Podemos ver el estado de salud de nuestra plataforma TI en cuanto a los SLAs establecidos, y a través de la plataforma Sharepoint podemos compartir la información con las herramientas que ya conocemos.

Un gráfico de Technet muy interesante que nos ayuda a comprender el producto es el siguiente:

SLD Overview
Link | Service Level Dashboard 2.0 for System Center Operations Manager 2007 R2
Link | Service Level Dashboard MP for System Center Operations Manager 2007
Link | Microsoft Technet SLD

¿Cierto?

Tira Ecol

OpsMgr: Master List of Mutual Authentication Related Errors for OpsMgr 2007

Mutual Authentication takes one of two forms in Operations Manager – 1) Kerberos or 2) Certificate Authentication.  This is a list of authentication failures compiled by Pete Zerger based on field experience and his MMS 2008 presentation on Gateway Scenarios in OpsMgr 2007 SP1, which can be downloaded HERE. Having helped many dozens (perhaps hundreds) of OpsMgr administrators troubleshoot mutual authentication issues, I have encountered many different scenarios. Here is a list of event IDs and potential explanations you may find helpful.

 

The following is a list of mutual authentication-related error messages and some general indicators of source cause. Some errors are Kerberos-related issues (like SPN problems) and some are related to certificate authentication. These errors are are also applicable to System Center Essentials 2007

Event ID Description Explanation
20050 Enhanced key usage error Wrong OID specified on the certificate
20057 The OpsMgr Connector could not connect to MSOMHSvc/rms01.local because mutual authentication failed.  Verify the SPN is properly registered Often associated with SPN registration failures. Make sure SPNs are registered (and forest trust in place if separate forest) so Kerberos authentication.
20070 The OpsMgr Connector connected to <server> but the connection was closed immediately after authentication occurred.  The most likely cause of this error is that the agent is not authorized to communicate with the server, or the server has not received configuration.

This and 21016 are general indicators of failed authentication. However, these two events do not provide much insight into source cause. This error will appear when a manually installed agent is in “Pending” status, but for a host of other reasons.
21001 The OpsMgr Connector could not connect to MSOMHSvc/rmsxxx.domain.com because  mutual authentication failed. Verify the SPN is properly registered Often associated with SPN registration failures. Make sure SPNs are registered (and forest trust in place if separate forest) so Kerberos authentication can succeed.
21005 DNS resolution failed Check DNS name resolution on the agent and upstream  gateway or mgmt server.
21006 TCP Connection failed (at TCP level) The OpsMgr Connector could not connect to <server>. The error code is 10061L… Often indicates you have a firewall in the path blocking communication. Try telnet to 5723 from both nodes attempting to communicate.

 

The other instance where I occasionally see this is when the wrong management group name AND management server are entered.

 

21007 Not in a trusted domain Cannot establish a security communication channel to the management server because the correct certificates are not available. Retrace your steps on certificate Configuration (see KB947691)
21008 Untrusted target (usually means untrusted domain or failure to reach DC) Check name resolution and network connectivity.
21016 OpsMgr was unable to set up a communications channel to server and there are no failover hosts. This and 20070 are general indicators of failed authentication. However, these two events do not provide much insight into source cause. This error will appear when a manually installed agent is in “Pending” status, but for a host of other reasons.
21035 SPN registration failed; Kerberos authentication will not work Often associated with SPN registration failures. Make sure SPNs are registered so Kerberos authentication.
21036 The certificate specified in the registry at cannot be used for authentication. Private key is missing from the certificate. Usually see this on export and CLI registration OR when certificate is copied between stores in Certificates snap-in.
20068 Certificates has unusable / no private key Also indication of private key missing
20069 Wrong type of certificate (KEY_SPEC) Wrong OIDs on certificate
20072 Remote certificate not trusted The certificate of the CA (CA chain, root to issuer) of the remote servers certificate must be in the “Trusted Root Certification Authorities” store of the local computer account in the Certificates snap-in
20075 Unable to obtain subject or issuer from certificate Never seen this one in a live environment…Indicates failure to retrieve subject (aka common name) or issuing authority on the certificate
20076 Unable to obtain subject or issuer from remote certificate Never seen this one in a live environment…Indicates failure to retrieve subject (aka common name) or issuing authority on the certificate presented by the other system
20077 Certificates cannot be queried for property info This typically means that no private key was included with the certificate.

OpsMgr 2007: RMS cluster node registers the Health Service SPN with the physical node’s computer account

========

Issue: In System Center Operations Manager 2007, a node in an RMS cluster registers the servicePrincipalName (SPN) for the Health Service with the physical node’s computer account. This is a problem because the SPN must be registered with the account of the RMS cluster computer. When the SPN registration is duplicated or the registration is with the wrong computer account, mutual authentication fails. This causes the RMS and agents to go into gray state.

Additionally, when the RMS cluster group is active on the affected node, the service state folders for the Config Service, SDK Service and Health Service are on the node’s local drive instead of the shared cluster drive.

Cause: This can occur when the ManagementServerConfigTool.exe has not been run successfully on an RMS cluster node.

When you run ManagementServerConfigTool.exe with the InstallCluster or AddRMSNode argument, the tool creates a registry value named HealthServiceVirtualHost in the following registry sub-key:

HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Microsoft Operations Manager\3.0

When the Health Service starts, it tries to read the HealthServiceVirtualHost registry value. If that value exists, Health Service skips SPN registration and logs the following Information event in the Native trace log:

0              00000000             [0]7592.8548::10/15/2008-15:32:47.019 [MOMConnector]  Information CConnectorSolutionSharedState::TryRegisterServiceSpn(ConnectorSolutionSharedState_cpp2788)Received value for GetHealthServiceVirtualHostName.  Assuming that this is clustered RHS so not trying to register SPN.

ManagementServerConfigTool.exe creates the HealthServiceVirtualHost registry value using the name specified in the /vs argument. It also changes the service state path for the OpsMgr services to the drive specified in the /Disk argument. That way, the service state folders will be on the shared cluster drive instead of the local installation directory.

For more information about installing an RMS cluster and using ManagementServerConfigTool.exe, refer to the following topic in the OpsMgr 2007 Deployment Guide:

Deploying a Root Management Server on a Windows Cluster in Operations Manager 2007
http://technet.microsoft.com/en-us/library/bb432140.aspx

Resolution: Run ManagementServerConfigTool.exe on the affected cluster node with the AddRMSNode argument. This will configure the HealthServiceVirtualHost registry value and prevent the incorrect SPN registration. It will also configure the clustered OpsMgr services to use the shared cluster drive for storage state instead of a local drive. To do this, use the following steps:

1. Using Cluster Administrator, move the RMS cluster group to the affected node.
2. Take the Config Service, SDK Service and Health Service resources offline.
3. Copy the latest version of ManagementServerConfigTool.exe from the OpsMgr source media (in the SupportTools folder) to the System Center Operations Manager 2007 installation folder.
4. From a command prompt, run the following command:

ManagementServerConfigTool.exe AddRMSNode /vs:<VirtualServerNetbiosName> /Disk:<VirtualServer Disk Resource>

In the above command, VirtualServerNetbiosName is the Network Name resource in the RMS cluster group. The value you enter for VirtualServerNetbiosName must be the value that appears in the Name text box located on the Parameters tab of the Properties dialog box for the Network Name cluster resource. VirtualServerDiskResource is the disk resource allocated to the RMS cluster group . The Disk location can be found by on the Parameters tab of the Properties dialog box for the Disk Resource.

5. After this command completes, verify that the HealthServiceVirtualHost registry value exists in the following registry sub-key:

HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Microsoft Operations Manager\3.0

6. Use adsiedit.msc or setspn.exe to remove the Health Service SPN from the computer account for the physical node. Make sure that the SPN is registered correctly with the account of the RMS cluster computer.

7. Bring the OpsMgr services online and verify that the invalid Health Service SPN registration does not recur.

========

Setting the Default Process Security Level Using VBScript

A script can use the default WMI authentication and impersonation settings. However, the script may need a connection with more security or may connect to a namespace that requires an encrypted connection. For more information, see Setting Namepace Security Descriptors and Requiring an Encrypted Connection to a Namespace.

In the simplest case, a script can use the default authentication and impersonation settings. WMI normally runs in a shared service host and shares the same authentication as other processes in the host. If you want to run the WMI process with a different level of authentication, run WMI with the winmgmt command with the /standalonehost switch and set the authentication level for WMI generally. For more information, see Maintaining WMI Security.

Windows Server 2003, Windows XP, and Windows 2000: The /standalonehost switch is not available.

The following script uses default settings for impersonation and authentication levels.

strComputer = "." 
Set objServices = GetObject("winmgmts:\\" _
    & strComputer & "\root\CIMV2") 
set objProcessSet = objServices.ExecQuery _
     ("SELECT Name FROM Win32_Process",,48)
For Each Process in objProcessSet
    WScript.Echo Process.Name
Next

You can also use a moniker in a call to GetObject, and set the default security settings, as in the following example.

strComputer = "." 
Set objServices = GetObject( _
    "winmgmts:{impersonationLevel=impersonate," _
    & "authenticationLevel=pktPrivacy}!root/cimv2")
set objProcessSet = objServices.ExecQuery _
     ("SELECT Name FROM Win32_Process",,48)
For Each Process in objProcessSet
    WScript.Echo Process.Name
Next

For more information about setting different impersonation or authentication levels in a script, or for setting the default values for a computer, see the following topics:

Changing the Default Authentication Credentials Using VBScript

You can change the authentication level in a script using a moniker string, and the SWbemLocator and SWbemSecurity objects.

The authentication level must be set according to the requirements of the target operating system to which you are connecting. For more information, see Connecting Between Different Operating Systems.

The following VBScript code example shows how to change the authentication level in a script that obtains the free space data from a remote computer named “Server1”.

strComputer = "Server1"
Set objWMIService = GetObject("winmgmts:" _
    & "{authenticationLevel=Pkt}!\\" _
    & strComputer & "\root\cimv2")
Set colDisks = objWMIService.ExecQuery _
    ("Select * from Win32_LogicalDisk")
For each objDisk in colDisks
    Wscript.Echo "DeviceID: " & vbTab & _
        objDisk.DeviceID & vbNewLine & _
        "FreeSpace: " & vbTab & objDisk.FreeSpace 
    NextstrComputer = "." 
    Set objServices = GetObject( _
        "winmgmts:{impersonationLevel=impersonate," _
        & "authenticationLevel=pktPrivacy}!root/cimv2")
    Set objProcessSet = objServices.ExecQuery _
        ("SELECT Name FROM Win32_Process",,48)
    For Each Process in objProcessSet
        WScript.Echo Process.Name
    Next
Next

In script moniker connections to WMI, use the short name shown in the “Moniker name/description” column of the table below. For example, in the following script, the authentication level is set to WbemAuthenticationLevelPktIntegrity.

SetobjWMIService = GetObject( _
    "winmgmts:{authenticationLevel=pktPrivacy}!root\cimv2")

The following table lists the authentication levels you can set. These levels are defined in Wbemdisp.tlb in the enumeration WbemAuthenticationLevelEnum.

Name/value Description
WbemAuthenticationLevelDefault0 Moniker: DefaultWMI uses the default Windows Authentication setting. This is the recommended setting that allows WMI to negotiate to the level required by the server returning data. However, if the namespace requires encryption, use WbemAuthenticationLevelPktPrivacy.
WbemAuthenticationLevelNone1 Moniker: NoneUses no authentication.
WbemAuthenticationLevelConnect2 Moniker: ConnectAuthenticates the credentials of the client only when the client establishes a relationship with the server.
WbemAuthenticationLevelCall3 CallAuthenticates only at the beginning of each call when the server receives the request.
WbemAuthenticationLevelPkt4 Moniker: PktAuthenticates that all data received is from the expected client.
WbemAuthenticationLevelPktIntegrity5 Moniker: PktIntegrityAuthenticates and verifies that none of the data transferred between client and server has been modified.
WbemAuthenticationLevelPktPrivacy6 Moniker: PktPrivacyAuthenticates all previous impersonation levels and encrypts the argument value of each remote procedure call. Use this setting if the namespace to which you are connecting requires an encrypted connection.

 

To determine a successful call, check the return value after you change the authentication level.

For example, because local connections always have an authentication level of wbemAuthenticationLevelPktPrivacy, the following example fails to set the authentication level because it connects to the local computer.

strComputer = "."
Set objWMIService = GetObject("winmgmts:" _
    & "{impersonationLevel=impersonate," _
    & "authenticationLevel=pktPrivacy}!" _
    & "\\" & strComputer & "\root\cimv2")

A provider can set the security on a namespace so that no data is returned unless you use packet privacy (PktPrivacy) in your connection to that namespace. This ensures that data is encrypted as it crosses the network. If you try to set a lower authentication level, you will get an access denied message. For more information, see Securing WMI Namespaces.

Windows Server 2003, Windows XP, and Windows 2000: Before Windows Server 2003 with Service Pack 1 (SP1), providers could not set namespace security to require encryption before returning data.

Changing the Default Impersonation Levels Using VBScript

When you make calls to the Scripting API for WMI, it is recommended that you use the defaults that WMI provides for the impersonation level. Remote calls and some providers with more than one network hop require a higher impersonation level than WMI uses. If the impersonation level is not sufficient, a provider might refuse a request or provide incomplete information.

If you do not set the impersonation level in either a moniker or by setting SWbemSecurity.ImpersonationLevel on a securable object, then set the default DCOM impersonation level for the operating system. The impersonation level must be set according to the requirements of the target operating system to which you are connecting. For more information, see Connecting Between Different Operating Systems.

The following VBScript code example shows changing the impersonation level in the same script shown above.

strComputer = "Server1"
Set objWMIService = GetObject("winmgmts:" _
    & "{impersonationLevel=Impersonate}!\\" _
    & strComputer & "\root\cimv2")
Set colDisks = objWMIService.ExecQuery _
    ("Select * from Win32_LogicalDisk")
For each objDisk in colDisks
Wscript.Echo "DeviceID: " & vbTab _
    & objDisk.DeviceID & vbNewLine & _
    "FreeSpace: " & vbTab & objDisk.FreeSpace 
Next


The following table lists the authentication levels in WbemImpersonationLevelEnum that use.

Name/value Description
wbemImpersonationLevelAnonymous1 Moniker: AnonymousHides the credentials of the caller. Calls to WMI may fail with this impersonation level.
wbemImpersonationLevelIdentify2 Moniker: IdentifyAllows objects to query the credentials of the caller. Calls to WMI may fail with this impersonation level.
wbemImpersonationLevelImpersonate3 Moniker: ImpersonateAllows objects to use the credentials of the caller. This is the recommended impersonation level for Scripting API for WMI calls.
wbemImpersonationLevelDelegate4 Moniker: DelegateAllows objects to permit other objects to use the credentials of the caller. This impersonation will work with Scripting API for WMI calls but may constitute an unnecessary security risk.

 

The following example shows how to set the impersonation in a moniker string when obtaining a specific instance of Win32_Process.

Set object = GetObject( _
    "winmgmts:{impersonationLevel=impersonate}" _
    & "!root\cimv2:Win32_Process.Handle='0'")

For more information, see Creating a WMI Application or Script.

Setting the Default Impersonation Level Using the Registry

If you have access to the registry, you can also set the default impersonation level registry key. This key specifies which impersonation level the Scripting API for WMI uses unless otherwise specified. The following path identifies the registry path.

HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\WBEM\Scripting\Default Impersonation Level

By default, the registry key is set to 3, specifying the Impersonate impersonation level. Some providers may require a higher level of impersonation.

Accessing the SWbemSecurity Object in VBScript

The other way you can set the impersonation level is from the SWbemSecurity security object, which appears as the Security_ property of the SWbemServices, SWbemObject, SWbemObjectSet, SWbemEventSource, SWbemObjectPath, and SwbemLocator objects.

WMI passes the security setting of a parent object to the descendants of the original object. Therefore, you can set the impersonation level of an SWbemServices object after logging on to WMI and API calls using this object or objects created from it, such as objects of type SWbemObject.