Forefront UAG 2010 SP4 wydany

Wczoraj pojawił się kolejny, już czwarty Service Pack do UAG-a 2010, który oprócz usunięcia kilku problemów, dodaje wsparcie dla Windows 8.1 i Internet Explorera 11, w tym również możliwość konfiguracji połączeń z wbudowanego w Windows 8.1 klienta pocztowego Mail do Exchange Servera oraz wsparcie dla klienta RDC 8.1. Niestety instalacja jest jak zwykle skomplikowana. Poniżej krótka ścieżka kolejności instalacji UAG-a z SP4 od zera:

• Instalacja Forefront UAG z SP1. Szczegóły w artykule Installing Forefront UAG 2010.
• Instalacja Update 1 dla Forefront UAG SP1. Szczegóły w artykule Installing Update 1 for Forefront UAG SP1.
• Instalacja Forefront TMG SP2. Szczegóły w artykule Microsoft Forefront Threat Management Gateway (TMG) 2010 Service Pack 2.
• Instalacja Forefront UAG SP2. Szczegóły w artykule Installing SP2 for Forefront UAG 2010.
• Instalacja Forefront UAG SP3. Szczegóły w artykule Installing SP3 for Forefront UAG 2010.
• Instalacja Update 1 dla Forefront UAG SP3.
• Instalacja Forefront UAG SP4.

Jak na razie Release Notes nie zostały zaktualizowane, jednak na pewno za kilka dni dokumentacja produktu zostanie odświeżona.

Jak na razie, żeby nadążyć za zmianami w kolejnych numerach wersji UAG-a, dobrze jest skorzystać z artykułu na Technet Wiki, gdzie kolejne wersje są aktualizowane, poniżej kopia tej tabeli:

Build Number	KB Article ID	Comment
4.0.1101.0	n/a	Forefront Unified Access Gateway 2010 RTM
4.0.1101.052	2433585	Security Update MS10-089
4.0.1152.100	981323	Update 1
4.0.1152.110	981932	Update 1 Rollup 1
4.0.1152.150	2433584	Update 1+Security Update MS10-089
4.0.1269.200	2288900	Update 2
4.0.1269.250	2418933	Update 2+Security Update MS10-089
4.0.1575.10000	n/a	Service Pack 1 RC
4.0.1752.10000	2285712	Service Pack 1
4.0.1752.10020	2475733	Service Pack 1 Rollup 1
4.0.1752.10025	n/a	Service Pack 1 Rollup 2
4.0.1752.10073	2522485	Security Update MS11-079
4.0.1753.10076	2649261	Service Pack 1+Security Update MS12-026
4.0.1773.10100	2585140	Service Pack 1 Update 1
4.0.1773.10110	2647899	Service Pack 1 Update 1 Rollup 1
4.0.1773.10190	2649262	Service Pack 1 Update 1+Security Update MS12-026
4.0.1773.10220	n/a	Service Pack 1 Update 1 Rollup 2
4.0.2095.10000	2710791	Service Pack 2
4.0.3123.10000	2744025	Service Pack 3
4.0.3206.10100	2827350	Service Pack 3 Rollup 1
4.0.4083.10000	2861386	Service Pack 4

Stan komponentów serwerowych w Exchange 2013

Jedną z nowości w Exchange 2013 jest koncepcja stanu komponentów serwera (Server Component States), którą ciekawie opisano niedawno na blogu zespołu produktowego. Możemy również wyłączyć komponent w związku z jakimiś pracami serwisowymi, ale może to również zrobić sam system Exchange. Podstawowa kwestia, która może nas dotknąć w związku z tym jest możliwość wyłączenia komponentów przez setup Exchange przy instalacji pakietu poprawek CU. Na jednej z maszyn testowych sam ostatnio miałem okazję przetestować tą funkcjonalność. Po awarii instalatora na jednym z kroków konfiguracyjnych i ręcznym uruchomieniu serwisów Exchange się nie zgłaszał. Po weryfikacji stanu komponentów okazało się, że wszystkie są wyłączone:

Można oczywiście zdiagnozowaćzgłoszony przez setup błąd, powtórzyć setup i dobrowadzićaktualizację do poprawnego końca, ale można również spróbować włączyć ręcznie poszczególne komponenty:

Jak widać na powyższym rysunku, włączenie dwóch komponetów tak naprawdę powoduje uruchomienie dużo większej ilości powiązanych komponentów. Warto wiedzieć, że coś takiego jak komponenty serwera są dostępne do zarządzania i jak weryfikowaćich dostępność.

UPDATE

Przydatny skrypt do dokładniejszego weryfikowania stanu, zwłaszcza tych nieaktywnych komponentów, opublikował na swoim blogu Michael Van Horenbeeck. Wg. mnie bardzo przydatny – pokazuje jaki requestor wyłączył komponent, co jest bardzo przydatne, ponieważ musimy użyć tego samego requestora do przełączenia komponentu w stan Active:

Listopadowe poprawki do Exchange

