• Artículo

Tareas posteriores a la actualización de Operations Manager 2007 R2

 

Se aplica a: System Center 2012 R2 Operations Manager, System Center 2012 - Operations Manager, System Center 2012 SP1 - Operations Manager

Después de completar el proceso de actualización de System Center 2012 – Operations Manager, debe realizar una serie de tareas posteriores a la actualización.

Tareas posteriores a la actualización

La siguiente tabla muestra las tareas que debe completar después de haber actualizado a System Center 2012 – Operations Manager. También indica cuándo se debe realizar la tarea.

Tarea

Cuándo realizar la tarea

Volver a habilitar las suscripciones de notificación

Después de completar las tareas de actualización en cualquier ruta de actualización.

Reiniciar o volver a habilitar los servicios del conector

Después de completar las tareas de actualización en cualquier ruta de actualización y, únicamente, si los servicios del conector están instalados.

Desinstalar el antiguo RMS

Únicamente si actualiza el grupo de administración del servidor de administración secundario.

Actualizar invalidaciones

Después de actualizar el grupo de administración

Comprobar que la actualización se realizó correctamente

Después de completar las tareas de actualización en cualquier ruta de actualización.

Ejecutar una consulta SQL en cada grupo de administración

Ejecute una consulta SQL en cada grupo de administración para limpiar la tabla Localizedtext y la tabla Publishmessage.

Asignar agentes de UNIX/Linux a un grupo de recursos

Después de completar las tareas de actualización en cualquier ruta de actualización.

Volver a habilitar las suscripciones de notificación

Una vez finalizada la actualización, realice el procedimiento siguiente para volver a habilitar las suscripciones.

Para volver a habilitar las suscripciones

  1. Abra la consola del operador con una cuenta que sea miembro del rol Administradores de Operations Manager para el grupo de administración de System Center 2012 – Operations Manager.

  2. Abra la consola del operador y, en el panel de navegación, haga clic en el botón Administración.

    Nota

    Al ejecutar la consola del operador en un equipo que no es un servidor de administración, aparece el cuadro de diálogo Conectar a servidor. En el cuadro de texto Nombre del servidor, escriba el nombre del servidor de administración de System Center 2012 – Operations Manager al que desea conectarse.

  3. En el panel Administración, en Notificaciones, haga clic en Suscripciones.

  4. En el panel Acciones, haga clic en Habilitar para cada suscripción que aparece en la lista.

Reiniciar o volver a habilitar los servicios del conector

Consulte la documentación de otros fabricantes para los conectores instalados a fin de determinar si los conectores son compatibles con System Center 2012 – Operations Manager.

Para reiniciar un servicio de conector

  1. En la barra de tareas, haga clic en Inicio, Herramientas administrativas y, a continuación, en Servicios.

  2. En la columna Nombre, haga clic con el botón secundario en el conector que desee reiniciar y, a continuación, haga clic en Iniciar.

Desinstalar el antiguo RMS

Si se actualizó a System Center 2012 – Operations Manager desde el servidor de administración secundario porque el RMS no cumplía las configuraciones admitidas para System Center 2012 – Operations Manager, se quitará el RMS del grupo de administración durante la actualización. A continuación, puede desinstalar el antiguo servidor de administración raíz (RMS).

Nota

Si actualizó desde el servidor de administración secundario, puede crear un nuevo servidor de administración con el mismo nombre del equipo Windows que el antiguo RMS, en lugar de cambiar los valores de la configuración para apuntar al nuevo servidor de administración.

Para desinstalar el antiguo RMS

  1. Inicie sesión en el equipo que hospeda el RMS con una cuenta que tenga permisos de administrador local.

  2. En la barra de tareas, haga clic en Inicio y, a continuación, en Panel de Control. A continuación, ejecute Programas y características.

  3. Haga clic con el botón secundario en Operations Manager 2007 R2 y, a continuación, haga clic en Desinstalar.

  4. En el cuadro de diálogo Programa y características, haga clic en Sí para confirmar que desea desinstalar.

Actualizar invalidaciones

Si ha creado invalidaciones de las reglas de integración de Active Directory, debe volver a crearlas después de finalizada la actualización de grupo de administración. Elimine la invalidación antigua y, a continuación, cree una invalidación nueva y coincidente orientada a los grupos de asignación de recursos de Active Directory.

Comprobar que la actualización se realizó correctamente

Realice las tareas siguientes para comprobar que la actualización se realizó correctamente.

  • Compruebe el estado de mantenimiento de los servidores de administración y de los agentes en la vista de estado Monitor de servicio de mantenimiento. En el área de trabajo Administración de la consola del operador, asegúrese de que los servidores de administración y los agentes están en buenas condiciones de mantenimiento. En el área de trabajo Supervisión, compruebe si hay alguna alerta relacionada con el estado del grupo de administración.

  • Revise los registros de eventos de todos los servidores de administración para detectar nuevos errores.

  • Ordene las alertas por la columna Última modificación para revisar las nuevas alertas.

  • Compruebe la utilización de la CPU y la E/S de disco en los servidores de base de datos para asegurarse de que funcionan con normalidad.

  • Si está instalada la característica de Informes, haga clic en Informes y, a continuación, ejecute un informe de rendimiento genérico para asegurarse de que la generación de informes funciona correctamente.

  • Vuelva a implementar los agentes que desinstaló durante el proceso de actualización.

