APN Promise Technology Summit 2016

Już pojutrze odbędzie się w Warszawie doroczna konferencja techniczna, przygotowana przez moją firmę - APN Promise Technology Summit 2016. 

Jak zwykle jestem odpowiedzialny za ścieżkę Communication, na którą serdecznie zapraszam - będzie się działo!

ITDEV CONNECTIONS 2016

W niedzielę wróciłem z konferencji IT/Dev Connections 2016, która odbywała się w Las Vegas. Nie jest to event tak duży jak Ignite, zaledwie 1000-1200 uczestników, ale w tym przypadku to zaleta. Przez 4 dni odbywało się równolegle około 15-20 sesji prowadzonych przez MVP i niezależnych ekspertów, skupiając się na technologicznych szczegółach i praktycznych doświadczeniach wdrożeniowych, zamiast marketingowym pustosłowiu.

W ramach IT/Dev Connections można było obejrzeć sesje w następujących  ścieżkach:

• Cloud and Datacenter (42 sesje)
• Community (17 sesji)
• Data Platform & Business Intelligence (49 sesji)
• Development Platform, Tools and DevOps (49 sesji)
• Enterprise Collaboration (58 sesji)
• Enterprise Management, Mobility and Security (59 sesji)
• Solutions (7 sesji)

Już kilkukrotnie słyszałem dużo dobrego na temat tej konferencji i muszę przyznać, że nie zawiodłem się. Mniejsza powierzchnia centrum kongresowego hotelu Aria (w porównaniu z ośrodkami gdzie odbywały się konferencje TechEd czy Ignite) dała wiele okazji do spotkań z prelegentami i innymi uczestnikami konferencji. Często niestety wybór sesji był trudny, bo w tym samym czasie prowadzone były sesje zarówno z nowych funkcjonalności Windows Server 2016 (Nano, wirtualizacja, kontenery), zarządzaniu tożsamością jak rozwiązywaniu problemów w Exchange.

Grupa produktowa Exchange była reprezentowana przez kilku najbardziej znaczących specjalistów z Redmond, pod przywództwem Grega Taylora. Oczywiście grupa MVP w kategorii Exchange Server (a właściwie już od roku Office Servers & Services, ale związanych przede wszystkim z systemem Exchange) była liczna, jak widać na poniższym zdjęciu.

Na zdjęciu znaleźli się wszyscy MVP, uczestniczący w konferencji, stoją od lewej:

Tony Redmond, Paul Cunningham, Gareth Gudger, Jeff Guillet, Konrad Sagała, Gary Steere, Paul Robichaux, Jaap Wesselius, Michel de Rooij, Siegfried Jagott

Kucają od lewej:

Michael van Horenbeeck (VanHybrid), Andrew Higginbotham, Ingo Gegenwarth, J. Peter Bruzzese

Konferencja była zdecydowanie techniczna - poziom sesji 300 i 400, z minimalną ilością firm partnerskich, które prezentowały swoje produkty, jednak znalazła się tam polska firma CodeTwo, oferująca znane od dawna oprogramowanie do stopek w Exchange, teraz również w wersji dla Exchange Online oraz oraz narzędzia ułatwiające migrację i wykonywanie kopii zapasowych skrzynek Office 365.

LS File Transfer Agent Service zgłasza błąd 1034 po usunięciu serwera z topologii

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ć.

Naprawa statusu usług Exchange

Pół roku temu opublikowałem na blogu skrypt, który przywracał poprawny status wszystkich usług Exchange, wyłączonych przez niepoprawnie zakończoną aktualizację. Jednak nie byłem zadowolony z takiej postaci skryptu i nieco go poprawiłem. Zamiast wypisywać kolejne komendy zmiany statusu usług Exchange, nowa wersja skryptu pobiera listę usług oraz poprawny status usługi z pliku csv (dwie kolumny - SrvName i Mode) i następnie w pętli dla każdej z usług sprawdza, czy nie ma ona statusu "Disabled".

Ponieważ parametr filtrowania wyników oczekuje czystego stringu a nie zmiennej, więc dodatkowo tworzę zmienną, zawierającą definicję filtru dla konkretnego serwisu.

Jeżeli usługa ma tryb uruchomienia ustawiony na "Disabled", to skrypt zmienia ustawienia serwisu zgodnie z informacjami w drugiej kolumnie pliku csv. Taką wersję skryptu opublikowałem w galerii Technet. Skrypt należy uruchamiać w kontekście administratora (zmienia ustawienia usług systemowych), ale nie potrzebuje powłoki Exchange ponieważ działa tylko na poziomie WMI i serwisów.