Z pewnym opóźnieniem (kwartał skończył się przeszło miesiąc temu) Microsoft dzisiaj wydał trzeci pakiet poprawek do Exchange 2013 – CU3. Zgodnie z zapowiedziami zespołu produktowego, model serwisowania Exchange 2013 zakłada raz na kwartał wydanie zbiorczego pakietu poprawek, które zawierają pełne binaria Exchange, a ponadto łatki na problemy znalezione w poprzednim kwartale. CU2 zawierało kilka błędów, które wymagały cofnięcia pakietu i wydania go ponownie. Tym razem okres testów, także przy pomocy grupy MVP był znacznie intensywniejszy, co zaowocowało kilkoma dodatkowymi uzupełnieniami pakietu, ale i przedłużeniem okredu testowego. Cumulative Update 3 usuwa wiele usterek zgłaszanych przez użytkowników, szczególnie ważna dla klientów korzystających ze standardowych kopii zapasowych jest poprawka usuwająca błąd, mogący pojawiać się przy odtwarzaniu danych, opisana w artykule KB2888315. Cumulative Update 3 zawiera również sporą ilość usprawnień i rozszerzeń, które chociaż nie wprowadzają rewolucji, to jednak warto o nich wspomnieć:

• Usprawnienie przy dodawaniu członków do nowych i już istniejących grup z wykorzystaniem konsoli webowej Exchange Administration Console.
• Wsparcie dla Online RMS, nowej możliwości zbezpieczania poczty korporacyjnej (a nawet prywatnej) na firmowych serwerach Exchange.
• Rozszerzone możliwości audytowania działań administratora na serwerach Exchange (admin audit logging).
• Poprawiona współpraca z przeglądarką Internet Explorer 11/Windows 8.1 (dotychczas IE11 był rozpoznawany jako przeglądarka niekompatybilna z trybem OWA Premium).

Jednocześnie zespół produktowy zapowiedział, że kolejny pakiet poprawek (CU4) będzie wydany jako Exchange Server 2013 Service Pack 1.

Cumulative Update 3, podobnie jak CU2 rozszerza schemat Active Directory i ustawienia partycji konfiguracyjnej, co wymaga od administratorów dodatkowych kroków konfiguracyjnych i eskalacji uprawnień, zgodnie z zaleceniami dokumentacji TechNet. Podobnie jak przy instalacji poprzednich poprawek należy zweryfikować czy mamy zdefiniowane Windows PowerShell Script Execution Policy jako “Unrestricted” na serwerach Exchange. Jeżeli ustawienia naszych serwerów są inne, to należy postąpić zgodnie z zaleceniami artykułu KB981474.

Dokładny opis poprawek zawartych w CU3 znajduje się w artykule KB2892464., a pakiet można pobrać z tego miejsca. Należy pamiętać przy instalacji, że CU3 usuwa wszystkie binaria Exchange w trakcie instalacji, co uniemożliwia cofnięcie się w przypadku problemów instalacyjnych. Należy to uwzględnić przygotowując się do aktualizacji Exchange. Opcjonalnie można też zainstalować pakiet językowy UM.

W porównaniu do CU3 pakiet poprawek Update Rollup 3 dla Exchange 2010 SP3 nie jest tak rozbudowany, jednak również zawiera liczne poprawki do błędów zgłoszonych przez klientów, co ciekawe poprawki te nie dotyczą obszaru bezpieczeństwa Exchange. Szczegółowa lista usuniętych błędów znajduje się w artykule KB2891587. Na początku grudnia RU3 powinna być również dostępna przez Windows Update.

Windows – ile wynosi czas życia rekordów w DNS?

Ostatnio zmieniałem ustawienia DNS na pewnym serwerze i zauważyłem pewne rozbieżności w czasie życia rekordów DNS. Zweryfikowałem ten temat, przy okazji odświeżając sobie wiedzę dotyczącą ustawień DNS w różnych wersjach Windows. Tak naprawdę zmiany pomiędzy kolejnymi wersjami nie są duże. Pierwszym parametrem, jaki możemy ustawić, jest domyślny czas życia rekordu dla danej strefy DNS, ustawiając odpowiednią wartość w rekordzie opisującym strefę (SOA). Domyślnie jest to jedna godzina, co łatwo możemy zmienić z konsoli graficznej - HOW TO: Modify Time to Live on Domain Name System Records.

Jednakże ustawienie te, jak łatwo się przekonać weryfikując właściwości poszczególnych rekordów, dotyczy wyłącznie obiektów dodawanych statycznie przez administratora. Dla rekordów tworzonych dynamicznie wygląda to zupełnie inaczej - rekordy A i PTR rejestrowane przez usługę Net Logon (np. rekordy SRV usług udostępnianych przez kontrolery domeny) mają ustawiany czas życia (TTL) o wartości 10 minut. Rekordy rejestrowane przez usługę DHCP Client domyślnie mają TTL ustawiany na 15 minut. Rekordy tworzone przez usługę DNS Server service (w większości wypadków są to rekordy zgłaszane przez serwery/stacje robocze poprzez usługę DNS Client) mają domyślnie ustawiony TTL na 20 minut. I takich rekordów, w domenie ze stacjami roboczymi Windows 7/8 jest najwięcej. Oczywiście w większości wypadków takie ustawienia są wystarczające, jednak czasami chcemy zmienić domyślny czas dla niektórych hostów, np. dla wybranych serwerów. Można to zrobić poprzez klucz w rejestrze na wybranych hoście:

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Tcpip\Parameters\DefaultRegistrationTTL