Ejecutar una consulta SQL en cada grupo de administración

Ejecute la siguiente consulta SQL en la base de datos operativa de cada grupo de administración para limpiar la tabla Localizedtext y la tabla Publishmessage.

-- Create a temporary table to quickly find a PublisherId when you know the MessageId.
BEGIN TRY
CREATE TABLE #PublisherMessageReverseIndex(MessageStringId UNIQUEIDENTIFIER, 
   MessageId INT)
CREATE CLUSTERED INDEX #PublisherMessageReverseIndex_CI ON #PublisherMessageReverseIndex(MessageStringId)
INSERT INTO #PublisherMessageReverseIndex (MessageStringId, MessageId)
SELECT MessageStringId, MessageId
FROM dbo.PublisherMessages

-- Create a temporary table of message lengths, message IDs, and message hashes with the
-- MessageStringId to quickly determine whether a message is duplicated. Index the table. 

CREATE TABLE #LTHashStrings (MessageStringId UNIQUEIDENTIFIER, 
 LTValueLen INT, 
 LTValueHash VARBINARY(32),
 MessageId INT NULL)
CREATE CLUSTERED INDEX #LTHashStrings_CI ON #LTHashStrings(MessageStringId)
CREATE NONCLUSTERED INDEX #LTHashStrings_NCI1 ON #LTHashStrings(LTValueLen, MessageId, LTValueHash)

-- Create a temporary table for the orphaned PublisherStrings that you find. Orphaned PublisherStrings 
-- are rows in PublisherMessages whose corresponding events have already been groomed. They still
-- have corresponding rows in LocalizedText.  Do not add rows for PublisherMessages; they are not
-- for duplicated messages.

CREATE TABLE #OrphanedPublisherStrings (PublisherId UNIQUEIDENTIFIER, 
MessageStringId UNIQUEIDENTIFIER)
CREATE CLUSTERED INDEX #OrphanedPublisherStrings_CI ON #OrphanedPublisherStrings(MessageStringId)

-- Create a temporary table so that you can determine whether a PublisherMessages row still
-- has a corresponding event. These events do not have an index on the PublisherId, so do 
-- not query the EventAllView. If a PublisherId occurs multiple times in the event tables,
-- it is only needed one time in the temp table; therefore, the unique clustered index
-- must contain IGNORE_DUP_KEY. This keeps the temporary table relatively small and saves
-- time when you want to see the orphaned PublisherMessages.

CREATE TABLE #EventAllPublishers (PublisherId UNIQUEIDENTIFIER)
CREATE UNIQUE CLUSTERED INDEX #EventAllPublishers_CI ON #EventAllPublishers (PublisherId)
WITH (IGNORE_DUP_KEY = ON)

-- Populate the temporary table by scanning EventAllView one time.
INSERT INTO #EventAllPublishers(PublisherId) 
SELECT PublisherId 
FROM EventAllView

-- Populate the first temporary table to determine which messages are duplicated.
INSERT INTO #LTHashStrings (MessageStringId, LTValueLen, LTValueHash, MessageId)
SELECT LTStringId, len(LTValue), HashBytes('SHA1', LTValue), MessageId
FROM dbo.LocalizedText LT 
JOIN #PublisherMessageReverseIndex PM ON PM.MessageStringId = LTStringId

-- Create the second table to determine which messages are duplicated.  
CREATE TABLE #LTCountByMessage( LTValueLen INT, 
MessageId INT, 
LTValueHash VARBINARY(32), 
MsgCount INT)
CREATE CLUSTERED INDEX #LTCountByMessage_CI ON #LTCountByMessage(LTValueLen, MessageId, LTValueHash)

-- Populate second message for duplicate message detection by scanning the INDEX of
-- the first one and by doing a grouped count.
INSERT INTO #LTCountByMessage (LTValueLen, MessageId, LTValueHash, MsgCount)
SELECT LTValueLen, MessageId, LTValueHash, COUNT(1) 
FROM #LTHashStrings
GROUP BY LTValueLen, MessageId, LTValueHash

-- You are now set up to detect both orphaned PublisherStrings and duplicated messages
-- by joining to our relatively small (and correctly indexed) temporary tables.
-- Determine the OrphanedPublisherStrings that have duplicate messages.
INSERT INTO #OrphanedPublisherStrings (PublisherId, MessageStringId)
SELECT PM.PublisherId, PM.MessageStringId 
FROM dbo.PublisherMessages PM 
JOIN #LTHashStrings LTS ON (LTS.MessageStringId = PM.MessageStringId AND LTS.MessageId = PM.MessageId)
JOIN #LTCountByMessage LTC ON (LTC.LTValueLen = LTS.LTValueLen AND
LTC.MessageId = LTS.MessageId AND LTC.LTValueHash = LTS.LTValueHash)
WHERE PM.PublisherId NOT IN (SELECT PublisherId FROM #EventAllPublishers) AND
LTC.MsgCount > 1

-- Deleting all the OrphanedPublisherStrings and all the corresponding LocalizedText rows
-- at one time may be too large for the transaction log to handle.  Create a numbered
-- or ordered table so that you can delete them in relatively small batches and not
-- overtax the transaction log.
CREATE TABLE #NumberOrphanPublisherStrings(OrphanNum INT IDENTITY,
   PublisherId UNIQUEIDENTIFIER, 
   MessageStringId UNIQUEIDENTIFIER)
