Niedawno zauważyłem uciążliwy problem po usunięciu z topologii serwera, który poprzednio pełnił rolę CMS. Usługa LS File transfer Agent Service cyklicznie zgłaszała błąd 1034 (jak widać na poniższym rysunku), co oczywiście śmieciło w konsoli SCOM-a, a dodatkowo wprowadzało zamieszanie w logach serwera:
Zasadniczo powinno pomóc wymuszenie odświeżenia konfiguracji poprzez wykonanie komendy
Invoke-CsManagementStoreReplication, jednak po jej wykonaniu i po sprawdzeniu konfiguracji poprzez Get-CsManagementStoreReplicationStatus -CentralManagementStoreStatus, serwer usunięty z topologii i odinstalowany, był widoczny w tablicy DeletedReplicas.
Podobny problem opisał na swoim blogu Thomas Poett, pokazując niewspieraną ale skuteczną metodę polegającą na ręcznym usunięciu z SQL-a odpowiedniego wiersza z tabeli [Replica]. W przypadku, który rozwiązywałem, jednak sposób opisany przez Thomasa nie do końca pomógł - SQL nie pozwalał usunąć wiersza ze względu na referecje w innych tabelach. Faktycznie okazało się, że w tabeli ReplicaStatus są odwołania do tabeli identy
Nie jestem ekspertem od SQL-a, więc zamiast tworzyć kolejne linie T-SQLa, zrobiłem to z wykorzystaniem SQL Management Studio. Po połączeniu do serwera, na którym jest Central Management Store, przeszedłem do widoku tabel tej bazy (rysunek poniżej).
Następnie wyświetliłem pierwszych 200 rekordów tabeli [Replica].
Korzystając z kolumny ReplicaId, zweryfikowałem wartość z wiersza, odpowiadającego serwerowi, który powinien być skasowany, a następnie przeszedłem do edycji wierszy tabeli [ReplicaStatus] i usunąłem wszystkie wiersze z tym samym numerem.
Teraz już wiersz z tabeli [Replica] pozwala się skasować. I błędy 1034 w logu aplikacyjnym przestaje się pojawiać.
Brak komentarzy:
Prześlij komentarz