Klucz jest typu REG_DWORD i domyślnie ma wartość 0x4B0 (1,200 sekund = 20 minut). Możemy to zmienić na dowolną wartość z zakresu: 0x0 - 0xFFFFFFFF sekund – np. 0xE10 (1 godzina), a nawet 0x15180 (24 godziny), choć jak dla mnie to już lekka przesada. Więcej ustawień modyfikujących parametry ustawień klienta DNS można znaleźć w artykule KB 246804.

Możemy to również zmienić poprzez GPO:

Wykorzystanie karmazynowego kanału do rozwiązywania problemów z Exchange 2013

Ale o co chodzi zapytacie? Sam byłem zaskoczony, kiedy po raz pierwszy spotkałem się z tym określeniem. Jednak pomimo nietypowej nazwy wygląda to całkiem przyjaźnie. Crimson channel event logging, to po prostu drugi obszar logów w systemie Windows – oprócz znanych od dawien dawna logów systemu Windows (System, Security i Application) od Windows 2008 można znaleźć w Event Viewerze kategorię logów Applications and Services, określane przez Microsoft właśnie jako ‘karmazynowy kanał’.

W Exchange 2013 obszar ten jest mocno rozbudowany, szczególnie w obszarze aktywnego monitorowania i dostępności usług (Managed Availability) – trochę informacji na ten temat niedawno publikowałem na tym blogu, ale MA to rozbudowany temat. Kilka artykułów, pokazujących jak wykorzystać tę funkcjonalność można znaleźć na blogu grupy produktowej, szczególnie polecam artykuły:

• http://blogs.technet.com/b/exchange/archive/2012/09/21/lessons-from-the-datacenter-managed-availability.aspx
• http://blogs.technet.com/b/exchange/archive/2013/07/16/managed-availability-monitors.aspx
• http://blogs.technet.com/b/exchange/archive/2013/06/13/what-did-managed-availability-just-do-to-this-service.aspx
• http://blogs.technet.com/b/exchange/archive/2013/08/13/customizing-managed-availability.aspx

Ogólnie logi aplikacyjne i serwisowe dzielą sie na cztery grupy - Admin, Operational, Analytic oraz Debug. Do rozwiązywania problemów szczególnie przydatne są logi operacyjne i administracyjne (jeżeli istnieją dla danej funkcjonalności), chociaż informacje w nich zawarte nie zawsze są prezentowane w sposób przejrzysty i zrozumiały. Na listopadowym spotkaniu PEPUG chciałbym nieco przybliżyć ten temat, serdecznie zapraszam na spotkanie. Teraz tylko sygnalizuję temat, ale mam nadzieję, że uda mi się znaleźć trochę czasu, żeby opisać kilka przykładowych scenariuszy diagnozowania problemów.

Poprawki ASP.Net dla Exchange 2013

Coś ostatnio dużo piszę o błędach, ale bynajmniej nie jest to złośliwe. Exchange 2013 używając intensywnie usług webowych do komunikacji z klientami stał sie nieco wrażliwy na błędy w ASP.Net 4.5, w którym niestety kilku takich błedów znaleziono. Dokumentacja do Exchange 2013 zaleca instalację poprawki, w zależności od wersji systemu operacyjnego – dla Windows Server 2008 R2, hotfix jest opisany w artykule KB2803754 i może być pobrany z tego odnośnika, używając Windows Server 2012 poprawka jest opisana w artykule KB2803755, a dostępna jest tutaj.

Dodatkowo po zainstalowaniu niezbędne jest ustawienie klucza rejestru

HKLM\Software\Microsoft\.NETFramework\DisableRetStructPinning=1 (REG_DWORD)

lub dodanie zmiennej środowiskowej systemu Windows COMPLUS_DisableRetStructPinning z wartością 1

Niestety,ostatnio się okazało, że w niektórych środowiskach Exchange 2013 restartuje się lub wyłącza usługa RPC Client Access Service, generując błąd 7031. Początkowo przetestowałem z sukcesem obejście problemu poprzez wyłączenie usługi Exchange Health Manager Service, jak opisano na blogu http://msexchangeguru.com/2013/05/22/rpc-client-access-restart.

Jednak w ostatnich dniach okazało się, że problem powoduje również ASP.Net 4.5, co Microsoft opisał w artukułach KB2862063 dla Windows Server 2008 R2 SP1 oraz KB286204 dla Windows Server 2012. Czekamy na udostępnienie publiczne poprawki. Na razie można je pobrać z tego miejsca.