CREATE CLUSTERED INDEX #NumberOrphanPublisherStrings_CI on #NumberOrphanPublisherStrings(OrphanNum)

-- Populate the numbered table.
INSERT INTO #NumberOrphanPublisherStrings (PublisherId, MessageStringId)
SELECT PublisherId, MessageStringId FROM #OrphanedPublisherStrings
END TRY
BEGIN CATCH
GOTO Error
END CATCH

-- Set up variables so that you can delete the orphaned rows.
-- If the transaction log fills up, try to reduce the @OrphanIncrement value,
-- which controls the number of rows that are delete at the same time.
DECLARE @OrphanNum INT
DECLARE @OrphanIncrement INT
DECLARE @OrphanLimit INT
SET @OrphanNum = 0
SET @OrphanIncrement = 10000
SELECT @OrphanLimit = MAX(OrphanNum) FROM #NumberOrphanPublisherStrings
BEGIN TRY
WHILE @OrphanNum < @OrphanLimit
BEGIN
DELETE dbo.LocalizedText FROM
#NumberOrphanPublisherStrings OPS JOIN dbo.LocalizedText LT
ON LT.LTStringId = OPS.MessageStringId
WHERE OPS.OrphanNum >= @OrphanNum AND OPS.OrphanNum < @OrphanNum + @OrphanIncrement
DELETE dbo.PublisherMessages FROM
#NumberOrphanPublisherStrings OPS JOIN dbo.PublisherMessages PM
ON PM.PublisherId = OPS.PublisherId
WHERE OPS.OrphanNum >= @OrphanNum AND OPS.OrphanNum < @OrphanNum + @OrphanIncrement
SET @OrphanNum = @OrphanNum + @OrphanIncrement
END
END TRY
BEGIN CATCH
GOTO Error
END CATCH

Error:
IF @@ERROR <> 0
   SELECT 
        ERROR_NUMBER() AS ErrorNumber,
        ERROR_MESSAGE() AS ErrorMessage;

-- Try to drop all the temporary tables
BEGIN TRY
IF EXISTS (SELECT 1 FROM tempdb.INFORMATION_SCHEMA.TABLES WHERE TABLE_NAME LIKE '#PublisherMessage%')
DROP TABLE #PublisherMessageReverseIndex
IF EXISTS (SELECT 1 FROM tempdb.INFORMATION_SCHEMA.TABLES WHERE TABLE_NAME LIKE '#OrphanedPublisherStrings%')
DROP TABLE #OrphanedPublisherStrings
IF EXISTS (SELECT 1 FROM tempdb.INFORMATION_SCHEMA.TABLES WHERE TABLE_NAME LIKE '#LTHashStrings%')
DROP TABLE #LTHashStrings
IF EXISTS (SELECT 1 FROM tempdb.INFORMATION_SCHEMA.TABLES WHERE TABLE_NAME LIKE '#EventAllPublishers%')
DROP TABLE #EventAllPublishers
IF EXISTS (SELECT 1 FROM tempdb.INFORMATION_SCHEMA.TABLES WHERE TABLE_NAME LIKE '#LTCountByMessage%')
DROP TABLE #LTCountByMessage
IF EXISTS (SELECT 1 FROM tempdb.INFORMATION_SCHEMA.TABLES WHERE TABLE_NAME LIKE '#NumberOrphanPublisherStrings%')
DROP TABLE #NumberOrphanPublisherStrings
END TRY
BEGIN CATCH
   SELECT 
        ERROR_NUMBER() AS ErrorNumber,
        ERROR_MESSAGE() AS ErrorMessage;
END CATCH

Asignar agentes de UNIX/Linux a un grupo de recursos

Una vez finalizada la actualización, los agentes de UNIX/Linux deben asignarse a un grupo de recursos para habilitar la supervisión de alta disponibilidad y la administración de agentes. Para obtener más información sobre la creación de grupos de recursos, vea How to Create a Resource Pool (Creación de un grupo de recursos).

  1. Abra la consola del operador con una cuenta que sea miembro de la función Administradores de Operations Manager para el grupo de administración de om12short.

  2. Abra la consola del operador y, en el panel de navegación, haga clic en el botón Administración.

  3. En el panel Administración, en Administración de dispositivos, haga clic en Equipos UNIX/Linux.

  4. Seleccione los equipos UNIX/Linux que se van a asignar un grupo de recursos y, en el panel Acciones, haga clic en Cambiar grupo de recursos.

  5. Complete el Asistente para Cambiar grupo de recursos para asignar los equipos al grupo de recursos seleccionado.